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
> 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. :(
> 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/