Joseph Poon [ARCHIVE] on Nostr: 📅 Original date posted:2016-01-16 📝 Original message: TL;DR: It's possible to ...
📅 Original date posted:2016-01-16
📝 Original message:
TL;DR: It's possible to do 2-of-3 party escrow in Lightning,
functionally the same as the use case for on-chain "2-of-3 multisig"
escrow systems (without the 3rd party escrow being a custodian for any
funds! Or anyone else holding custodial ownership of coins for the
matter). As Lightning uses Bitcoin transactions and scripts (using
Bitcoins, not 3rdPartyCoins), it'll be possible to do nearly *instant*
*offchain* multisig "escrow" on decentralized Lightning! This is useful
for payments for goods and services which needs a 3rd party mediator.
By making multiple R-value hashes supported in HTLCs, you can do
something equivalent to "multisig" where payments are conditional upon
2-of-3 parties agreeing. This is to support conditional multiparty
payments, e.g. 2-of-3 "escrow", which is one of the biggest use cases of
bitcoin scripting today. An example use case is a 3rd party escrow
verifies whether a seller should be paid. This design is such that the
escrow is not a traditional custodial escrow, but instead determines who
should get the money in the event of non-cooperation. See the Bitcoin
Script below for details.
There isn't message integration for 2-of-3 yet, but can work with *very*
minimal changes. Arbitrary N-of-M can be supported with M values higher
than 3 and lower than max script size, but let's keep this simple for
now!
How it works: Require 2-of-3 R-value preimages (from 3 hashes) in order
for the HTLC to be fulfilled. For each hop in the payment, it requires
this 2-of-3 condition. The timeout minimum for each hop in the path is
at least the minimum agreed contractual escrow timeout. The timeouts
should be fairly long compared to straight payments for security and
giving enough time for the escrow service. This means each hop consumes
a higher amount of time-value (due to much longer timeouts along all
channels in the path, and possibly higher fees to pay for larger scripts
and greater time-sensitivity for transaction inclusion), which does have
greater pressure towards lower hop-distances, compared to straight
payments where it matters a whole lot less.
This is a slightly different way of thinking about things. It's not
signatures that the escrow produces (or for that matters any of the
3-parties in the 2-of-3 after the actual Commitment is signed). It's
some secret which is revealed to authorize payment. So if the escrow
wants the payment to go through without cooperation of the sender, they
disclose the secret (R-value) to the recipient. If the recipient is
unable to produce 2-of-3, after the agreed timeout, the sender will be
refunded. Sender and receiver can agree to authorize payment in most
cases where there is cooperation, escrow is only contacted if there is
non-cooperation.
Assume the order in the stack is Sender, Escrow, Recipient.
For PAID 2-of-3 Escrow+Recipient, the HTLC stack is:
<BobSig> <0> <EscrowPreimageR> <RecipientPreimageR> <0>
If it's REFUND because 2-of-3 has not been redeemed in time:
<AliceSig> <0> <1>
Bitcoin Script (Alice's, we use OP_1/OP_0 to distinctly show computed
true/false. 0/1 is for supplied data as part of the
sigScript/redeemScript stack):
------------------------------------------------------------------------
//Paid
OP_IF
<CSVDelay> OP_DROP OP_CSV //under rusty's CSV style
//Stack: <BobSig> <0> <EscrowPreimageR> <RecipientPreimageR>
//Recipient must agree to receive funds.
OP_HASH160 <RecipientHash> OP_EQUALVERIFY
//Stack: <BobSig> <0> <EscrowPreimageR>
//Either the Sender or Escrow must consent for payment
OP_HASH160 <EscrowHash> OP_EQUAL
//Stack: <BobSig> <0> <OP_1>
OP_SWAP
//Stack: <BobSig> <OP_1> <0>
OP_HASH160 <SenderHash> OP_EQUAL
//Stack: <BobSig> <OP_1> <OP_0>
OP_BOOLOR
//Stack: <BobSig> <OP_1>
OP_VERIFY
<BobPubKey>
//Stack: <BobSig> <BobPubKey>
//Refund
OP_ELSE
//Stack: <AliceSig> <0>
OP_HASH160 OP_DUP
<R-HASH> OP_EQUAL
OP_NOTIF
<CSVDelay> OP_DROP OP_CSV
OP_ENDIF
<HTLCTimeout> OP_DROP OP_CLTV
//Stack: <AliceSig>
<AlicePubKey>
//Stack: <AliceSig> <AlicePubKey>
OP_ENDIF
OP_CHECKSIG
------------------------------------------------------------------------
Note: It is possible that Alice and Bob may not be Sender, Recipient,
nor Escrow! They could be nodes along the routing path. Script might
have a typo or two or might be able to be optimized a couple bytes
smaller maybe? Also, the script would be a bit different depending upon
is broadcasting due to the revocations/R-HASH.
The result? We can do 2-of-3 escrow payments which refund to the sender
after a timeout! The Sender and Recipient can agree to redeem and they
only need to go to the Escrow if there's a dispute. All nodes along the
path gets paid or refunded atomically, the same as a single-HTLC payment
on Lightning. Escrowed payments can be nearly instant and off-chain (but
enforced/net-settled ultimately using the blockchain).
Proposed HTLC wire message for the uint8 (two 4-bit N-of-M) determining
type:
0x11 (00010001): 1-of-1
0x22 (00100010): 2-of-2
0x23 (00100011): 2-of-3 [with Recipient being 1 of the two N parties]
0x33 (00110011): 3-of-3
I think the only ones that really matter are 1-of-1, 2-of-3, and 2-of-2.
1-of-2 and 1-of-3 doesn't make sense if the recipient must consent to
receiving funds anyway (pushing funds w/o consent is tricky due to
pay-to-contract-hash) so that's basically a 1-of-1.
Possible Resolution States:
* Recipient paid: Recipient and Sender provide R-values
* Recipient paid: Recipient and Escrow provide R-values
* Sender refunded via timeout: Sender is refunded if Recipient cannot
convince Escrow or Sender to disclose their R-value before HTLC
timeout
* Payment immediately cancelled and Sender gets refunded: Payment sent
in the opposite direction enforced by same R-values (if there is
sender & receiver consent/cooperation to cancel payment)
Sender+Escrow isn't going to want to push funds w/o cooperation of
Recipient. However, it's possible to construct a script that way.
Escrow is only contacted if the recipient needs to redeem and the sender
is uncooperative so this is still true to the "lazy escrow service" in
Bitcoin multisig.
Ta-da! "Smart Contract(TM)" meme on Lightning.
P.S. Tadge, Laolu, and I have also put up a repo of our in-progress
design/code for Lightning here: https://github.com/LightningNetwork/lnd
--
Joseph Poon
📝 Original message:
TL;DR: It's possible to do 2-of-3 party escrow in Lightning,
functionally the same as the use case for on-chain "2-of-3 multisig"
escrow systems (without the 3rd party escrow being a custodian for any
funds! Or anyone else holding custodial ownership of coins for the
matter). As Lightning uses Bitcoin transactions and scripts (using
Bitcoins, not 3rdPartyCoins), it'll be possible to do nearly *instant*
*offchain* multisig "escrow" on decentralized Lightning! This is useful
for payments for goods and services which needs a 3rd party mediator.
By making multiple R-value hashes supported in HTLCs, you can do
something equivalent to "multisig" where payments are conditional upon
2-of-3 parties agreeing. This is to support conditional multiparty
payments, e.g. 2-of-3 "escrow", which is one of the biggest use cases of
bitcoin scripting today. An example use case is a 3rd party escrow
verifies whether a seller should be paid. This design is such that the
escrow is not a traditional custodial escrow, but instead determines who
should get the money in the event of non-cooperation. See the Bitcoin
Script below for details.
There isn't message integration for 2-of-3 yet, but can work with *very*
minimal changes. Arbitrary N-of-M can be supported with M values higher
than 3 and lower than max script size, but let's keep this simple for
now!
How it works: Require 2-of-3 R-value preimages (from 3 hashes) in order
for the HTLC to be fulfilled. For each hop in the payment, it requires
this 2-of-3 condition. The timeout minimum for each hop in the path is
at least the minimum agreed contractual escrow timeout. The timeouts
should be fairly long compared to straight payments for security and
giving enough time for the escrow service. This means each hop consumes
a higher amount of time-value (due to much longer timeouts along all
channels in the path, and possibly higher fees to pay for larger scripts
and greater time-sensitivity for transaction inclusion), which does have
greater pressure towards lower hop-distances, compared to straight
payments where it matters a whole lot less.
This is a slightly different way of thinking about things. It's not
signatures that the escrow produces (or for that matters any of the
3-parties in the 2-of-3 after the actual Commitment is signed). It's
some secret which is revealed to authorize payment. So if the escrow
wants the payment to go through without cooperation of the sender, they
disclose the secret (R-value) to the recipient. If the recipient is
unable to produce 2-of-3, after the agreed timeout, the sender will be
refunded. Sender and receiver can agree to authorize payment in most
cases where there is cooperation, escrow is only contacted if there is
non-cooperation.
Assume the order in the stack is Sender, Escrow, Recipient.
For PAID 2-of-3 Escrow+Recipient, the HTLC stack is:
<BobSig> <0> <EscrowPreimageR> <RecipientPreimageR> <0>
If it's REFUND because 2-of-3 has not been redeemed in time:
<AliceSig> <0> <1>
Bitcoin Script (Alice's, we use OP_1/OP_0 to distinctly show computed
true/false. 0/1 is for supplied data as part of the
sigScript/redeemScript stack):
------------------------------------------------------------------------
//Paid
OP_IF
<CSVDelay> OP_DROP OP_CSV //under rusty's CSV style
//Stack: <BobSig> <0> <EscrowPreimageR> <RecipientPreimageR>
//Recipient must agree to receive funds.
OP_HASH160 <RecipientHash> OP_EQUALVERIFY
//Stack: <BobSig> <0> <EscrowPreimageR>
//Either the Sender or Escrow must consent for payment
OP_HASH160 <EscrowHash> OP_EQUAL
//Stack: <BobSig> <0> <OP_1>
OP_SWAP
//Stack: <BobSig> <OP_1> <0>
OP_HASH160 <SenderHash> OP_EQUAL
//Stack: <BobSig> <OP_1> <OP_0>
OP_BOOLOR
//Stack: <BobSig> <OP_1>
OP_VERIFY
<BobPubKey>
//Stack: <BobSig> <BobPubKey>
//Refund
OP_ELSE
//Stack: <AliceSig> <0>
OP_HASH160 OP_DUP
<R-HASH> OP_EQUAL
OP_NOTIF
<CSVDelay> OP_DROP OP_CSV
OP_ENDIF
<HTLCTimeout> OP_DROP OP_CLTV
//Stack: <AliceSig>
<AlicePubKey>
//Stack: <AliceSig> <AlicePubKey>
OP_ENDIF
OP_CHECKSIG
------------------------------------------------------------------------
Note: It is possible that Alice and Bob may not be Sender, Recipient,
nor Escrow! They could be nodes along the routing path. Script might
have a typo or two or might be able to be optimized a couple bytes
smaller maybe? Also, the script would be a bit different depending upon
is broadcasting due to the revocations/R-HASH.
The result? We can do 2-of-3 escrow payments which refund to the sender
after a timeout! The Sender and Recipient can agree to redeem and they
only need to go to the Escrow if there's a dispute. All nodes along the
path gets paid or refunded atomically, the same as a single-HTLC payment
on Lightning. Escrowed payments can be nearly instant and off-chain (but
enforced/net-settled ultimately using the blockchain).
Proposed HTLC wire message for the uint8 (two 4-bit N-of-M) determining
type:
0x11 (00010001): 1-of-1
0x22 (00100010): 2-of-2
0x23 (00100011): 2-of-3 [with Recipient being 1 of the two N parties]
0x33 (00110011): 3-of-3
I think the only ones that really matter are 1-of-1, 2-of-3, and 2-of-2.
1-of-2 and 1-of-3 doesn't make sense if the recipient must consent to
receiving funds anyway (pushing funds w/o consent is tricky due to
pay-to-contract-hash) so that's basically a 1-of-1.
Possible Resolution States:
* Recipient paid: Recipient and Sender provide R-values
* Recipient paid: Recipient and Escrow provide R-values
* Sender refunded via timeout: Sender is refunded if Recipient cannot
convince Escrow or Sender to disclose their R-value before HTLC
timeout
* Payment immediately cancelled and Sender gets refunded: Payment sent
in the opposite direction enforced by same R-values (if there is
sender & receiver consent/cooperation to cancel payment)
Sender+Escrow isn't going to want to push funds w/o cooperation of
Recipient. However, it's possible to construct a script that way.
Escrow is only contacted if the recipient needs to redeem and the sender
is uncooperative so this is still true to the "lazy escrow service" in
Bitcoin multisig.
Ta-da! "Smart Contract(TM)" meme on Lightning.
P.S. Tadge, Laolu, and I have also put up a repo of our in-progress
design/code for Lightning here: https://github.com/LightningNetwork/lnd
--
Joseph Poon