Atomic payments

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 Wednesday, 28 June 2017 18:43:34 UTC