Re: Atomic payments

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?

Received on Friday, 30 June 2017 07:52:31 UTC