W3C home > Mailing lists > Public > public-interledger@w3.org > June 2017

Re: Atomic payments

From: Dave Cohen <interledger@dave-cohen.com>
Date: Wed, 28 Jun 2017 19:22:48 -0700
Message-Id: <1498702968.1124322.1024796424.4FB2CC08@webmail.messagingengine.com>
To: public-interledger@w3.org
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?


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?
Received on Friday, 30 June 2017 07:52:31 UTC

This archive was generated by hypermail 2.3.1 : Friday, 30 June 2017 07:52:40 UTC