Basic ILP flow #124
Basic ILP flow #124
Conversation
pgarg-ripple
requested review from
adrianhopebailie,
sappenin,
emschwartz,
sharafian and
kincaidoneil
|
|
||
| ### Payment flow | ||
|
|
||
| 1. The sender initiates a payment by connecting with the receiver over an out-of-band authenticated channel and obtaining the receiver's ILP address and a secret hash condition. |
There was a problem hiding this comment.
While possible, are you actually trying to describe SPSP here? Or is this meant to be a more generic thing?
There was a problem hiding this comment.
My intention is to keep it generic. I didn't want to name SPSP or moneyd in this flow because similar applications can be created by anyone in the future but the general concept will remain the same (I guess?).
There was a problem hiding this comment.
We should make the prerequisites more generic in that case, because right now they say "payment pointer"
There was a problem hiding this comment.
(Lois here): I've taken this file over in Prachi's absence. How about persistent payment identifier then, as a payment pointer is meant to be a persistent identifier?
| ### Payment flow | ||
|
|
||
| 1. The sender initiates a payment by connecting with the receiver over an out-of-band authenticated channel and obtaining the receiver's ILP address and a secret hash condition. | ||
| 0. The sender constructs a Prepare packet with the destination ILP address, the secret hash condition, amount, and expiry. |
There was a problem hiding this comment.
Nit: the sender and recipient are exchanging a shared secret they can use to derive fulfillments, but that secret isn't a "hash condition" itself (but it's fine if that simplifies the explanation)
There was a problem hiding this comment.
| 0. The sender constructs a Prepare packet with the destination ILP address, the secret hash condition, amount, and expiry. | |
| 0. The sender constructs a Prepare packet with the destination ILP address, the derived hash condition, amount, and expiry. |
There was a problem hiding this comment.
derived could be confusing if we're not making the assumption that this is through STREAM
| 0. The router forwards the Prepare packet to the next hop, which may be another router. All subsequent routers go through steps 4-6 (treating the previous router as the sender) until the packet reaches the receiver. | ||
| 0. The receiver receives the packet and checks the packet contents, for example, if the amount to be received is acceptable. | ||
| 0. If the receiver accepts the Prepare packet, the receiver returns a Fulfill packet. If the receiver does not want the Prepare packet or it does not pass one of the checks, the receiver returns a Reject packet instead. | ||
| 0. The router checks if the receiver returned a Fulfill before the expiry in the Prepare packet. If so, the router returns the same Fulfill packet to the previous router. If the receiver returned a Reject packet or the Prepare expired before the Fulfill was returned, the router returns the Reject packet to the preceding router. Each router repeats this step until the Fulfill or Reject packet reaches the sender. |
There was a problem hiding this comment.
The router also must check that the fulfillment is the preimage to the hash/execution condition, otherwise the Fulfill is invalid. This is an important part of the story: what's preventing any intermediary connector from just returning the Fulfill packet?
|
My two cents: this focuses a lot on the expiration part of the flow, but omits how Interledger's cryptographic proof of payment fits in -- I'd like a little more on that if possible |
| 0. The router forwards the Prepare packet to the next hop, which may be another router. All subsequent routers go through steps 4-6 (treating the previous router as the sender) until the packet reaches the receiver. | ||
| 0. The receiver receives the packet and checks the packet contents, for example, if the amount to be received is acceptable. | ||
| 0. If the receiver accepts the Prepare packet, the receiver returns a Fulfill packet. If the receiver does not want the Prepare packet or it does not pass one of the checks, the receiver returns a Reject packet instead. | ||
| 0. The router checks if the receiver returned a Fulfill before the expiry in the Prepare packet. If so, the router returns the same Fulfill packet to the previous router. If the receiver returned a Reject packet or the Prepare expired before the Fulfill was returned, the router returns the Reject packet to the preceding router. Each router repeats this step until the Fulfill or Reject packet reaches the sender. |
There was a problem hiding this comment.
| 0. The router checks if the receiver returned a Fulfill before the expiry in the Prepare packet. If so, the router returns the same Fulfill packet to the previous router. If the receiver returned a Reject packet or the Prepare expired before the Fulfill was returned, the router returns the Reject packet to the preceding router. Each router repeats this step until the Fulfill or Reject packet reaches the sender. | |
| 0. The router checks if the receiver returned a Fulfill before the expiry in the Prepare packet. It also verifies that the fulfillment received from the receiver matches the original condition received in the Prepare packet from the sender. If both checks pass, the router returns the same Fulfill packet to the previous router. If the receiver returned a Reject packet or the Prepare expired before the Fulfill was returned or the fulfilment was invalid, the router returns the Reject packet to the preceding router. Each router repeats this step until the Fulfill or Reject packet reaches the sender. |
There was a problem hiding this comment.
I got a little confused where this was talking about SPSP or STREAM or ILP. Things like deriving the condition or exchanging a shared secret, or breaking the payment into many packets seem to be implicitly referencing STREAM. Talking about payment pointers in the prerequisites refers to SPSP. But the rest seems to be referring to ILP.
If the goal is just to describe the life cycle of a single ILP packet then this could be simplified a bit. You could move the condition into the prerequisites and just assume that the sender and receiver have some way of working out a condition that the receiver knows the preimage of.
|
|
||
| ### Payment flow | ||
|
|
||
| 1. The sender initiates a payment by connecting with the receiver over an out-of-band authenticated channel and obtaining the receiver's ILP address and a secret hash condition. |
There was a problem hiding this comment.
We should make the prerequisites more generic in that case, because right now they say "payment pointer"
| ### Payment flow | ||
|
|
||
| 1. The sender initiates a payment by connecting with the receiver over an out-of-band authenticated channel and obtaining the receiver's ILP address and a secret hash condition. | ||
| 0. The sender constructs a Prepare packet with the destination ILP address, the secret hash condition, amount, and expiry. |
There was a problem hiding this comment.
derived could be confusing if we're not making the assumption that this is through STREAM
| 0. The sender sends the Prepare packet to the router it is connected to. | ||
| 0. The router checks the expiry of the Prepare packet. If the router receives the packet after the expiry, the router sends a Reject packet to the sender. If the router receives the packet before the expiry, the following steps take place. | ||
| 0. The router uses its local routing tables and the destination address from the Prepare packet to determine which next hop to forward the packet to. The next hop can be another router or the receiver. | ||
| 0. The router determines the outgoing asset type based on the next hop it will forward the packet to and applies its exchange rate and fees to the Prepare amount. |
There was a problem hiding this comment.
The router also moves the expiry of the packet a little bit earlier, to give it a window of time (called the min message window in the code) during which it can pass the fulfill backwards. That also means that when checking the expiry the router needs to ensure there's enough time left to take this min message window off. Typically min message window is around a second but could be configured to be more or less depending on network conditions
| 0. The receiver receives the packet and checks the packet contents, for example, if the amount to be received is acceptable. | ||
| 0. If the receiver accepts the Prepare packet, the receiver returns a Fulfill packet. If the receiver does not want the Prepare packet or it does not pass one of the checks, the receiver returns a Reject packet instead. | ||
| 0. The router checks if the receiver returned a Fulfill before the expiry in the Prepare packet. If so, the router returns the same Fulfill packet to the previous router. If the receiver returned a Reject packet or the Prepare expired before the Fulfill was returned, the router returns the Reject packet to the preceding router. Each router repeats this step until the Fulfill or Reject packet reaches the sender. | ||
| 0. Sender repeats the process, starting from step 2, as many times as is necessary to transfer the desired total amount of value. |
There was a problem hiding this comment.
if we're talking about a chunked payment then this leaves out some thing for instance determining the MTU
|
@LoisRP For a while back in October, we were trying to rename the "Connector" to a "Router" and started using that term. However, this has never really taken hold, so I think we should just stick to calling the Connector a Connector. |
The purpose of this page to make the newcomers more familiar with Interledger before they dive deeper into other aspects (RFCs) of Interledger.
This page will be placed after the Overview page in the docs.
Please also review the UML diagram in this PR.
https://github.com/pgarg-ripple/interledger.github.io/blob/pg-ilp-flow/docs/markdown/ilp-flow.md