Re: Ripple

Andrew Miller <amiller@cs.umd.edu<amiller@cs.umd.edu?Subject=Re%3A%20Ripple&In-Reply-To=%3CCAF7tpEz_WSvJ_DoD9qRyxd%2BYt0nELFqW6WjuettMKVY12WO6BA%40mail.gmail.com%3E&References=%3CCAF7tpEz_WSvJ_DoD9qRyxd%2BYt0nELFqW6WjuettMKVY12WO6BA%40mail.gmail.com%3E>>
wrote:

3. Ripple, on the other hand, takes yet another approach. There's no
> global administrator, but nor is there a well-understood public
> competition. Instead, individual users are supposed to configure their
> clients to identify particular servers they have determined they
> trust. Here's where it gets really murky, and I can't figure out any
> set of assumptions that actually lead to robust functioning of the
> network. What if users entirely disagree with which servers they
> trust? Are they on two different networks or the same one? If an
> individual doesn't do their due diligence, and carelessly approves bad
> servers, are they individually affected or does it affect the overall
> network? I really wish more people were looking into this rather than
> ignoring it, because I suspect it's not sound (although I haven't come
> up with a super clear explanation why not), and if the underlying
> assumptions aren't sound then does it matter if the frontend UI is
> great?
>

Users can entirely disagree on which servers they trust. That won't put
them on two different networks unless there is no indirect overlap. One
user, for example, could choose only to trust Bitstamp if they want. And
another user can choose only to trust Ripple Labs. If you assume both
Bitstamp and Ripple Labs are competently administered, they will always
agree with other, and thus the two users will always agree with each other
as well. (Not that I'm suggesting anyone do this. I'm just showing that
direct overlap is not required. The majority of entities you trust just
need to be competent.)

If a server operator chooses bad servers, they negatively impact themselves
and anyone who has decided to trust them. But so long as you don't have a
supermajority of conspiring or broken servers on your trust list, the worst
thing that will happen is that you will deny yourself service.



> Unfortunately the only set of assumptions I can think of that lead to
> this actually working is where every one essentially picks the same
> default list, and the servers on that list are actually trustworthy.
> This is the "centralized" option, where the default list determines
> who participates, and no user has any incentive to deviate from the
> default list, either by adding some newcomer they individually trust
> or by removing default servers they don't trust.


Everyone using the same list obviously works just fine. However,
surprisingly little overlap is needed and the network is still robust. For
example, we simulated with 1,000 validators, each picking 32 of the other
nodes randomly to use as a trust list. There were no problems whatsoever.
We then tried with each picking 12 other nodes randomly. Again, no problems
whatsoever. All these topologies result in everyone trying to come to an
agreement with everyone else.

The algorithm is surprisingly robust. One key reason is that if there's
absolutely no reason a transaction shouldn't be included in the consensus
set, every honest validator will choose to include it. If there's any
reason it shouldn't be included, then there's no harm in excluding it,
since every honest validator will just vote it into the next consensus set
anyway. So you can opt to exclude transactions with a very low threshold to
preserve agreement.

Every server operator values correctness as the highest priority. Money
must not be teleported from one account to another. Transactions must be
properly signed. But given that, every legitimate server and server
operator values agreement as the next highest priority.

Our plan is to get a few organizations to choose validators using an open
process with clearly defined criteria. The server software will ship, by
default, with several of those organizations configured. It will pull their
current list, impose local policy (to ensure variation in jurisdiction,
organization type, and the like) and choose validators with a probability
based on, among other things, how many of those lists include them. This
will ensure human decision making is involved, the process remains open,
new participants can get in, and there are no central authorities. (Just
organizations people choose to trust to save themselves effort so long as
the decision continues to make sense). See
https://ripple.com/forum/viewtopic.php?f=1&t=3881&p=19414#p19420

David Schwartz