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

👋 Thanks for assigning @carlaKC 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.

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

Codecov Report

❌ Patch coverage is 78.79147% with 179 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.14%. Comparing base (d830f10) to head (6a49cf6).

Files with missing lines	Patch %	Lines
lightning/src/ln/channel.rs	70.74%	155 Missing and 3 partials ⚠️
lightning/src/ln/channelmanager.rs	83.33%	16 Missing ⚠️
lightning/src/ln/msgs.rs	94.87%	4 Missing ⚠️
lightning/src/sign/tx_builder.rs	99.21%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4428      +/-   ##
==========================================
- Coverage   86.18%   86.14%   -0.05%     
==========================================
  Files         160      160              
  Lines      107536   108071     +535     
  Branches   107536   108071     +535     
==========================================
+ Hits        92680    93094     +414     
- Misses      12231    12353     +122     
+ Partials     2625     2624       -1

Flag	Coverage Δ
tests	`86.14% <78.79%> (-0.05%)`	⬇️

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

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.

lightning/src/sign/tx_builder.rs

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

ldk-claude-review-bot · 2026-03-18T18:57:46Z

lightning/src/ln/channelmanager.rs

 		&self, temporary_channel_id: &ChannelId, counterparty_node_id: &PublicKey,
-		user_channel_id: u128, config_overrides: Option<ChannelConfigOverrides>,
+		user_channel_id: u128, accept_0conf: bool, accept_0reserve: bool,
+		config_overrides: Option<ChannelConfigOverrides>,


Bug: accept_0reserve is silently ignored for V2/dual-funded channels. When the code path at the V2 branch (around line 10921) calls PendingV2Channel::new_inbound, it doesn't pass accept_0reserve — that function hardcodes is_0reserve = false (channel.rs line 14373-14375).

A user calling accept_inbound_channel_from_trusted_peer(id, node, 0, false, /*accept_0reserve=*/true, None) on a V2 channel open will believe they've set up zero-reserve, but the channel will be created with a normal 1% reserve.

Either:

Pass accept_0reserve through to PendingV2Channel::new_inbound and wire it into the reserve calculation, or

Return an APIError::APIMisuseError when accept_0reserve == true and the channel is V2, so the caller knows their intent was not honored.

ldk-claude-review-bot · 2026-03-18T18:58:01Z

fuzz/src/chanmon_consistency.rs

 					random_bytes
 						.copy_from_slice(&$dest_keys_manager.get_secure_random_bytes()[..16]);
 					let user_channel_id = u128::from_be_bytes(random_bytes);
-					$dest
-						.accept_inbound_channel(
-							temporary_channel_id,
-							counterparty_node_id,
-							user_channel_id,
-							None,
-						)
-						.unwrap();
+					if $trusted_accept {
+						$dest
+							.accept_inbound_channel_from_trusted_peer(
+								temporary_channel_id,
+								counterparty_node_id,
+								user_channel_id,
+								false,
+								true,
+								None,
+							)
+							.unwrap();
+					} else {
+						$dest


nit: The $trusted_accept branch calls accept_inbound_channel_from_trusted_peer with (accept_0conf=false, accept_0reserve=true), which means the zero-reserve acceptance path never exercises zero-conf. Consider also fuzzing the combination (true, true) on at least one channel to cover the zero-conf + zero-reserve interaction path that test_zero_reserve_zero_conf_combined tests.

leaving this to a follow-up to this PR

ldk-claude-review-bot · 2026-03-19T02:18:44Z

lightning/src/ln/channel.rs

+		channel_value_satoshis: u64, push_msat: u64, user_id: u128, config: &UserConfig,
+		current_chain_height: u32, outbound_scid_alias: u64,
+		temporary_channel_id: Option<ChannelId>, logger: L,
+		trusted_channel_features: Option<TrustedChannelFeatures>,


Bug: The signature change from bool to Option<TrustedChannelFeatures> here was not propagated to the two #[cfg(ldk_test_vectors)] test functions that call OutboundV1Channel::new:

outbound_commitment_test() — currently passes false (around line 17032)

zero_fee_commitment_test_vectors() — currently passes false (around line 17757)

Both need to be updated to pass None instead of false. This won't be caught in normal CI since the tests are gated on #[cfg(ldk_test_vectors)], but will cause a compilation failure when running test vectors.

tankyleo · 2026-03-19T08:39:31Z

Highlights from previous review:

rewrite tests for readability.
add is_0reserve: bool parameter to get_holder_selected_channel_reserve_satoshis and get_v2_channel_reserve_satoshis to prevent forgetting to handle 0-reserve channels.
exercise force-closes with a commitment that only has a single output, itself P2A.
use an enum to represent 0-conf, 0-reserve features instead of bools to guard against mistakes.
add zero-reserve to the internal API of V2 channels.

The branch with fixups for these items is here https://github.com/tankyleo/rust-lightning/releases/tag/2026-03-19-zero-reserve-fixups

ldk-claude-review-bot · 2026-03-19T08:57:37Z

fuzz/src/chanmon_consistency.rs

+pub enum ChanType {
+	Legacy,
+	KeyedAnchors,
+	ZeroFeeCommitments,
+}


nit: Consider adding #[derive(Clone, Copy)] (or at least Copy) on this fieldless enum. While Rust allows matching without Copy on fieldless enums (it reads only the discriminant), having Copy makes the intent explicit and avoids confusion for future maintainers. It also enables patterns like let ct = chan_type; if ever needed.

ldk-claude-review-bot · 2026-03-19T08:57:45Z

lightning/src/ln/channel.rs

 	fn new_for_inbound_channel<'a, ES: EntropySource, F: FeeEstimator, L: Logger>(
-		fee_estimator: &'a LowerBoundedFeeEstimator<F>,
-		entropy_source: &'a ES,
-		signer_provider: &'a SP,
-		counterparty_node_id: PublicKey,
-		their_features: &'a InitFeatures,
-		user_id: u128,
-		config: &'a UserConfig,
-		current_chain_height: u32,
-		logger: &'a L,
-		is_0conf: bool,
-		our_funding_satoshis: u64,
-		counterparty_pubkeys: ChannelPublicKeys,
-		channel_type: ChannelTypeFeatures,
-		holder_selected_channel_reserve_satoshis: u64,
-		msg_channel_reserve_satoshis: u64,
-		msg_push_msat: u64,
-		open_channel_fields: msgs::CommonOpenChannelFields,
+		fee_estimator: &'a LowerBoundedFeeEstimator<F>, entropy_source: &'a ES,
+		signer_provider: &'a SP, counterparty_node_id: PublicKey, their_features: &'a InitFeatures,
+		user_id: u128, config: &'a UserConfig, current_chain_height: u32, logger: &'a L,
+		trusted_channel_features: Option<TrustedChannelFeatures>, our_funding_satoshis: u64,


nit: The #[rustfmt::skip] removal on new_for_inbound_channel and new_for_outbound_channel reformats ~500 lines in the diff, burying the actual semantic changes (the trusted_channel_features parameter, zero-reserve validation relaxation, and minimum_depth logic). Consider splitting the formatting into a separate commit (the last commit message mentions formatting create_channel_internal but not these two functions).

joostjager · 2026-03-19T09:17:57Z

fuzz/src/chanmon_consistency.rs

 			config.reject_inbound_splices = false;
-			if !anchors {
-				config.channel_handshake_config.negotiate_anchors_zero_fee_htlc_tx = false;
+			match chan_type {


I don't think it is good to build out this way of increasing coverage. If chan type is part of the fuzz bytes, the fuzzer is able to zoom in on type-specific code paths.

thanks for taking a look ! see the commit below

ldk-claude-review-bot · 2026-03-19T16:52:04Z

fuzz/src/chanmon_consistency.rs

 }

 pub fn chanmon_consistency_test<Out: Output + MaybeSend + MaybeSync>(data: &[u8], out: Out) {
-	do_test(data, out.clone(), false);
-	do_test(data, out, true);
+	do_test(data, out);


The previous code ran do_test twice per fuzz input — once with anchors=false, once with anchors=true — guaranteeing every corpus entry exercised both channel type families. The new code runs do_test only once, with the channel type extracted from the fuzz input byte.

This means existing fuzz corpus entries that were evolved to cover interesting states under the two-pass model now only exercise a single channel type (determined by whatever happens to be in bits 3-4 of byte 0). Corpus entries that were valuable because they triggered anchor-specific behaviour may now be routed to the Legacy path or vice-versa, effectively discarding coverage.

Consider keeping the multi-pass structure by iterating over ChanType variants, or at minimum re-minimizing the corpus after this change.

ldk-claude-review-bot · 2026-03-19T16:52:16Z

lightning/src/ln/channelmanager.rs

+			override_config,
+			Some(TrustedChannelFeatures::ZeroReserve),
+		)
+	}


create_channel_to_trusted_peer_0reserve hardcodes TrustedChannelFeatures::ZeroReserve, meaning there's no API for opening an outbound channel with both zero-conf and zero-reserve. The accept side has ZeroConfZeroReserve, but the open side has no counterpart.

This asymmetry means a user who wants to create a zero-reserve channel and also trust the counterparty for zero-conf funding (e.g., a mutual trust scenario) can't do so from the opener side. They'd need to call create_channel_internal directly, which is private.

Consider either:

Adding a trusted_channel_features parameter to create_channel_to_trusted_peer_0reserve, or

Adding a separate create_channel_to_trusted_peer that takes TrustedChannelFeatures directly (analogous to the accept side's API).

carlaKC

one more q for adjust_boundaries_if_max_dust_htlc_produces_no_output, but otherwise nothing blocking from me!

Happy for squash + rebase when others are.

carlaKC · 2026-03-20T13:41:56Z

lightning/src/sign/tx_builder.rs

+			// Remember we've got no non-dust HTLCs on the commitment here
+			let current_spiked_tx_fee_sat = commit_tx_fee_sat(spiked_feerate, 0, channel_type);
+			let spike_buffer_tx_fee_sat = commit_tx_fee_sat(spiked_feerate, 1, channel_type);


If is_outbound_from_holder = false, do we need to consider fees here at all?
Because the fee wouldn't be coming off our balance.

yes ! thank you carla for catching this

carlaKC · 2026-03-20T14:31:02Z

lightning/src/sign/tx_builder.rs

+			local_balance_before_fee_msat,
+			remote_balance_before_fee_msat,
+			remote_nondust_htlc_count,
+			spiked_feerate,


Just confirming my own understanding:

Sender side: we check has_output against our spiked_feerate, a higher feerate makes us more likely to think that a HTLC is dust, and thus more likely to think that we'll have no outputs.

Receiver side: we check has_output against our feerate_per_kw, a lower feerate makes us less likely to think that a HTLC is dust, and thus less likely to think that we'll have no outputs.

Send conservatively / receive permissively 👌

When we receive HTLCs from other impls, we're good provided that they have checked that the HTLC will result in our having outputs at the current commitment feerate. This means we won't run into funny force close issues if they happen to have a different spiked_feerate to us (which would be odd, but could happen).

Yes overall SGTM, thanks for checking.

Note that receiver side we've got two checks: the least permissive one is at validate_update_add_hltc, which checks outputs against the current feerate_per_kw, and fails the channel in case of failure. The stricter one happens at can_accept_incoming_htlc, where we check the remote commitment against 2 * feerate_per_kw, and fail the individual HTLC in case of failure, not the full channel.

From the spec, spiked_feerate is recommended to be 2 * feerate_per_kw, so we should be in sync with other implementations.

carlaKC · 2026-03-20T14:41:43Z

lightning/src/ln/channelmanager.rs

+	/// Note that there is no guarantee that the counterparty accepts such a channel themselves.
+	ZeroReserve,
+	/// Sets combination of [`TrustedChannelFeatures::ZeroConf`] and [`TrustedChannelFeatures::ZeroReserve`]
+	ZeroConfZeroReserve,


nit: slight preference to just have a vec<TrustedChannelFeatures> rather than try express combinations in an enum, but I don't think we're likely to add more options here so non-blocking.

Hmm on the public API, I'd rather keep things as constrained as possible, which the enum does. The Vec<TrustedChannelFeatures> route is more open-ended, and hence more open to misunderstanding / misuse.

carlaKC · 2026-03-20T15:00:11Z

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);


Separate commit sgtm, agree on the dust limits you've stated 👌

carlaKC · 2026-03-20T17:02:26Z

lightning/src/ln/htlc_reserve_unit_tests.rs

+	let feerate_per_kw = details.feerate_sat_per_1000_weight.unwrap();
+	let anchors_sat =
+		if channel_type == ChannelTypeFeatures::anchors_zero_htlc_fee_and_dependencies() {
+			2 * 330
+		} else {
+			0
+		};
+	let spike_multiple = if channel_type == ChannelTypeFeatures::only_static_remote_key() {
+		FEE_SPIKE_BUFFER_FEE_INCREASE_MULTIPLE as u32
+	} else {
+		1
+	};
+	let spiked_feerate = spike_multiple * feerate_per_kw;
+	let reserved_commit_tx_fee_sat = chan_utils::commit_tx_fee_sat(
+		spiked_feerate,
+		2, // We reserve space for two HTLCs, the next outbound non-dust HTLC, and the fee spike buffer HTLC
+		&channel_type,
+	);
+
+	let max_outbound_htlc_sat =
+		channel_value_sat - anchors_sat - reserved_commit_tx_fee_sat - reserve_sat;


nit: de-dup across tests

if you don't mind, I'd like to leave it as is: requiring people to jump to a different function to understand these two tests seems harder to understand for me. My own preference is to have the test "transcript" be easy to follow down the page instead of jumping to different functions.

The floor for *our* selected reserve is *their* dust limit.

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.

Co-Authored-By: HAL 9000

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

lightning/src/ln/channel.rs

tankyleo · 2026-03-23T07:25:12Z

fixups: https://github.com/tankyleo/rust-lightning/releases/tag/2026-03-23-zero-reserve-fixups
a. make chan type part of the fuzz bytes
b. allow the fundee to spend dust HTLCs up to the exact dust limit satoshis
squashed (no changes from 1): https://github.com/tankyleo/rust-lightning/releases/tag/2026-03-23-zero-reserve-squashed
then rebase, new HEAD is now 6a49cf6

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 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 requested a review from carlaKC March 13, 2026 12:50

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

View reviewed changes

tankyleo force-pushed the 2026-02-zero-reserve branch from cde4d01 to f56ae64 Compare March 19, 2026 02:02

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

View reviewed changes

tankyleo force-pushed the 2026-02-zero-reserve branch from f56ae64 to 3542a15 Compare March 19, 2026 08:38

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

View reviewed changes

joostjager reviewed Mar 19, 2026

View reviewed changes

tankyleo requested a review from joostjager March 19, 2026 16:35

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

View reviewed changes

joostjager removed their request for review March 19, 2026 17:06

carlaKC reviewed Mar 20, 2026

View reviewed changes

TheBlueMatt linked an issue Mar 22, 2026 that may be closed by this pull request

0-output commitment tx with 0-reserve #1306

Open

tankyleo added 8 commits March 23, 2026 03:55

Set the correct floor for the reserves in inbound V2 channels

6c59e69

The floor for *our* selected reserve is *their* dust limit.

Add inbound and outbound checks for zero reserve channels

ab735ff

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

b605605

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

Add ChannelManager::create_channel_to_trusted_peer_0reserve

0ace97f

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

Shakedown zero reserve channels

52b3e1a

Update chanmon_consistency to include 0FC and 0-reserve channels

ec697e1

Co-Authored-By: HAL 9000

Add 0-reserve to the internal API of V2 channels

1a5ed78

Format ChannelManager::create_channel_internal and...

6a49cf6

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

tankyleo force-pushed the 2026-02-zero-reserve branch 2 times, most recently from 5fa3a7c to 6a49cf6 Compare March 23, 2026 06:51

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

View reviewed changes

lightning/src/ln/channel.rs Show resolved Hide resolved

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

View reviewed changes

lightning/src/ln/channel.rs Show resolved Hide resolved

tankyleo requested review from TheBlueMatt and carlaKC March 23, 2026 07:40

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!

Uh oh!

Uh oh!

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!

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 Mar 19, 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!

carlaKC left a comment • 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

tankyleo commented Feb 19, 2026 •

edited

Loading

ldk-reviews-bot commented Feb 19, 2026 •

edited

Loading

codecov bot commented Feb 26, 2026 •

edited

Loading

carlaKC left a comment •

edited

Loading

tankyleo commented Mar 23, 2026 •

edited

Loading