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

tnull · 2026-07-06T10:41:30Z

Discussed offline, I brought back enable_zero_fee_commitments, but I still require submitpackage from the chain sources. Let me know if I can squash and rebase, and we can wait to hear back from our users if they'd be ok with this ? many thanks

Hmm, it seems that we could get users to upgrade (although it also doesn't seem seamless to them). But more generally I still find it a bit unfortunate to require submitpackage if there is no technical reason for it. Do you think we could find a way to only require it when users actually set enable_zero_fee_commitments?

tankyleo · 2026-07-07T03:17:40Z

m, it seems that we could get users to upgrade (although it also doesn't seem seamless to them). But more generally I still find it a bit unfortunate to require submitpackage if there is no technical reason for it. Do you think we could find a way to only require it when users actually set enable_zero_fee_commitments?

Agreed, we can yes, I'll make the diff tomorrow.

`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.

We previously allowed users to disable anchor channels and drain their anchor reserve while still having anchor channels open or pending resolution. This was acceptable for keyed anchor channels, as the commitment transaction therein still contained some fees, and had some chance of getting mined into a block without any anchor bumps. In upcoming commits, we will add support for 0FC channels, and their commitment transactions have zero fees and depend entirely on the anchor reserve to reach miners and get confirmed in a block. It is thus dangerous to disable anchor channels and drain the reserve after 0FC channels have been opened. Therefore, we make `AnchorChannelsConfig` required, and prevent this case from ever happening.

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.

In upcoming commits we will read this knob to determine whether to negotiate 0FC channels. For now, we make a best-effort attempt to make sure the configured chain source supports 0FC channels if this knob is set. Do this roundtrip at the same time we make a roundtrip to retrieve the feerates to keep startup as fast as possible.

tnull · 2026-07-08T13:20:42Z

 	}
 }

+fn supports_anchor_channel_type(init_features: &InitFeatures) -> bool {


Codex:

P2: /home/tnull/worktrees/ldk-node/pr-660/src/lib.rs:219 treats a peer advertising option_zero_fee_commitments as requiring an anchor reserve even when local enable_zero_fee_commitments is false. But /home/tnull/worktrees/ldk-node/pr-660/src/config.rs:415 only enables 0FC negotiation when
that flag is true. A zero-fee-only peer would fall back to static remotekey, while open_channel/open_channel_with_all and LSPS2 still reserve per_channel_reserve_sats, potentially rejecting valid opens as InsufficientFunds.

thanks addressed below

tnull · 2026-07-08T13:21:11Z

+
+		match timeout_fut.await {
+			Ok(Ok(Ok(_))) => Ok(()),
+			Ok(Ok(Err(electrum_client::Error::AllAttemptsErrored(e)))) => {


Codex:

P3: /home/tnull/worktrees/ldk-node/pr-660/src/chain/electrum.rs:338 only maps AllAttemptsErrored to ChainSourceNotSupported. electrum-client returns server protocol errors directly for unsupported methods, so an Electrum server without blockchain.transaction.broadcast_package will likely
surface as ConnectionFailed instead of the new ChainSourceNotSupported.

addressed below

some context: the current AllAttemptsErrored variant works when using the existing live blockstream electrum endpoints (ssl://electrum.blockstream.info:50002, and ssl://blockstream.info:700), so I kept it (it's how I picked that variant in the first place). I now also map the Protocol error to ChainSourceNotSupported, which codex tells me will address lack of support for submitpackage in mempool-electrs, romanz-electrs, Fulcrum, and ElectrumX

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.

tankyleo · 2026-07-08T18:29:02Z

Noted CI, will address on the next rebase

tnull

CI is failing currently and this now needs a rebase after #791 landed (please make sure we still classify transactions correctly after the broadcaster changes in this PR).

Feel free to squash the fixups, I'll do a (hopefully final) full round of review once it's rebased and passes CI.

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

tankyleo requested a review from tnull July 2, 2026 15:31

tnull removed their request for review July 7, 2026 11:05

tankyleo added 10 commits July 7, 2026 21:56

Use a patched blockstream-electrs in CI

56dc066

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

59b08b4

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

7c28111

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

f: validate chain source on any 0fc channels

202459b

f: fixup documentation on 0fc channels

8f68eed

tankyleo force-pushed the 25-10-0fc-channel-config branch from 7dc92d3 to 0726159 Compare July 7, 2026 23:53

tankyleo requested a review from tnull July 8, 2026 00:20

tnull reviewed Jul 8, 2026

View reviewed changes

tankyleo added 9 commits July 8, 2026 17:55

f: handle Electrum protocol errors in package probe

9fa6b98

Use helper functions to log broadcast errors

2002a3c

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

f: only use submitpackage in the multi-tx v3 case

a55a6ac

Read even bits to check the anchor channel type

b46fd09

Include 0FC channels in anchor channel checks

28efbdc

f: allow channel opens in more cases

2ce9d93

Negotiate 0FC channels if configured

ad147c7

tankyleo force-pushed the 25-10-0fc-channel-config branch from 0726159 to ad147c7 Compare July 8, 2026 17:59

tankyleo requested a review from tnull July 8, 2026 18:29

tnull reviewed Jul 9, 2026

View reviewed changes

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!

tnull commented Jul 6, 2026

Uh oh!

tankyleo commented Jul 7, 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!

tankyleo Jul 8, 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!

tankyleo commented Jul 8, 2026

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

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 Jul 8, 2026 •

edited

Loading