Streaming payments for risk mitigation in Interledger

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?