Re: Atomic payments

Thanks Stefan!  I agree that it makes sense to define the protocol in
general, flexible terms.  I'm glad that doesn't mean that you aren't
focused on enabling atomic payments wherever possible.

On Thu, Jun 29, 2017 at 6:46 AM, Stefan Thomas <stefan@ripple.com> wrote:

> > Why have we seemingly abandoned the ideal of atomic payments?
>
> Great question. I would say that we haven't abandoned the ideal insofar as
> we still want any many payments as possible to be atomic as much as
> possible. However, I would argue that we cannot assume that atomic mode
> will always be available.
>
> In atomic mode, all participants along the payment chain have to have full
> unconditional trust in the notary. Since the set of all possible paths
> contains all possible combinations of participants, that means that in
> order to be able to use atomic mode all of the time, there must be at least
> one notary that is trusted by all people in the world. Otherwise, we may
> run into situations where a liquidity path is available, but no valid
> notary can be selected.
>
> It is possible to use multiple notaries in a payment, but that actually
> doesn't make the trust problem easier and arguably makes it harder. If we
> assume f=1 (i.e. one notary may fail), then we now need all participants to
> trust notaries such that none of the notaries they trust would ever collude
> with any other notary they trust. Granted, that's a weaker requirement, but
> now we need at least four notaries that the entire world trusts (in this
> weaker sense.)
>
> In practice, this is achievable. HTTPS relies on CAs such that all people
> in the world must trust one CA for them to access a website that has chosen
> to use that CA. So, it's not that it's fundamentally impossible to
> standardize ILP to always require atomic mode and just have a group of
> notaries (like CAs in TLS) that everyone trusts.
>
> But, I think we can do better.
>
> It is possible to use atomic mode in the context of a universal mode
> payment. Any number of participants can decide to make the transfer between
> them subsidiary to some notary. If all the participants do that,
> congratulations, the payment is fully atomic.
>
> So the idea is to default to universal mode and use atomic where possible.
> Ripple is currently building a proprietary network for banks that uses
> atomic mode internally and universal mode externally. (This is comparable
> to autonomous systems (ASes) on the internet, which may use different
> routing protocols or peering policies internally.) And we are very much
> thinking about ways to negotiate with other networks for agreement
> on notaries, so that connectors between the networks don't have settlement
> risk.
>
> Another example is a technology we call XRP Atomic Mode Autodetection
> (XAMA). The idea is to allow participants in a payment to detect that XRP
> is used as one of the hops and then defer to the outcome of the XRP
> transaction instead of using their own timeouts, effectively making the XRP
> Ledger a de-facto notary. This can be generalized as a defer-right and
> defer-left behavior. Any neighboring pair of participants (using
> terminology from the white paper - a participant is a sender, receiver or
> connector) can - by mutual agreement - decide to defer the outcome of their
> transfer to whatever the outcome on the ledger right of them or the ledger
> left of them.
>
> Often you will have payment chains where you start on a constrained device
> or some kind subsidiary ledger. And often in those cases, it will make
> sense to defer to the superior ledger. It's certainly conceivable that at
> some point in the future all smaller ledgers on the sending side will
> defer-right and all smaller ledgers on the receiving side will defer-left.
> If the larger networks in the center have peering agreements like the ones
> we are planning to have for RippleNet, that means that many or most
> payments may well end up being fully atomic.
>
> In summary, don't be fooled by our current focus on universal mode. We
> want the general ILP protocol to be as simple as possible, yet still
> universal. Universal mode gives us that while leaving the door open for
> anyone to upgrade to atomic mode in their local context if they so desire.
>
> It isn't an open-and-shut case. There are certainly benefits in pushing
> everyone to use atomic from the start and perhaps even running the initial
> set of notaries that everyone has to trust. But I believe in the simplicity
> and extensibility of our current approach.
> -
>
> On Wed, Jun 28, 2017 at 11:44 AM Ryan Fugger <arv@ryanfugger.com> wrote:
>
>> It seems to me that streaming payments allows participants to trade off
>> execution speed for lower risk, with the potential for a bit of messiness
>> when payment "packets" get stalled/lost.  Atomic payments seem to be ideal
>> for both speed and risk, though...  How sure are we that atomic payments
>> aren't realistic for a significant portion of real-world ILP payments?
>> Would it be more useful to try to make atomic mode work for more cases
>> rather than optimizing non-atomic modes at this point?
>>
>> I do think streaming payments is cool in how it mimics TCP/IP, and how
>> things like flow control could be implemented for payment packets, but it
>> worries me that transferring value is fundamentally different than
>> transferring data, in that you can't just resend the value if it gets lost
>> on the way...
>>
>> Why have we seemingly abandoned the ideal of atomic payments?
>>
>