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

Rusty Russell rusty at rustcorp.com.au
Mon Feb 8 23:39:12 UTC 2016


CJP <cjp at ultimatestunts.nl> 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
        <R-HASH> OP_EQUAL B redeeming the contract, using R preimage?
        OP_IF
                <DELAY> OP_CHECKSEQUENCEVERIFY Delay gives A enough
                        time to use revocation if it has it.
                OP_2DROP Drop extra hash and delay from the stack
                <KEY-B> Pay to B
        OP_ELSE
                <COMMIT-REVOCATION-HASH> OP_EQUAL If the commit
                                        has been revoked.
                OP_NOTIF If not, you need to wait for timeout.
                        <HTLC-TIMEOUT> OP_CHECKLOCKTIMEVERIFY OP_DROP
                                       Ensure (absolute) time has passed.
                OP_ENDIF
                <KEY-A> 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.


More information about the Lightning-dev mailing list