Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2016-02-09 📝 Original message: CJP <cjp at ...
📅 Original date posted:2016-02-09
📝 Original message:
CJP <cjp at ultimatestunts.nl> writes:
> Rusty Russell schreef op di 09-02-2016 om 10:09 [+1030]:
>>
>> 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):
>> [..]
>
> So, summarized, the "HTLC Receiver Redeemscript" is actually something
> like:
>
> R-VALUE & OP_CSV & SIG-PAYEE
> OR
> HTLC-TIMEOUT & SIG-PAYER
> OR
> REVOCATION-B & SIG A
Yes.
> Now, I thought it wouldn't be OK to add an OP_CSV there, so let's see if
> I can exploit it.
>
> Same situation: Alice and Eve, connected with two channels. Eve performs
> a payment to herself, routed through these two channels.
>
> 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.
>
> 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. 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.
>
> 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.
Yes, unfortunately they're intertwined. I was sure we'd discussed
this before, and I found it.
https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000077.html
We keep rediscovering this problem so I need to document it somewhere.
> 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. Eve wants to delay
> Alice's commit transaction as long as possible, so she sends the R value
> just before T0 + 1 day. 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.
>
> So, I think it *is possible*. However, this leads to some uncomfortable
> time trade-offs. The CSV delay determines how often your node must be up
> and running, to catch the use of revoked commit transactions. Longer is
> better: I'd be much more comfortable with 30 days than with 1 day. The
> HTLC timeout increment determines how long funds can be locked up and
> payment status can stay undetermined (worst-case); it adds up over the
> entire route. For this, shorter is better: 1 day would be much better
> than 30 days.
Yes. If A insists that B use a 30 day CSV, A can't ask B to accept an
HTLC with less than (say) 31 days lifetime.
In general, an HTLC timeout must comfortably exceed the highest CSV
delay on the route.
It sucks, but at least it's not the sum of CSV delays. Keeping CSV time
down is the motivation for outsourcing the enforcement (which I think
SegWit gives us the ability to do, because the txids of the commit
transactions won't be malleable).
> Even if you assume "always-on, always connected" nodes, e.g. cell
> phones, service providers and home servers, you have to take into
> account that systems can fail, and manual intervention may be needed to
> restore them. The downtime / DoS attack -> theft escalation is something
> we don't want to happen.
Indeed! c-lightning requests a CSV timeout of 1 day, allows requests of
up to 2 days (comment says 3, but it's wrong). It only allows HTLCS of
up to 5 days in the future, but it wants a 6 hour window minimum[1].
If we want to allow CSV timeouts of 5 days[2], HTLC timeout decrements
of up to 1 day per node over 20 hops, that means we need to allow HTLC
timeouts of 26 days :(
We can play with those numbers a bit (20 hops is a bit much, 1 day seems
excessive given you can always drop commit txs to blockchain if DDoS is
severe), but I think the per-hop decrement will dominate.
Cheers,
Rusty.
[1] It should be "CSV + 6 hours", this is the bug.
[2] A 4-day long weekend plus one day of frantic panic; this was the
default timeout in the Linux NAT code.
📝 Original message:
CJP <cjp at ultimatestunts.nl> writes:
> Rusty Russell schreef op di 09-02-2016 om 10:09 [+1030]:
>>
>> 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):
>> [..]
>
> So, summarized, the "HTLC Receiver Redeemscript" is actually something
> like:
>
> R-VALUE & OP_CSV & SIG-PAYEE
> OR
> HTLC-TIMEOUT & SIG-PAYER
> OR
> REVOCATION-B & SIG A
Yes.
> Now, I thought it wouldn't be OK to add an OP_CSV there, so let's see if
> I can exploit it.
>
> Same situation: Alice and Eve, connected with two channels. Eve performs
> a payment to herself, routed through these two channels.
>
> 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.
>
> 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. 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.
>
> 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.
Yes, unfortunately they're intertwined. I was sure we'd discussed
this before, and I found it.
https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000077.html
We keep rediscovering this problem so I need to document it somewhere.
> 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. Eve wants to delay
> Alice's commit transaction as long as possible, so she sends the R value
> just before T0 + 1 day. 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.
>
> So, I think it *is possible*. However, this leads to some uncomfortable
> time trade-offs. The CSV delay determines how often your node must be up
> and running, to catch the use of revoked commit transactions. Longer is
> better: I'd be much more comfortable with 30 days than with 1 day. The
> HTLC timeout increment determines how long funds can be locked up and
> payment status can stay undetermined (worst-case); it adds up over the
> entire route. For this, shorter is better: 1 day would be much better
> than 30 days.
Yes. If A insists that B use a 30 day CSV, A can't ask B to accept an
HTLC with less than (say) 31 days lifetime.
In general, an HTLC timeout must comfortably exceed the highest CSV
delay on the route.
It sucks, but at least it's not the sum of CSV delays. Keeping CSV time
down is the motivation for outsourcing the enforcement (which I think
SegWit gives us the ability to do, because the txids of the commit
transactions won't be malleable).
> Even if you assume "always-on, always connected" nodes, e.g. cell
> phones, service providers and home servers, you have to take into
> account that systems can fail, and manual intervention may be needed to
> restore them. The downtime / DoS attack -> theft escalation is something
> we don't want to happen.
Indeed! c-lightning requests a CSV timeout of 1 day, allows requests of
up to 2 days (comment says 3, but it's wrong). It only allows HTLCS of
up to 5 days in the future, but it wants a 6 hour window minimum[1].
If we want to allow CSV timeouts of 5 days[2], HTLC timeout decrements
of up to 1 day per node over 20 hops, that means we need to allow HTLC
timeouts of 26 days :(
We can play with those numbers a bit (20 hops is a bit much, 1 day seems
excessive given you can always drop commit txs to blockchain if DDoS is
severe), but I think the per-hop decrement will dominate.
Cheers,
Rusty.
[1] It should be "CSV + 6 hours", this is the bug.
[2] A 4-day long weekend plus one day of frantic panic; this was the
default timeout in the Linux NAT code.