Re: Streaming payments for risk mitigation in Interledger

I think the streaming comes into play in case of some type of cyber
security breach??

On Jun 25, 2017 10:44 AM, "Steven Roose" <stevenroose@gmail.com> wrote:

> 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.
>
> [image: 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?
>
>
>