[Lightning-dev] HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and revocation hashes.
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:
> 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
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.
More information about the Lightning-dev