mention ILP-like transaction as special case #75

Open
michielbdejong opened this Issue Jan 5, 2017 · 3 comments

Comments

Projects
None yet
1 participant
@michielbdejong
Collaborator

michielbdejong commented Jan 5, 2017

Alice has an account at Bank
at Bank, Charlie has an account, with money in it.
Charlie wants to buy Alice's bicycle.

Alice offers her bicycle to Charlie and mentions a hash challenge
Charlie promises to give Bank permission to lower his account balance in exchange for the preimage
Bank promises to give Alice a higher account balance in exchange for the preimage

Alice gives the preimage to Bank
As promised, Bank gives Alice a higher account balance in exchange for the preimage

Bank gives the preimage to Charlie
As promised, Charlie gives Bank permission to lower his account balance in exchange for the preimage

Charlie shows the preimage to Alice
As promised, Alice gives her bicycle to Charlie in exchange for the preimage

@michielbdejong

This comment has been minimized.

Show comment
Hide comment
@michielbdejong

michielbdejong Jul 4, 2017

Collaborator

Actually, the way the "payment" use case works is slightly different, the hashlock doesn't travel full-loop:

  • Alice puts her bicycle on e-bay
  • Charlie instructs his bank to make an spsp payment to Alice
  • It either succeeds or fails, but one of the design features of Interledger is that all payments reach a final state quicky (say, in 10 seconds); if it fails you can retry
  • Once Alice sees the money in her account, she sends the bicycle to Charlie

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.

Collaborator

michielbdejong commented Jul 4, 2017

Actually, the way the "payment" use case works is slightly different, the hashlock doesn't travel full-loop:

  • Alice puts her bicycle on e-bay
  • Charlie instructs his bank to make an spsp payment to Alice
  • It either succeeds or fails, but one of the design features of Interledger is that all payments reach a final state quicky (say, in 10 seconds); if it fails you can retry
  • Once Alice sees the money in her account, she sends the bicycle to Charlie

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.

@michielbdejong

This comment has been minimized.

Show comment
Hide comment
@michielbdejong

michielbdejong Oct 2, 2017

Collaborator

Payments are used to settle one trustline at the expense of bringing other (more trusted) trustlines further out of balance.

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.

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.

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.

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.

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.

Collaborator

michielbdejong commented Oct 2, 2017

Payments are used to settle one trustline at the expense of bringing other (more trusted) trustlines further out of balance.

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.

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.

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.

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.

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.

@michielbdejong

This comment has been minimized.

Show comment
Hide comment
@michielbdejong

michielbdejong Oct 2, 2017

Collaborator

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.

Collaborator

michielbdejong commented Oct 2, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment