Enable 0conf and 0reserve on channels with trusted peers by tankyleo · Pull Request #853 · lightningdevkit/ldk-node

tankyleo · 2026-03-30T03:40:25Z

No description provided.

ldk-reviews-bot · 2026-03-30T03:40:28Z

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

tankyleo · 2026-03-30T03:49:27Z

For now, we restrict the API to a single list of "trusted peers", and for all the peers on that list, we'll accept 0-conf and 0-reserve channels from them, and open 0-reserve channels to them (for outbound channels the 0-conf decision rests with the accepter of the channel).
I would rather make these restrictions for now; and if there is user-demand later, we can add greater flexibility.
We already have 4 similar fn open_channel calls (given the "fund_with_all", and "announced" bits), I did not want to multiply the number of such calls by two just for 0-reserve channels. So I read what peers to set 0-reserve for outbound channels from the same list that determines 0-conf, 0-reserve for inbound channels, though I grant that this could be a source of confusion.

jkczyz · 2026-03-30T17:10:03Z

Cargo.toml

 prost = { version = "0.11.6", default-features = false}
 #bitcoin-payment-instructions = { version = "0.6" }
-bitcoin-payment-instructions = { git = "https://github.com/joostjager/bitcoin-payment-instructions", branch = "ldk-dcf0c203e166da2348bef12b2e5eff4a250cdec7" }
+bitcoin-payment-instructions = { git = "https://github.com/tankyleo/bitcoin-payment-instructions", branch = "ldk-688544da72cb348e4405d39a75e4d81102c1278a" }


Should we use rev here? Seems otherwise the revision could move if the branch is updated.

src/config.rs

tnull · 2026-03-31T09:18:29Z

src/lib.rs

-			},
+		let is_trusted_peer = self.config.trusted_peers_0conf_0reserve.contains(&node_id);
+		if is_trusted_peer {
+			match self.channel_manager.create_channel_to_trusted_peer_0reserve(


Hmm, I'm a bit dubious if we indeed should always opt for 0reserve if the peer is marked trusted?

For the outbound case, I now add Node::{open_0reserve_channel, open_0reserve_channel_with_all}. For now, we do not allow 0-reserve channels to be announced.

So if we mix it in trusted_peers_0conf_0reserve, this is somewhat strange, as I'd expect 0reserve to be set by default also for outbound channels if I add the peer to the list. But maybe making it more fine-grained would help, see below?

tnull · 2026-03-31T09:24:12Z

src/config.rs

+	/// allow them to spend their entire balance (zero-reserve). If we open a channel to a peer
+	/// on this list, we will allow them to spend their entire channel balance (note that for
+	/// channels *we* open, the decision of whether to accept HTLC forwards with no
+	/// confirmations of the funding transaction is *the peer's* decision).


Hmm, to be honest this is what makes it a bit weird to mix the concepts: yes, both require trust in the counterparty, but the AFAIU the use case is entirely opposite:

We usually opt into 0conf if we are the client and want to allow the LSP to open 0conf channels

If we are the client, there is little incentive to allow the LSP to not keep any reserve? So setting 0 reserve only makes sense if we are the LSP and want to allow the client to spend their full channel funds, no?

So, rather than also setting 0reserve if we are a LSPS client (see above), shouldn't we only set that if we are the LSP? Or maybe I'm missing something?

If we are the client, there is little incentive to allow the LSP to not keep any reserve? So setting 0 reserve only makes sense if we are the LSP and want to allow the client to spend their full channel funds, no?

Thanks for the review will mull on this more, a quick reaction to this point: the LSP might want 0-reserve on their side of the channel for greater capital efficiency, ie dedicate as much of their capital as possible towards allowing clients to receive payments. If they get caught making even a single cheating attempt, their entire reputation is burned, and their business goes to 0 (hopefully !) so the incentives are aligned. 1000sats (the min reserve) * x users quickly becomes a lot of dead capital.

So, rather than also setting 0reserve if we are a LSPS client (see above), shouldn't we only set that if we are the LSP? Or maybe I'm missing something?

I see your point yes. Do you have in mind to not offer any public API for setting 0-reserve on outbound channels (assuming the client is usually the opener of the channel, and not the LSP) ?

If we were to offer a completely separate API we have these options:

Standalone function calls; this would at least require two more open_channel functions, one with max funding, and one with a parameterized amount.

A separate list, similar to what we currently have for inbound channels.

Some kind of boolean / enum flag on the existing open_channel functions.

Discussed offline see the revised API below:

trusted_peers_0conf_0reserve now only applies to inbound channels.

Add allow_client_0reserve to LSPS2ServiceConfig

For outbound 0-reserve channels, offer Node::{open_0reserve_channel, open_0reserve_channel_with_all}

Question:
1. in case LSP opens the channel, the client might want 0-conf, but not 0-reserve (ie LSP keeps some funds at stake).
2. In case the client opens the channel, the LSP wants both 0-conf, and 0-reserve (ie client keeps no funds at stake).

At the moment the list trusted_peers_0conf_0reserve accommodates point number 2. For point number 1, it seems to me if you trust the LSP with a 0-conf channel, you would also trust them enough to set 0-reserve.

trusted_peers_0conf_0reserve now only applies to inbound channels.

This is a bit odd to me, we should def. clarify that in the docs.

How about #853 (comment) ? Then the user has more fine-grained control, and maybe we can even avoid the dedicated new open_channel variants? Or, if we want to keep them, it's more clear that they'd override whatever is in the trusted_peers map?

This is a bit odd to me, we should def. clarify that in the docs.

Done below

…nels

This setting allows LSPS2 services to open 0-reserve channels to their clients.

tnull · 2026-04-03T08:15:06Z

src/config.rs

+	/// transaction never gets confirmed on-chain. Zero-reserve channels allow the peer to try
+	/// to steal your funds with no financial penalty. Zero-confirmation, and zero-reserve
+	/// channels should therefore only be accepted from trusted peers.
+	pub trusted_peers_0conf_0reserve: Vec<PublicKey>,


Hmm, given the potentially very different usecases, I'm still not sure whether it makes sense to mix the two concepts like this. Should this maybe be a HashMap<PublicKey, TrustedChannelFeatures> to allow finer-grained control?

As long as this only applies to inbound channels, I think these are similar use cases no ? If you trust your inbound peer with a 0-conf, you very likely also trust them with a 0-reserve channel, and vice versa.

On the main branch this list already applies only to inbound channels.

For a value set to TrustedChannelFeatures::ZeroConfZeroReserve in the hashmap, we would actually discard the ZeroConf bit for outbound channels, would this be a source of confusion ? "Hey I set my peer to trusted, and opened a channel to that peer, why is it not 0conf ?"

I think this would be quite easy to grok: "Hey this list only applies to inbound channels, if you want to open a zero-reserve yourself, see open_0reserve_channel."

I think this would be quite easy to grok: "Hey this list only applies to inbound channels, if you want to open a zero-reserve yourself, see open_0reserve_channel."

If me and you want to open a 0 reserve channel to eachother, but don't want to accept 0 conf from eachother. Would open_0reserve_channel work? Or when I do open_0reserve_channel will your node just reject it because its not in the list?

when alice calls open_0reserve_channel, she allows bob to spend his entire balance. Bob will accept regardless of whether Alice is on his "trusted peers" list.

If Bob has placed alice on his "trusted peers" list, bob in turn allows alice to spend her entire balance, and at the moment, allows alice to start immediately using the channel with 0-conf.

I think this would be quite easy to grok: "Hey this list only applies to inbound channels, if you want to open a zero-reserve yourself, see open_0reserve_channel."

Added this in the commit below

tnull · 2026-04-03T08:17:14Z

src/lib.rs

-			},
+		let is_trusted_peer = self.config.trusted_peers_0conf_0reserve.contains(&node_id);
+		if is_trusted_peer {
+			match self.channel_manager.create_channel_to_trusted_peer_0reserve(


So if we mix it in trusted_peers_0conf_0reserve, this is somewhat strange, as I'd expect 0reserve to be set by default also for outbound channels if I add the peer to the list. But maybe making it more fine-grained would help, see below?

tnull · 2026-04-03T08:26:55Z

src/lib.rs

+	///
+	/// [`Config::trusted_peers_0conf_0reserve`]: crate::config::Config::trusted_peers_0conf_0reserve
+	/// [`AnchorChannelsConfig::per_channel_reserve_sats`]: crate::config::AnchorChannelsConfig::per_channel_reserve_sats
+	pub fn open_0reserve_channel(


If we go ahead with these new APIs, they need to be exposed in uniffi bindings.

benthecarman · 2026-04-03T17:45:01Z

src/lib.rs

+	///
+	/// [`Config::trusted_peers_0conf_0reserve`]: crate::config::Config::trusted_peers_0conf_0reserve
+	/// [`AnchorChannelsConfig::per_channel_reserve_sats`]: crate::config::AnchorChannelsConfig::per_channel_reserve_sats
+	pub fn open_0reserve_channel(


we are getting a combinatorial explosion with these

Discussed offline, we retain separate calls for now, and will ship your ChannelBuilder::new().with_no_reserve().announced().fund_withall() suggestion in case there is further expansion of these calls.

benthecarman · 2026-04-03T17:51:14Z

src/config.rs

+	/// transaction never gets confirmed on-chain. Zero-reserve channels allow the peer to try
+	/// to steal your funds with no financial penalty. Zero-confirmation, and zero-reserve
+	/// channels should therefore only be accepted from trusted peers.
+	pub trusted_peers_0conf_0reserve: Vec<PublicKey>,


I think this would be quite easy to grok: "Hey this list only applies to inbound channels, if you want to open a zero-reserve yourself, see open_0reserve_channel."

If me and you want to open a 0 reserve channel to eachother, but don't want to accept 0 conf from eachother. Would open_0reserve_channel work? Or when I do open_0reserve_channel will your node just reject it because its not in the list?

tankyleo · 2026-04-03T22:13:08Z

My takeaways after some discussion offline with Ben:

Rename the name of the list + strengthen the docs to make clear to people ZeroConfZeroReserve only applies to inbound channels.
OK to restrict inbound channels to either both 0-conf, 0-reserve, or both off.
OK to restrict outbound 0-reserve channels to private channels only.
Ben's suggestion: if we get further explosion in the list of open_channel calls, we can eventually ship a ChannelBuilder::new().with_no_reserve().announced().fund_withall().
- I could get this done in this PR if people want.

Enable 0conf and 0reserve on channels with trusted peers

663864a

tankyleo requested a review from tnull March 30, 2026 03:40

jkczyz reviewed Mar 30, 2026

View reviewed changes

tnull reviewed Mar 31, 2026

View reviewed changes

tankyleo added 5 commits March 31, 2026 18:16

f: the trusted peers 0 reserve list now only applies to accepted chan…

d44c10e

…nels

f: use rev to pin the dependency instead of branch

2502910

Add LSPS2ServiceConfig::allow_client_0reserve

27bc80c

This setting allows LSPS2 services to open 0-reserve channels to their clients.

Add set_0reserve parameter to Node::open_channel_inner

e0146c3

Add Node::{open_0reserve_channel, open_0reserve_channel_with_all}

9125870

tankyleo force-pushed the 2026-03-zero-reserve branch from 28276e6 to 9125870 Compare March 31, 2026 21:58

tankyleo added this to Weekly Goals Apr 1, 2026

tankyleo moved this to Goal: Merge in Weekly Goals Apr 1, 2026

tankyleo self-assigned this Apr 1, 2026

tankyleo requested a review from tnull April 1, 2026 14:26

tnull reviewed Apr 3, 2026

View reviewed changes

benthecarman reviewed Apr 3, 2026

View reviewed changes

tankyleo added 2 commits April 3, 2026 19:39

f: Highlight the list only applies to inbound channels

aa005f4

f: Update bindings with open_0reserve_channel methods

c1e1b51

tankyleo requested a review from tnull April 3, 2026 22:18

Conversation

tankyleo commented Mar 30, 2026

Uh oh!

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

Uh oh!

Uh oh!

tankyleo commented Mar 30, 2026 • 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!

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!

tnull Mar 31, 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!

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!

Choose a reason for hiding this comment

Uh oh!

tankyleo commented Apr 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

ldk-reviews-bot commented Mar 30, 2026 •

edited

Loading

tankyleo commented Mar 30, 2026 •

edited

Loading

tnull Mar 31, 2026 •

edited

Loading