Re: Ripple

On 17 November 2013 22:27, Fabio Barone <holon.earth@gmail.com> wrote:

> I should do this as a homework, I apologize,
> but I'm currently pretty busy.
>
> Would someone be so kind and answering these questions about Ripple:
>  - Is the code open source?
>

Yes


> - Is the protocol they use openly documented,
>   as openly as bitcoin is?
>

I can only answer this superficially as I've not written a web ripple
implementation (yet)

But it seems to be yes: https://ripple.com/wiki/

You only ever know after you've drilled down into every last detail ...
something I plan to do next year ...


>
> thanks
>
>
> 2013/11/17 Manu Sporny <msporny@digitalbazaar.com>
>
>> On 11/14/2013 04:30 PM, Andrew Miller wrote:
>>
>>> 2. But this doesn't work for public/anonymous networks.
>>>
>>
>> Why doesn't it work for public/anonymous networks? Link? This is Web of
>> Trust stuff we're talking about, isn't it (chained trust metrics)?
>>
>>
>>  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.
>>>
>>
>> Isn't this a good thing? If you allow anyone to pick who they trust, you
>> force cooperation in the system, don't you? The idea being that for the
>> system to be useful, people need to coordinate and thus won't pick
>> participants with whom they entirely disagree with.
>>
>>
>>  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?
>>>
>>
>> Why would someone deliberately do this? If you have to pick from 32
>> servers, why would you pick from 32 servers that are in a completely
>> different trust set? It would be incredibly difficult to do that in a
>> dependency chain based system, wouldn't it?
>>
>>
>>  Are they on two different networks or the same one?
>>>
>>
>> No idea.
>>
>>
>>  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'd expect that in the worst case, the overall network suffers. However,
>> the likelihood of this is in the 51% attack against the Bitcoin network
>> category, isn't it?
>>
>>
>>  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?
>>>
>>
>> Well, yeah, if the algorithm is broken then no UI in the world is going
>> to save it. However, I don't think you've explained quite why Ripple's
>> consensus algorithm is broken. Why is allowing individuals to pick whom
>> they trust a bad thing (when the number of servers is large enough)?
>>
>>
>>  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.
>>>
>>
>> I think the problem surfaces when a group of servers create a trust set
>> that has no intersection with another set of servers. With that said,
>> why would anyone do this? What's the attack?
>>
>>
>>  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.
>>>
>>
>> I thought that only a subset of the list needs to be trusted for Ripple
>> to function, and all trust sets that all servers choose have to overlap
>> by at least a small degree. Is that not true?
>>
>>
>> -- manu
>>
>> --
>> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
>> Founder/CEO - Digital Bazaar, Inc.
>> blog: Meritora - Web payments commercial launch
>> http://blog.meritora.com/launch/
>>
>>
>
>