Re: Atomic payments

In my experience to date, it's most often people familiar with existing
payment systems that want atomic mode. I think that in time we'll find that
complete end to end atomicity comes at a cost that is not justified for a
lot of payments.

At the end of the day the cost of a payment is mostly about covering the
various risks involved. There are operational costs that must be covered
but those also often stem from some kind of risk-mitigation operations. The
cost to move the bytes from A to B to make a payment is certainly nowhere
near the 1% and up that most payments cost to send.

In a world where ILP is a foundational layer for the mechanics of moving
value, risk will likely be dealt with at higher layers in the stack so that
it's still possible for someone to send a payment at almost zero cost if
they accept the associated risks.

This is better than today where your choice of network determines your
costs. Instead you'd have a network of networks with very low costs and
only the protocol providing any guarantees but you can pick service
providers that provide insurance etc at a fee.


On 29 June 2017 at 04:22, Dave Cohen <interledger@dave-cohen.com> wrote:

> Ryan makes good points here.  And he concludes with a good question.
>
> Streaming payments may create a perverse incentive for liquidity
> providers.  If they can detect a streaming payment in progress, they could
> profit from widening a spread for the duration of the payment.  (It might
> be hard to predict that duration, or detect in the first place.)
>
> If the corridor has sufficient competitive liquidity, widening a spread
> might not be effective.  However, that condition (strong liquidity)
> supports atomic payments.
>
> As the sender of a payment, how would I decide between a known total cost
> vs a cost that might be higher (or lower) over time?
>
> -Dave
>
>
> On Wed, Jun 28, 2017, at 11:42 AM, Ryan Fugger 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?
>
>
>