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