📅 Original date posted:2022-11-07
📝 Original message:
Hey laolu,
Thanks for your feedback.
> However, I can imagine that if an implementation doesn't have its own
> wallet, then things can be a bit more difficult, as stuff like the
bitcoind
> wallet may not expose the APIs one needs to do things like CPFP properly.
I don't think this is only an issue of wallet management though. I would
bet that most node operators today don't have a good enough utxo reserve
to actually provide safety against a malicious attacker once mempool
backlog starts filling up. Eclair isn't really limited by bitcoind APIs
here, but rather by BIP 125 rules, which creates the same issues for
lnd's internal wallet.
The reason we're not seeing issues today is only because there is no
malicious behavior on the network, but when that happens, there will
be issues (remember, the turkey thinks everything is fine and really
likes that guy who comes everyday to feed it, until Thanksgiving comes).
The issue I'm most concerned with is an attacker filling your outgoing
HTLC slots with HTLCs that timeout at blocks N+1, N+2, ..., N+483. It's
not trivial to batch those HTLCs because they all have different cltv
expiries. If you're low on utxo count, you only have two choices:
1. Re-create a batched transaction at every block to include more utxos
2. Create trees of unconfirmed transactions where the change output of
one HTLC tx is the funding input of another HTLC tx
With option 1, you'll need to increase the overall feerate at every
block to match RBF rules, which means you'll end up greatly overpaying
the fees once you've RBF-ed a hundred times or more...
With option 2, it's even worse, because HTLCs that timeout earlier end
up closer to the root of tree. It will be prohibitively costly to RBF
them because BIP 125 will force you to pay a huge fee for replacing a
high number of unconfirmed descendants. Your only option is to CPFP at
one of the leaves of the tree, which is going to be very costly as well
because it requires setting a high feerate to the *whole* tree, even
though it could contain many HTLCs that still have time available before
the cltv-expiry-delta ends.
The attacker may also regularly claim HTLCs one-by-one by revealing the
preimage just to invalidate your whole batched transaction or tree of
unconfirmed transactions, requiring you to rebuild it at every block and
wait one more block before getting transactions confirmed (until you
reach the point where the attacker can also claim all HTLC outputs and
your only solution is a scorched-earth strategy).
Both options end up with the node operator greatly overpaying fees when
fighting a relatively smart attacker (which means the node operator is
actually losing money).
Also, this is a fairly complex bit of logic to implement, which depends
on bitcoin node's relaying policies and is really hard to test against
enough malicious scenarios. It's thus very likely to have subtle bugs.
This class of attacks are why eclair's default are very conservative:
* 30 accepted HTLCs instead of 483
* 144 blocks of cltv-expiry-delta
I'm afraid this is the only way to tip the odds in the favor of the
honest node operators with the current protocol. It's very frustrating
though!
As for Taproot compatibility, this is perfectly doable: if we're able
to share one nonce, we can just share multiple every time. If we're
able to watch one transaction, we're able to watch multiple. It's more
costly, but it's not a fundamental limitation.
I'm more concerned about limitations of this proposal to tackle dusty
HTLCs kind of attacks and the complexity it introduces, as was raised
in the comments of the spec PR [1]. Granted, this isn't a very *good*
proposal, but it's an attempt at raising awareness that we probably
need to do *something* to get slightly better funds safety.
Thanks,
Bastien
[1] https://github.com/lightning/bolts/pull/1036
Le sam. 5 nov. 2022 à 01:52, Olaoluwa Osuntokun <laolu32 at gmail.com> a écrit
:
>
> Hi tbast,
>
> FWIW, we haven't had _too_ many issues with the additional constraints
> anchor channels bring. Initially users had to deal w/ the UTXO reserve,
but
> then sort of accepted the trade-off for the safety that actually being
able
> to dynamically bump the fee on your commitment transaction and HTLCs.
We're
> also able to re-target the fee level of second level spends on the fly,
and
> even aggregate them into distinct fee buckets.
>
> However, I can imagine that if an implementation doesn't have its own
> wallet, then things can be a bit more difficult, as stuff like the
bitcoind
> wallet may not expose the APIs one needs to do things like CPFP properly.
> lnd has its own wallet (btcwallet), which is what has allowed us to adopt
> default P2TR addresses everywhere so quickly (tho ofc we inherit
additional
> maintenance costs).
>
> > Correctly managing this fee-bumping reserve involves a lot of complex
> > decisions and dynamic risk assessment, because in worst-case scenarios,
a
> > node may need to fee-bump thousands of HTLC transactions in a short
period
> > of time.
>
> IMO these new considerations aren't any worse than needing to predict the
> future fee schedule of the chain to ensure that you can force close in a
> timely manner when you need to. Re fee bumping thousands of HTLCs: anchor
> lets them all be batched in the same transaction, which reduces fees and
> also the worst-case on-chain force close footprint.
>
> > each node can simply sign multiple versions of the HTLC transactions at
> > various feerates
>
> I'm not sure this can be mapped super cleanly to taproot channels that use
> musig2. Today in the spec draft/impl, both sides maintain a pair of nonces
> (one for each commitment transaction). If they need to sign N different
> versions, then they also need to exchange N nonces, both during the
initial
> funding process, and also each time a new commitment transaction is
created.
> Mo signatures means mo transaction latency. Also how would retransmitting
be
> handled? By sending distinct valid signatures for a given fee rate, you're
> effectively creating _even more_ commitments one needs to watch to be able
> to play once they potentially hit the chain.
>
> Ultimately, I'm not sure why implementations that have already rolled out
> anchors by default, and have a satisfactory policy for ensuring fee
bumping
> UTXOs are available at all times would implement this. It's just yet
another
> option defined in the spec, and prescribes a more restrictive solution to
> what's already possible: being able to dynamically fee bump commitment
> transactions, and aggregate second level spends.
>
> -- Laolu
>
> On Thu, Oct 27, 2022 at 6:51 AM Bastien TEINTURIER <bastien at acinq.fr>
wrote:
>>
>> Good morning list,
>>
>> The lightning network transaction format was updated to leverage CPFP
>> carve-out and allow nodes to set fees at broadcast time, using a feature
>> called anchor outputs [1].
>>
>> While desirable, this change brought a whole new set of challenges, by
>> requiring nodes to maintain a reserve of available utxos for fee-bumping.
>> Correctly managing this fee-bumping reserve involves a lot of complex
>> decisions and dynamic risk assessment, because in worst-case scenarios,
>> a node may need to fee-bump thousands of HTLC transactions in a short
>> period of time.
>>
>> This is especially frustrating because HTLC transactions should not need
>> external inputs, as the whole value of the HTLC is already provided in
>> its input, which means we could in theory "simply" decrease the amount of
>> the corresponding output to set the fees to any desired value. However,
>> we can't do this safely because it doesn't work well with the revocation
>> mechanism, unless we find fancy new sighash flags to add to bitcoin.
>> See [2] for a longer rant on this issue.
>>
>> A very low tech and unsatisfying solution exists, which is what I'm
>> proposing today: each node can simply sign multiple versions of the
>> HTLC transactions at various feerates, and at broadcast time if you're
>> lucky you'll have a pre-signed transaction that approximately matches
>> the feerate you want, so you don't need to add inputs from your fee
>> bumping reserve. This reduces the requirements on your on-chain wallet
>> and simplifies transaction management logic. I believe that it's a
>> pragmatic approach, even though not very elegant, to increase funds
>> safety for existing node operators and wallets. I opened a spec PR
>> that is currently chasing concept ACKs before I refine it [3].
>>
>> Please let me know what you think, and if this is something that you
>> would like your implementation to provide.
>>
>> Thanks,
>> Bastien
>>
>> [1] https://github.com/lightning/bolts/pull/688
>> [2] https://github.com/lightning/bolts/issues/845
>> [3] https://github.com/lightning/bolts/pull/1036
>> _______________________________________________
>> 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/20221107/890d4429/attachment.html>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 13:07:21
in reply to nevent1q…67yu
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 13:07:21Event JSON
{
"id": "d0212cd88b9c12a0c1e6e2f63ca7414562ac91d9412ab1c77aef3767bbd95463",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686316041,
"kind": 1,
"tags": [
[
"e",
"431bf50115f301780e5cabeec68b571a6b43d111f72d4bf4e2e9240e6f7e8715",
"",
"root"
],
[
"e",
"b4fcbb96ccbf11eebf8537e992bd889d5d9035df0d333a3dfe03a9b36f1b7178",
"",
"reply"
],
[
"p",
"2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476"
]
],
"content": "📅 Original date posted:2022-11-07\n📝 Original message:\nHey laolu,\n\nThanks for your feedback.\n\n\u003e However, I can imagine that if an implementation doesn't have its own\n\u003e wallet, then things can be a bit more difficult, as stuff like the\nbitcoind\n\u003e wallet may not expose the APIs one needs to do things like CPFP properly.\n\nI don't think this is only an issue of wallet management though. I would\nbet that most node operators today don't have a good enough utxo reserve\nto actually provide safety against a malicious attacker once mempool\nbacklog starts filling up. Eclair isn't really limited by bitcoind APIs\nhere, but rather by BIP 125 rules, which creates the same issues for\nlnd's internal wallet.\n\nThe reason we're not seeing issues today is only because there is no\nmalicious behavior on the network, but when that happens, there will\nbe issues (remember, the turkey thinks everything is fine and really\nlikes that guy who comes everyday to feed it, until Thanksgiving comes).\n\nThe issue I'm most concerned with is an attacker filling your outgoing\nHTLC slots with HTLCs that timeout at blocks N+1, N+2, ..., N+483. It's\nnot trivial to batch those HTLCs because they all have different cltv\nexpiries. If you're low on utxo count, you only have two choices:\n\n1. Re-create a batched transaction at every block to include more utxos\n2. Create trees of unconfirmed transactions where the change output of\none HTLC tx is the funding input of another HTLC tx\n\nWith option 1, you'll need to increase the overall feerate at every\nblock to match RBF rules, which means you'll end up greatly overpaying\nthe fees once you've RBF-ed a hundred times or more...\n\nWith option 2, it's even worse, because HTLCs that timeout earlier end\nup closer to the root of tree. It will be prohibitively costly to RBF\nthem because BIP 125 will force you to pay a huge fee for replacing a\nhigh number of unconfirmed descendants. Your only option is to CPFP at\none of the leaves of the tree, which is going to be very costly as well\nbecause it requires setting a high feerate to the *whole* tree, even\nthough it could contain many HTLCs that still have time available before\nthe cltv-expiry-delta ends.\n\nThe attacker may also regularly claim HTLCs one-by-one by revealing the\npreimage just to invalidate your whole batched transaction or tree of\nunconfirmed transactions, requiring you to rebuild it at every block and\nwait one more block before getting transactions confirmed (until you\nreach the point where the attacker can also claim all HTLC outputs and\nyour only solution is a scorched-earth strategy).\n\nBoth options end up with the node operator greatly overpaying fees when\nfighting a relatively smart attacker (which means the node operator is\nactually losing money).\n\nAlso, this is a fairly complex bit of logic to implement, which depends\non bitcoin node's relaying policies and is really hard to test against\nenough malicious scenarios. It's thus very likely to have subtle bugs.\n\nThis class of attacks are why eclair's default are very conservative:\n\n* 30 accepted HTLCs instead of 483\n* 144 blocks of cltv-expiry-delta\n\nI'm afraid this is the only way to tip the odds in the favor of the\nhonest node operators with the current protocol. It's very frustrating\nthough!\n\nAs for Taproot compatibility, this is perfectly doable: if we're able\nto share one nonce, we can just share multiple every time. If we're\nable to watch one transaction, we're able to watch multiple. It's more\ncostly, but it's not a fundamental limitation.\n\nI'm more concerned about limitations of this proposal to tackle dusty\nHTLCs kind of attacks and the complexity it introduces, as was raised\nin the comments of the spec PR [1]. Granted, this isn't a very *good*\nproposal, but it's an attempt at raising awareness that we probably\nneed to do *something* to get slightly better funds safety.\n\nThanks,\nBastien\n\n[1] https://github.com/lightning/bolts/pull/1036\n\nLe sam. 5 nov. 2022 à 01:52, Olaoluwa Osuntokun \u003claolu32 at gmail.com\u003e a écrit\n:\n\u003e\n\u003e Hi tbast,\n\u003e\n\u003e FWIW, we haven't had _too_ many issues with the additional constraints\n\u003e anchor channels bring. Initially users had to deal w/ the UTXO reserve,\nbut\n\u003e then sort of accepted the trade-off for the safety that actually being\nable\n\u003e to dynamically bump the fee on your commitment transaction and HTLCs.\nWe're\n\u003e also able to re-target the fee level of second level spends on the fly,\nand\n\u003e even aggregate them into distinct fee buckets.\n\u003e\n\u003e However, I can imagine that if an implementation doesn't have its own\n\u003e wallet, then things can be a bit more difficult, as stuff like the\nbitcoind\n\u003e wallet may not expose the APIs one needs to do things like CPFP properly.\n\u003e lnd has its own wallet (btcwallet), which is what has allowed us to adopt\n\u003e default P2TR addresses everywhere so quickly (tho ofc we inherit\nadditional\n\u003e maintenance costs).\n\u003e\n\u003e \u003e Correctly managing this fee-bumping reserve involves a lot of complex\n\u003e \u003e decisions and dynamic risk assessment, because in worst-case scenarios,\na\n\u003e \u003e node may need to fee-bump thousands of HTLC transactions in a short\nperiod\n\u003e \u003e of time.\n\u003e\n\u003e IMO these new considerations aren't any worse than needing to predict the\n\u003e future fee schedule of the chain to ensure that you can force close in a\n\u003e timely manner when you need to. Re fee bumping thousands of HTLCs: anchor\n\u003e lets them all be batched in the same transaction, which reduces fees and\n\u003e also the worst-case on-chain force close footprint.\n\u003e\n\u003e \u003e each node can simply sign multiple versions of the HTLC transactions at\n\u003e \u003e various feerates\n\u003e\n\u003e I'm not sure this can be mapped super cleanly to taproot channels that use\n\u003e musig2. Today in the spec draft/impl, both sides maintain a pair of nonces\n\u003e (one for each commitment transaction). If they need to sign N different\n\u003e versions, then they also need to exchange N nonces, both during the\ninitial\n\u003e funding process, and also each time a new commitment transaction is\ncreated.\n\u003e Mo signatures means mo transaction latency. Also how would retransmitting\nbe\n\u003e handled? By sending distinct valid signatures for a given fee rate, you're\n\u003e effectively creating _even more_ commitments one needs to watch to be able\n\u003e to play once they potentially hit the chain.\n\u003e\n\u003e Ultimately, I'm not sure why implementations that have already rolled out\n\u003e anchors by default, and have a satisfactory policy for ensuring fee\nbumping\n\u003e UTXOs are available at all times would implement this. It's just yet\nanother\n\u003e option defined in the spec, and prescribes a more restrictive solution to\n\u003e what's already possible: being able to dynamically fee bump commitment\n\u003e transactions, and aggregate second level spends.\n\u003e\n\u003e -- Laolu\n\u003e\n\u003e On Thu, Oct 27, 2022 at 6:51 AM Bastien TEINTURIER \u003cbastien at acinq.fr\u003e\nwrote:\n\u003e\u003e\n\u003e\u003e Good morning list,\n\u003e\u003e\n\u003e\u003e The lightning network transaction format was updated to leverage CPFP\n\u003e\u003e carve-out and allow nodes to set fees at broadcast time, using a feature\n\u003e\u003e called anchor outputs [1].\n\u003e\u003e\n\u003e\u003e While desirable, this change brought a whole new set of challenges, by\n\u003e\u003e requiring nodes to maintain a reserve of available utxos for fee-bumping.\n\u003e\u003e Correctly managing this fee-bumping reserve involves a lot of complex\n\u003e\u003e decisions and dynamic risk assessment, because in worst-case scenarios,\n\u003e\u003e a node may need to fee-bump thousands of HTLC transactions in a short\n\u003e\u003e period of time.\n\u003e\u003e\n\u003e\u003e This is especially frustrating because HTLC transactions should not need\n\u003e\u003e external inputs, as the whole value of the HTLC is already provided in\n\u003e\u003e its input, which means we could in theory \"simply\" decrease the amount of\n\u003e\u003e the corresponding output to set the fees to any desired value. However,\n\u003e\u003e we can't do this safely because it doesn't work well with the revocation\n\u003e\u003e mechanism, unless we find fancy new sighash flags to add to bitcoin.\n\u003e\u003e See [2] for a longer rant on this issue.\n\u003e\u003e\n\u003e\u003e A very low tech and unsatisfying solution exists, which is what I'm\n\u003e\u003e proposing today: each node can simply sign multiple versions of the\n\u003e\u003e HTLC transactions at various feerates, and at broadcast time if you're\n\u003e\u003e lucky you'll have a pre-signed transaction that approximately matches\n\u003e\u003e the feerate you want, so you don't need to add inputs from your fee\n\u003e\u003e bumping reserve. This reduces the requirements on your on-chain wallet\n\u003e\u003e and simplifies transaction management logic. I believe that it's a\n\u003e\u003e pragmatic approach, even though not very elegant, to increase funds\n\u003e\u003e safety for existing node operators and wallets. I opened a spec PR\n\u003e\u003e that is currently chasing concept ACKs before I refine it [3].\n\u003e\u003e\n\u003e\u003e Please let me know what you think, and if this is something that you\n\u003e\u003e would like your implementation to provide.\n\u003e\u003e\n\u003e\u003e Thanks,\n\u003e\u003e Bastien\n\u003e\u003e\n\u003e\u003e [1] https://github.com/lightning/bolts/pull/688\n\u003e\u003e [2] https://github.com/lightning/bolts/issues/845\n\u003e\u003e [3] https://github.com/lightning/bolts/pull/1036\n\u003e\u003e _______________________________________________\n\u003e\u003e Lightning-dev mailing list\n\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221107/890d4429/attachment.html\u003e",
"sig": "fd5a96513a80901ad1e232d4c76485c6ec284b8f2d760685f9c3f7a7f0f26a798fb64ab1119288deef18fdcf81b762c6750e9194c0fc61fac219f7482f7514c4"
}