106 lines
4.1 KiB
Plaintext
106 lines
4.1 KiB
Plaintext
|
NOTE: Not implemented in code, only included as part of the wire protocol for
|
||
|
|
future implementation!
|
||
|
|
|
||
|
|
There are multiple R-value hashes supported in HTLCs in the wire protocol. 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 normal escrow which holds custody, but
|
||
|
|
determines who should get the money in the event of non-cooperation.
|
||
|
|
|
||
|
|
In this implementation, we are including *future protocol support* but not
|
||
|
|
writing code yet for 2-of-3, it is to be implemented later. Arbitrary N-of-M
|
||
|
|
can be supported, 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. This means each hop consumes a higher amount
|
||
|
|
of time-value (due to much longer timeouts along all channels in the path),
|
||
|
|
which does have greater pressure towards lower hop-distances compared to
|
||
|
|
straight payments.
|
||
|
|
|
||
|
|
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). It's some secret which is revealed to authorize payment. So if the
|
||
|
|
Escrow wants the payment to go through, 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.
|
||
|
|
|
||
|
|
Supported in the wire protocol for the unit8:
|
||
|
|
1: 1-of-1
|
||
|
|
2: 1-of-2
|
||
|
|
3: 2-of-2
|
||
|
|
4: 1-of-3
|
||
|
|
5: 2-of-3
|
||
|
|
6: 3-of-3
|
||
|
|
|
||
|
|
I think the only ones that really matter are 1-of-1, 2-of-3, and maybe 2-of-2
|
||
|
|
and 3-of-3 (in that order of declining importance).
|
||
|
|
|
||
|
|
Assume the order in the stack is Sender, Recipient, Escrow.
|
||
|
|
|
||
|
|
For PAID 2-of-3 Recipient+Escrow, the HTLC stack is:
|
||
|
|
<BobSig> <0> <RecipientPreimageR> <EscrowPreimageR> <0>
|
||
|
|
|
||
|
|
If it's REFUND because 2-of-3 has not been redeemed in time:
|
||
|
|
<AliceSig> <1>
|
||
|
|
|
||
|
|
Script (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
|
||
|
|
//Optional... <CSVDelay> OP_CSV
|
||
|
|
|
||
|
|
OP_HASH160 <EscrowHash> OP_EQUAL
|
||
|
|
//Stack: <BobSig> <0> <RecipientPreimageR> <OP_1>
|
||
|
|
OP_SWAP
|
||
|
|
//Stack: <BobSig> <0> <OP_1> <RecipientPreimageR>
|
||
|
|
OP_HASH160 <RecipientHash> OP_EQUAL
|
||
|
|
//Stack: <BobSig> <0> <OP_1> <OP_1>
|
||
|
|
OP_ADD
|
||
|
|
//Stack: <BobSig> <0> <OP_2>
|
||
|
|
OP_SWAP
|
||
|
|
//Stack: <BobSig> <OP_2> <0>
|
||
|
|
OP_HASH160 <SenderHash> OP_EQUAL
|
||
|
|
//Stack: <BobSig> <OP_2> <OP_0>
|
||
|
|
OP_ADD
|
||
|
|
//Stack: <BobSig> <OP_2>
|
||
|
|
<2> OP_EQUALVERIFY
|
||
|
|
|
||
|
|
<BobPubKey>
|
||
|
|
//Stack: <BobSig> <BobPubKey>
|
||
|
|
//Refund
|
||
|
|
OP_ELSE
|
||
|
|
//Optional... <CSVDelay> OP_CSV
|
||
|
|
|
||
|
|
<HTLCTimeout> OP_CLTV
|
||
|
|
<AlicePubKey>
|
||
|
|
//Stack: <AliceSig> <AlicePubKey>
|
||
|
|
OP_ENDIF
|
||
|
|
OP_CHECKSIG
|
||
|
|
-------------------------------------------------------------------------------
|
||
|
|
|
||
|
|
Note: It is possible that Alice and Bob may not be Sender, Recipient, nor
|
||
|
|
Escrow!
|
||
|
|
|
||
|
|
If we have all 3 R-values, we only include 2 and include a dummy zero on the
|
||
|
|
third.
|
||
|
|
|
||
|
|
The result? We can do 2-of-3 escrow payments which refund to the sender after a
|
||
|
|
timeout! The Buyer and Seller can agree to redeem and they only need to go to
|
||
|
|
the Escrow if there's a dispute. Each node along the path gets paid or refunded
|
||
|
|
atomically, the same as a single-HTLC payment on Lightning.
|
||
|
|
|
||
|
|
Ta-da! "Smart Contract(TM)" maymay.
|
||
|
|
|
||
|
|
Immediately refundable payments (2-of-3 can immediately cancel a payment) are
|
||
|
|
also possible but requires another payment in the opposite direction with the
|
||
|
|
R-value hashed twice (the R value becomes the H), but that's kind of annoying to
|
||
|
|
write... it's easier to just assume immediate refund can only occur if both
|
||
|
|
buyer+seller agree to cancel the payment immediately (otherwise it will wait
|
||
|
|
until the timeout).
|