Re: Streaming payments for risk mitigation in Interledger

Absolutely agree that streaming payments is the future!

The great thing is that one is able to balance risk with time to execute.
For a very large payment one may be prepared to give it up to an hour to
execute in which case you can drop the size of the "packets" and reduce the
in-flight risk.

What this will mean is considering new risks though like incomplete
payments. If I need to send $1000 and want to send it in $1 packets but I
only have a $1000, then I have to wait until any failed payments fully
expire and I get refunded before I can attempt to send that $1 again.

The great thing is that as the sender i control that expiry on the first
transfer!

In terms of how this might be implemented, it feels like it could be done
entirely at the application (maybe transport) layer. A single payment can
have a unique destination address (like the address per invoice concept we
already have today). I expect PSK in it's current form is already fully
capable of supporting this use case.

Very keen to see this in action!

On 23 June 2017 at 18:40, Bob Way <bob@ripple.com> wrote:

> One other thought to add:
>
> If a connector is attempting to provide liquidity to make a profit, then
> (return / deployed capital) becomes a key ratio.
>
> The average payment size has a huge effect on the necessary amount of
> deployed capital needed to make markets in an otherwise balanced flow
> corridor. Taking the extremes:
>
> if we knew a given corridor was going to have two payments of $1,000,000
> in value (one in each direction) then the amount of deployed capital
> necessary to enable those payments is either $1,000,000 or $2,000,000. The
> difference depends on whether or not we know which payment will happen
> first.
>
> However if we take the same volume corridor, but with 1,000,000 individual
> $1 payments in each direction, then the amount of deployed capital could be
> reduced by a factor of 1,000 or more.
>
> Given the same spread, lowering capital requirements tends to increase the
> ROI exponentially. This will of course will interest more traders whose
> competition will lower market spreads.
>
> This is really the same concept Stefan described in “risk” terms. But I
> think it is also useful to describe the concept in “reward” terms.
>
> Bob Way
>
> Integration Architect | Ripple
> bob@ripple.com <ben@ripple.com> | ripple.com
>
>
>
>
>
>
>
> On Jun 23, 2017, at 1:42 AM, Evan Schwartz <evan@ripple.com> wrote:
>
> 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
>
>
>