đ
Original date posted:2022-12-13
đ Original message:
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/45a189de/attachment.html>;
Greg Sanders [ARCHIVE] /
npub1jdâŚ3gh0m
2023-06-09 13:07:44
in reply to nevent1qâŚ84yu
Author Public Key
npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0mPublished at
2023-06-09 13:07:44Event JSON
{
"id": "903b86a327942aa5c6a9a3e4e69e509b96eb00c075fd681eb71e6f5ba1a2627d",
"pubkey": "937f10fc4f78d8676348562d9d886843fbb351d99d6c96423fe9970819962e19",
"created_at": 1686316064,
"kind": 1,
"tags": [
[
"e",
"b81b9b3c106e3ebeb51b59657e273fa06b192516401a8d41be6cf5377dab9ae8",
"",
"root"
],
[
"e",
"208551ecf075758018679966ce9152888020716a04bbf2287a3512fbb6b497ae",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "đ
Original date posted:2022-12-13\nđ Original message:\nHi Antoine,\n\nNothing you say here(about vanilla eltoo) sounds absurd.\n\n\u003e Therefore, transaction RN.0 should fail to punish update transaction 0 as\nit's double-spent by update transaction 1, transaction RN.1 should fail to\npunish update transaction 1 as it's double-spent by update transaction 2,\ntransaction RN.2 should fail to punish update transaction 2 as it's\ndouble-spent by update transaction 3...\n\n\u003eWhile there is a RBF-race, I think this can be easily won by Malicia by\nmass-connecting on the transaction-relay network and ignoring the Core\ntransaction-relay delay timers (here for privacy purposes iirc).\n\nRight, there are some network-level games that can be played, however\nhonest participants can be given a leg up through as AJ notes, alternative\nrelays, or even a \"rebinder\" widget which means only the single highest fee\nbidding copy of the final update transaction has to make it to the miners'\nmempool. So if the honest party bids X% of the HTLC value in fees, the\nattacker will be paying more than that every single block,\nconstantly racing, until it loses either a mempool race or the latest bid.\n\nI'm starting simple and assuming we don't need all this machinery, and hope\nthe risk of counterparty either losing the race a single time, or being\noutbid a single time is enough to dissuade an attack at all.\n\n\u003e A mitigation could be for a fee-bumping strategy to adopt a scorched\napproach when the HTLC-timeout is approaching, and there is a corresponding\nincoming HTLC. When the HTLC-timeout is near expiration (e.g X blocks from\nincoming HTLC expiry), probably 100% of the HTLC value should be burnt in\nupdate transaction fees.\n\nI kind of always thought that's how HTLCs would have worked in theory and\npractice eventually. As the clock runs down you're willing to spend more to\ntake less of the full value.\n\n\u003e Assuming the attack holds, and scorched approach are adopted by default\nto mitigate this concern, there is a second-order concern, we might open\nLightning channels to miner-harvesting attacks, where the confirmation of\nthe update transactions are deferred to kick-out the scorched earth\nreaction of the fee-bumping engine. In my opinion, this would be still an\nimprovement, as we're moving a (plausible) security risk triggerable by a\nLightning counterparty to (hypothetical) one triggerable by a wide\ncoalition of miners.\n\nAs I said before, I think this is already the case. We're assuming\nliveliness of blockchain for these contracts, if a unilateral close gets\ntargeted by a large fraction of miners, I don't think eltoo is the risk,\nit's the HTLC constract that's the risk.\n\n\u003e There is another caveat, it sounds if the update transaction can be\nmalleable (i.e SIGHASH_SINGLE|ANYONECANPAY), update transactions across\nLightning channels could be aggregated by the attacker, changing the\neconomy there in a way defavorable to the victims. I.e the attacker can\nselect the targeted channels, but the victim cannot coordinate with each\nother to respond with a collective fee-bumping.\n\nIn my current eltoo design, I'm assuming *by policy* APO (V3?) transactions\ncan only have one input, and each transaction is only allowed a single\nephemeral anchor which is attached but not committed to by the\nSIGHASH_SINGLE|APOAS signature. This results in a 1-input-2-output\ntransaction that isn't malleable. If and when we figure out how to un-pin\nthese kinds of transactions, this policy can be relaxed, and we can get the\nbenefits of aggregated transactions.\n\nCheers,\nGreg\n\nOn Mon, Dec 12, 2022 at 8:39 PM Antoine Riard \u003cantoine.riard at gmail.com\u003e\nwrote:\n\n\u003e Hi list,\n\u003e\n\u003e The following post describes a potential attack vector against eltoo-based\n\u003e Lightning channels, from my understanding also including the recent\n\u003e two-party eltoo w/ punishment construction. While I think this concern has\n\u003e been known for a while among devs, and I believe it's mitigable by adopting\n\u003e an adequate fee-bumping strategy, I still wonder how exactly it affects\n\u003e eltoo-based constructions.\n\u003e\n\u003e AFAICT, the eltoo 2-stage proposal relies on a serie of pre-signed update\n\u003e transactions, of which in the optimistic case only one of them confirms.\n\u003e There is a script-spend path, where an update transaction N can spend an\n\u003e update transaction K, assuming K\u003cN and an aggregated musig for the\n\u003e checksigverify.\n\u003e\n\u003e The attack purpose is to delay the confirmation of the final settlement\n\u003e transaction S, to double-spend a HTLC forwarded by a routing hop. I.e you\n\u003e have Ned the routing hop receiving the HTLC from Mallory upstream and\n\u003e sending the HTLC to Malicia downstream. Thanks to the cltv_expiry_delta,\n\u003e the HTLC forward should be safe as Ned can timeout the HTLC on the\n\u003e Ned-Malicia link before it is timed-out by Mallory on the Mallory-Ned link.\n\u003e In case of timeout failure, Malicia can claim the HTLC forward with the\n\u003e corresponding preimage, at the same block height than Mallory timeout the\n\u003e HTLC, effectively double-spending Ned.\n\u003e\n\u003e The cltv_expiry_delta requested by Ned is equal to N=144.\n\u003e\n\u003e The attack scenario works in the following way: Malicia updates the Eltoo\n\u003e channel N time, getting the possession of N update transactions. At block\n\u003e A, she breaks the channel and confirms the update transaction 0 by\n\u003e attaching a feerate equal to or superior to top mempool block space + 1\n\u003e sat. At each new block, she iterates by confirming the next update\n\u003e transaction, i.e update transaction 1 at block A+1, update transaction\n\u003e transaction 2 at block A+2, update transaction 3 at block A+3, ...\n\u003e\n\u003e From Ned's viewpoint, there is limited rationality of the network\n\u003e mempools, as such each punishment transaction R, as it's confirmation could\n\u003e have been delay due to \"honest\" slow propagation on the network is likely\n\u003e to be pre-signed with top mempool block space feerate, but not more to save\n\u003e on fees. Therefore, transaction RN.0 should fail to punish update\n\u003e transaction 0 as it's double-spent by update transaction 1, transaction\n\u003e RN.1 should fail to punish update transaction 1 as it's double-spent by\n\u003e update transaction 2, transaction RN.2 should fail to punish update\n\u003e transaction 2 as it's double-spent by update transaction 3...\n\u003e\n\u003e While there is a RBF-race, I think this can be easily won by Malicia by\n\u003e mass-connecting on the transaction-relay network and ignoring the Core\n\u003e transaction-relay delay timers (here for privacy purposes iirc).\n\u003e\n\u003e If it holds, I think the attack is economically opportun as long as the\n\u003e sum of the chain of update transactions weight multiplied by the spent\n\u003e feerate is inferior to the sum of HTLC values stolen (upper bounded to\n\u003e `max_htlc_value_in_flight_msat`, not `funding_satoshis`). The attack could\n\u003e be more sound in periods of low-fee, as the number of HTLC exploitable is\n\u003e higher.\n\u003e\n\u003e A mitigation could be for a fee-bumping strategy to adopt a scorched\n\u003e approach when the HTLC-timeout is approaching, and there is a corresponding\n\u003e incoming HTLC. When the HTLC-timeout is near expiration (e.g X blocks from\n\u003e incoming HTLC expiry), probably 100% of the HTLC value should be burnt in\n\u003e update transaction fees.\n\u003e\n\u003e I think some implementations in the LN-penalty are already doing \"upward\"\n\u003e fee-bumping frequency, while I believe it reduces the attack surface, I\n\u003e still think there is an exploitable window for \"update overflow\" attack.\n\u003e E.g in LDK justice transactions are bumped by 25% every block according to\n\u003e a height timer schedule [0].\n\u003e\n\u003e Assuming the attack holds, and scorched approach are adopted by default to\n\u003e mitigate this concern, there is a second-order concern, we might open\n\u003e Lightning channels to miner-harvesting attacks, where the confirmation of\n\u003e the update transactions are deferred to kick-out the scorched earth\n\u003e reaction of the fee-bumping engine. In my opinion, this would be still an\n\u003e improvement, as we're moving a (plausible) security risk triggerable by a\n\u003e Lightning counterparty to (hypothetical) one triggerable by a wide\n\u003e coalition of miners.\n\u003e\n\u003e There is another caveat, it sounds if the update transaction can be\n\u003e malleable (i.e SIGHASH_SINGLE|ANYONECANPAY), update transactions across\n\u003e Lightning channels could be aggregated by the attacker, changing the\n\u003e economy there in a way defavorable to the victims. I.e the attacker can\n\u003e select the targeted channels, but the victim cannot coordinate with each\n\u003e other to respond with a collective fee-bumping.\n\u003e\n\u003e Is the understanding of the two-party eltoo construction correct, and this\n\u003e \"update overflow\" attack is sound and economically opportun ? If it holds,\n\u003e I still wonder if we have variants playing with mempool descendant limits.\n\u003e In all cases, it sounds to me the implications are more in the way\n\u003e fee-bumping is implemented by Lightning softwares rather than directly on\n\u003e eltoo-based constructions, I don't see an immediate way to address it by\n\u003e the construction itself.\n\u003e\n\u003e Mistakes and confusions are my own.\n\u003e\n\u003e Antoine\n\u003e\n\u003e [0]\n\u003e https://github.com/lightningdevkit/rust-lightning/blob/5e14c24a11f610ab8c402f788ec5bd637e9e24af/lightning/src/chain/onchaintx.rs#L505\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221213/45a189de/attachment.html\u003e",
"sig": "20139d7caa259631ebb370e91768b1abcaa28e58eb22c777ec23ca17bb924ab5df2ee16a9961fb882676e1cbcf4d19cdcdf40e3fd4e4d7b76fcdbbea472b9edd"
}