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

[David Mazieres <[e-mail]>]

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.

> 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 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.

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.

David