Zero-fee commitments support by tankyleo · Pull Request #660 · lightningdevkit/ldk-node

tankyleo · 2025-10-13T13:14:22Z

No description provided.

ldk-reviews-bot · 2025-10-13T13:14:24Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

tnull · 2025-10-13T13:25:43Z

+	/// `option_anchor_zero_fee_commitments`. All the caveats and warnings in
+	/// [`AnchorChannelsConfig`] still apply.
+	/// [`AnchorChannelsConfig`]: Config::anchor_channels_config
+	pub enable_zero_fee_commitments: bool,


I don't think we'll wan to add a new flag here that's probably hard to understand for the user? Rather, shouldn't we enable this for the user based on our current 'trust model settings' here?

Also, from these docs it's very unclear what this setting even does, when the user would want to enable it, what drawbacks it has, etc

FWIW, thinking about it again it seems that we should never set negotiate_anchor_zero_fee_commitments until we're positive our chain sources support submitpackage/TRUC, no? And once we are positive, we would always set it?

Rather, shouldn't we enable this for the user based on our current 'trust model settings' here?

Don't quite follow here could you expand ? I think 0FC channels merit an explicit setting somewhere rather than derived from trust model settings.

Also, from these docs it's very unclear what this setting even does, when the user would want to enable it, what drawbacks it has, etc

Yes will expand

Don't quite follow here could you expand ? I think 0FC channels merit an explicit setting somewhere rather than derived from trust model settings.

Why, what do they fundamentally change for the user compared to our three current modes (fully trusted/keep 0-reserve, still try to claim/keep X reserve, try to claim)? Keep in mind that communicating these three modes to the user is already very hard, they always have a very hard time understanding what this means. Now, how would we communicate any changed assumptions for 0FC here? If we already trust our counterparty already, wouldn't we always want to enable 0FC for the UX improvements?

Why, what do they fundamentally change for the user compared to our three current modes (fully trusted/keep 0-reserve, still try to claim/keep X reserve, try to claim)?

Let me see I don't think they change anything ? Whether to enable or disable 0FC channels is orthogonal to these modes ie trusted_peers_no_reserve and per_channel_reserve_sats should have no influence on whether we enable 0FC channels (only that per_channel_reserve_sats should be set to some value). I suspect you don't agree :)

If we already trust our counterparty already, wouldn't we always want to enable 0FC for the UX improvements?

It seems to me trusting our counterparty -> keeping 0 reserve is orthogonal to whether the user wants to enable 0FC channels ? for example a user trusts their counterparty, but wants to wait for greater adoption of Core v29+ before using 0FC channels.

tankyleo · 2025-10-24T06:06:59Z

Marked as draft: I think we should wait for electrum and esplora submit package support before merging this PR.

tankyleo · 2025-10-27T05:28:19Z

Successfully opened some 0FC channels, made payments, and force closed them with the esplora diff in this branch.

https://mutinynet.com/tx/508a954d85f5b7daf224a2fdc54ea6de9a26c0f62f7d58284bf61c3cdfd346e6

tankyleo · 2026-06-25T03:52:02Z

Rebased, squashed the previous fixups, added a few more

tnull · 2026-06-25T08:58:39Z

 	}

+	pub(super) async fn validate_zero_fee_commitments_support(&self) -> Result<(), Error> {
+		self.esplora_client.submit_package(&super::dummy_package(), None, None).await.map_err(


Especially if we already submitted this package before, couldn't the backend return an different error that we'd misinterpret as 'doesn't support submitpackage'? E.g., typical transaction broadcast errors are 'already known' or 'missing-inputs'. Why can't we ever hit them here?

I've looked down the stack, and also had codex review the mempool-electrs and blockstream-electrs code.

already-known and missing-inputs errors get placed in the package_msg and error fields of the response, but still yield status 200.

Non 200 error codes are for transport-level errors, not for errors returned in the fields of the submitpackage response. As long as Bitcoin Core RPC returns some valid response for submitpackage, we get back 200.

Hmm, if we always get back a 200 if there's no connectivity error, then I'm still confused why we interpret any error here as Esplora server does not support submitpackage? Shouldn't we only match on 404 (assuming that's what's returned if the endpoint isn't known?)

Also want to note that this way of checking support for Electrum/Esplora is error prone as it will pass if the service runs bitcoind v26+ I believe, while we require v29+ in reality?

Shouldn't we only match on 404 (assuming that's what's returned if the endpoint isn't known?)

Sounds good yes I will be more precise.

Also want to note that this way of checking support for Electrum/Esplora is error prone as it will pass if the service runs bitcoind v26+ I believe, while we require v29+ in reality?

Yes agreed this is not a guarantee we are safe. Do you see another way to do this?

Added some more prevision below based on the error returned across both electrum and esplora.

Also want to note that this way of checking support for Electrum/Esplora is error prone as it will pass if the service runs bitcoind v26+ I believe, while we require v29+ in reality?

Thought about it further, I'm open to all options here.

Is it too early / reckless to ship 0FC channels against electrum / esplora given that they offer no way to assert that the backend Bitcoind is v29+ ?

Should we wait for a way to assert more cleanly that some esplora server supports submitpackage? You have a PR to do this for the electrum client thank you !

Should we drop the validate_zero_fee_commitments_support startup roundtrip in electrum and esplora given that it doesn't even guarantee that the backend bitcoind will relay ephemeral dust?

ah I also note, mempool-electrs HTTP esplora responses add a x-bitcoin-version to all response headers, containing the bitcoin version of the node it's running against. This is not the case yet for blockstream-electrs.

Yes agreed this is not a guarantee we are safe. Do you see another way to do this?

No, not sure either. At the very least we need to make sure our docs clearly say this, and we should probably also add a compatibility note in the (pending) changelog.

Is it too early / reckless to ship 0FC channels against electrum / esplora given that they offer no way to assert that the backend Bitcoind is v29+ ?

Hmm, not necessarily, though maybe we should check what the big explorers are running right now? Are we positive mempool and Blockstream are on v29+?

Should we drop the validate_zero_fee_commitments_support startup roundtrip in electrum and esplora given that it doesn't even guarantee that the backend bitcoind will relay ephemeral dust?

Good question that I'm also not entirely sure about. Given the call should be pretty quick and runs in parallel to the blocking fee rate update we shouldn't lose much time? But we just need to make sure it's as robust as possible, and maybe even add a TODO/issue to drop it again in a few months when we're positive the support is ubiquitous?

ah I also note, mempool-electrs HTTP esplora responses add a x-bitcoin-version to all response headers, containing the bitcoin version of the node it's running against. This is not the case yet for blockstream-electrs.

Yeah, we should def. not lean on proprietary optional features for this.

Added docs on Config.anchor_channels_config, and a note in the pending changelog.

Added TODO + issue to drop 0FC chain source validation when support is ubiquitous.

From the x-bitcoin-version header, looks like mempool is running v30, I have not checked blockstream, I'll try to broadcast ephemeral dust against them tomorrow.

tnull · 2026-06-25T09:04:53Z

 			.init_features;
-		let anchor_channel = init_features.requires_anchors_zero_fee_htlc_tx();
+		let anchor_channel = init_features.requires_anchors_zero_fee_htlc_tx()
+			|| init_features.requires_anchor_zero_fee_commitments();


Hmm, pre-existing, but it seems for init features we should be using supports_?

Yes @febyeji had a similar question further above in this comment: #660 (comment)

Can we revisit these checks in a standalone PR ?

Can we revisit these checks in a standalone PR ?

Well, if we touch it here we should at least not add incorrect code if we think it's incorrect. If you prefer a separate PR, feel free to open an base this one on top, but could also make it a prefactor commit.

ok will add a prefactor commit then

Done, added two commits below

tankyleo · 2026-06-25T15:30:43Z

Let me know if I can squash

tnull

Please squash!

tnull · 2026-06-26T06:12:15Z

 	}

-	pub(crate) async fn process_broadcast_package(&self, txs: TransactionBroadcast) {
+	fn log_broadcast_error(&self, e: impl core::fmt::Display, txids: &[Txid], txs: &[Transaction]) {


Please make the DRYing up a freestanding prefactor commit and then use it in a fixup to your code (to not touch unrelated preexisting code in your commits)

Yes that's the plan!

Done, see commit below

tnull · 2026-06-26T06:15:58Z

-		let spawn_fut =
-			self.runtime.spawn_blocking(move || electrum_client.transaction_broadcast(&tx));
+		let spawn_fut = self.runtime.spawn_blocking({
+			let tx = tx.clone();


Why do we need this clone now?

the log helpers further below take a &[Transaction] now, will rework things to remove it.

tnull · 2026-06-26T06:19:40Z

+		let txids: Vec<_> = package.iter().map(|tx| tx.compute_txid()).collect();
+
+		let spawn_fut = self.runtime.spawn_blocking({
+			let package = package.clone();


Can we avoid cloning the whole package? It seems it's only required because we need the reference later for logging, but previously we intentionally avoided the allocations. Can we do the same still here and above?

Sounds good will remove these clones thank you

tnull · 2026-06-26T06:32:50Z

 					total_anchor_channels_reserve_sats(&self.channel_manager, &self.config);
 				let spendable_amount_sats =
 					self.wallet.get_spendable_amount_sats(cur_anchor_reserve_sats).unwrap_or(0);
+				let anchor_channel = init_features.requires_anchors_zero_fee_htlc_tx()


Claude:

/home/tnull/workspace/ldk-node-pr-660/src/liquidity/service/lsps2.rs:455: git diff --check upstream/main...HEAD fails because added lines contain trailing \r whitespace at lines 455, 456, and 459.

I removed all carriage returns across all rust files in a prefactor commit below.

tnull · 2026-06-26T06:34:07Z

 	}

+	pub(super) async fn validate_zero_fee_commitments_support(&self) -> Result<(), Error> {
+		self.esplora_client.submit_package(&super::dummy_package(), None, None).await.map_err(


Also want to note that this way of checking support for Electrum/Esplora is error prone as it will pass if the service runs bitcoind v26+ I believe, while we require v29+ in reality?

tnull · 2026-06-26T06:54:40Z


 const BCAST_PACKAGE_QUEUE_SIZE: usize = 50;

+pub(crate) struct TransactionBroadcast(Vec<Transaction>);


Btw, this is now redudant/overlapping with the BroadcastPackage in #888. Not sure if you want to coordinate to use exactly the same type in both PRs ahead of time, or just have one rebase depending what ends up landing first? @tankyleo @jkczyz

Yea happy to rebase myself in case that's needed no problem

Feel free to rename the type, BTW, if TransactionBroadcast is more accurate. I didn't put much thought on checking the naming.

tankyleo · 2026-06-29T05:10:49Z

I just added this last commit here "Tighten requirements to unset anchor channels config", if it looks good I'll adapt it to a prefactor commit to the "Check that the chain source supports 0FC channels" commit.

tnull

This needs a rebase now that #888 landed. Sorry!

Feel free to squash, I'll do a full pass once it's rebased and hopefully we should be close then.

We only do this for rust files, and leave bat files untouched. Use git show --ignore-cr-at-eol to check that this commit has no other edits.

`BroadcasterInterface::broadcast_transactions` requires that any passed vector containing multiple transactions must be a single child together with its parents. We will lean on this contract in upcoming commits, so here we fix a case where we broke this contract.

In an upcoming commit, we will fix `check_sufficient_funds_for_channel` to check that we have on-chain funds to cover the anchor reserve for an additional anchor channel in the validation of outbound channel opens. Before we do this, we stop using this function to check that any splice-ins leave enough on-chain anchor reserves. This function keeps an anchor reserve for an additional anchor channel on top of the existing set of anchor channels, but after splice-ins, our anchor reserve only needs to cover the existing set of anchor channels.

When we are preparing to open a channel to a peer, we should reserve onchain funds for an anchor channel when the peer's init features signals anchor channels as optional, as channel negotiation with such a peer can result in an anchor channel. Tests written with codex.

The patch adds support for the `broadcast_package` method added in electrum protocol v1.6. Upcoming commits will require this patch to pass CI.

The mempool/electrs docker image used in those tests only supports submitpackage via the esplora interface, not the electrum interface.

We bump the Bitcoin Core version used in kotlin and python tests to support ephemeral dust. This is required for 0FC channels.

Do this roundtrip at the same time we make a roundtrip to retrieve the feerates to keep startup as fast as possible.

Implementations of `BroadcasterInterface` cannot assume any topological ordering on the transactions received, so here we order the received transactions before adding them to the broadcast queue. Any consumers of the queue can now assume all transactions received to be topologically sorted. Codex wrote the tests.

These will be useful when we add support for broadcasting packages in an upcoming commit.

We rely on the `BroadcasterInterface` contract whereby any multi-transaction vector must be a single child and its parents, and must be broadcasted together as a package using `submitpackage`. In a prior commit, we added the guarantee that any packages received from the broadcast queue are already topologically sorted, and hence can be passed directly to the `submit_package` Bitcoin Core RPC.

We previously allowed users to unset the anchor channels config while they still had anchor channels open or unresolved. This allowed our users to drain their anchor reserves while still having anchor channels open. This is particularly dangerous for 0FC channels, as these rely entirely on anchor bumps to force-close the channel. Here, we require that a user first close and resolve all their existing anchor channels before unsetting their anchor channels config to disable the opening of fresh anchor channels.

tnull

One comment, otherwise LGTM! Unfortunately needs another tiny rebase by now due to minor conflicts in the test files.

tnull · 2026-06-30T07:29:43Z

+				are still open or unresolved. You must close and resolve all anchor \
+				channels before disabling anchor channels."
+			);
+			return Err(Error::ChannelConfigUpdateFailed);


Hmm, I really dislike the pattern of letting users configure something that we end up erroring on. If we think we need to be more strict now, we should probably find an API that doesn't allow the user to setup an 'unsafe' configuration in the first place.

In LDK we previously discussed making anchors mandatory. Should we rather trailblaze here, and simply make AnchorsChannelConfig non-optional?

If we do this, maybe we should make negotiating 0fc optional though, if only because of the chain source requirements, and we want to maintain backwards compat for a while?

All makes sense to me, will prepare the fixups.

we want to maintain backwards compat for a while

A clarification I thought ldk-node does not allow downgrades ?

@benthecarman does the above sound good to you ? First make anchors required in this release, then next release we turn on 0FC channels by default ?

by anchors we just mean that they should always be available for negotiation, we will still negotiate down to legacy channels if needed.

tankyleo requested a review from tnull October 13, 2025 13:14

tnull reviewed Oct 13, 2025

View reviewed changes

tankyleo force-pushed the 25-10-0fc-channel-config branch from cb1cdf9 to c874049 Compare October 24, 2025 06:05

tankyleo requested a review from tnull October 24, 2025 06:06

tankyleo marked this pull request as draft October 24, 2025 06:06

tankyleo force-pushed the 25-10-0fc-channel-config branch from c874049 to ef3ba7a Compare October 27, 2025 05:15

tankyleo force-pushed the 25-10-0fc-channel-config branch from ef3ba7a to 3ebd017 Compare October 29, 2025 08:56

tankyleo changed the title ~~Add AnchorChannelsConfig::enable_zero_fee_commitments~~ Zero-fee commitments support Oct 30, 2025

tankyleo self-assigned this Oct 30, 2025

tankyleo added this to Weekly Goals Oct 30, 2025

tankyleo force-pushed the 25-10-0fc-channel-config branch from 3ebd017 to eda13d4 Compare November 11, 2025 04:16

tankyleo removed this from Weekly Goals Nov 12, 2025

tankyleo force-pushed the 25-10-0fc-channel-config branch 4 times, most recently from e136f33 to d4a2a04 Compare November 19, 2025 19:11

tankyleo force-pushed the 25-10-0fc-channel-config branch 9 times, most recently from 771f45b to a7c7911 Compare May 29, 2026 00:36

tankyleo marked this pull request as ready for review May 29, 2026 01:08

tankyleo requested a review from benthecarman May 29, 2026 01:08

tnull reviewed Jun 25, 2026

View reviewed changes

tankyleo requested a review from tnull June 25, 2026 15:30

tnull reviewed Jun 26, 2026

View reviewed changes

tankyleo force-pushed the 25-10-0fc-channel-config branch from fcf54fd to 5eab461 Compare June 28, 2026 00:36

tankyleo requested a review from tnull June 29, 2026 05:12

tnull reviewed Jun 29, 2026

View reviewed changes

tankyleo added 15 commits June 29, 2026 17:33

Remove all carriage returns at end-of-lines

b4aa7ea

We only do this for rust files, and leave bat files untouched. Use git show --ignore-cr-at-eol to check that this commit has no other edits.

Use a patched blockstream-electrs in CI

8983426

The patch adds support for the `broadcast_package` method added in electrum protocol v1.6. Upcoming commits will require this patch to pass CI.

Switch cln lnd and eclair interop tests to esplora

9af1ab4

The mempool/electrs docker image used in those tests only supports submitpackage via the esplora interface, not the electrum interface.

Bump Bitcoin Core version used in kotlin and python tests

51c8cab

We bump the Bitcoin Core version used in kotlin and python tests to support ephemeral dust. This is required for 0FC channels.

Check that the chain source supports 0FC channels

f0adeaa

Do this roundtrip at the same time we make a roundtrip to retrieve the feerates to keep startup as fast as possible.

Use helper functions to log broadcast errors

106230d

These will be useful when we add support for broadcasting packages in an upcoming commit.

Read even bits to check the anchor channel type

c85f592

Include 0FC channels in anchor channel checks

aa4d290

Negotiate 0FC channels if the anchor config is set

9f3544e

tankyleo force-pushed the 25-10-0fc-channel-config branch from 90e6a9b to 9f3544e Compare June 30, 2026 01:01

tankyleo mentioned this pull request Jun 30, 2026

Drop 0FC chain source validation when support is ubiquitous #953

Open

tankyleo requested a review from tnull June 30, 2026 01:18

tnull reviewed Jun 30, 2026

View reviewed changes


		const BCAST_PACKAGE_QUEUE_SIZE: usize = 50;

		pub(crate) struct TransactionBroadcast(Vec<Transaction>);

Uh oh!

Conversation

tankyleo commented Oct 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ldk-reviews-bot commented Oct 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tnull Oct 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tankyleo commented Oct 24, 2025

Uh oh!

tankyleo commented Oct 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tankyleo commented Jun 25, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tankyleo Jun 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tankyleo commented Jun 25, 2026

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tankyleo commented Oct 13, 2025 •

edited

Loading

ldk-reviews-bot commented Oct 13, 2025 •

edited

Loading

tnull Oct 13, 2025 •

edited

Loading

tankyleo commented Oct 27, 2025 •

edited

Loading

tankyleo Jun 30, 2026 •

edited

Loading

tnull Jun 26, 2026 •

edited

Loading