- From: Jeffrey Cliff <jeffrey.cliff@gmail.com>
- Date: Fri, 15 Nov 2013 13:32:19 -0600
- To: Kumar McMillan <kmcmillan@mozilla.com>
- Cc: Web Payments CG <public-webpayments@w3.org>, Melvin Carvalho <melvincarvalho@gmail.com>, Andrew Miller <amiller@cs.umd.edu>, Margaux <margaux.r.a@gmail.com>
- Message-ID: <CAAR2Wu_kx84sJ3WcytRLmpCM3Dmn-kuQF2Czkm-KRqkv+GMH5w@mail.gmail.com>
If not for the incentive of xrp we would still be using villages as a primary system or perhaps multiswap or something. It is only an advantage to the extent that ripple labs has given the world a valuable system. It will be years before a competing system would have been developed. We are all ahead for their doing so. Le 2013-11-15 13:49, "Kumar McMillan" <kmcmillan@mozilla.com> a écrit : > > On Nov 14, 2013, at 3:30 PM, Andrew Miller <amiller@cs.umd.edu> wrote: > > > 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. > > """ > > > > I agree. Ripple's model seems to be too centralized. It's distributed not > decentralized. Also, as I understand it, Ripple is reserving some currency > for itself which seems to give them (as a corporate entity) an unfair > advantage. > > > > > > > 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.comimplementation. > >> 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 19:32:47 UTC