Re: Streaming payments for risk mitigation in Interledger

> In practice, you may well want to do multiple chunks at a time in order
to maximize some of the other benefits of streaming payments, like using
bandwidth from multiple paths simultaneously.

Another advantage of using several paths simultaneously is that the
sender/recipient is hedging its settlement risk. For example, you might not
feel comfortable with trusting a single peer *X* amount of money in flight,
but it might be acceptable to trust *Y* distinct peers each with *X/Y*
amount of money in flight. This assumes that it is less likely that all *Y*
peers are defaulting on you than that a single peer is defaulting on you.

On Wed, Jun 28, 2017 at 3:49 AM, Stefan Thomas <stefan@ripple.com> wrote:

> @Michele: We ended up using the form of Interledger that the white paper
> calls "Universal mode". So no, Interledger payments are not atomic.
> However, any subset of participants can decide to upgrade to an atomic
> protocol for their section of the Interledger payment.
>
> The reason we designed it this way is: For atomicity, some amount of
> agreement (such as agreeing on a transaction leader or group of leaders) is
> required among all participants. Since you can't guarantee that that
> agreement will always exist, you can't use an atomic protocol as the top
> level interoperability protocol. It just wouldn't be universal. So it's
> better to use universal mode end-to-end and then upgrade some subpath(s) -
> which *can* be the whole path - to atomic mode, if available.
>
> @Steven:
>
> > In payment channels, the settlement risk is by definition equal to the
> limits in both directions of the channel.
>
> This is true for trustlines, but not for payment channels. The point of
> (this type of) a payment channel is that I get a non-repudiable, signed
> claim on a certain amount of funds. So even if my counterparty decides to
> default I can still force settlement via the underlying ledger. The only
> way I can get screwed is if the underlying ledger malfunctions, which is
> (theoretically) the same level of security/risk as if we had settled the
> payment immediately.
>
> Compare this to a virtual ledger or trustline where there is no
> cryptographically signed claim. So I need to rely on my counterparty to
> make good on their promise to settle, creating settlement risk.
>
>
> > 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.
>
> Quite an interesting point!
>
>
> > This means that payments are sent sequentially. Is that required?
>
> In order to get the benefits I described, yes. As discussed above, there
> is no settlement risk in a payment channel once both sides consider the
> payment executed and a cryptographic claim has been issued. So for all
> intents and purposes, we can consider this payment settled. Between the
> time of preparation or the time of execution, however, somebody is taking a
> risk. Either the sender, because they've issued a claim already and the
> payment hasn't executed yet. Or the recipient, because the sender *hasn't*
> issued a claim and they already prepared the following payment. Once the
> payment either succeeds or fails, however, each side will find out if the
> other is honest.
>
> For instance, let's say the claim is supposed to be issued on execution.
> When the payment executes, the recipient finds out if the sender actually
> issues the claim or not. Once they do, the payment is fully settled and the
> amount is no longer at risk. So if we only do one chunk at a time, the
> maximum risk is that that one chunk is lost, because either side can refuse
> to do the next chunk if the previous one was not correctly settled.
>
> On the other hand, if we prepare multiple payments simultaneously, then
> someone is again taking a new risk for each successive chunk, before
> previous chunks have fully resolved. So the maximum amount risked is the
> highest total amount that is in-flight at any moment in time.
>
> In practice, you may well want to do multiple chunks at a time in order to
> maximize some of the other benefits of streaming payments, like using
> bandwidth from multiple paths simultaneously.
>
> On Sun, Jun 25, 2017 at 11:06 AM Jeff Martinez <jmar42@gmail.com> wrote:
>
>> 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?
>>>
>>>
>>>