It's not a showstopper at all. :) I'm just very interested in determinism because it massively reduces the need for participants to source dependencies correctly and safely.
Sean On Sun, Jan 28, 2018 at 11:23 AM, Devrandom <c1.devran...@niftybox.net> wrote: > Very happy to hear about the go implementation for a couple of reasons: > > - this gives us another path to trusted binaries from pure source + gcc > - this may work well on ARM64, which gives us another architecture - one > that doesn't have a management engine (in contrast, mrustc currently only > works on x86) > > It would be good to look into how distributions compile their go binaries - > whether they use the latest version of the toolchain, or they bootstrap from > golang 1.4 (which only depends on gcc). If they use the latest, it would be > good to have people compile their own from source. > > About the mrustc work that I've done - I don't think the lack of determinism > is a showstopper. It just means that contributors have to compile from > source, which is time consuming. Perhaps there was some miscommunication > about that? > > > On Sun, Jan 28, 2018 at 5:12 AM Sean Bowe via zapps-wg > <zapps...@lists.z.cash.foundation> wrote: >> >> Great work on this. I wonder if this implementation will be a better >> foundation for fully-deterministic and trustworthy builds? I am >> disappointed that devrandom's efforts were stymied by non-determinism >> in the Rust compiler. :( >> >> Sean >> >> On Sat, Jan 27, 2018 at 12:30 PM, Filippo Valsorda via zapps-wg >> <zapps...@lists.z.cash.foundation> wrote: >> > Hello folks, >> > >> > https://github.com/FiloSottile/powersoftau is a fully independent >> > implementation of Powers of Tau. It is written in Go, shares no code with >> > the main Rust implementation, and uses the RELIC library for BLS12-381. >> > >> > I used it for my contribution, but for it to be truly valuable to the >> > security of the MPC ceremony more people need to run it, including in more >> > secure settings than my laptop. >> > >> > The README includes build instructions. If there are any problems feel >> > free to open an issue on GitHub or email me. >> > >> > To enable people to run both implementations there's a -next option to >> > generate the next challenge file while computing the response. This is much >> > faster than running verify_transform as it doesn't do verification and it >> > doesn't have to decompress points. >> > >> > You should assume that secret material will be left in memory, and >> > protect against side channels, just like with the Rust implementation. >> > >> > _o/
