From aj at erisian.com.au Wed Feb 10 16:50:49 2016 From: aj at erisian.com.au (Anthony Towns) Date: Thu, 11 Feb 2016 02:50:49 +1000 Subject: [Lightning-dev] HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and revocation hashes. In-Reply-To: <1455047339.3757.38.camel@ultimatestunts.nl> References: <87fv51eqjl.fsf@rustcorp.com.au> <87bnf2qssy.fsf@rustcorp.com.au> <1454969273.1633.35.camel@ultimatestunts.nl> <87fux2pyan.fsf@rustcorp.com.au> <1455047339.3757.38.camel@ultimatestunts.nl> Message-ID: <20160210165049.GC8070@sapphire.erisian.com.au> On Tue, Feb 09, 2016 at 08:48:59PM +0100, CJP wrote: Reference: http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000361.html > Same situation: Alice and Eve, connected with two channels. Eve performs > a payment to herself, routed through these two channels. Okay, so the channels are: Eve <-> Alice Evelyn <-> Alice (Eve's alias) with the delay (OP_CSV) parameter for both channels set at the value "D". In addition, Alice's commitments include a fee that she expects will result in confirmation in less than a delay of "F", and she's confident that a transaction can be spent so long as its been in the blockchain for "N" units of time. The HTLCs are: Eve pays Alice $X on receipt of R, CLTV at time T Alice pays Evelyn $X on receipt of R, CLTV at time T' Per the mail above, when forwarding the HTLC, Alice calculates T' such that T' <= T - D - 2*F - N and T' >= now + D + F > 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. Assuming that all works out, and Evelyn reveals R and collects $X straight away, the second HTLC is dealt with, and things are fine so far. > 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. At this point Alice should start the timer ticking. If she doesn't get an ack from Eve prior to T-D-F, she must go to the blockchain. Suppose she leaves it to the last minute. > 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. So she publishes her commitment transaction at T-D-F. The transaction gets mined before "F" time units transpire, so the time is now T-D-x. After an additional "D" time units, the time is T-x, at which point Alice can spend the transaction, but Eve cannot. > 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. So I think that answers the question. > 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. In that case, from the above inequalities: D + 2*F + N <= 1 day > Eve wants to delay > Alice's commit transaction as long as possible, so she sends the R value > just before T0 + 1 day. That doesn't work: if the forwarded HTLC isn't resolved by T'-D-F she has to close the channel on the blockchain to be safe. If her fees are high enough, D+F could perhaps be as low as an hour, though, so T0+23 hours might be reasonable. > 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. Yes, rearranging the inequality above gives D <= (T-T') - 2*F - N, so it has to be quite a bit smaller than the delta between timeouts across a given node. Cheers, aj