Re: Streaming payments for risk mitigation in Interledger

Here are a couple more thoughts to add:

*More Competitive Rates*
Streaming payments could give you a better rate than sending larger
payments. In addition to the risk factors you mentioned, there will always
be more parties who can compete to facilitate smaller payments than higher
value ones

*Slow Start*
With streaming payments you could split your payment across multiple
connectors and use their time to complete each payment as a kind of back
pressure on sending. You start sending one little chunk and automatically
send more through whatever connectors respond the quickest. Slow start
might also be useful for the same congestion-related reasons it's used on
the Internet

*Path MTU*
The size of payment a path can support is equivalent to the Path Maximum
Transmission Unit (MTU) on the Internet. To maximize the chance of being
able to reach someone you probably want to minimize the transmission unit,
or do path MTU discovery


*Packet Switching*The bandwidth concept is especially apt because one of
the benefits of packet switching originally was better utilization of
network bandwidth, so it makes sense that splitting payments would have a
similar effect

*Simpler Data Format for Exchange Rates*
Right now we use Liquidity Curves to express exchange rates. One of the
things Stefan brought up earlier was that if all payments are small you
could express the exchange rate as a simple number, which would massively
simplify one part of the Interledger protocol stack

*Probes*
If all payments were small, connectors would have a hard time
distinguishing between test payments someone is sending to probe their
routes or check their exchange rate from the real thing



It's a totally crazy idea but I do think we're going to end up with
streaming payments.

On Fri, Jun 23, 2017 at 8:05 AM DC <dc@ebank.ac> wrote:

> Your Streaming Payments for Risk Mitigation in Interledger 'SPRMI' concept
> is a very interesting solution and has a lot of merit.
>
> Obviously, in a real world environment (let’s use but one example; the
> US$6Trillion a day FX market), both latency and bandwidth are critical
> considerations because SPRMI would test the parameters of any underlying
> platform by multiplying load (thus impacting not only speed but in fact
> available capacity).
>
> However, there is nothing trivial about your observation.  It warrants
> exploration because the ultimate success of any platform (financial or
> otherwise) is to mitigate the risk of using that platform.  People will
> only use the platform if they can trust it (especially in a financial
> environment).  SPRMI is worth pursuing further.
>
> DC
>
> On 23 Jun 2017, at 8:51 AM, Stefan Thomas <stefan@ripple.com> 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?
>
> --

Evan Schwartz
Software Engineer
Managing Director of Ripple Luxembourg
<http:> <http:>