From rusty at rustcorp.com.au Mon Feb 8 23:39:12 2016 From: rusty at rustcorp.com.au (Rusty Russell) Date: Tue, 09 Feb 2016 10:09:12 +1030 Subject: [Lightning-dev] HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and revocation hashes. In-Reply-To: <1454969273.1633.35.camel@ultimatestunts.nl> References: <87fv51eqjl.fsf@rustcorp.com.au> <87bnf2qssy.fsf@rustcorp.com.au> <1454969273.1633.35.camel@ultimatestunts.nl> Message-ID: <87fux2pyan.fsf@rustcorp.com.au> CJP writes: >> See: >> >> https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf > > Sorry for replying to a very old e-mail, but I've finally had a really > close look at this, and the way I see it, there could be a potential > problem. > > Suppose Eve (E) has two channels with Alice (A). She intends to steal > funds from Alice. This is what she does: > > She performs a payment to herself, routed through Alice with the two > channels. When the funds are locked in the two channels, she is supposed > to reveal the transaction R value as a payee, but she doesn't. So, the > transaction times out on both channels, leading to a channel update on > both: the HTLCs are removed, reverting back to the original situation. > > The following actions primarily take place on the channel where Eve was > on the RECEIVING side of the transaction. First, Eve spends all her > coins on that channel, e.g. by sending them to herself on the other > channel. This way, she doesn't risk losing them. > > Next, on the channel where Eve was on the RECEIVING side of the > transaction, Eve signs and broadcasts the version of the commit > transaction that contained the HTLC. Of course, since revocation > pre-images have been exchanged, Alice can immediately spend the HTLC, > using either the HTLC-TIMEOUT & SIG-PAYER clause or the REVOCATION-E & > SIG A clause. However, this is not guaranteed to work: Eve has the > transaction R value, so Eve can *also* try to spend it, using the > R-VALUE & SIG-PAYEE clause. In fact, since Eve knows sooner about the > commit transaction than Alice, Eve is more likely to be the first to > spend the HTLC, especially when Alice is offline for a moment (Eve can > know that). For this reason, the rule is that all outputs to A in A's commit transaction must be delayed (via OP_CSV). This includes HTLC outputs. Referring to Appendix A of the paper, under "HTLC Receiver Redeemscript" (since Alice offers Eve the HTLC, Eve is B): HTLC Receiver Redeemscript OP_HASH160 OP_DUP Replace top element with two copies of its hash OP_EQUAL B redeeming the contract, using R preimage? OP_IF OP_CHECKSEQUENCEVERIFY Delay gives A enough time to use revocation if it has it. OP_2DROP Drop extra hash and delay from the stack Pay to B OP_ELSE OP_EQUAL If the commit has been revoked. OP_NOTIF If not, you need to wait for timeout. OP_CHECKLOCKTIMEVERIFY OP_DROP Ensure (absolute) time has passed. OP_ENDIF Pay to A OP_ENDIF OP_CHECKSIG Verify A or B's signature is correct. Here you can see the CSV delay on the "using R preimage" path. I have a subtler suggestion, though: perhaps we should OP_CSV delay all the non-revocation paths in HTLCs and in the straight payment outputs. Otherwise, if you want to do a unilateral close, there's some game theory as you'd rather convince the other side to do it so your own funds aren't locked up. Delaying all non-revocation paths makes it an arbitrary choice. I know Joseph will have some thoughts about that :) Cheers, Rusty.