Re: Streaming payments for risk mitigation in Interledger

Hi,

interesting concept, but I don't get where the risks come from. It has been a while I'm not updated on ILP, but why there can be the fulfillment risk? Isn't everything atomic?


Regards

________________________________
Da: Adrian Hope-Bailie <adrian@hopebailie.com>
Inviato: sabato 24 giugno 2017 12:58:17
A: Bob Way
Cc: Stefan Thomas; DC; Evan Schwartz; Interledger Community Group
Oggetto: 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<mailto: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<mailto:ben@ripple.com> | ripple.com<http://ripple.com/>







On Jun 23, 2017, at 1:42 AM, Evan Schwartz <evan@ripple.com<mailto: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<mailto: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<mailto: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
[https://ripple.com/wp-content/themes/ripple-beta/assets/img/logo/ripple-logo-color@2x.png]