[feature]: Zero Fee Commitments

[TheBlueMatt]

Zero-fee commitments are specified at lightning/bolts#1228 and fix a number of important security and usability issues.

First of all, 0FC addresses a remaining major naive pinning attack against anchor channels - the trivial "just put a bunch of crap in the mempool" attack, driving fees up for a replacement, potentially higher than you're willing to pay. 0FC relies on tx version 3 to restrict package sizes to entirely remove the attack.

More generally, though, 0FC fixes important UX issues with non-routing nodes.

• 0FC fixes remaining issues with feerate disagreements. Sadly, with Harding's feerate-inflation attack a peer (LSP) setting a surprisingly high feerate is indistinguishable from an attack. We often see complaints where an LSP is using some conservative estimator with LND (eg at some point last week a few LSPs got stuck with the Bitcoin Core estimator thinking fees need to be 10sat/vB while blocks were empty, due to using CONSERVATIVE fee estimation mode) and a non-routing node client uses a more reasonable estimator, causing the non-routing node client to assume the LSP is performing a feerate-inflation attack and refusing to send HTLCs. Of course the client can disable these checks and opt to trust the LSP, but switching lightning to a trusted mode isn't exactly an ideal outcome.
• Especially those with (pre-splicing) many channels, even things as basic as providing a "balance" to the user is complicated and ends up being horrendously confusing. If you have multiple channels, each individual channel is limited by reserve value, in-flight limits, and HTLC output tx fees. When you end up with (again, pre-splicing) several fairly-small channels, as is common for "end-user nodes" with an LSP, these issues compound and often show up as a nontrivial restriction in your ability to send your "balance", frustrating users. 0FC fixes the last issue (HTLC output tx fees) here, with 0-reserve being employed sometimes and in-flight limits being only optional.

Of course none of this is to mention the absolute sheer joy that removing the feerate-updating logic should bring to everyone. Both the above-mentioned feerate-inflation attacks and feerate disagreement issues, but also the edge cases around sudden fee spikes leaving channels unable to add any additional HTLCs that could come back to bite us at any moment are overhead none of us should want.

[TheBlueMatt]

Oh, and I forgot to mention, 0FC is really surprisingly easy to implement! Nothing wild, really, just a new commitment tx format and that's it.

[Roasbeef]

See #9778, this is what we plan to tackle first. Would also be good to get the BOLT PR out of draft.

[TheBlueMatt]

Sure, I just wanted to highlight all the issues that this fixes specifically for LND nodes operating as LSPs to edge nodes, given that's not a perspective I assume y'all hear a ton of. As for the BOLT PR, I'll nag t-bast, but I think we're gonna ship support for this, like, this month, so that's probably enough :)

[Roasbeef]

Do y'all plan to ship with a staging feature bit? As possible things shift around between now and when it finally lands, similar to some of the changes that were made taproot chans.

[TheBlueMatt]

Sure, of course.

[TheBlueMatt]

Though its probably worth noting that this is really quite a trivial commitment tx format change, so I'm not really sure how many changes people can come up with here...

[Roasbeef]

so I'm not really sure how many changes people can come up with here...

I thought the same for taproot channels 🤷 (miniscript changes rejected, then revisited, even though wallets can't actually solely use bitcoind to sweep all the outs). Dunno, maybe the filtooors take over and we can no longer rely on the new policies 😝

[MegalithicBTC]

From the perspective of an LSP running LND, with many open channels to a variety of clients, including a large number of LDK clients, we've seen I think two flavors of bad behavior:

POTENTIALLY CATASTROPHIC BEHAVIOR
In July of 2024, we implemented a fancy custom fee.url for LND...

lnd/config.go

Line 376 in c02e94e

FeeURL string `long:"feeurl" description:"DEPRECATED: Use 'fee.url' option. Optional URL for external fee estimation. If no URL is specified, the method for fee estimation will depend on the chosen backend and network. Must be set for neutrino on mainnet." hidden:"true"`

.. in at attempt to be clever and efficient about how LND would estimate chain fees. We were swiftly rewarded with hundreds of force-closures (I think all from CLN and LDK nodes?) over just a few minutes. We took this lesson, and retreated to using bitcoind for fee estimation -- that is, just LND with its default settings.

QUITE UNPLEASANT BEHAVIOR
Now, with LND now using bitcoind for fee estimation, we can still have problems. As indicated above ( #10201 (comment) ) -- after a fee spike (and possibly some other, so far undetermined issues with gossip propagation) we saw many of our LDK clients refusing to send HTLCs.

So yes, it would definitely be useful for us, and likely other LND nodes who have LDK or CLN or other clients, to be able to use zero-fee commitments.

[Roasbeef]

That's great feedback (though I still don't understand why fee rate disagreements are happening at all, you can pay 2 sat/vb and get into the next block for months now). I don't doubt that zero fee commitments is super useful, I've been a proponent from the start and participated in rounds of feedback and discussion which led up to the creation of the draft PR.

If you're interested in what our current road to implementation looks like, then check out this issue: #9778.

The aspect that we'll likely spend the most time on is the reserve requirements for wallets.

Today we require 10k sat per channel, up to 100k total (now capped based on feedback that we required to much) confirmed in the wallet if you have anchor channels. Today, we still have some fee on the commitment transaction, and use update_fee from time to time.

If we go to zero fee commitments, then we need even stronger requirements. Consider the following scenario: user has 100k sat in their wallet, they have 10 channels, all 10 of those needs to go on chain urgently. The first channel closed snags that single 100k UTXO, this works for that channel, but now the 9 other channels don't have an input in the wallet they can use to spend the P2A output.

So in addition to the existing reserve requirement, we need some form of active UTXO management (eg: splitting them optimistically) to ensure that if a large portion of the channel try to force close, then we actually have spare fees to pay for them to enter the mempool. Otherwise, we can end up in the dire state of not having enough UTXOs confirmed to force close to resolve HTLCs.

The commitment format itself is a pretty straight forward change. The operational updates to our UTXO management will need some careful consideration.

As they say: all solutions lead to new problems...

[MegalithicBTC]

Makes sense. Just, regarding...

I still don't understand why fee rate disagreements are happening at all, you can pay 2 sat/vb and get into the next block for months now

In all the cases where we have trouble it's actually SHORT LIVED fee-spikes which are causing the problem. That said, we were running Bitcoind 27 until recently, and now that we are on Bitcoind 28, which defaults to ECONOMICAL mode ( bitcoin/bitcoin#30275 ) ... it will be interesting to see what happens during the next fee-spike.

[TheBlueMatt]

we need some form of active UTXO management (eg: splitting them optimistically)

Not sure I understand why this is a new requirement? With existing anchor channels its already the case that you need one UTXO per channel-closing if you need to go to chain and fees have gone up a bit (which you have to assume is when your channels will close if there's something malicious going on). Of course once a channel closes you now have an extra UTXO (or two) for the next channel.