lnd.xprv/lnwire/ESCROWED_HTLC_NOTES

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:
	<BobSig> <0> <EscrowPreimageR> <RecipientPreimageR> <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
	<CSVDelay> OP_DROP OP_CSV

	//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
	<CSVDelay> OP_DROP OP_CSV

	<HTLCTimeout> OP_DROP 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!

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.)