02a9b1e237
he didn't allow for multiple HTLCs. Gotta explain the rationale for that that... will merge the progress in the next commit tomorrow.
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).
|