Add ILPv4 RFC

[emschwartz]

Replaces the previous ILP spec (IL-RFC 3). See #359.

Open questions:

• Do we need diagrams or any more explanation of the protocol flow or motivations?
• Should we add any more error codes?
• Anything else that should go in this spec?

[mDuo13]

This is a nicely concise description of a much-simplified and elegant protocol. I left a few questions and comments on things that were not clear to me.

I'll be interested to see what the higher-level protocol landscape looks like.

[mDuo13]

Is the expiry a duration or a deadline? The phrasing in point 5 ("shorten the expiry time") makes me wonder.

[emschwartz]

What is the difference? The expiry / deadline by which each bilateral transfer must be made or rolled back decreases with each successive hop so that the connectors have a window of time to deliver the fulfillment back even if the next transfer executes at the last possible moment.

[mDuo13]

It's a question about whether it's represented as a point in time ("February 9th, at 17:24 UTC") or a duration of time ("3600 seconds from now").

You can't "shorten" a point, so ultimately this may just be a nitpick with that wording.

If it's a duration, then that raises other questions. (Whose "now" are we using? Which end do I shorten it from? etc.)

[emschwartz]

It's a timestamp, so I'll adjust the wording about it

[chan-maddanna]

I second others opinion, that it is much more elegant and simplified protocol. also the naming conventions are very well placed for comparison with tradition ipv4 & hence the understanding of layers/packets. I have two minor points that I found was not clear to me.

1.) using PaymentChannels instead of hashlocks - I understand they do not need to include the processing time of slower ledgers, hence connector risks & somewhat even underlying ledger (architectural) issues are mitigated.

However How can this produce the same or better settlement of Bilateral payment obligations ?

2.) For proof of settlement - the document says ".. sender's signed payment channel update (or other proof of settlement) .. "
But could not find what other proofs of settlement are accepted and is this something that a user/entity can change ( ex: add/select ones own accepted proofs among a bunch of proofs that are "verified for use"? )

As i mentioned, really find this a much more simplified & way more elegant . I think its a great move to have such close design co-relation with the ip stack. Thanks for all the great work kindly.

[mDuo13]

In later hops, is the "sender" the originator or the previous connector?

[mDuo13]

Somewhere in this document, we should discuss what the difference is between "bandwidth" and "balance". I'm fuzzy about what "reducing the sender's bandwidth" actually looks like in practice. Does the connector need pull permissions to the shared payment channel? Does doing this give the connector money they can theoretically spend elsewhere? Is this just a hold?

In particular, I'm unclear if there's a difference between this operation and the one in step 9 where "connector credits the receiver's account".

[mDuo13]

If it's possible to deliver an exact amount—no more than a desired amount—maybe it's worth noting that here too.

If it's not possible, that's definitely worth note.

[emschwartz]

It's not possible to ask connectors to deliver an exact amount but you can have the receiver reject the packet if it's less than you want it to be

[mDuo13]

In this step, "credit's the receiver's account" seems to refer to the receiver of an individual hop, not the overall beneficiary. If so, that should be explicit.

[emschwartz]

Each hop does credit the next one if the connector or receiver after them delivers the fulfillment in time

[mDuo13]

This definitely sounds like a bigger risk on connectors than in ILPv1, even if the amounts are smaller. In v1, connectors only had to choose ledgers they trust to enforce cryptographic escrow. Now it sounds like senders can shop around for sucker connectors. Given that this protocol does not define any way to identify senders, blocking them permanently could be quite a challenge.

I suspect that this is supposed to be solved in a higher-level protocol or in the setup of the payment channels, but the phrasing of this point doesn't really make that clear.

Mostly unrelated, this is another place "bandwidth" is used in a somewhat mysterious way.

[emschwartz]

It's certainly a different type of risk but I'm not sure it's a bigger one. In ILPv1, connectors ran the risk that some sender would tie up their liquidity for a long period of time and then either reject the payment or accept it only if the exchange rate had moved in their favor (the free option problem). A big issue with that was that anyone could cause that to happen, even someone that was indirectly connected.

Now, the model is that each bilateral connection requires some level of trust. Either the sender needs to trust the connector (if the account is pre-funded) or the connector needs to trust the sender (if their account is post-funded, as in this example). Like in ILPv1, you need to trust whoever you're directly connected to, but now you're directly connected to other connectors (or senders or receivers), rather than ledgers.

[mDuo13]

The description refers to a "memo" which is (I think) not defined elsewhere in the protocol.

[mDuo13]

Does "receiver" here only refer to the beneficiary, or could it also be a connector?

[mDuo13]

Should the "Ledger" errors (T01 and T02) be re-specified or removed now that the ledgers are not synchronously part of this protocol?

[emschwartz]

We could deprecate those or change the meaning to talk about connectors now. Both of them could apply if a previous connector knows the route but can't contact their peer at that moment. I don't think these are actually used right now

[mDuo13]

Yeah, maybe redefine them to relate to connectors and rename them "Peer Busy" and "Peer Unreachable".

So you'd have:

• T01 Peer Unreachable - "I can't pass this forward because the connector I want to pass it to didn't respond."
• T02 Peer Busy - "I can't pass this forward because the connector I want to pass it to is lagging or giving me a busy signal."
• T03 Connector Busy - "I'm busy."

Although, given that, I don't know when T02 would be used over T03 or vice versa. So maybe we should just remove one of those.

[mDuo13]

Is "liquidity" or "money" here the same as the "bandwidth" described in the Flow section?

[emschwartz]

Yes. I think the main difference between the bandwidth and balance concepts is that bandwidth captures the fact that it may refill quickly if you have a fast settlement method like a payment channel

[mDuo13]

before the payment was prepared

I think this one needs to be rephrased for v4. It probably means that after subtracting fees, the Amount went below 0 or a minimum specified by a higher-level protocol.

[mDuo13]

I would argue that connectors need one more piece of data that's not in the ILP packet: the sender from the previous hop.

The connector can figure this out from the communication channel by which they received an ILP packet, but I suspect it would simplify implementations and make them far more flexible in terms of underlying communication layers if the packet contained a from field identifying the previous connector (or the originator in the first hop), probably also by ILP address.

With that information, a connector would know whose "bandwidth" to debit from just the ILP Packet itself. Although I guess you'd have to worry about spoofing other senders to tie up their "bandwidth"...

[emschwartz]

Yeah, connectors should figure this out based on which communication channel they got the packet from. If there were a from field, it would just be one more thing the connector would need to verify because it would be easy to lie about it.

[mDuo13]

That makes sense. You should find a place to state it explicitly in the standard.

[michielbdejong]

explain what "the core ILP" is. Is it the three OER-encoded packet formats? Do we (or should we) have an RFC that describes "the core ILP"? Does "Interledger Protocol v4" contain more than "the core ILP", or are they synonymous?

[michielbdejong]

Is "the Interledger layer" synonymous with "the core ILP"?

[emschwartz]

Previously the Interledger layer was made up of ILP and ILQP. Now it's just ILP

[michielbdejong]

I think by "core" you mean "the parts of the protocol, and the nodes in the network, that are only concerned with forwarding payments for others, and neither with receiving nor sending such payments"

[michielbdejong]

first mention of the existence of packets, other than the figurative "packets of money" in the opening sentence. maybe in the first paragraph, state that there are three packet types, corresponding to request / success / error, and that they are OER-encoded. Then here, you can explain that it's those OER strings that are being sent between peers.

[michielbdejong]

maybe we should explain why PSKv2 and not PSKv1. so one of the design goals should be speed, right? and that will lead to small max payment size and that will lead to PSKv2 being a better fit than PSKv1.

[michielbdejong]

ah, i see that's mentioned in the next paragraph. still, i think we should also list it as a design goal now.

[michielbdejong]

in which sense is ILPv4 optimized for smaller packets? is the choice for unconditional payment channels a part of the ILPv4 design, or could someone do conditional payment channels and large packets, and still call it ILPv4?

[emschwartz]

That's an interesting question. I think a lot of the things we've now built into or on top of ILPv4 assume the packets are relatively small, but you might still be able to do larger packets or conditional transfers.

Some of the assumptions are:

• Sending packets is free or of negligible cost, so we can use them liberally for things like quoting
• Ledger protocols are now mostly request/response, meaning the response isn't retried if it doesn't go through the first time
• Connectors don't store prepared packets in a db, because the assumption is that if your system dies you just lose all the packets that are in-flight
• Connectors have relatively low maximum hold times by default and as a connector you should be prepared to forward packets that have less than 30 seconds before they expire (you won't fare very well if you need to build in a long expiry window because your ledger is slower than that)
• As someone sending packets through the open Interledger, you won't be able to rely on the assumption that your payment can go through in one chunk and you might be told it's too big

[mDuo13]

Thinking on this spec overnight, I had a couple more points:

• We probably want to add some definitions of key terms, like a one-paragraph description of payment channels, and an explanation of how "bandwidth" is different from "balance" (if we're going to use the term bandwidth at all).
• Similarly, maybe add a brief list of required or recommended background reading?

[wilsonianb]

If the Prepare has expired, the connector returns an ILP Reject packet to the previous connector.

Why can't the previous connector just determine that the Prepare expired when they don't get a Fulfill packet before their own expiration?

[sentientwaffle]

typo: "importantance"

[sentientwaffle]

typo: "destintations"

[sharafian]

Maybe say using "penny switching" to limit risk instead of expensive atomic swaps

[emschwartz]

There are a bunch of reasons we opted for penny switching, risk being one of them. To me, that phrasing seems to bring up more questions than it answers (for example, what makes atomic swaps expensive?) and I'm not sure this document is the place to speak to all of those points

[adrianhopebailie]

I think this is actually incorrect. The size of the packets will be emergent and has nothing to do with the protocol. The protocol limits amounts per packet to UInt64.MAX and given that this can be scaled it's effectively unlimited.

I think you could replace "designed primarily for "penny switching", or routing large volumes of smaller-value packets. ILPv4" with "which"

[emschwartz]

It is emergent but we have made a number of assumptions that are based on relatively small packet amounts:

• Connectors can severely limit their customers' bandwidths to limit their risk, without making their customers' payments fail (because the customers will work around that)
• Sending packets is free or of negligible cost, so we can use them liberally for things like quoting
• We don't need a way to express how exchange rates vary based on the payment amount and/or hold time
• As someone sending packets through the open Interledger, you won't be able to rely on the assumption that your payment can go through in one chunk and you might be told it's too big

And some of the implementation assumptions:

• Ledger protocols are now mostly request/response, meaning the response (fulfillment) isn't retried if it doesn't go through the first time
• Connectors don't store prepared packets in a db, because the assumption is that if your system dies you just lose all the packets that are in-flight and the timeout is too short for you to bring the system up and submit the fulfillments anyway
• Connectors have relatively low maximum hold times by default and as a connector you should be prepared to forward packets that have less than 30 seconds before they expire (you won't fare very well if you need to build in a long expiry window because your ledger is slower than that)

[sharafian]

tie up too much of connectors' funds -> tie up connectors' funds

[emschwartz]

Why? You tie up connectors' funds every time you prepare a payment. The problem is if you take up too much bandwidth

[sharafian]

"Interledger stack" should be updated for ILPv4 as well, otherwise reading it will contradict this document

[emschwartz]

#364

[sharafian]

How about: "Because this balance represents un-settled debt between direct neighbors, either party can default on it. If an account is pre-funded, the customer/peer trusts the connector not to zero their balance. If an account is post-funded, the connector trusts the customer/peer to later settle this debt. Either party may stop transacting if the balance exceeds their trust in the other party. The amount of trust required to practically transact is related inversely to the speed of the ledger used for settlement."

[adrianhopebailie]

I would recommend using the term Account and not balance as this aligns well with financial terminology people will be familiar with.

I also think defining the term Node makes a lot of explanations simpler.

• Node - A participant in an Interledger payment (node on the Interledger network), that has accounts with one or more other nodes. There are three specializations of a node:
  • Senders - originate payments
  • Receivers - are the final recipients of payments, and
  • Connectors - are the intermediaries between a sender and a receiver that forward ILP packets. They may generate revenue from spreads on currency conversion, through subscription fees, or other means.

(Moved connector definition up here)

• Peer - A node with which another node holds an account. In some cases the relationship between two nodes will be a parent/child relationship whereby the parent provides additional services to the child beyond simply forwarding ILP packets.

• Account - Two peers establish an account with one another where they track the current obligations they hold with one another; i.e. the balance on the account. The account is denominated in a single asset. The peers agree on the precision and scale they will use for the amounts of that asset when they express amounts in messages between one another. Accounts may be pre-funded (in which case the customer or peer trusts the connector for the value of the account balance) or post-funded (in which case the connector trusts the customer or peer for the amount the account is allowed to go negative). Connectors may refuse to process further ILP packets if an account balance goes too low.

@sharafian said:

The amount of trust required to practically transact is related inversely to the speed of the ledger used for settlement.

This is a useful point to make somewhere in this document but not here in the definitions.

[sharafian]

all of the connector's liquidity -> all of the connector's bandwidth with their peers.

[adrianhopebailie]

within a given time period.

This sounds like a hard limit as opposed to a limit on the total in-flight. Is that intentional?

[sharafian]

The connector also has to verify that the fulfillment matches the condition.

Also treating the next connector as the receiver whom they will credit might be confusing, because "next" could be interpreted as either direction.

[sharafian]

The receiver should only fulfill so long as it doesn't put the Connector's unsettled balance with them above the maximum amount that the receiver tolerates (just like what the connector does in step 3)

[sharafian]

Additionally, the sender has to do some accounting to acknowledge that their packet was fulfilled, so they can determine how much to settle. Otherwise the trust model is different because the connector could tell them to settle more. Sometimes it might be acceptable (I trust my bank to not put fake charges on my account), but in the payment channel case especially the sender tracks their balance.

[adrianhopebailie]

@sharafian said:

so they can determine how much to settle

How can this be different from the amount they specified in the prepare packet?

[emschwartz]

He means that you want to keep track of how much you owe (based on the sum of the amounts in the prepare packets) so that the connector doesn't just make up an amount they want you to pay them.

[sharafian]

Not sure if 11 and 12 should actually go in here, because technically they're not a part of the packet flow. Maybe an appendix of some kind to this list? I guess for payment channels it makes sense that you might do it every packet, but that's not mandated by ILP

[emschwartz]

I think it's useful to have in there to give some explanation of how the balance is expected to be settled.

I guess for payment channels it makes sense that you might do it every packet, but that's not mandated by ILP

Is that not clear from "(or they may settle less frequently using slower on-ledger transfers or physical deliveries of cash or other goods)"?

[adrianhopebailie]

I agree with @sharafian here. We should describe it as part of the overall process but not put it in the flow. This may be a pre-paid account in which case this step happens before step 2.

[sharafian]

Based on communication channel and authentication information (e.g. in the case of an HTTP endpoint)

[adrianhopebailie]

@sharafian depending on your definition of "communication channel" that is implied.

http://www.enterpriseintegrationpatterns.com/patterns/messaging/PointToPointChannel.html

[sappenin]

The second sentence in the intro has an ambiguous modifier after the phrase, "previous versions of the protocol" (it's unclear if the penny-switching phrase referes to ILPv4, or to previous versions).

Consider something like the following:

Interledger (ILP) is a protocol for sending packets of money across different payment networks or ledgers. The latest version, ILPv4, is a simplification of the protocol designed primarily for "penny switching", or routing large volumes of smaller-value packets, to limit risk instead of trying to accommodate expensive atomic swaps

[sappenin]

Or just this if you don't like the change proposed by Ben...

Interledger (ILP) is a protocol for sending packets of money across different payment networks or ledgers. The latest version, ILPv4, is a simplification of the protocol designed primarily for "penny switching", or routing large volumes of smaller-value packets.

[adrianhopebailie]

Great document. Some suggested changes but excited about getting this published.

[adrianhopebailie]

There is no length prefix here. The type tells you what the sequence of remaining fields is.

[emschwartz]

I think the comment in the ASN.1 might contradict the definition (see here) but the implementation definitely uses a length-prefixed field

[adrianhopebailie]

Hmmm. I believe that is an implementation error. The ASN.1 definition resolves to:

InterledgerPreparePacket ::= SEQUENCE {
  type UInt8,
  data InterledgerPrepare -- If type == 12 then data is of type InterledgerPrepare
}

InterledgerPrepare ::= SEQUENCE {
  amount UInt64,
  expiresAt Timestamp,
  executionCondition UInt256,
  destination Address,
  data OCTET STRING (SIZE (0..32767))
}

In other words it is a SEQUENCE as a field within a SEQUENCE. There is no length indicator on the field.

[emschwartz]

🤷‍♂️ that might be the kind of implementation error that sticks because changing it would break everything (like HTTP "Referer")

[adrianhopebailie]

I think we can change the ASN.1 to reflect the implementation but it will be ugly. We'd lose the binding (in ASN.1) between the type and the format.

Something like:

InterledgerPacket ::= SEQUENCE {
  type UInt8,
  data OCTET STRING
}

Then implementors need to know that if type == 12 then data must be parsed as an InterledgerPrepare. It's not pretty.

[sharafian]

The intended meaning is definitely that there should be a length prefix (otherwise extensibility is broken). I couldn't find a document that describes how CLASS is encoded in OER, so I don't know whether the ASN.1 is technically correct. Given that @justmoon tested this in an ASN.1 tool, I assume that CLASS does encode with a length prefix.

[adrianhopebailie]

The intended meaning is definitely that there should be a length prefix (otherwise extensibility is broken).

No, that's why we previously had extensibility in each packet type. An ASN.1 SEQUENCE has no overall length indicator because the sequence of fields is known and their length can be determined independently.

As we've discussed before, this is why you can't send an ILP packet over a transport that doesn't support framing because if you get a bad packet you don't know when the the next good packet starts.

I couldn't find a document that describes how CLASS is encoded in OER, so I don't know whether the ASN.1 is technically correct.

CLASS is not explicitly encoded. It is a way of defining Information Objects which are arrangements of other ASN.1 types. See http://www.oss.com/asn1/resources/asn1-made-simple/advanced-topics.html

In our definition of PACKET we specify that a packet must be defined by a UInt8 type and then the packet data.

We then define PacketSet which is the acceptable list of types.

This is not valid ASN.1 but basically we define an InterledgerPreparePacket as:

InterledgerPreparePacket ::= SEQUENCE {
  type ::= UInt8 12,
  data ::= SEQUENCE {
    amount UInt64,
    expiresAt Timestamp,
    executionCondition UInt256,
    destination Address,
    data OCTET STRING (SIZE (0..32767))
  }
}

[adrianhopebailie]

I used the tool at http://asn1-playground.oss.com/ and it produces the same output as the implementation so either they are both wrong (unlikely) or there is some aspect of OER encoding that I need to understand better (more likely).

Encoding to the file 'data.oer' using OER encoding rule...
InterledgerPacket SEQUENCE
  type UInt8 INTEGER [length = 1]
    12
  data InterledgerPrepare SEQUENCE
    amount UInt64 INTEGER [length = 8]
      1000
    expiresAt Timestamp PrintableString [length = 17]
      "20170212201100000"
    executionCondition UInt256 OCTET STRING [length = 32]
      0x0000000000000000000000000000000000 ...
    destination Address IA5String [length = 6]
      "g.test"
    data OCTET STRING [length = 0]
      <no content>
Total encoded length = 67
Encoded successfully in 67 bytes:
0C410000 00000000 03E83230 31373032 31323230 31313030 30303000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000006 672E7465
737400

0C = 12
41 = 65 (length of data)
000000 00000003 E8 = 1000 (amount)
323031 37303231 32323031 31303030 3030 = "20170212201100000" (expiresAt)
0000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 0000 = 0 (condition as UInt256)
06 + 67 2E746573 74 = 6 (length of address) + "g.test" (address)
00 = 0 (length of data)

[justmoon]

The InterledgerPacket's data field is what's called an open type. The OER spec says:

30 Encoding of open type values

NOTE – An open type is an ASN.1 type that can take any abstract value of any ASN.1 type. Each value of an open type consists of:
a) a contained type; and
b) a value of the contained type.

The encoding of an open type value shall consist of a length determinant (see 8.6) followed by a series of octets, which are the encoding of the value of the contained type.

(emphasis added)

So both OSS' and our implementations are both correct in adding a length determinant.

[adrianhopebailie]

I realized when implementing this, the reason for having the length and it's important for implementors to be aware of this if they wish to be forward-compatible (although this is less of an issue in ILPv4 because there is not case when you would forward a packet with a type you don't know.)

Since this is an Open Type, a decoder may encounter a type value they don't recognize (e.g. 15) and therefor don't know how to decode the associated data. There may be situations where this is not a critical error and so the decoder can simply consume the correct number of bytes and continue decoding the rest of the message (and possibly forward these un-parsable bytes to the next entity).

[adrianhopebailie]

I think this is actually incorrect. The size of the packets will be emergent and has nothing to do with the protocol. The protocol limits amounts per packet to UInt64.MAX and given that this can be scaled it's effectively unlimited.

I think you could replace "designed primarily for "penny switching", or routing large volumes of smaller-value packets. ILPv4" with "which"

[adrianhopebailie]

I would recommend using the term Account and not balance as this aligns well with financial terminology people will be familiar with.

I also think defining the term Node makes a lot of explanations simpler.

• Node - A participant in an Interledger payment (node on the Interledger network), that has accounts with one or more other nodes. There are three specializations of a node:
  • Senders - originate payments
  • Receivers - are the final recipients of payments, and
  • Connectors - are the intermediaries between a sender and a receiver that forward ILP packets. They may generate revenue from spreads on currency conversion, through subscription fees, or other means.

(Moved connector definition up here)

• Peer - A node with which another node holds an account. In some cases the relationship between two nodes will be a parent/child relationship whereby the parent provides additional services to the child beyond simply forwarding ILP packets.

• Account - Two peers establish an account with one another where they track the current obligations they hold with one another; i.e. the balance on the account. The account is denominated in a single asset. The peers agree on the precision and scale they will use for the amounts of that asset when they express amounts in messages between one another. Accounts may be pre-funded (in which case the customer or peer trusts the connector for the value of the account balance) or post-funded (in which case the connector trusts the customer or peer for the amount the account is allowed to go negative). Connectors may refuse to process further ILP packets if an account balance goes too low.

@sharafian said:

The amount of trust required to practically transact is related inversely to the speed of the ledger used for settlement.

This is a useful point to make somewhere in this document but not here in the definitions.

[adrianhopebailie]

within a given time period.

This sounds like a hard limit as opposed to a limit on the total in-flight. Is that intentional?

[adrianhopebailie]

@sharafian suggested:

These do not correspond to on-ledger escrow, but allow parties to verify that their balances are correct.

I would go further and say that these are key to the reconciliation of balances between peers. Two peers should only consider an ILP payment complete (and therefor have an impact on the account between them) iff:

• the fulfillment is valid (the SHA-256 hash of it is exactly equal to the condition)
• the fulfillment was delivered before the expiry

[adrianhopebailie]

@sharafian said:

so they can determine how much to settle

How can this be different from the amount they specified in the prepare packet?

[adrianhopebailie]

I agree with @sharafian here. We should describe it as part of the overall process but not put it in the flow. This may be a pre-paid account in which case this step happens before step 2.

[adrianhopebailie]

"applies their exchange rate" and adjusts the amount to the appropriate scale and precision of the account on the outgoing channel.

[adrianhopebailie]

Some explanation as to what "earlier" means and how they would calculate this (or is that described somewhere else?)

[adrianhopebailie]

@sharafian depending on your definition of "communication channel" that is implied.

http://www.enterpriseintegrationpatterns.com/patterns/messaging/PointToPointChannel.html

[wilsonianb]

I'm still unclear on if the ILP Reject packet is necessary since the previous connector will just time out before receiving the Fulfill packet. Is the reject simply a courtesy?

[emschwartz]

I'll add a bit more of a description about that.

In short, the answer is that connectors must relay reject packets that they get. In addition, connectors can set timers for outgoing prepared and send back reject packets when they expire. I haven't thought about this too much but that's probably in the category of recommended behavior rather than mandatory functionality.

[sharafian]

I think right now a lot of things won't work without the ILP reject, but nobody will lose money so you could argue it's technically not necessary

[mDuo13]

Looking much, much better.

I strongly disagree with the term "node" (sorry I didn't jump on to weigh in on that sooner) and suggest "participant" instead.

Otherwise, I caught a couple typos and some ambiguous wordings but nothing big. Excited to see this finalized.

[mDuo13]

ILP Prepare packets are sent with a condition or SHA-256 hash in them. When the receiver receives the packet, they present the fulfillment, or valid preimage of the hash, to execute the transfer.

Is this intended to leave open the possibility that a condition might not be a SHA-256 hash? That's the implication I read from this phrasing. If that's not intended, I recommend the following rephrase:

ILP Prepare packets contain a condition in the form of a SHA-256 hash. When the receiver receives the packet, they present the fulfillment, in the form of a valid preimage of the condition hash, to execute the transfer.

[mDuo13]

This may be affected by sending multiple ILP Packets that together result in the total transfer of value required to complete the payment.

In this context, "affected" is the wrong verb. @adrianhopebailie's original "effected" was correct, if confusing. A less tricky rephrase might be as follows:

Higher-level protocols may execute a "payment" by sending a series of ILP Packets whose sum is equal to the desired payment value.

[mDuo13]

Apologies for being contrary here, but I have strong feelings against using the term "node" for this meaning, because the term "node" is so overloaded. In the XRP Ledger, people constantly misunderstand what constitutes a "node" and what level it exists on. Is a "node" the software server? A data structure? An identity? And so on.

I suggest using the term "Participant" here instead, and maybe even clarifying that a participant is probably a person or business entity—something that can own assets, generally.

[mDuo13]

Typo: accountsl

[mDuo13]

In some cases the relationship between two nodes will be a parent/child relationship whereby the parent provides additional services to the child beyond simply forwarding ILP packets.

Suggest simplifying this:

In some cases, one participant may provide additional services to the peer beyond simply forwarding ILP Packets.

Alternatively, I think it might be OK to remove the sentence entirely.

[mDuo13]

minimum account balances

Maybe "minimum or maximum"?

[mDuo13]

typo: noce

I think this is meant to read "node" but I suggest "participant" instead (categorically) as in my earlier comments.

[mDuo13]

...they may automatically credit accounts when payment channel updates or external transfers are received.

Suggest rephrasing to active voice:

..they may automatically credit accounts when they receive payment channel updates or external transfers.

[dora-gt]

I left some comments.
I'm sorry if I'm missing something and asking some strange questions.

[dora-gt]

It may be better that clarifying the words: "smaller-value packets", "penny-switching" and "chunked payments". I can understand the words because I know it already, but those who read this document for the first time may not be able to.

e.g.

ILPv4 sends large amount of money splitting it into "smaller-value packets", sending it repeatedly. As single packet transfers very small amount of value, we call it "penny-switching". It is also called "chunked-payments".

[dora-gt]

I may change like this,
but the Interledger layer is the one part where widespread agreement is needed for interoperability.
to
but the Interledger layer is the one part where widespread agreement is needed for interoperability and simplicity enables it.

[dora-gt]

Does this mean Payment Channel? or just an account on a ledger?

[emschwartz]

Neither actually, it's a kind of virtual account that tracks the value of settlements or payment channel claims minus the total value of fulfilled ILP packets.

If I've sent 100 units of packets through you and only sent you payment channel updates totaling 80 units, my account balance with you would be -20 units.

On the other hand, if I've prepaid and sent you 250 units upfront and then sent 100 units worth of packets through you, my account balance with you would be 150 units.

[dora-gt]

Link to 0016-pre-shared-key/0016-pre-shared-key.md helps a lot.
It was very hard for me to understand the relationship between condition and fulfillment.
Now I can understand thanks to the pseudo code in the bottom of the page.

[dora-gt]

constrast -> contrast?

[dora-gt]

Websocket -> WebSocket maybe?

[dora-gt]

How to determine who the sender is? I could not imagine because ILP packet does not contain the sender address.

[dora-gt]

On the same connection that the connector received the ILP Prepare packet on?
If the connection is lost, the connector may not be able to return the fulfillment packet because they can't identify who the sender was (ILP packet doesn't contain sender address).
Am I missing something?

[mDuo13]

The connection has to be authenticated in such a way that the connector can identify the sender and recognize which pre-established account¹ is theirs.

¹ In this case, the "account" is probably a payment channel but it could also be some other means of tracking a balance between the connector and the sender.

[dora-gt]

@mDuo13 is there protocol for it?

[mDuo13]

After reading @dora-gt 's comments, I think some things would be clearer if this RFC included a section defining the prerequisites—the necessary setup—for a sender and a connector to do ILPv4 transfers with one another. That would probably help clarify the account, connection authentication, and payment channel distinctions. Part of why they're confusing now is that you have to infer what the necessary setup is from the description of the repeatable process.

[dora-gt]

I think it's still unclear that WHO has the responsibility to maintain the account, and WHERE to store it.

[mDuo13]

New prerequisites section helps a lot

[ukstv]

This account definition reminds me of loro/nostro accounts, but surely is not. Could it be renamed totally to Link or Stream or something else? For fun: that could lead to uplink/downlink metaphor, which reflects connector and client distinction quite right. @emschwartz

[emschwartz]

There are probably some similarities, but I'm not a real expert on nostro/vostro accounts.

Link is an interesting idea, and kind of funny because the layer below the internetworking layer in the old OSI model is called the Data Link layer. You establish a "Money Link" with your peer...

It would help clear up the confusion between "accounts" on the underlying ledgers and the balance you hold with your Interledger peer

[adrianhopebailie]

Suggest this is merged and further discussion is raised as issues.

Looks like this is IL RFC 0027!

[rhuairahrighairidh]

I like document. Clears up a lot of confusions.
Although I feel it would be hard to understand without an understanding of the general interledger architecture.
In the future, adding a link back to an improved version of rfc001 would be nice.

[justmoon]

LGTM