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 traditional custodial escrow, but instead determines who should get the money in the event of non-cooperation. In this implementation, we are including *wire protocol support* but not writing code yet for 2-of-3, it is to be implemented later. 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. 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 uint8 (two 4-bit N-of-M): 17 (00010001): 1-of-1 34 (00100010): 2-of-2 35 (00100011): 2-of-3 [with Recipient being 1 of the two N parties] 51 (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. Assume the order in the stack is Sender, Escrow, Recipient. For PAID 2-of-3 Escrow+Recipient, the HTLC stack is: <0> <0> If it's REFUND because 2-of-3 has not been redeemed in time: <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 OP_DROP OP_CSV //Stack: <0> //Recipient must agree to receive funds. OP_HASH160 OP_EQUALVERIFY //Stack: <0> //Either the Sender or Escrow must consent for payment OP_HASH160 OP_EQUAL //Stack: <0> OP_SWAP //Stack: <0> OP_HASH160 OP_EQUAL //Stack: OP_BOOLOR //Stack: OP_VERIFY //Stack: //Refund OP_ELSE OP_DROP OP_CSV OP_DROP OP_CLTV //Stack: OP_ENDIF OP_CHECKSIG ------------------------------------------------------------------------------- Note: It is possible that Alice and Bob may not be Sender, Recipient, nor Escrow! 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. 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. Ta-da! "Smart Contract(TM)" maymay. Escrow-enforced 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 H becomes the R-value) and funds encumbered in the opposite direction, but that's kind of annoying to write... it's easier if immediate refund can only occur when both Recipient+Sender agree to cancel the payment immediately (otherwise it will wait until the timeout). 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. (2-of-2 is also needed for payment cancellation.)