RFC-4: Replace data field with ilpPacket

[interledger]

RFC-4: Replace data field with ilpPacket

[adrianhopebailie]

Lots in there that we need to say explicitly in the spec. Will work on some PRs.

[justmoon]

According to the spec, there is no transfer.data.ilp_header, since transfer.data is a binary string. The ILP header would be the first thing in the binary string.

We don't care about passing arbitrary data along with transfers,

Another way of saying this I think is that we don't expect to add or remove things from the binary string at each hop. I disagree.

Additional headers after the ILP header may be added and removed at each hop.

Some examples:

• When source routing you might strip off a source routing header each time.
• When debugging/tracing, you might add a debug header at each hop.
• When sending through a proprietary subnetwork you may add an Atomic mode header when entering and strip it when exiting.
• ...

As for what the field should be called - property names should makes sense in the context of the object, not the caller/user. The plugin interface abstracts a ledger and from the ledger's perspective, it knows nothing about ILP. So you could put an ILP packet in there, but you could also put any other data you wanted and it would work just fine, so I think data is better than ilpPacket.

[emschwartz]

Good points 👍

[adrianhopebailie]

According to the spec

Which spec? I am still struggling to understand what should be defined in the ILP plugin spec and what should be in the protocol spec.

It seems like the part of this that should be defined in the ILP protocol spec is the format of the binary data (at least the header and the way other headers can be added) but the rest is specific to each implementation (of which the plug-in is one).

Put differently, all ILP prescribes is that each time a ledger transfer is done as part of an end-to-end ILP transfer there is a packet of data that must be passed with it in a strictly defined format. All the other data that is sent in the transfer is implementation specific.

Coming back to the IP analogy:
an IP packet is "framed" in a way that is specific to the link-layer on which it is transferred

Therefor it would be useful to explain the transfer of an ILP packet in similar terms:
an ILP packet is "framed" in a way that is specific to the ledger on which it is transferred

Specifically, each ledger protocol MUST define a place in it's transfer instruction payload to put the ILP packet but what that is called is specific to the ledger. i.e. RFC 4 is effectively defining a ledger layer protocol since it's defining the details of how an ILP packet is framed and sent as the payload of a transfer.

The complication we have is that there is not a clean separation between ledger layer and ILP layer because the ledger has to look inside the ILP packet to get the condition and timeout. But since it only reads that data I don't think that's a problem.

[emschwartz]

The complication we have is that there is not a clean separation between ledger layer and ILP layer because the ledger has to look inside the ILP packet to get the condition and timeout.

This is actually not true. Connectors MAY look at the packet to determine the condition and timeout, but then they submit the transfer to the ledger with a condition and expiry. The ledger does not inspect the packet at all. Note that the packet expiry will be different than most of the ledger transfer expiries.

Also note that sending the executionCondition in the packet is redundant if it is also included elsewhere in the transfer. In discussions with @justmoon I pushed for having it in the packet even if it's redundant. I think it makes sense to include everything in the packet that constitutes the instructions about what you're trying to make happen on the last ledger, even at the expense of transmitting a few more bytes than is strictly necessary.

[adrianhopebailie]

The ledger must create holds based on the condition and understand that condition so it can evaluate the fulfillment.

Are you saying that only the final receiver looks at the condition in the ILP packet and that each connector along the way must explicitly pass a copy of that in the local transfer frame if they want the ledger they send the transfer to to use it?

That seems like a good idea but it's not documented anywhere and raises a lot of questions!

QUESTION 1: Are we saying explicitly:

• Ledgers MUST honor the condition passed in the transfer frame
• Ledgers MUST not reject a transfer if the condition in the transfer frame is different to that in the ILP packet (they actually shouldn't look at the packet at all)?

QUESTION 2: What does a connector do if they receive a transfer where the conditions in the transfer frame and the ILP packet are different? The connector wants to get the money on hold for them so they want the transfer frame condition to be fulfilled suggesting that's the one they should send on BUT what really matters is which one the receiver will fulfill.

QUESTION 3: What does a receiver do if they receive a transfer where the conditions in the transfer frame and the ILP packet are different? Do they fulfill both if they can? They are only incentivized to fulfill the one that gets them paid which means the one in the transfer frame.

I assume this is how we'll setup atomic mode transactions but wanted to think it through (out loud).

The incentives get very interesting if we don't assume that the condition on every hold along the way is the same one sent by the sender.

Example: Alice -> Connie -> Charlie -> Bob

Alice -> Connie: Condition in ILP Packet = C1 Condition in transfer frame = C1
Connie -> Charlie: Condition in ILP Packet = C1, Condition in transfer frame = C2
Charlie -> Bob: Condition in ILP Packet = C1 Condition in transfer frame = C1

• Bob fulfills C1 with F1 and gets paid
• Charlie needs F2 to get paid
• But if Connie somehow gets to see F1 then she can get paid and Charlie is out of pocket so presumably there is a non-technical (legal/regulatory) relationship between Connie and Charlie to protect Charlie
• C2 could also be derived from C1 so that F1 is part of fulfilling F2 or F2 could just be a notary signature
• Assume Connie and Charlie are part of an atomic mode network. Then Charlie submits F1 to the notary who returns him F2 and also passes F1 to Connie.

[emschwartz]

Are you saying that only the final receiver looks at the condition in the ILP packet and that each connector along the way must explicitly pass a copy of that in the local transfer frame if they want the ledger they send the transfer to to use it?

Ledgers should treat the data attached to transfers as completely opaque. They should only base the hold on the condition the transfer is set up with. Connectors and receivers are the ones who deal with the packet details.

What does a connector do if they receive a transfer where the conditions in the transfer frame and the ILP packet are different?

It depends on the circumstances. It is possible that the connector knows the relationship between the two conditions, for example in the Atomic scenario you describe.

Unless the connector knows the relationship between the conditions, it would probably forward the transfer using the condition from the source transfer (not the packet), because then it knows it will be able to claim the source funds.

What does a receiver do if they receive a transfer where the conditions in the transfer frame and the ILP packet are different? Do they fulfill both if they can?

They would probably either reject the transfer or fulfill the condition from the transfer (not the packet). They should not fulfill two conditions unless they are expecting two conditions for some reason. Otherwise, they may be unintentionally saying two obligations have been fulfilled by the one transfer.