From cjp at ultimatestunts.nl Tue Feb 9 19:48:59 2016 From: cjp at ultimatestunts.nl (CJP) Date: Tue, 09 Feb 2016 20:48:59 +0100 Subject: [Lightning-dev] HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and revocation hashes. In-Reply-To: <87fux2pyan.fsf@rustcorp.com.au> References: <87fv51eqjl.fsf@rustcorp.com.au> <87bnf2qssy.fsf@rustcorp.com.au> <1454969273.1633.35.camel@ultimatestunts.nl> <87fux2pyan.fsf@rustcorp.com.au> Message-ID: <1455047339.3757.38.camel@ultimatestunts.nl> Rusty Russell schreef op di 09-02-2016 om 10:09 [+1030]: > > 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): > [..] So, summarized, the "HTLC Receiver Redeemscript" is actually something like: R-VALUE & OP_CSV & SIG-PAYEE OR HTLC-TIMEOUT & SIG-PAYER OR REVOCATION-B & SIG A Now, I thought it wouldn't be OK to add an OP_CSV there, so let's see if I can exploit it. Same situation: Alice and Eve, connected with two channels. Eve performs a payment to herself, routed through these two channels. Now, Eve allows the transaction to succeed on the channel where she receives: Eve sends the R value to Alice, and Alice sends Eve a commit transaction update where the HTLC is removed and Eve receives the funds. On the other channel, Alice sends the R value to Eve, but Eve does not send Alice a commit transaction update. In fact, Eve becomes completely unresponsive on this channel. This forces Alice to broadcast her commit transaction, containing the HTLC. She has to do this *before* the CLTV of the HTLC times out, or otherwise Eve can try to claim the HTLC funds. Now, the question is: which times out first, Alice's CSV or Eve's CLTV? The one that times out first will be the first to be able to claim the funds. This *should* of course be Alice, so Alice's CSV should be the first to time out. Let's assume the HTLC timeout is T0 + 1 day on the channel where Eve receives, T0 + 2 days on the channel where Eve sends. Eve wants to delay Alice's commit transaction as long as possible, so she sends the R value just before T0 + 1 day. That means Alice's CSV should have a delay *less than* one day. If the CSV delay is set to 0.5 day, that means Alice has a remaining 0.5 day time window in which her node must be up and running and connected to the Bitcoin network, to claim the HTLC funds. So, I think it *is possible*. However, this leads to some uncomfortable time trade-offs. The CSV delay determines how often your node must be up and running, to catch the use of revoked commit transactions. Longer is better: I'd be much more comfortable with 30 days than with 1 day. The HTLC timeout increment determines how long funds can be locked up and payment status can stay undetermined (worst-case); it adds up over the entire route. For this, shorter is better: 1 day would be much better than 30 days. Even if you assume "always-on, always connected" nodes, e.g. cell phones, service providers and home servers, you have to take into account that systems can fail, and manual intervention may be needed to restore them. The downtime / DoS attack -> theft escalation is something we don't want to happen. CJP