RFC-[1,3,5,6]: Combine "Transport protocols" back into ILP?

[emschwartz]

We have been calling Optimistic, Universal, and Atomic "transport protocols" based on the analogy with the Internet's layers, rather than Interledger Protocol "modes" as described in the original whitepaper. This has caused some confusion, in part because the analogy with the Internet's transport protocols is not a perfect one. This is a proposal to (re)include Optimistic and Universal -- not Atomic -- in the Interledger Protocol (RFC-3).

Transport protocols are host-to-host, Universal is not
The Internet's transport protocols (UDP, TCP) are completely ignored by the intermediary routers and only used by the hosts on either end of a connection. Universal is not "host-to-host" because it must be understood and supported by all intermediary ledgers and connectors. The partial analogy with the Internet makes the "transport protocol" terminology confusing.

Include Universal (and Optimistic) in ILP
Since Universal is not truly a transport protocol, we should include executionCondition and expiresAt in the ILP packet and call it part of the core Interledger Protocol. This makes "ILP" slightly more complicated, but the hold + crypto condition feature is already required for "full" and even "basic" Interledger support. Optimistic is already just the plain ILP packet with no condition or expiry.

What about Atomic?
Since writing the whitepaper we've started to see Atomic as a protocol that will be used within defined groups of connectors (and ledgers that support cancellationConditions). Finding commonly trusted parties is non-trivial and unlikely to work across distant groups. Atomic mode is one of a potentially large set of optimizations specific groups may use, for example to reduce their risk or increase efficiency. Thus, Atmoic should not be something that should be part of the core protocol implemented by everyone.

Issues / questions:

• If the executionCondition is in the ILP packet as well as in the transfer, careless implementors may shoot themselves in the foot by failing to check that the two match.
• If someone wanted to use "Interledger" and even the packet format, but didn't want to use the Crypto Conditions spec for the hold conditions, would that be "Interledger"?
• It may be useful to have conditions in the ILP packet even if the ledgers don't support cryptographic holds. This way, senders could tell whether their payment made it to the recipient even though it's not secured by the ledgers. If this is a valid use case, is the crypto condition really an "execution condition"? Is it just a "condition"?

[emschwartz]

cc @justmoon @clark800 @sentientwaffle @tarcieri @adrianhopebailie @vhpoet

[emschwartz]

Note this comes from discussions with @justmoon, @clark800, @adrianhopebailie

[adrianhopebailie]

Since Universal is not truly a transport protocol, we should include executionCondition and expiresAt in the ILP packet and call it part of the core Interledger Protocol. This makes "ILP" slightly more complicated, but the hold + crypto condition feature is already required for "full" and even "basic" Interledger support. Optimistic is already just the plain ILP packet with no condition or expiry.

+1

I don't think these are different "transport" protocols. Optimistic is effectively universal with a null condition.

My proposal would be for connectors to hold knowledge in their routing tables of the capabilities of ledgers to support holds and the different condition flavors they support. It should be an exception condition if a connector sends a packet to a ledger that contains a condition the ledger can't support. In this case the ledger should reject the packet and the connector must try a different route.

The behavour of a ledger should be to look at the ILP packet header and if there is a condition it only passes the packet on if it supports that condition. i.e. All ledgers MUST look at the execution_condition and expiresAt fields in the header even if they don't support holds.

If there is no executionCondition specified then the ledger should pass the packet to the connector specified to forward it on.

In all cases the ledger should wait for acknowledgement from that connector that they are able to route the packet before executing the local transfer/hold.

Still thinking about atomic and cancellationCondition. Does it have value in universal potentially? Could the maximum fee be encoded as a cancellation condition that is passed back to roll everything back as soon as the payment gets too expensive?

[emschwartz]

My proposal would be for connectors to hold knowledge in their routing tables of the capabilities of ledgers to support holds and the different condition flavors they support. It should be an exception condition if a connector sends a packet to a ledger that contains a condition the ledger can't support.

Agree that connectors need to know what types of conditions ledgers support. Ledgers will use the condition bitmask to determine if there are condition types they do not support, and will reject the transfers if there are.

The behavour of a ledger should be to look at the ILP packet header and if there is a condition it only passes the packet on if it supports that condition. i.e. All ledgers MUST look at the execution_condition and expiresAt fields in the header even if they don't support holds.

Ledgers actually don't look at the packet. It's up to the connector to translate the packet into a ledger transfer that has an expiry and condition. If it sends the packet along in a transfer that doesn't have either of those, the ledger will pass it on as a simple transfer.

In all cases the ledger should wait for acknowledgement from that connector that they are able to route the packet before executing the local transfer/hold.

I disagree, ledgers should execute transfers if they are valid, not expired, and have a condition + fulfillment or no condition. They shouldn't care about any of the routing stuff. The way you could potentially handle that would be to have the connector use an "authorized credits" feature such that they need to explicitly approve all incoming transfers.

Still thinking about atomic and cancellationCondition. Does it have value in universal potentially? Could the maximum fee be encoded as a cancellation condition that is passed back to roll everything back as soon as the payment gets too expensive?

This is dangerous if you're expecting a Universal mode payment, because if you don't check for the non-existence of a cancellationCondition I can make you think I sent you money on hold but actually cancel it before you fulfill the condition.

[justmoon]

It may be useful to have conditions in the ILP packet even if the ledgers don't support cryptographic holds. This way, senders could tell whether their payment made it to the recipient even though it's not secured by the ledgers.

That's a valid use case, but it may be better to do this via a mechanism like ilp-plugin-virtual. I.e. assume that all ledgers support conditions. If a ledger doesn't, build a clearing ledger on top of it that does and use the legacy ledger for settlement.

The idea is that even if the ledger you're using doesn't afford you the security that comes from full holds you still want to track what the balance between you should have been. Otherwise if you just do optimistic payments you have to add a bunch of extra logic so honest connectors send money back etc.

---

Special thanks to @clark800 who grilled us on Slack about why we called Universal a transport protocol until we had to admit that our case wasn't actually very strong. Question everything!

[adrianhopebailie]

That's a valid use case, but it may be better to do this via a mechanism like ilp-plugin-virtual. I.e. assume that all ledgers support conditions. If a ledger doesn't, build a clearing ledger on top of it that does and use the legacy ledger for settlement.

This sounds like an argument to put conditions in the base ILP header? Am I right?

[emschwartz]

This sounds like an argument to put conditions in the base ILP header? Am I right?

Yeah, @justmoon's point was just that whenever payments have conditions all ledgers should hold the funds. The other idea I mentioned was just a thought but I agree that it shouldn't be added as a feature.

[justmoon]

We need to also remove cancellation conditions from IL-RFC 4.