Do we want to keep supporting escrow on ledgers that are not superfast and supercheap?

[michielbdejong]

Plugins that represent on-ledger escrow on superfast and supercheap ledgers, can implement plugin.sendRequest as a transfer.

Plugins that represent payment channels can do the same, because a payment channel transfer will be superfast and supercheap.

So if we decide to get rid of all other plugins where transfers are so slow that it makes sense to do messages over a side-channel (e.g. ilp-plugin-xrp-escrow and ilp-plugin-ethereum), then we would
get a situation where all plugins implement the sendRequest method in the same way, and then it would make sense to move that code out of the plugin.

But if we decide that on-ledger escrow on ledgers that are not superfast and supercheap is still worthy of being called Interledger, then we should keep the plugin.sendRequest method.

[michielbdejong]

Another situation in which we could get rid of sendRequest would be if connectors stop sending route broadcasts and other connector-to-connector messages to each other, but I don't think anyone is proposing that.

[emschwartz]

I think I would put this slightly differently. All types of ledgers can use transfers for quotes and route broadcasts as long as we define protocols built on top of ILP payments for those functions.

If your ledger is very slow and expensive, you're going to have a slow and expensive experience using ILP no matter what. For example, when sending payments, if the rest of the network caps the maximum payment size at something low, you might need to spend more on fees for an Ethereum escrow transaction than the value of the payment. Similarly, quotes and route broadcasts will be painfully slow or expensive.

So I think the question comes down to "should we keep additional features in the Interledger and ledger layers just to support slow and expensive ledgers", and I think the answer to that is definitely no.

Any functionality that is needed just to support specific ledgers should go in their ledger plugins, not in the LPI, nor in the Interledger layer. For example, you could have a ledger plugin for Ethereum that would send all transfers over a certain amount as on-ledger escrow transactions and all small transfers as trustline updates.

---

There is a slightly more practical question of whether our team should continue maintaining the code for the XRP and Ethereum escrow plugins. That's up to us but I don't think it's necessarily worth the effort. XRP is slightly faster and cheaper but the XRP escrow feature does not support having the receiver reject the transfer early, which means it is incapable of passing rejections back. I think it's more important for plugins to be able to reject incoming transfers with an ILP (rejection or error) packet attached, which is part of the core ILP payment flow, than supporting an additional messaging channel.

[michielbdejong]

Small payments are (obviously) easier than large payments. Larger atomically settled payments generally require third-party escrow on transfers which makes them slower, but small ones can usually be handled over unconditional transfers (no hashlock / escrow), which means they can be faster.

If it's really our decision to drop support for larger payments, and we decide to only focus on small ones from now on, then it would definitely simplify the goal/scope of the project quite a bit, and bring us closer to saying we got it working.

[BobWay]

I agree with everything in the thread. But I still hate the idea of removing grown up payment sizes.

I think we are just going to end up splitting the “ILP-OIV” work from the “ILP-xCurrent” work. My gut tells me that is a bad thing. We have banks sending payment sizes in the tens of million dollars daily. (The Swedish Bank) Splitting those into 10 million $1 payments is going to be a hard sell. If we send $1 per second, $10 million is about 115 days.

[emschwartz]

I disagree with the characterization that we are removing large payments.

We should look at this from the following three angles:

The Interledger Protocol (ILP)

The Interledger protocol can be used to send payments of any size. Connectors can set whatever Maximum Payment Size (MPS) they want, which means that some connectors can set it very low while others like banks may set them very high.

We should not add or keep complicated features in the core protocol that are only needed when there is a very wide range of supported payment sizes or desired hold times. (If we wanted to support the full range of possible payment sizes, hold times, and their corresponding exchange rates we would need a three-dimensional version of the liquidity curve to express that)

Furthermore, the point of Interledger is to enable interoperability. The more variability we allow into the core system, the more likely it will be that two people could be "using the same Interledger Protocol" and theoretically on the same network but still unable to send payments to one another. This could easily happen if one connector's MPS is smaller than another's minimum payment size, or if one connector's required hold time is longer than another's Maximum Hold Time.

The Interledger (the open network)

For a number of reasons, it is likely that the open Interledger network will -- at least initially -- have low Maximum Payment Sizes. Some of these reasons are under our control -- like what use cases we prioritize. Others, such as connector risks and initially limited liquidity, are not under our control.

Similarly, connectors can set whatever Maximum Hold Times they want, and connectors will want to keep those as low as possible.

Transport Layer protocols like PSKv2 will probably include some mechanism for discovering the path MPS and will try to send payments in the largest chunk sizes possible. Features like chunked payments may become unnecessary if the average path MPS ends up being greater than the average payment size.

Splitting those into 10 million $1 payments is going to be a hard sell. If we send $1 per second, $10 million is about 115 days.

This is like sending a 4k video over a dial-up connection. It is possible that in the beginning, the open Interledger may only be useful for smaller payments, like the Internet was originally only good for very small files. But as the network grows, it is very likely that the packet size and/or bandwidth (in-flight amount) will increase dramatically.

The Interledger Project

The final question is what the people working on the open source Interledger Project should focus on or prioritize. There is a strong argument to be made for reducing the scope of the problem we are trying to solve right now as much as possible to get the live network off the ground.

If some members want to focus on large payment use cases, that is completely fine. However, as mentioned in the first point, we should not include complex features in the core Interledger Protocol just for these use cases.

[emschwartz]

Also, I wrote up #358 to propose splitting the "Ledger Layer" into the Settlement and Clearing Layers. I think this makes it a bit easier to understand why we expect clearing to be fast, while the underlying ledgers or settlement systems can still be slow or expensive.

[michielbdejong]

👍 discussion about our "pivot to pennies" continued there