On Mon, Dec 12, 2022 at 08:38:43PM -0500, Antoine Riard wrote:
> The attack purpose is to delay the confirmation of the final settlement
> transaction S, to double-spend a HTLC forwarded by a routing hop.
> The cltv_expiry_delta requested by Ned is equal to N=144.
I believe what you're suggesting here is:
Mallory has two channels with Bob, M1 and M2. Both have a to_self_delay
of 144 blocks. In that case cltv_expiry_delay should include some slack,
I'm going to assume it's 154 blocks in total.
Mallory forwards a large payment, M1->Bob->M2.
Mallory claims the funds on M2 just prior to the timeout, but
goes offline on M1.
Bob chose the timeout for M2 via cltv_expiry_delay, so now has 154
blocks before the CLTV on the M1->Bob payment expires.
In this scenario, under the two-party eltoo scheme, Bob should:
1) immediately broadcast the most recent UB.n state for M1/Bob,
aiming for this to be confirmed within 5 blocks
2) wait 144 blocks for the relative timelock to expire
3) broadcast SB.n to finalise the funds, and immediately claim the
large HTLC. providing this confirms within 5 blocks, it will confirm
before the HTLC timelock expires, and Mallory will have been unable
to claim the funds.
The only transactions Mallory could broadcast are:
prior to (1): UA.k (k <= n) -- However this allows Bob to immediately
broadcast one of either CA.n or RA.n, and will then have ~150 blocks
to claim the HTLC before its timeout
during (2): CA.n -- Again, this allows Bob to claim the HTLC
immediately, prior to its timeout
The only delaying attack with repeated transactions comes if Bob
broadcasts an old state UB.k (k < n), in which case Mallory can broadcast
(n-k) WA.i watchtower transactions prior to finalising the state. However
if Bob *only* has old state, Mallory can simply broadcast WA.n, at which
point Bob can do nothing, as (by assumption) he doesn't have access
to current state and thus doesn't have SB.n to broadcast it.
> The attack scenario works in the following way: Malicia updates the Eltoo
> channel N time, getting the possession of N update transactions. At block
> A, she breaks the channel and confirms the update transaction 0 by
> attaching a feerate equal to or superior to top mempool block space + 1
> sat. At each new block, she iterates by confirming the next update
> transaction, i.e update transaction 1 at block A+1, update transaction
> transaction 2 at block A+2, update transaction 3 at block A+3, ...
I think traditional eltoo envisages being able to spend update transaction
1 immediately, without having to wait for the next block. This might
not be compatible with the version 3 relay rules that are being thought
about, though, and presumably would hit ancestor limits.
I think a simple way to avoid that problem would be for eltoo nodes
to have a priority tx relay network -- if they see a channel close to
state N, always replace any txs closing to an earlier state K<N, and
always quickly relay that close to all other peers. There's no reason
to assume the bad guys have the best access to the network when we can
write code so that the honest participants have it instead.
> From Ned's viewpoint, there is limited rationality of the network mempools,
> as such each punishment transaction R, as it's confirmation could have been
> delay due to "honest" slow propagation on the network is likely to be
> pre-signed with top mempool block space feerate, but not more to save on
> fees. Therefore, transaction RN.0 should fail to punish update transaction
> 0 as it's double-spent by update transaction 1, transaction RN.1 should
> fail to punish update transaction 1 as it's double-spent by update
> transaction 2, transaction RN.2 should fail to punish update transaction 2
> as it's double-spent by update transaction 3...
In the two-party scheme, the only transaction Mallory can broadcast
after sending UA.k and having it confirmed on chain is SA.k, and that
only after a 144 block relative timelock. UA.(k+1) etc only spend the
funding output, but that has already been spent by UA.k.
Cheers,
aj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
