[zapps-wg] Cut-off date for Powers of Tau Contributions

[Andrew Miller]

It sounds like an efficient way to dispense with the suggestions Devrandom
raised are to:
1. Do a round with the deterministic Go build, explicitly saving the binary
for posthoc analysis, and ideally running it on a non x86 architecture if
anyone has one...
2. Do a round with mrustc
What would it take to get a concrete plan to include those?

On Fri, Mar 9, 2018 at 2:17 PM, Sean Bowe <sean at z.cash> wrote:

> As far as security goes, we've successfully guarded against all but
> the most elaborate and unrealistic attack scenarios. The remaining
> threats require some combinatorial explosion of individually
> sophisticated attacks or breakthroughs, like stealthy backdoors in the
> Rust compiler and still for many participants to be colluding in
> secret, somehow without leaving evidence behind.
>
> We don't need an absolutely perfect ceremony to get strong privacy
> guarantees, we get that already even with a totally compromised
> ceremony. We *could* continue to invest time and resources for many
> more months or years in order to make us marginally more resistant to
> these absurd attack scenarios, but by the time we'd be finished with
> the ceremony we'll probably have better proving systems available
> anyway. It's silly to let privacy languish in the meantime.
>
> I think we did the best with the time we had, but if you disagree,
> remember that all of this can be extended and improved by anyone, even
> after this ceremony is done!
>
> Sean
>
> On Fri, Mar 9, 2018 at 11:06 AM, Peter Todd <pete at petertodd.org> wrote:
> > On Fri, Mar 09, 2018 at 04:49:37PM +0000, Devrandom wrote:
> >> Hi all,
> >>
> >> I have some concerns about the lack of diversity of contributions:
> >>
> >> - most (all?) of the contributions used a distributed Rust toolchain,
> which
> >> suffers from the "trusting-trust" issue since they are self-compiled.  I
> >> don't think I've seen any contributions using the mrustc build path.
> >> - there were very few contributions (two?) using the golang
> implementation
> >> - no attempt has been made to replicate the deterministic golang build
> >> - people did not capture the binary they used, so we can't do forensics
> in
> >> case of future questions
> >> - there were no contributions using alternative processor architectures
> >> (e.g. ARM64).  I believe this is possible using the golang
> implementation.
> >> - there was a lot of focus on destroying toxic waste and not enough on
> the
> >> trustworthiness of the tools
> >
> > I agree with all these points, particularly the latter: we should be
> focused on
> > genuine security, not flashy marketing stunts. (indeed, I regret the way
> my own
> > participation was marketted the last time around)
> >
> > --
> > https://petertodd.org 'peter'[:-1]@petertodd.org
>



-- 
Andrew Miller
University of Illinois at Urbana-Champaign