Re: Streaming payments for risk mitigation in Interledger

Some thoughts.


First of all, I don't agree with the involvement of settlement risk:

 > Settlement risk in unconditional payment channels. If I use an 
unconditional payment channel plugin like ilp-plugin-bitcoin-paychan or 
ilp-plugin-xrp-paychan, I have to trust my peer for the amount of money 
in flight.

In payment channels, the settlement risk is by definition equal to the 
limits in both directions of the channel. Whether the channel balances 
moves in a direction in big chunks or in slow increments changes little. 
Upon creation of the contract, both parties limited the settlement risk 
to the amount they are comfortable with.

That doesn't mean that risk is not an important driver for streaming 
payments. Personally I think that next to the fulfillment risk you 
described, the biggest risk is for the sender to have a payment that 
gets stuck. Some paths might have a worst-case timeout of hours. A user 
trying to make a purchase should not have to way for that single payment 
to be refunded when the fulfillment phase fails. If he tries again, he 
risks spending the money twice. With streaming payments, in the case 
that one or some chunks get lost, the user has the choice to retry only 
those stalled payments, only risking to double pay a few small chunks.


Further, I wonder why you made this calculation as such:

 > The overall speed of streaming payments is the payment amount times 
the latency (i.e. time between preparation and fulfillment on a given 
link) divided by the bandwidth (i.e. max amount in-flight).

This means that payments are sent sequentially. Is that required? I 
think most ledgers allow for multiple concurrent escrows and the user 
can use several different paths in the case some connects don't support 
concurrent escrows. In the case where all chunks are submitted in 
parallel, the total latency is equal to the latency of the slowest link.

 From a risk point of view that is quite similar. Even though your graph 
seems to suggest that with sequential payments, you have a max risk of 
one chunk at the time, that doesn't really hold when all the chunks are 
part of one payment. When halfway some chunks fail, you still risk all 
the previously successfully sent chunks when you make the decision to 
abort or continue. So even though chunks are sent sequentially, I 
consider the chances low that a user would decide to abort instead of 
retrying a single or a low amount of failed chunks.

As such, it makes sense to at least add some level of concurrency to the 
mechanic, fiercely increasing throughput ;)


I'm looking forward to the time when "streaming payment" fully live up 
to the name and VLC automatically makes micropayments to Netflix to 
stream the next minute from the TV show that I'm watching. (Even though 
that's technically not a streaming payment.)


Cheers

Steven



On 23-06-17 02:51, Stefan Thomas wrote:
> Apologies for the subject line, it's a mouthful. But once you 
> understand the terminology, it's actually a pretty simple (some would 
> say trivial) observation.
>
> *Streaming Payments*
>
> A streaming payment is a single large payment (e.g. 100$) split into 
> many smaller payments (e.g. 10¢). So far, our thought has been that 
> there is one main upside: Small payments consume less liquidity 
> because the individual payments can take multiple paths and are also 
> spread out over time.
>
> *Pro and Con*
>
> And there is a downside: If I use streaming payments for example to 
> pay an invoice, I might pay 50% of an invoice and then stop. We 
> haven't really been able to come up with a scenario where that would 
> be a serious problem, but it certainly seems ... awkward.
>
> *The Real Benefit is Risk Mitigation*
>
> However, when put in the context of managing risk in Interledger, 
> streaming payments suddenly seem *very* attractive.
>
> There are two forms of risks that we're concerned about:
>
> 1. Fulfillment risk. A connector may not be able to pass on a 
> fulfillment in time. The incoming transfer times out, even though the 
> outgoing transfer executed. The connector loses money. This situation 
> can turn a DoS attack into a way to steal money from the connector. 
> The amount at risk at any given moment is the amount of money in flight.
>
> 2. Settlement risk in unconditional payment channels. If I use an 
> unconditional payment channel plugin like ilp-plugin-bitcoin-paychan 
> <https://github.com/interledgerjs/ilp-plugin-bitcoin-paychan> or 
> ilp-plugin-xrp-paychan 
> <https://github.com/ripple/ilp-plugin-xrp-paychan>, I have to trust my 
> peer for the amount of money in flight.
>
> The key is that both risks are limited to the maximum amount of money 
> in flight. And streaming payments are a way to vastly reduce that 
> amount by splitting one large payment ($100) into many tiny ones 
> (10¢). Given a conservative connector that immediately stops 
> processing when it is under attack, the maximum loss is now 1000x 
> lower. That also lowers the risk cost 1000x, which could be a 
> significant portion of the overall payment cost.
>
> Streaming Payment Risk Reduction.png
> *Latency is Key*
>
> The overall speed of streaming payments is the payment amount times 
> the latency (i.e. time between preparation and fulfillment on a given 
> link) divided by the bandwidth (i.e. max amount in-flight). Sticking 
> with our example, to send $100 in 10¢ increments, we need just over 
> eight minutes if the average latency is 500 milliseconds. To speed 
> this up, we can either lower the latency (500ms -> 100ms => 1.67 
> minutes) or increase the bandwidth (10¢ -> $1 => 50 seconds).
>
> *Payment Bandwidth Simplifies Peering*
>
> Bandwidth is also a useful concept for commercial peering. As an 
> Interledger Service Provider (ILSP), I need to know how much liquidity 
> I need to deploy. And the money needed to provide that liquidity is my 
> main capital expense. That means that charging my customers for 
> bandwidth (as opposed to payments) makes my financial planning a lot 
> simpler. Of course, just like on the Internet, if the flows are 
> balanced, I may not charge anything at all and we may simply peer for 
> mutual benefit. I'll also assume that my customers won't all utilize 
> their available payment bandwidth, so I may have some ratio of 
> oversubscription.
>
> One final note: 10¢ of bandwidth is obviously very low. In practice, 
> if you wanted to make $100 and larger payments on a regular basis 
> you'd probably choose a higher bandwidth provider. I could easily see 
> an ILSP serving corporate customers offering bandwidth of $1m and more.
>
> What do you think? Is the Interledger going to be routing tiny payment 
> packets?