Re: Ripple

Thanks,

RE: it has an order book and the market determines the price

How exactly?  And is the order book and associated process documented
somewhere? I'd love to see the UML sequence or activity diagram, for
example, but text will do.

Is the general user experience that of a price-maker or price-taker? A
currency "price maker" is asked to bid. A currency "price taker" is shown a
rate as a fait-accompli.  And does the user make or take the intermediate
XRP rate, or the destination currency rate?  (i.e. If Fred pays CAD to a
vendor who wants to receive USD, he'd want to make or take the CAD-USD
rate. The CAD-XRP then the XRP-USD rates would be invisible and of no
concern to him.)

Joseph



On Sun, Nov 17, 2013 at 5:26 PM, Melvin Carvalho
<melvincarvalho@gmail.com>wrote:

>
>
>
> On 17 November 2013 23:24, Joseph Potvin <jpotvin@opman.ca> wrote:
>
>> Melvin, Can you point to the specific documentation about how Ripple
>> determines XRP inter-currency spot exchange rates with all the central bank
>> currencies,and for BTC? And is there a documented policy for choosing the
>> official source of exchange rate data for any other present or future alt
>> crypto currency out there would be added to the Ripple portfolio of
>> currencies?
>>
>
> AFIAK it doesnt use a spot rate, it has an order book and the market
> determines the price.
>
>
>>
>> Tx,
>>
>> Joseph Potvin
>>
>>
>>
>> On Sun, Nov 17, 2013 at 4:32 PM, Melvin Carvalho <
>> melvincarvalho@gmail.com> wrote:
>>
>>>
>>>
>>>
>>> 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/
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>> <http://goo.gl/Ssp56>
>>
>
>

Received on Sunday, 17 November 2013 23:25:27 UTC