Verification passed (in fact, new_challenge was identical). BTW, would be nice if `compute` had a flag to only take entropy from STDIN, so that we can check for any differences in the response.
On Tue, Dec 5, 2017 at 12:48 PM Devrandom <c1.devran...@niftybox.net> wrote: > Thank you. Will do the verification shortly. > > Also, I've updated the instructions in > https://github.com/devrandom/powersoftau/wiki/Trusted-build-instructions-via-mrustc > to > use the cargo built by mrustc. This required vendoring of the dependencies. > > > On Tue, Dec 5, 2017 at 11:24 AM Sean Bowe <s...@z.cash> wrote: > >> Excellent work! :) >> >> new, compute, verify_transform is a good demonstration. I would >> verify_transform with a binary compiled with the normal Rust compiler >> to double-check. >> >> Sean >> >> On Tue, Dec 5, 2017 at 11:59 AM, Devrandom <c1.devran...@niftybox.net> >> wrote: >> > Hi all, >> > >> > I was able to build rustc completely from sources. This means no >> network >> > access during the build and without any Rust distributed binaries. >> > >> > The steps are here: >> > >> > >> https://github.com/devrandom/powersoftau/wiki/Trusted-build-instructions-via-mrustc >> > >> > I'm still looking into building a cargo binary that supports TLS, to >> > eliminate the need to download it for building powersoftau itself. >> Worst >> > case we can use a shell script. >> > >> > Would like to merge https://github.com/ebfull/pairing/pull/72 so that >> we >> > don't have to maintain a separate patch for Rust 1.19 compatibility. >> > >> > Sean, what is the best method of validating that the generated binary >> works >> > correctly? Just use "new", then "compute" and then "verify_transform"? >> > >> > Also, I found that the generated binary is *very* different from the one >> > generated by the downloadable Rust compiler. This is somewhat >> worrisome, >> > although it doesn't affect us if we use the mrustc path. Will spend a >> bit >> > more time to get to the bottom of it. >> > >> >
