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

[David Mazieres <[e-mail]>]

Tony Arcieri <[e-mail]> writes:

> Like many things in this space, "Satoshi consensus" is an ill-defined
> buzzword. In part I think it means incorporating programs into the
> consensus decision, which seems like fairly novel and interesting work to
> me (and somewhat similar to e.g. Trillian's "personalities"). In this
> space, yes incorporating consensus programs into (P)BFT-like schemes such
> as Tendermint is interesting.

Okay, then by that definition, "Satoshi consensus" is only one possible
approach among several to realizing Internet-level consensus.

> However, above I was using it specifically to refer to the proof-of-work
> scheme for consensus. "CP" versus "AP" of course both assume "P", a
> property Bitcoin (and systems using a similar proof-of-work consensus
> model) do not have. Under a network partition in Bitcoin, the system will
> both make progress and be available for reading (where CP systems will fail
> closed if they can't reach a quorum). When the partition is healed,
> acknowledge writes are lost and data is clobbered. Systems which truly
> uphold "CP" or "AP" semantics do not clobber data this way.

I agree about CP, but not AP.  AP systems are not safe, and hence will
clobber data.

Perhaps CAP is not the best way to categorize these systems, though.  It
may be better just to assume an asynchronous communication model (which
subsumes temporary partitions as equivalent to slow nodes).  Then we can
just talk about safety (agreement + validity), liveness (termination),
and fault tolerance.

> This sort of split-brain behavior can be exploited by attackers who are
> able to arbitrarily create network partitions. Eclipse attacks are a common
> example.

Right, so basically you are saying any Internet-level consensus
mechanism should guarantee safety even in an asynchronous communication
model where you can't distinguish slow from failed nodes.  I agree,
personally.  However, reasonable people might push for greater
availability.  It would be interesting to see if list members have
"rough consensus" (non-technical meaning) on this point, or
alternatively if makes sense to layer a less safe but more available
"short-term" system on top of one that guarantees safety for long-term
events (e.g., for certificates issued over a week ago).  We may want to
revisit this question down the line after discussing more applications.

David