Re: Atomic payments

> 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?
>