[Lightning-dev] HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and revocation hashes.

Anthony Towns aj at erisian.com.au
Wed Feb 10 16:50:49 UTC 2016


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



More information about the Lightning-dev mailing list