Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2016-02-08 📝 Original message: CJP <cjp at ...

📅 Original date posted:2016-02-08
📝 Original message:
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.