Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2022-12-13 📝 Original message: Hi Greg, > Right, there ...
📅 Original date posted:2022-12-13
📝 Original message:
Hi Greg,
> Right, there are some network-level games that can be played, however
> honest participants can be given a leg up through as AJ notes, alternative
> relays, or even a "rebinder" widget which means only the single highest
fee
> bidding copy of the final update transaction has to make it to the miners'
> mempool. So if the honest party bids X% of the HTLC value in fees, the
> attacker will be paying more than that every single block,
> constantly racing, until it loses either a mempool race or the latest bid.
Yes, I think you could have a p2p extension enabling "blind" rebinding on a
chain of update transactions by pointing to the known channel funding
output. However, the attacker might still pay the mempool feerate (assuming
nversion=3), and win any round of the race. As noted in the description,
the attack opportunity relies on some economic bounds, like the HTLC value,
the CLTV expiry delta and the mempool backlog.
> A mitigation could be for a fee-bumping strategy to adopt a scorched
approach when the HTLC-timeout is approaching, and there is a corresponding
incoming HTLC. When the HTLC-timeout is near expiration (e.g X blocks from
incoming HTLC expiry), probably 100% of the HTLC value should be burnt in
update transaction fees.
> I kind of always thought that's how HTLCs would have worked in theory and
> practice eventually. As the clock runs down you're willing to spend more
to
> take less of the full value.
One of the biggest unknown from a fee-bumping strategy design is the
fee-bump delta you should attach in function of your prediction of mempool
backlogs. To the best of my knowledge, this is not how current generations
of fee-estimators are working.
> As I said before, I think this is already the case. We're assuming
> liveliness of blockchain for these contracts, if a unilateral close gets
> targeted by a large fraction of miners, I don't think eltoo is the risk,
> it's the HTLC constract that's the risk.
Yes, here it's just under LN-penalty. I think the rational fee-bumping
strategy is to target top mempool feerate backlog (assuming nversion=3), as
during the HTLC CLTV delay, there is no competition from the counterparty.
So I agree the HTLC contract is the risk itself, though the dimensions of
the miners bribery attacks might be changed under eltoo.
> In my current eltoo design, I'm assuming *by policy* APO (V3?)
transactions
> can only have one input, and each transaction is only allowed a single
> ephemeral anchor which is attached but not committed to by the
> SIGHASH_SINGLE|APOAS signature. This results in a 1-input-2-output
> transaction that isn't malleable. If and when we figure out how to un-pin
> these kinds of transactions, this policy can be relaxed, and we can get
the
> benefits of aggregated transactions.
I think this is the most conservative design for now, to restrain
malleability of transactions to the minimum, as aggregation transactions
can be played out by honest channel participants by an adversary.
Best,
Antoine
Le mar. 13 déc. 2022 à 09:47, Greg Sanders <gsanders87 at gmail.com> a écrit :
> Hi Antoine,
>
> Nothing you say here(about vanilla eltoo) sounds absurd.
>
> > 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...
>
> >While there is a RBF-race, I think this can be easily won by Malicia by
> mass-connecting on the transaction-relay network and ignoring the Core
> transaction-relay delay timers (here for privacy purposes iirc).
>
> Right, there are some network-level games that can be played, however
> honest participants can be given a leg up through as AJ notes, alternative
> relays, or even a "rebinder" widget which means only the single highest fee
> bidding copy of the final update transaction has to make it to the miners'
> mempool. So if the honest party bids X% of the HTLC value in fees, the
> attacker will be paying more than that every single block,
> constantly racing, until it loses either a mempool race or the latest bid.
>
> I'm starting simple and assuming we don't need all this machinery, and
> hope the risk of counterparty either losing the race a single time, or
> being outbid a single time is enough to dissuade an attack at all.
>
> > A mitigation could be for a fee-bumping strategy to adopt a scorched
> approach when the HTLC-timeout is approaching, and there is a corresponding
> incoming HTLC. When the HTLC-timeout is near expiration (e.g X blocks from
> incoming HTLC expiry), probably 100% of the HTLC value should be burnt in
> update transaction fees.
>
> I kind of always thought that's how HTLCs would have worked in theory and
> practice eventually. As the clock runs down you're willing to spend more to
> take less of the full value.
>
> > Assuming the attack holds, and scorched approach are adopted by default
> to mitigate this concern, there is a second-order concern, we might open
> Lightning channels to miner-harvesting attacks, where the confirmation of
> the update transactions are deferred to kick-out the scorched earth
> reaction of the fee-bumping engine. In my opinion, this would be still an
> improvement, as we're moving a (plausible) security risk triggerable by a
> Lightning counterparty to (hypothetical) one triggerable by a wide
> coalition of miners.
>
> As I said before, I think this is already the case. We're assuming
> liveliness of blockchain for these contracts, if a unilateral close gets
> targeted by a large fraction of miners, I don't think eltoo is the risk,
> it's the HTLC constract that's the risk.
>
> > There is another caveat, it sounds if the update transaction can be
> malleable (i.e SIGHASH_SINGLE|ANYONECANPAY), update transactions across
> Lightning channels could be aggregated by the attacker, changing the
> economy there in a way defavorable to the victims. I.e the attacker can
> select the targeted channels, but the victim cannot coordinate with each
> other to respond with a collective fee-bumping.
>
> In my current eltoo design, I'm assuming *by policy* APO (V3?)
> transactions can only have one input, and each transaction is only allowed
> a single ephemeral anchor which is attached but not committed to by the
> SIGHASH_SINGLE|APOAS signature. This results in a 1-input-2-output
> transaction that isn't malleable. If and when we figure out how to un-pin
> these kinds of transactions, this policy can be relaxed, and we can get the
> benefits of aggregated transactions.
>
> Cheers,
> Greg
>
> On Mon, Dec 12, 2022 at 8:39 PM Antoine Riard <antoine.riard at gmail.com>
> wrote:
>
>> Hi list,
>>
>> The following post describes a potential attack vector against
>> eltoo-based Lightning channels, from my understanding also including the
>> recent two-party eltoo w/ punishment construction. While I think this
>> concern has been known for a while among devs, and I believe it's mitigable
>> by adopting an adequate fee-bumping strategy, I still wonder how exactly it
>> affects eltoo-based constructions.
>>
>> AFAICT, the eltoo 2-stage proposal relies on a serie of pre-signed update
>> transactions, of which in the optimistic case only one of them confirms.
>> There is a script-spend path, where an update transaction N can spend an
>> update transaction K, assuming K<N and an aggregated musig for the
>> checksigverify.
>>
>> The attack purpose is to delay the confirmation of the final settlement
>> transaction S, to double-spend a HTLC forwarded by a routing hop. I.e you
>> have Ned the routing hop receiving the HTLC from Mallory upstream and
>> sending the HTLC to Malicia downstream. Thanks to the cltv_expiry_delta,
>> the HTLC forward should be safe as Ned can timeout the HTLC on the
>> Ned-Malicia link before it is timed-out by Mallory on the Mallory-Ned link.
>> In case of timeout failure, Malicia can claim the HTLC forward with the
>> corresponding preimage, at the same block height than Mallory timeout the
>> HTLC, effectively double-spending Ned.
>>
>> The cltv_expiry_delta requested by Ned is equal to N=144.
>>
>> 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, ...
>>
>> 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...
>>
>> While there is a RBF-race, I think this can be easily won by Malicia by
>> mass-connecting on the transaction-relay network and ignoring the Core
>> transaction-relay delay timers (here for privacy purposes iirc).
>>
>> If it holds, I think the attack is economically opportun as long as the
>> sum of the chain of update transactions weight multiplied by the spent
>> feerate is inferior to the sum of HTLC values stolen (upper bounded to
>> `max_htlc_value_in_flight_msat`, not `funding_satoshis`). The attack could
>> be more sound in periods of low-fee, as the number of HTLC exploitable is
>> higher.
>>
>> A mitigation could be for a fee-bumping strategy to adopt a scorched
>> approach when the HTLC-timeout is approaching, and there is a corresponding
>> incoming HTLC. When the HTLC-timeout is near expiration (e.g X blocks from
>> incoming HTLC expiry), probably 100% of the HTLC value should be burnt in
>> update transaction fees.
>>
>> I think some implementations in the LN-penalty are already doing "upward"
>> fee-bumping frequency, while I believe it reduces the attack surface, I
>> still think there is an exploitable window for "update overflow" attack.
>> E.g in LDK justice transactions are bumped by 25% every block according to
>> a height timer schedule [0].
>>
>> Assuming the attack holds, and scorched approach are adopted by default
>> to mitigate this concern, there is a second-order concern, we might open
>> Lightning channels to miner-harvesting attacks, where the confirmation of
>> the update transactions are deferred to kick-out the scorched earth
>> reaction of the fee-bumping engine. In my opinion, this would be still an
>> improvement, as we're moving a (plausible) security risk triggerable by a
>> Lightning counterparty to (hypothetical) one triggerable by a wide
>> coalition of miners.
>>
>> There is another caveat, it sounds if the update transaction can be
>> malleable (i.e SIGHASH_SINGLE|ANYONECANPAY), update transactions across
>> Lightning channels could be aggregated by the attacker, changing the
>> economy there in a way defavorable to the victims. I.e the attacker can
>> select the targeted channels, but the victim cannot coordinate with each
>> other to respond with a collective fee-bumping.
>>
>> Is the understanding of the two-party eltoo construction correct, and
>> this "update overflow" attack is sound and economically opportun ? If it
>> holds, I still wonder if we have variants playing with mempool descendant
>> limits. In all cases, it sounds to me the implications are more in the way
>> fee-bumping is implemented by Lightning softwares rather than directly on
>> eltoo-based constructions, I don't see an immediate way to address it by
>> the construction itself.
>>
>> Mistakes and confusions are my own.
>>
>> Antoine
>>
>> [0]
>> https://github.com/lightningdevkit/rust-lightning/blob/5e14c24a11f610ab8c402f788ec5bd637e9e24af/lightning/src/chain/onchaintx.rs#L505
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221213/0dc36ccc/attachment-0001.html>;
📝 Original message:
Hi Greg,
> Right, there are some network-level games that can be played, however
> honest participants can be given a leg up through as AJ notes, alternative
> relays, or even a "rebinder" widget which means only the single highest
fee
> bidding copy of the final update transaction has to make it to the miners'
> mempool. So if the honest party bids X% of the HTLC value in fees, the
> attacker will be paying more than that every single block,
> constantly racing, until it loses either a mempool race or the latest bid.
Yes, I think you could have a p2p extension enabling "blind" rebinding on a
chain of update transactions by pointing to the known channel funding
output. However, the attacker might still pay the mempool feerate (assuming
nversion=3), and win any round of the race. As noted in the description,
the attack opportunity relies on some economic bounds, like the HTLC value,
the CLTV expiry delta and the mempool backlog.
> A mitigation could be for a fee-bumping strategy to adopt a scorched
approach when the HTLC-timeout is approaching, and there is a corresponding
incoming HTLC. When the HTLC-timeout is near expiration (e.g X blocks from
incoming HTLC expiry), probably 100% of the HTLC value should be burnt in
update transaction fees.
> I kind of always thought that's how HTLCs would have worked in theory and
> practice eventually. As the clock runs down you're willing to spend more
to
> take less of the full value.
One of the biggest unknown from a fee-bumping strategy design is the
fee-bump delta you should attach in function of your prediction of mempool
backlogs. To the best of my knowledge, this is not how current generations
of fee-estimators are working.
> As I said before, I think this is already the case. We're assuming
> liveliness of blockchain for these contracts, if a unilateral close gets
> targeted by a large fraction of miners, I don't think eltoo is the risk,
> it's the HTLC constract that's the risk.
Yes, here it's just under LN-penalty. I think the rational fee-bumping
strategy is to target top mempool feerate backlog (assuming nversion=3), as
during the HTLC CLTV delay, there is no competition from the counterparty.
So I agree the HTLC contract is the risk itself, though the dimensions of
the miners bribery attacks might be changed under eltoo.
> In my current eltoo design, I'm assuming *by policy* APO (V3?)
transactions
> can only have one input, and each transaction is only allowed a single
> ephemeral anchor which is attached but not committed to by the
> SIGHASH_SINGLE|APOAS signature. This results in a 1-input-2-output
> transaction that isn't malleable. If and when we figure out how to un-pin
> these kinds of transactions, this policy can be relaxed, and we can get
the
> benefits of aggregated transactions.
I think this is the most conservative design for now, to restrain
malleability of transactions to the minimum, as aggregation transactions
can be played out by honest channel participants by an adversary.
Best,
Antoine
Le mar. 13 déc. 2022 à 09:47, Greg Sanders <gsanders87 at gmail.com> a écrit :
> Hi Antoine,
>
> Nothing you say here(about vanilla eltoo) sounds absurd.
>
> > 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...
>
> >While there is a RBF-race, I think this can be easily won by Malicia by
> mass-connecting on the transaction-relay network and ignoring the Core
> transaction-relay delay timers (here for privacy purposes iirc).
>
> Right, there are some network-level games that can be played, however
> honest participants can be given a leg up through as AJ notes, alternative
> relays, or even a "rebinder" widget which means only the single highest fee
> bidding copy of the final update transaction has to make it to the miners'
> mempool. So if the honest party bids X% of the HTLC value in fees, the
> attacker will be paying more than that every single block,
> constantly racing, until it loses either a mempool race or the latest bid.
>
> I'm starting simple and assuming we don't need all this machinery, and
> hope the risk of counterparty either losing the race a single time, or
> being outbid a single time is enough to dissuade an attack at all.
>
> > A mitigation could be for a fee-bumping strategy to adopt a scorched
> approach when the HTLC-timeout is approaching, and there is a corresponding
> incoming HTLC. When the HTLC-timeout is near expiration (e.g X blocks from
> incoming HTLC expiry), probably 100% of the HTLC value should be burnt in
> update transaction fees.
>
> I kind of always thought that's how HTLCs would have worked in theory and
> practice eventually. As the clock runs down you're willing to spend more to
> take less of the full value.
>
> > Assuming the attack holds, and scorched approach are adopted by default
> to mitigate this concern, there is a second-order concern, we might open
> Lightning channels to miner-harvesting attacks, where the confirmation of
> the update transactions are deferred to kick-out the scorched earth
> reaction of the fee-bumping engine. In my opinion, this would be still an
> improvement, as we're moving a (plausible) security risk triggerable by a
> Lightning counterparty to (hypothetical) one triggerable by a wide
> coalition of miners.
>
> As I said before, I think this is already the case. We're assuming
> liveliness of blockchain for these contracts, if a unilateral close gets
> targeted by a large fraction of miners, I don't think eltoo is the risk,
> it's the HTLC constract that's the risk.
>
> > There is another caveat, it sounds if the update transaction can be
> malleable (i.e SIGHASH_SINGLE|ANYONECANPAY), update transactions across
> Lightning channels could be aggregated by the attacker, changing the
> economy there in a way defavorable to the victims. I.e the attacker can
> select the targeted channels, but the victim cannot coordinate with each
> other to respond with a collective fee-bumping.
>
> In my current eltoo design, I'm assuming *by policy* APO (V3?)
> transactions can only have one input, and each transaction is only allowed
> a single ephemeral anchor which is attached but not committed to by the
> SIGHASH_SINGLE|APOAS signature. This results in a 1-input-2-output
> transaction that isn't malleable. If and when we figure out how to un-pin
> these kinds of transactions, this policy can be relaxed, and we can get the
> benefits of aggregated transactions.
>
> Cheers,
> Greg
>
> On Mon, Dec 12, 2022 at 8:39 PM Antoine Riard <antoine.riard at gmail.com>
> wrote:
>
>> Hi list,
>>
>> The following post describes a potential attack vector against
>> eltoo-based Lightning channels, from my understanding also including the
>> recent two-party eltoo w/ punishment construction. While I think this
>> concern has been known for a while among devs, and I believe it's mitigable
>> by adopting an adequate fee-bumping strategy, I still wonder how exactly it
>> affects eltoo-based constructions.
>>
>> AFAICT, the eltoo 2-stage proposal relies on a serie of pre-signed update
>> transactions, of which in the optimistic case only one of them confirms.
>> There is a script-spend path, where an update transaction N can spend an
>> update transaction K, assuming K<N and an aggregated musig for the
>> checksigverify.
>>
>> The attack purpose is to delay the confirmation of the final settlement
>> transaction S, to double-spend a HTLC forwarded by a routing hop. I.e you
>> have Ned the routing hop receiving the HTLC from Mallory upstream and
>> sending the HTLC to Malicia downstream. Thanks to the cltv_expiry_delta,
>> the HTLC forward should be safe as Ned can timeout the HTLC on the
>> Ned-Malicia link before it is timed-out by Mallory on the Mallory-Ned link.
>> In case of timeout failure, Malicia can claim the HTLC forward with the
>> corresponding preimage, at the same block height than Mallory timeout the
>> HTLC, effectively double-spending Ned.
>>
>> The cltv_expiry_delta requested by Ned is equal to N=144.
>>
>> 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, ...
>>
>> 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...
>>
>> While there is a RBF-race, I think this can be easily won by Malicia by
>> mass-connecting on the transaction-relay network and ignoring the Core
>> transaction-relay delay timers (here for privacy purposes iirc).
>>
>> If it holds, I think the attack is economically opportun as long as the
>> sum of the chain of update transactions weight multiplied by the spent
>> feerate is inferior to the sum of HTLC values stolen (upper bounded to
>> `max_htlc_value_in_flight_msat`, not `funding_satoshis`). The attack could
>> be more sound in periods of low-fee, as the number of HTLC exploitable is
>> higher.
>>
>> A mitigation could be for a fee-bumping strategy to adopt a scorched
>> approach when the HTLC-timeout is approaching, and there is a corresponding
>> incoming HTLC. When the HTLC-timeout is near expiration (e.g X blocks from
>> incoming HTLC expiry), probably 100% of the HTLC value should be burnt in
>> update transaction fees.
>>
>> I think some implementations in the LN-penalty are already doing "upward"
>> fee-bumping frequency, while I believe it reduces the attack surface, I
>> still think there is an exploitable window for "update overflow" attack.
>> E.g in LDK justice transactions are bumped by 25% every block according to
>> a height timer schedule [0].
>>
>> Assuming the attack holds, and scorched approach are adopted by default
>> to mitigate this concern, there is a second-order concern, we might open
>> Lightning channels to miner-harvesting attacks, where the confirmation of
>> the update transactions are deferred to kick-out the scorched earth
>> reaction of the fee-bumping engine. In my opinion, this would be still an
>> improvement, as we're moving a (plausible) security risk triggerable by a
>> Lightning counterparty to (hypothetical) one triggerable by a wide
>> coalition of miners.
>>
>> There is another caveat, it sounds if the update transaction can be
>> malleable (i.e SIGHASH_SINGLE|ANYONECANPAY), update transactions across
>> Lightning channels could be aggregated by the attacker, changing the
>> economy there in a way defavorable to the victims. I.e the attacker can
>> select the targeted channels, but the victim cannot coordinate with each
>> other to respond with a collective fee-bumping.
>>
>> Is the understanding of the two-party eltoo construction correct, and
>> this "update overflow" attack is sound and economically opportun ? If it
>> holds, I still wonder if we have variants playing with mempool descendant
>> limits. In all cases, it sounds to me the implications are more in the way
>> fee-bumping is implemented by Lightning softwares rather than directly on
>> eltoo-based constructions, I don't see an immediate way to address it by
>> the construction itself.
>>
>> Mistakes and confusions are my own.
>>
>> Antoine
>>
>> [0]
>> https://github.com/lightningdevkit/rust-lightning/blob/5e14c24a11f610ab8c402f788ec5bd637e9e24af/lightning/src/chain/onchaintx.rs#L505
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221213/0dc36ccc/attachment-0001.html>;