Re: Ripple

I think everything *except* the consensus algorithm is terrific. The
consensus algorithm though, in my opinion, is completely nonsensical
and no one seems to be allocating any attention to it. The problem is
not with the algorithm itself, but with the assumptions about what
parties are chosen to participate.

1. In ordinary distributed systems (a topic with 30 years of academic
research, the kind involving Byzantine consensus and Chubby locks and
fault tolerant databases etc.,) there is a global system administrator
who simply designates N servers to participate in the consensus
protocol.

2. But this doesn't work for public/anonymous networks. So Bitcoin is
based on a very novel alternative, where the participants are
self-selected, their input is weighted according to the "hashpower"
they invest, and participation is rewarded with Bitcoins which
encourages lots of individuals to participate. This is cool!

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?

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.

https://ripple.com/wiki/Consensus#Not_colluding
"""
In real world terms, people should select a UNL list of 1,000
validators. They should choose 200 validators from 5 different
continents. They should choose a mix of validators with different
interests: merchants, financial firms, non-profits, political parties,
religious groups, etc... By choosing a large number of reputable
parties who are unlikely to lie or be coerced as a group and that are
unlikely to collude to defraud us we can be assured the ledger is
accurate.

In practice, most people will use the default UNL supplied by their
client. But, the software will enable them to choose specific
validators if they'd like.
"""



On Thu, Nov 14, 2013 at 3:56 PM, Melvin Carvalho
<melvincarvalho@gmail.com> wrote:
>
>
>
> On 14 November 2013 21:01, Margaux <margaux.r.a@gmail.com> wrote:
>>
>> Hi,
>>
>> I was wondering what people's thoughts were on Ripple. Here is video and
>> slides from the developer conference in Las Vegas
>> https://ripple.com/blog/ripple-developer-conference-2013-replay/
>>
>> My interest in it is regarding the protocol for currency exchange.
>
>
> Am a fan of both the original protocol, and the ripple.com implementation.
> The server has just become open source so many people are giving it a try
> now.  I've run it and I have to say I was impressed.
>
> There are many innovations in ripple.  Things I like are : ability to give
> credit lines, ability to issue IOUs, ability to create new currency, the
> consensus algorithm.
>
> I've been intending to translate ripple core concepts to the web, so that
> any of the features can be used in a modular way.  I'm doing bitcoin fist
> tho, and expect to have most of ripple done Q1 or Q2 next year.
>
>>
>>
>> Thanks!
>> Margaux
>
>



-- 
Andrew Miller

Received on Friday, 15 November 2013 11:52:49 UTC