Open and accept zero reserve channels by tankyleo · Pull Request #4428 · lightningdevkit/rust-lightning

tankyleo · 2026-02-19T17:43:43Z

ldk-reviews-bot · 2026-02-19T17:43:46Z

👋 I see @TheBlueMatt was un-assigned.
If you'd like another reviewer assignment, please click here.

codecov · 2026-02-26T11:44:38Z

Codecov Report

❌ Patch coverage is 78.74818% with 146 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.91%. Comparing base (14e522f) to head (5fa3a7c).
⚠️ Report is 25 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channel.rs	70.64%	121 Missing and 2 partials ⚠️
lightning/src/ln/channelmanager.rs	81.70%	15 Missing ⚠️
lightning/src/ln/functional_test_utils.rs	94.33%	6 Missing ⚠️
lightning/src/sign/tx_builder.rs	97.46%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4428      +/-   ##
==========================================
- Coverage   85.94%   85.91%   -0.03%     
==========================================
  Files         159      159              
  Lines      104644   105103     +459     
  Branches   104644   105103     +459     
==========================================
+ Hits        89934    90298     +364     
- Misses      12204    12300      +96     
+ Partials     2506     2505       -1

Flag	Coverage Δ
tests	`85.91% <78.74%> (-0.03%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

TheBlueMatt

chanmon_consistency needs to be updated to have a 0-reserve channel or two (I believe we now have three channels between each pair of peers, so we can just do it on a subset of them, in fact we could have three separate channel types for better coverage).

TheBlueMatt · 2026-02-27T01:58:37Z

lightning/src/ln/channelmanager.rs

+	/// Creates a new outbound channel to the given remote node and with the given value.
+	///
+	/// The only difference between this method and [`ChannelManager::create_channel`] is that this method sets
+	/// the reserve the counterparty must keep at all times in the channel to zero. This allows the counterparty to


nit: If that's the only difference let's say create_channel_to_trusted_peer_0_reserve? Nice to be explicit, imo.

TheBlueMatt · 2026-02-27T02:10:13Z

lightning/src/ln/channel.rs


 		let channel_value_satoshis =
 			our_funding_contribution_sats.saturating_add(msg.common_fields.funding_satoshis);
+		// TODO(zero_reserve): support reading and writing the `disable_channel_reserve` field


Two questions. Shouldn't we check that if a channel has the 0-reserve feature bit and if it is fail if the user isn't accepting 0-reserve? Also why shouldn't we just set it now? I'm not sure we need to bother with a staging bit, really, honestly...

TheBlueMatt · 2026-03-04T18:36:41Z

Needs rebase now :/

tankyleo · 2026-03-05T10:57:51Z

Needs rebase now :/

Let me know if you prefer I rebase first

TheBlueMatt · 2026-03-05T14:25:02Z

Feel free to go ahead and rebase and squash, yea.

tankyleo · 2026-03-05T17:24:05Z

Squash diff (do not click compare just above, I pushed the wrong branch, and later corrected it):

https://github.com/lightningdevkit/rust-lightning/compare/253db4d9a05cda43f74c2835448126d3205b27b8..43be438f70ba28ad7918e407026a78763ac2b368

The goal is to prevent any commitments with no outputs, since these are not broadcastable.

This new flag sets 0-reserve for the channel opener.

This new method sets 0-reserve for the channel accepter.

`ChannelContext::do_accept_channel_checks`, `ChannelContext::new_for_outbound_channel`, `ChannelContext::new_for_inbound_channel`, `InboundV1Channel::new`, `OutboundV1Channel::new`.

Co-Authored-By: HAL 9000

tankyleo · 2026-03-05T17:44:48Z

git range-diff main 43be438 7fde002

1:  bfba6e993 ! 1:  b916c3596 Add inbound and outbound checks for zero reserve channels
    @@ lightning/src/ln/channel.rs: impl FundingScope {

                // New reserve values are based on the new channel value and are v2-specific
     -          let counterparty_selected_channel_reserve_satoshis =
    --                  Some(get_v2_channel_reserve_satoshis(post_channel_value, MIN_CHAN_DUST_LIMIT_SATOSHIS));
    +-                  get_v2_channel_reserve_satoshis(post_channel_value, MIN_CHAN_DUST_LIMIT_SATOSHIS);
     -          let holder_selected_channel_reserve_satoshis = get_v2_channel_reserve_satoshis(
     -                  post_channel_value,
     -                  context.counterparty_dust_limit_satoshis,
    @@ lightning/src/ln/channel.rs: impl FundingScope {
     +                  == 0
     +          {
     +                  // If we previously had a 0-value reserve, continue with the same reserve
    -+                  Some(0)
    ++                  0
     +          } else {
    -+                  Some(get_v2_channel_reserve_satoshis(post_channel_value, MIN_CHAN_DUST_LIMIT_SATOSHIS))
    ++                  get_v2_channel_reserve_satoshis(post_channel_value, MIN_CHAN_DUST_LIMIT_SATOSHIS)
     +          };
     +          let holder_selected_channel_reserve_satoshis =
     +                  if prev_funding.holder_selected_channel_reserve_satoshis == 0 {
    @@ lightning/src/sign/tx_builder.rs: fn get_next_commitment_stats(
        );

     @@ lightning/src/sign/tx_builder.rs: fn get_available_balances(
    -   let fee_spike_buffer_htlc =
                if channel_type.supports_anchor_zero_fee_commitments() { 0 } else { 1 };

    +   // Note that the feerate is 0 in zero-fee commitment channels, so this statement is a noop
     -  let local_feerate = feerate_per_kw
     +  let spiked_feerate = feerate_per_kw
                * if is_outbound_from_holder && !channel_type.supports_anchors_zero_fee_htlc_tx() {
2:  1f8ca6c66 = 2:  53fc9a354 Add 0-reserve to `accept_inbound_channel_from_trusted_peer`
3:  1b94f7cc3 = 3:  da0520818 Add `ChannelManager::create_channel_to_trusted_peer_0reserve`
4:  19b8d7943 = 4:  1905f94e7 Shakedown zero reserve channels
5:  de2366da4 = 5:  4e6a7527a Format `ChannelManager::create_channel_internal` and...
6:  43be438f7 = 6:  7fde002e7 Update `chanmon_consistency` to include 0FC and 0-reserve channels

ldk-reviews-bot · 2026-03-05T18:44:59Z

✅ Added second reviewer: @joostjager

ldk-reviews-bot · 2026-03-07T10:57:40Z

🔔 1st Reminder

Hey @TheBlueMatt @joostjager! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-03-09T00:00:12Z

🔔 1st Reminder

Hey @TheBlueMatt @joostjager! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-03-09T10:58:39Z

🔔 2nd Reminder

Hey @TheBlueMatt @joostjager! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-03-11T10:59:40Z

🔔 3rd Reminder

Hey @TheBlueMatt @carlaKC! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

carlaKC

First pass - haven't gone through the tests yet.

carlaKC · 2026-03-11T13:51:40Z

lightning/src/sign/tx_builder.rs

+	let dust_limit_msat = dust_limit_satoshis.saturating_mul(1000);
+	if holder_balance_msat.saturating_sub(max_dust_htlc_msat) < dust_limit_msat
+		&& counterparty_balance_msat < dust_limit_msat
+		&& nondust_htlc_count == 0


Can we re-use check_no_outputs here? Could also return early if we don't need any action.

We'd need to change it to a saturating_sub, but I think that's okay because we have a checked_sub check of our balances on 321 after calling check_no_outputs anyway?

done below thank you !

lightning/src/sign/tx_builder.rs

carlaKC · 2026-03-11T14:21:01Z

lightning/src/sign/tx_builder.rs

+			// 1) The dust_limit_satoshis plus the fee of the exisiting commitment at the spiked feerate.
+			// 2) The fee of the commitment with an additional non-dust HTLC, aka the fee spike buffer HTLC.
+			//    In this case we don't mind the holder balance output dropping below the dust limit, as
+			//    this additional non-dust HTLC will create the single remaining output on the commitment.
+			let min_balance_msat =
+				cmp::max(dust_limit_satoshis + tx_fee_sat, fee_spike_buffer_sat) * 1000;


Comment for (1) says "at the spiked feerate" but isn't tx_fee_sat is just our current feerate?

A more descriptive name would be helpful here (if you can thing of something less gross than max_output_preserving_fee?).

Comment for (1) says "at the spiked feerate" but isn't tx_fee_sat is just our current feerate?

See the callsites of the function; we always use the spiked_feerate as the feerate_per_kw parameter. I admit this is confusing, should I rename the function parameter to spiked_feerate ?

A more descriptive name would be helpful here (if you can thing of something less gross than max_output_preserving_fee?).

How is current_spiked_tx_fee_sat ? It would be consistent with the spiked_feerate style. With max_output_preserving_fee you want to highlight that we want to maintain an output on the commitment transaction even with a 2x increase in the feerate ?

went ahead with both variable renames below

lightning/src/ln/channel.rs

carlaKC · 2026-03-11T14:49:53Z

lightning/src/ln/channelmanager.rs

 	/// If it does not confirm before we decide to close the channel, or if the funding transaction
 	/// does not pay to the correct script the correct amount, *you will lose funds*.
 	///
+	/// # Zero-reserve


Shouldn't we be setting the option_zero_reserve feature in lightning/bolts#1140?

Discussed offline, I'll hold off on signaling for now pending further spec discussions

Also take the opportunity to remove some test case runs that don't do anything novel compared to other runs.

…s 0-reserve

ldk-reviews-bot · 2026-03-14T00:02:44Z

🔔 4th Reminder

Hey @TheBlueMatt @carlaKC! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

TheBlueMatt · 2026-03-14T21:40:00Z

Needs rebase already :/

ldk-claude-review-bot · 2026-03-14T21:45:52Z

lightning/src/ln/channel.rs

+			.expect("counterparty reserve is set")
+			== 0
+		{
+			// If we previously had a 0-value reserve, continue with the same reserve


The comment says "If we previously had a 0-value reserve" but counterparty_selected_channel_reserve_satoshis is the reserve selected by the counterparty for us (i.e., the amount we must keep). If this was 0, it means the counterparty previously didn't require us to hold any reserve — not that "we had a 0-value reserve" in general. The comment is technically correct but could be clearer: e.g., "If the counterparty previously set our reserve to 0, continue with the same reserve."

Similarly, line 2801's comment says "If the counterparty previously had a 0-value reserve" for holder_selected_channel_reserve_satoshis — this is the reserve we selected for the counterparty. The phrasing is correct but could match the field semantics more precisely.

ldk-claude-review-bot · 2026-03-14T21:46:05Z

Automated Review

The main concern is that accept_0reserve is silently ignored for V2 (dual-funded) channels. When accept_inbound_channel_from_trusted_peer is called with accept_0reserve=true on a V2 channel (OpenChannelV2), the parameter is never passed to PendingV2Channel::new_inbound (channelmanager.rs ~line 10921-10934). The caller receives Ok(()) with no indication their zero-reserve request was dropped. While there's a TODO(zero_reserve) in PendingV2Channel::new_inbound (channel.rs:14366), consider returning an error for V2 channels when accept_0reserve=true until support is implemented, to avoid silent misconfiguration.

One minor inline comment on a misleading comment in the splice reserve-preservation logic.

🤖 Generated with Claude Code

ldk-reviews-bot · 2026-03-16T00:00:21Z

🔔 1st Reminder

Hey @TheBlueMatt @carlaKC! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-03-16T00:03:55Z

🔔 5th Reminder

Hey @TheBlueMatt @carlaKC! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

carlaKC

Went through the tx_builder changes together IRL, those lgtm.

Just one q on v2 and a few comments on breaking up the tests for readability.

carlaKC · 2026-03-16T15:08:18Z

lightning/src/ln/functional_test_utils.rs

 	}
 }

+pub fn handle_and_accept_open_zero_reserve_channel(


(first time I posted this I think it got lost in the depths of GH).

Can we live without some of these helpers, because this accept step is the only one where we need to take a custom action?

Will add a few lines in do_test_accept_inbound_channel_from_trusted_peer_0reserve but the others are unaffected?

carlaKC · 2026-03-16T18:08:00Z

lightning/src/ln/htlc_reserve_unit_tests.rs

+		// We can't afford the fee for an additional non-dust HTLC + the fee spike HTLC, so we can only send
+		// dust HTLCs...
+		// We don't bother to add the second stage tx fees, these would only make this min bigger
+		let min_nondust_htlc_sat = dust_limit_satoshis;
+		assert!(
+			channel_value_sat
+				- commit_tx_fee_sat(spike_multiple * feerate_per_kw, 2, &channel_type)
+				< min_nondust_htlc_sat
+		);
+		// But sending a big (not biggest) dust HTLC trims our balance output!
+		let max_dust_htlc = dust_limit_satoshis - 1;
+		assert!(
+			channel_value_sat - commit_tx_fee_sat(feerate_per_kw, 0, &channel_type) - max_dust_htlc
+				< dust_limit_satoshis
+		);


Can we pull these asserts out of the channel type branching? If we use the correct fee rate / anchor values for each different type (eg, zero for 0FC) then they're the same?

carlaKC · 2026-03-16T18:10:19Z

lightning/src/ln/htlc_reserve_unit_tests.rs

+		let sender_amount_msat = (channel_value_sat - min_value_sat) * 1000;
+		let details_0 = &nodes[0].node.list_channels()[0];
+		assert_eq!(details_0.next_outbound_htlc_minimum_msat, 1000);
+		assert_eq!(details_0.next_outbound_htlc_limit_msat, sender_amount_msat);
+		assert!(
+			details_0.next_outbound_htlc_limit_msat > details_0.next_outbound_htlc_minimum_msat
+		);


Same here I think? Asserts are common for sender_amount_msat, we may just sometimes have zero anchors/fees somtimes.

carlaKC · 2026-03-16T18:48:47Z

lightning/src/ln/channel.rs

+		// TODO(zero_reserve): support reading and writing the `disable_channel_reserve` field
 		let counterparty_selected_channel_reserve_satoshis = get_v2_channel_reserve_satoshis(
-			channel_value_satoshis, msg.common_fields.dust_limit_satoshis);
-		let holder_selected_channel_reserve_satoshis = get_v2_channel_reserve_satoshis(
 			channel_value_satoshis, MIN_CHAN_DUST_LIMIT_SATOSHIS);
+		let holder_selected_channel_reserve_satoshis = get_v2_channel_reserve_satoshis(
+			channel_value_satoshis, msg.common_fields.dust_limit_satoshis);


We've switched the dust limits used to floor channel reserve here - I think the counterparty's reserve should use the common_fields.dust_limit_satoshi and we should use MIN_CHAN_DUST_LIMIT_SATOSHIS for holder?

carlaKC · 2026-03-16T18:52:24Z

lightning/src/sign/tx_builder.rs

-	{
+	// If this dust HTLC produces no outputs, then we have to say something! It is now possible to produce a
+	// commitment with no outputs.
+	if !has_output(


Nice changes here 👌

carlaKC · 2026-03-16T19:01:16Z

lightning/src/ln/htlc_reserve_unit_tests.rs

+			nodes[1].node.list_channels()[0].next_outbound_htlc_limit_msat,
+			sender_amount_msat
+		);
+		send_payment(&nodes[1], &[&nodes[0]], sender_amount_msat);


PaymentSucceeds is the only test case that's common to all of our channel types, and FailsReceiverUpdateAddHTLC has its own branch within the failure case here.

Wondering if these can be separated into different handlers with common setup to improve readability? Would also save our needing to check the channel type / NoOutputs combination above - just assert that ReceiverCanAcceptA/B is only running on static_remote_key, for example.

tankyleo added this to Weekly Goals Feb 19, 2026

tankyleo moved this to Goal: Merge in Weekly Goals Feb 19, 2026

tankyleo self-assigned this Feb 19, 2026

tankyleo force-pushed the 2026-02-zero-reserve branch from ffa1657 to 5fa3a7c Compare February 26, 2026 09:56

tankyleo marked this pull request as ready for review February 26, 2026 10:45

tankyleo requested a review from TheBlueMatt February 26, 2026 10:46

tankyleo added this to the 0.3 milestone Feb 26, 2026

TheBlueMatt reviewed Feb 27, 2026

View reviewed changes

tankyleo force-pushed the 2026-02-zero-reserve branch from 471ba8f to 253db4d Compare March 5, 2026 10:55

tankyleo requested a review from TheBlueMatt March 5, 2026 10:57

tankyleo force-pushed the 2026-02-zero-reserve branch 2 times, most recently from 5fa3a7c to 43be438 Compare March 5, 2026 17:21

tankyleo added 6 commits March 5, 2026 17:32

Add inbound and outbound checks for zero reserve channels

b916c35

The goal is to prevent any commitments with no outputs, since these are not broadcastable.

Add 0-reserve to accept_inbound_channel_from_trusted_peer

53fc9a3

This new flag sets 0-reserve for the channel opener.

Add ChannelManager::create_channel_to_trusted_peer_0reserve

da05208

This new method sets 0-reserve for the channel accepter.

Shakedown zero reserve channels

1905f94

Format ChannelManager::create_channel_internal and...

4e6a752

`ChannelContext::do_accept_channel_checks`, `ChannelContext::new_for_outbound_channel`, `ChannelContext::new_for_inbound_channel`, `InboundV1Channel::new`, `OutboundV1Channel::new`.

Update chanmon_consistency to include 0FC and 0-reserve channels

7fde002

Co-Authored-By: HAL 9000

tankyleo force-pushed the 2026-02-zero-reserve branch from 43be438 to 7fde002 Compare March 5, 2026 17:36

ldk-reviews-bot requested a review from joostjager March 5, 2026 18:44

tankyleo requested review from carlaKC and removed request for joostjager March 10, 2026 14:33

carlaKC reviewed Mar 11, 2026

View reviewed changes

tankyleo added 3 commits March 12, 2026 19:53

f: tx_builder cleanups

da22c33

f: 0FC channels always have an output on the commitment, the P2A output

2b67511

Also take the opportunity to remove some test case runs that don't do anything novel compared to other runs.

f: underscore that there is no guarantee that the counterparty accept…

ba6bd60

…s 0-reserve

tankyleo requested a review from carlaKC March 13, 2026 12:50

ldk-claude-review-bot reviewed Mar 14, 2026

View reviewed changes

carlaKC reviewed Mar 16, 2026

View reviewed changes

TheBlueMatt removed their request for review March 16, 2026 20:42

Conversation

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

Uh oh!

Uh oh!

ldk-reviews-bot commented Feb 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov bot commented Feb 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

TheBlueMatt 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!

TheBlueMatt commented Mar 4, 2026

Uh oh!

tankyleo commented Mar 5, 2026

Uh oh!

TheBlueMatt commented Mar 5, 2026

Uh oh!

tankyleo commented Mar 5, 2026

Uh oh!

tankyleo commented Mar 5, 2026

Uh oh!

ldk-reviews-bot commented Mar 5, 2026

Uh oh!

ldk-reviews-bot commented Mar 7, 2026

Uh oh!

ldk-reviews-bot commented Mar 9, 2026

Uh oh!

ldk-reviews-bot commented Mar 9, 2026

Uh oh!

ldk-reviews-bot commented Mar 11, 2026

Uh oh!

carlaKC 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!

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!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ldk-reviews-bot commented Mar 14, 2026

Uh oh!

TheBlueMatt commented Mar 14, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ldk-claude-review-bot commented Mar 14, 2026

Automated Review

Uh oh!

ldk-reviews-bot commented Mar 16, 2026

Uh oh!

ldk-reviews-bot commented Mar 16, 2026

Uh oh!

carlaKC 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

tankyleo commented Feb 19, 2026 •

edited

Loading

ldk-reviews-bot commented Feb 19, 2026 •

edited

Loading

codecov bot commented Feb 26, 2026 •

edited

Loading