Cleanup comments & removed notes on escrow

lnwire/ESCROWED_HTLC_NOTES

@@ -1,121 +0,0 @@
-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.)