Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
mention ILP-like transaction as special case #75
Alice has an account at Bank
Alice offers her bicycle to Charlie and mentions a hash challenge
Alice gives the preimage to Bank
Bank gives the preimage to Charlie
Charlie shows the preimage to Alice
Actually, the way the "payment" use case works is slightly different, the hashlock doesn't travel full-loop:
Payments are used to settle one trustline at the expense of bringing other (more trusted) trustlines further out of balance. The special thing about them in Interledger is that they can succeed or fail, and they roll back if not successful within about 10 seconds. Also, the hashlock doesn't need to travel full-circle, it can be fulfilled by the payment-receiver if they share a secret with the payment-sender.
It doesn't always feel that way because the thing that's being paid for is left out of the picture. But every payment either creates a debt, or cancels one, or does a bit of both: if before the payment, the sender's one-to-one debt was at least equal to the payment amount, then it's just settling that debt. If it was lower (including if it was already zero or negative), the payment will create a payment in the other direction.
That part is important for retrying. It becomes asymptotically less important for streaming payments. It's useful in Interledger, but I'm still not sure if it's at all useful in LedgerLoops.
This is a funny point though, because if the sender explicitly gives the fulfillment to the receiver, especially if that's on the receiver's request, then that can be counted as the acceptance of the payment (see also the discussion about bulk-fulfill in interledger/rfcs repo). Without it, the sender sees "my money left my account, through the action of someone who knows our shared secret", but cannot prove to the receiver that this happened. If the sender had their computer hacked, they will get very confused about what they paid. So it's usually probably better to use some sort of payment request, where at least you get some immediate feedback when a payment gets derailed. The non-full circle comes at the cost of needing to securely remember shared secrets.
In LedgerLoops, we explicitly model the debt created/cancelled by the payment. So in that sense, it's a settlement.
One thing about one-off, as well as bulk-fulfill, Interledger (also related to the timeout) is that it's all-or-nothing. This is useful to make a sale conditional on liquidity: if I can't pay you, the sale is automatically cancelled. That's an arrangement between us, and it's useful when buying/selling non-dividable goods from/to a stranger. But bear in mind that this advantage needs to be provided by effectively an ILSP, and for that, centralization of power gives economies of scale. So if we can decide on a different peer-to-peer arrangement (e.g. escrow the goods) then we can keep the liquidity flow more peer-to-peer.