Re: [Ilc] Clarifications and thoughts purpose of ILC list

[Ben Laurie <[e-mail]>]

On 23 February 2017 at 18:35, David Mazieres
<[e-mail]> wrote:
> Ben Laurie <[e-mail]> writes:
>
>>> While obviously consensus mechanisms have been around for decades, one
>>> recent development has been the advent of so-called permissionless
>>> consensus mechanisms with open membership.  These mechanisms allow new
>>> types of system, for instance ones in which mutually distrustful parties
>>> with no pre-existing relationship can execute atomic transactions
>>> together.  If we abstract the Internet slightly (maybe pretending some
>>> centralized IANA-controled identifiers are public keys anyone could have
>>> unilaterally allocated), the Internet, too, starts to look like a
>>> permissionless system.  That's where this idea of "Internet-level"
>>> consensus originates.  Does it make sense to leverage the permissionless
>>> aspects of the Internet to implement some sort of permissionless
>>> consensus mechanism?  Should the IETF be undertaking efforts along these
>>> lines?  Could such efforts benefit existing IETF efforts or solve
>>> existing challenges?  If the answer to any of these questions is yes,
>>> then this mailing list is the place to start throwing out ideas...
>>
>> Sorry to be a bit late to the party here, but I feel this narrow
>> approach is not for the best, for various reasons.
>>
>> a) IMO, it is still not proven that permissionless consensus with open
>> membership is actually possible - as I've argued before, the examples
>> we have now actually rest on an underlying permissioned consensus with
>> somewhat closed membership (e.g. the major mining pools or the code
>> developers), and claims that the permissionless versions are actually
>> not subvertible rely on somewhat weak economic arguments.
>
> Well, there's at least one existence proof, which is the SCP protocol we
> use at Stellar.  SCP changes the question slightly from whether the
> system is subvertible to who is being subverted, because it depends on
> whom people trust.  E.g., if you trust TurkTrust and I trust the
> conjunction of the ACLU and Google, you might get subverted because
> TurkTrust has been known to issue bad certificates.  On the other hand,
> even if Google somehow gets compromised, that won't subvert my view of
> the world so long as the ACLU remains honest.

OK, so here's where I get to confess that I don't understand Stellar,
and, worse, I don't know anyone who does.

Is there an idiot's guide somewhere?

That said, the properties you claim are also trivially obtainable with
a CT-like system, so I totally buy it can be done. But I don't see how
this corresponds to the popular notion of "permissionless"? Not that I
actually care, btw.

>
>> b) CT, for example, needs an internet-wide consensus, in effect, but
>> is not permissionless. At least some variants of the things you
>> mention above that would benefit from consensus are also not
>> permissionless (e.g. auditable Linux distros).
>
> Well, maybe SCP shows that permissionless is not a binary setting.  It's
> important that the ACLU be able to participate in consensus without any
> existing participant's permission, and that people have the option to
> depend on the ACLU for safety should they so desire.  However, unless
> and until people do decide to wait for the ACLU for consensus, the ACLU
> will not have any power.
>
> I think this model is very Internet-like, in that it promotes "tussle
> spaces" that resolve issues by market forces.  Though ultimately I'd
> defer to you on what is and is not workable for CT, it seems to me that
> SCP's model would in fact be good for some future CT 2.0, as well as
> other transparency efforts such as software distribution.  In
> particular, with CT you have a bunch of CAs, and even though not
> everyone agrees on who is and is not a valid CA, there's significant
> transitive overlap.  Moreover, independent third parties should be able
> to audit the system, with end users able to depend on these parties.
> That way, even if some extremely powerful attacker subverts all the
> major players, people can survive by additionally depending on
> independent players (e.g., now to fool me it's not enough to subvert
> Google, you also have to subvert the ACLU).

I totally agree with all of this, but have two comments:

a) it seems utterly disconnected with the standard view of
"permissionless", so I think real care is needed with the charter.

b) whilst I think everyone should choose who they trust, in practice
this is mostly totally unusable. The ability to do it is not a system
problem: you have an answer in Stellar, I have one in CT/Trillian.
Others exist, I am sure. The problem is usability. Who chooses the CAs
you trust, for example? Not you (for most values of "you"), that's for
sure.

>
>> I don't object to those who believe in permissionless trying to work
>> out how to do that, but those of us who don't also need these
>> protocols and I think the IETF should address our needs, too.
>
> Well, two things.  First, thanks for joining the conversation, because
> of course any IETF-based consensus effort should address your needs.  At
> the very least, an IETF-sanctioned "permissionless" consensus protocol
> should probably support a degenerate "permissioned" configuration that
> can serve CT's needs (or those of some future CT 2.0).
>
> Second, the state of the art in decentralized Byzantine agreement may be
> more advanced than a lot of IETF attendees are aware.  Hence, please
> keep an open mind about what is and is not already possible.  Stellar's
> payment network is an existence proof of a production system using this
> technology today.  Since deploying Stellar, several people have people
> approached us with other compelling applications, including package
> management and end-to-end email encryption.

Of course, this is exactly what Trillian
(https://github.com/google/trillian) is all about.

> CT is perhaps a bit different in that it has an unusual requirement to
> "fail open"--e.g., I don't want to stop seeing new web sites just
> because the ACLU's server is down.  That could mean my intuition is not
> right about what is and is not workable for a hypothetical CT 2.0.
> However, there's a good possibility that if, either on this list or in
> Chicago, we hash out a set of requirements for an ideal CT 2.0 consensus
> mechanism, we will find ourselves a lot closer to the ideal than you
> might think.

I dunno, I'm feeling pretty positive right now. :-)