Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2022-12-13 📝 Original message: Hi AJ, I believe we're in ...
📅 Original date posted:2022-12-13
📝 Original message:
Hi AJ,
I believe we're in sync on the attack description.
> 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
>From my understanding, with two party eltoo w/punihsment, UA.k has a
tapscript path with "1 CHECKSIGVERIFY k<n CLTV", where the internal pubkey
substituted is "musig(A,B)/1. Mallory should receive Bob's signature for
UA.k, though also UA.k+1, UA.k+2, UAk+3, until k=n.
Or is this a tapscript only existing for the dual-funding case ? I think
this a bit unclear from the gist construction, how Mallory is restrained to
use the tapscript path on UA.k, with UA.k+1 as she should be in possession
of Bob's signature for this state.
> 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.
While update transaction 1 could spend update transaction 0 immediately,
there is no reliable knowledge by U*.1 transaction broadcaster of the state
of the network mempools. I believe the update transactions themselves could
be used to partition network mempools in multiple subsets (at least this is
achievable under LN-penalty with using old revoked states).
> 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.
While I think this solution of eltoo nodes quickly replacing any state K
previous to the latest state N, there is no guarantee the latest state K
doesn't offer a higher feerate than state N, making it more attractive to
the miners.
One other solution could be a p2p extension allowing an update transaction
N to be "blindly" rebinded on any update transaction K, with K < N, by
pointing to the channel funding output, and a per-counterparty ancestor
limit enforced as a policy rule (otherwise the malicious counterparty could
still buy all the ancestor limits).
A more sophisticated solution could be to "trim" the counterparty ability
to confirm multiple update transactions with some TLUV mechanism.
> 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.
See above question on the existence of a tapscript 1 path in update
transaction, and by which transaction type it could/should be spent. I
think the crux of the attack's soundness (or not) against two parties eltoo
w/ punishment relies here. AFAICT, if there is an unbounded spending path
cycle introduced for one of the counterparties, you're exposed to "eltoo
states overflow".
Best,
Antoine
Le lun. 12 déc. 2022 à 22:51, Anthony Towns <aj at erisian.com.au> a écrit :
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221213/caed9efb/attachment-0001.html>;
📝 Original message:
Hi AJ,
I believe we're in sync on the attack description.
> 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
>From my understanding, with two party eltoo w/punihsment, UA.k has a
tapscript path with "1 CHECKSIGVERIFY k<n CLTV", where the internal pubkey
substituted is "musig(A,B)/1. Mallory should receive Bob's signature for
UA.k, though also UA.k+1, UA.k+2, UAk+3, until k=n.
Or is this a tapscript only existing for the dual-funding case ? I think
this a bit unclear from the gist construction, how Mallory is restrained to
use the tapscript path on UA.k, with UA.k+1 as she should be in possession
of Bob's signature for this state.
> 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.
While update transaction 1 could spend update transaction 0 immediately,
there is no reliable knowledge by U*.1 transaction broadcaster of the state
of the network mempools. I believe the update transactions themselves could
be used to partition network mempools in multiple subsets (at least this is
achievable under LN-penalty with using old revoked states).
> 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.
While I think this solution of eltoo nodes quickly replacing any state K
previous to the latest state N, there is no guarantee the latest state K
doesn't offer a higher feerate than state N, making it more attractive to
the miners.
One other solution could be a p2p extension allowing an update transaction
N to be "blindly" rebinded on any update transaction K, with K < N, by
pointing to the channel funding output, and a per-counterparty ancestor
limit enforced as a policy rule (otherwise the malicious counterparty could
still buy all the ancestor limits).
A more sophisticated solution could be to "trim" the counterparty ability
to confirm multiple update transactions with some TLUV mechanism.
> 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.
See above question on the existence of a tapscript 1 path in update
transaction, and by which transaction type it could/should be spent. I
think the crux of the attack's soundness (or not) against two parties eltoo
w/ punishment relies here. AFAICT, if there is an unbounded spending path
cycle introduced for one of the counterparties, you're exposed to "eltoo
states overflow".
Best,
Antoine
Le lun. 12 déc. 2022 à 22:51, Anthony Towns <aj at erisian.com.au> a écrit :
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221213/caed9efb/attachment-0001.html>;