CJP [ARCHIVE] on Nostr: 📅 Original date posted:2016-02-09 📝 Original message: Rusty Russell schreef op ...
📅 Original date posted:2016-02-09
📝 Original message:
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
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.
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.
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.
CJP
📝 Original message:
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
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.
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.
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.
CJP