Skip to content

Enable 0conf and 0reserve on channels with trusted peers #853

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
tankyleo wants to merge 8 commits into
base: main
Choose a base branch
from
Open

Enable 0conf and 0reserve on channels with trusted peers #853

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
663864a
Enable 0conf and 0reserve on channels with trusted peers
tankyleo Mar 28, 2026
d44c10e
f: the trusted peers 0 reserve list now only applies to accepted chan…
tankyleo Mar 31, 2026
2502910
f: use `rev` to pin the dependency instead of `branch`
tankyleo Mar 31, 2026
27bc80c
Add `LSPS2ServiceConfig::allow_client_0reserve`
tankyleo Mar 31, 2026
e0146c3
Add `set_0reserve` parameter to `Node::open_channel_inner`
tankyleo Mar 31, 2026
9125870
Add `Node::{open_0reserve_channel, open_0reserve_channel_with_all}`
tankyleo Mar 31, 2026
aa005f4
f: Highlight the list only applies to inbound channels
tankyleo Apr 3, 2026
c1e1b51
f: Update bindings with `open_0reserve_channel` methods
tankyleo Apr 3, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 13 additions & 13 deletions Cargo.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -39,17 +39,17 @@ default = []
#lightning-liquidity = { version = "0.2.0", features = ["std"] }
#lightning-macros = { version = "0.2.0" }

lightning = { git = "https://github.com/lightningdevkit/rust-lightning", rev = "dcf0c203e166da2348bef12b2e5eff4a250cdec7", features = ["std"] }
lightning-types = { git = "https://github.com/lightningdevkit/rust-lightning", rev = "dcf0c203e166da2348bef12b2e5eff4a250cdec7" }
lightning-invoice = { git = "https://github.com/lightningdevkit/rust-lightning", rev = "dcf0c203e166da2348bef12b2e5eff4a250cdec7", features = ["std"] }
lightning-net-tokio = { git = "https://github.com/lightningdevkit/rust-lightning", rev = "dcf0c203e166da2348bef12b2e5eff4a250cdec7" }
lightning-persister = { git = "https://github.com/lightningdevkit/rust-lightning", rev = "dcf0c203e166da2348bef12b2e5eff4a250cdec7", features = ["tokio"] }
lightning-background-processor = { git = "https://github.com/lightningdevkit/rust-lightning", rev = "dcf0c203e166da2348bef12b2e5eff4a250cdec7" }
lightning-rapid-gossip-sync = { git = "https://github.com/lightningdevkit/rust-lightning", rev = "dcf0c203e166da2348bef12b2e5eff4a250cdec7" }
lightning-block-sync = { git = "https://github.com/lightningdevkit/rust-lightning", rev = "dcf0c203e166da2348bef12b2e5eff4a250cdec7", features = ["rest-client", "rpc-client", "tokio"] }
lightning-transaction-sync = { git = "https://github.com/lightningdevkit/rust-lightning", rev = "dcf0c203e166da2348bef12b2e5eff4a250cdec7", features = ["esplora-async-https", "time", "electrum-rustls-ring"] }
lightning-liquidity = { git = "https://github.com/lightningdevkit/rust-lightning", rev = "dcf0c203e166da2348bef12b2e5eff4a250cdec7", features = ["std"] }
lightning-macros = { git = "https://github.com/lightningdevkit/rust-lightning", rev = "dcf0c203e166da2348bef12b2e5eff4a250cdec7" }
lightning = { git = "https://github.com/lightningdevkit/rust-lightning", rev = "688544da72cb348e4405d39a75e4d81102c1278a", features = ["std"] }
lightning-types = { git = "https://github.com/lightningdevkit/rust-lightning", rev = "688544da72cb348e4405d39a75e4d81102c1278a" }
lightning-invoice = { git = "https://github.com/lightningdevkit/rust-lightning", rev = "688544da72cb348e4405d39a75e4d81102c1278a", features = ["std"] }
lightning-net-tokio = { git = "https://github.com/lightningdevkit/rust-lightning", rev = "688544da72cb348e4405d39a75e4d81102c1278a" }
lightning-persister = { git = "https://github.com/lightningdevkit/rust-lightning", rev = "688544da72cb348e4405d39a75e4d81102c1278a", features = ["tokio"] }
lightning-background-processor = { git = "https://github.com/lightningdevkit/rust-lightning", rev = "688544da72cb348e4405d39a75e4d81102c1278a" }
lightning-rapid-gossip-sync = { git = "https://github.com/lightningdevkit/rust-lightning", rev = "688544da72cb348e4405d39a75e4d81102c1278a" }
lightning-block-sync = { git = "https://github.com/lightningdevkit/rust-lightning", rev = "688544da72cb348e4405d39a75e4d81102c1278a", features = ["rest-client", "rpc-client", "tokio"] }
lightning-transaction-sync = { git = "https://github.com/lightningdevkit/rust-lightning", rev = "688544da72cb348e4405d39a75e4d81102c1278a", features = ["esplora-async-https", "time", "electrum-rustls-ring"] }
lightning-liquidity = { git = "https://github.com/lightningdevkit/rust-lightning", rev = "688544da72cb348e4405d39a75e4d81102c1278a", features = ["std"] }
lightning-macros = { git = "https://github.com/lightningdevkit/rust-lightning", rev = "688544da72cb348e4405d39a75e4d81102c1278a" }

bdk_chain = { version = "0.23.0", default-features = false, features = ["std"] }
bdk_esplora = { version = "0.22.0", default-features = false, features = ["async-https-rustls", "tokio"]}
Expand Down Expand Up @@ -79,13 +79,13 @@ async-trait = { version = "0.1", default-features = false }
vss-client = { package = "vss-client-ng", version = "0.5" }
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" }
Copy link
Copy Markdown
Contributor

@jkczyz jkczyz Mar 30, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


[target.'cfg(windows)'.dependencies]
winapi = { version = "0.3", features = ["winbase"] }

[dev-dependencies]
lightning = { git = "https://github.com/lightningdevkit/rust-lightning", rev = "dcf0c203e166da2348bef12b2e5eff4a250cdec7", features = ["std", "_test_utils"] }
lightning = { git = "https://github.com/lightningdevkit/rust-lightning", rev = "688544da72cb348e4405d39a75e4d81102c1278a", features = ["std", "_test_utils"] }
rand = { version = "0.9.2", default-features = false, features = ["std", "thread_rng", "os_rng"] }
proptest = "1.0.0"
regex = "1.5.6"
Expand Down
16 changes: 8 additions & 8 deletions src/builder.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -435,16 +435,16 @@ impl NodeBuilder {
/// Configures the [`Node`] instance to source inbound liquidity from the given
/// [bLIP-51 / LSPS1] service.
///
/// Will mark the LSP as trusted for 0-confirmation channels, see [`Config::trusted_peers_0conf`].
/// Will mark the LSP as trusted for 0-confirmation, 0-reserve channels, see [`Config::trusted_peers_0conf_0reserve`].
///
/// The given `token` will be used by the LSP to authenticate the user.
///
/// [bLIP-51 / LSPS1]: https://github.com/lightning/blips/blob/master/blip-0051.md
pub fn set_liquidity_source_lsps1(
&mut self, node_id: PublicKey, address: SocketAddress, token: Option<String>,
) -> &mut Self {
// Mark the LSP as trusted for 0conf
self.config.trusted_peers_0conf.push(node_id.clone());
// Mark the LSP as trusted for 0conf, 0reserve
self.config.trusted_peers_0conf_0reserve.push(node_id.clone());

let liquidity_source_config =
self.liquidity_source_config.get_or_insert(LiquiditySourceConfig::default());
Expand All @@ -456,16 +456,16 @@ impl NodeBuilder {
/// Configures the [`Node`] instance to source just-in-time inbound liquidity from the given
/// [bLIP-52 / LSPS2] service.
///
/// Will mark the LSP as trusted for 0-confirmation channels, see [`Config::trusted_peers_0conf`].
/// Will mark the LSP as trusted for 0-confirmation, 0-reserve channels, see [`Config::trusted_peers_0conf_0reserve`].
///
/// The given `token` will be used by the LSP to authenticate the user.
///
/// [bLIP-52 / LSPS2]: https://github.com/lightning/blips/blob/master/blip-0052.md
pub fn set_liquidity_source_lsps2(
&mut self, node_id: PublicKey, address: SocketAddress, token: Option<String>,
) -> &mut Self {
// Mark the LSP as trusted for 0conf
self.config.trusted_peers_0conf.push(node_id.clone());
// Mark the LSP as trusted for 0conf, 0reserve
self.config.trusted_peers_0conf_0reserve.push(node_id.clone());

let liquidity_source_config =
self.liquidity_source_config.get_or_insert(LiquiditySourceConfig::default());
Expand Down Expand Up @@ -956,7 +956,7 @@ impl ArcedNodeBuilder {
/// Configures the [`Node`] instance to source inbound liquidity from the given
/// [bLIP-51 / LSPS1] service.
///
/// Will mark the LSP as trusted for 0-confirmation channels, see [`Config::trusted_peers_0conf`].
/// Will mark the LSP as trusted for 0-confirmation, 0-reserve channels, see [`Config::trusted_peers_0conf_0reserve`].
///
/// The given `token` will be used by the LSP to authenticate the user.
///
Expand All @@ -970,7 +970,7 @@ impl ArcedNodeBuilder {
/// Configures the [`Node`] instance to source just-in-time inbound liquidity from the given
/// [bLIP-52 / LSPS2] service.
///
/// Will mark the LSP as trusted for 0-confirmation channels, see [`Config::trusted_peers_0conf`].
/// Will mark the LSP as trusted for 0-confirmation, 0-reserve channels, see [`Config::trusted_peers_0conf_0reserve`].
///
/// The given `token` will be used by the LSP to authenticate the user.
///
Expand Down
23 changes: 15 additions & 8 deletions src/config.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -123,7 +123,7 @@ pub(crate) const LNURL_AUTH_TIMEOUT_SECS: u64 = 15;
/// | `listening_addresses` | None |
/// | `announcement_addresses` | None |
/// | `node_alias` | None |
/// | `trusted_peers_0conf` | [] |
/// | `trusted_peers_0conf_0reserve` | [] |
/// | `probing_liquidity_limit_multiplier` | 3 |
/// | `anchor_channels_config` | Some(..) |
/// | `route_parameters` | None |
Expand Down Expand Up @@ -156,12 +156,19 @@ pub struct Config {
/// **Note**: We will only allow opening and accepting public channels if the `node_alias` and the
/// `listening_addresses` are set.
pub node_alias: Option<NodeAlias>,
/// A list of peers that we allow to establish zero confirmation channels to us.
///
/// **Note:** Allowing payments via zero-confirmation channels is potentially insecure if the
/// funding transaction ends up never being confirmed on-chain. Zero-confirmation channels
/// should therefore only be accepted from trusted peers.
pub trusted_peers_0conf: Vec<PublicKey>,
/// A list of peers that we trust. If a peer on this list opens a channel to us, we will
/// forward their HTLCs before any confirmations of the funding transaction (zero-conf), and
/// 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).
Copy link
Copy Markdown
Collaborator

@tnull tnull Mar 31, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor Author

@tankyleo tankyleo Mar 31, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

@tankyleo tankyleo Mar 31, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Collaborator

@tnull tnull Apr 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • 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?

Copy link
Copy Markdown
Contributor Author

@tankyleo tankyleo Apr 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Done below

///
/// **Note:** Allowing payments via zero-confirmation channels is potentially insecure if
/// the funding transaction never gets confirmed on-chain. Zero-reserve channels
/// allow the counterparty to make cheating attempts with no financial penalty.
/// Zero-confirmation, and zero-reserve channels should therefore only be accepted from and
/// opened to trusted peers.
pub trusted_peers_0conf_0reserve: Vec<PublicKey>,
Copy link
Copy Markdown
Collaborator

@tnull tnull Apr 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor Author

@tankyleo tankyleo Apr 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • 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."

Copy link
Copy Markdown
Contributor

@benthecarman benthecarman Apr 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor Author

@tankyleo tankyleo Apr 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

@tankyleo tankyleo Apr 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

/// The liquidity factor by which we filter the outgoing channels used for sending probes.
///
/// Channels with available liquidity less than the required amount times this value won't be
Expand Down Expand Up @@ -208,7 +215,7 @@ impl Default for Config {
network: DEFAULT_NETWORK,
listening_addresses: None,
announcement_addresses: None,
trusted_peers_0conf: Vec::new(),
trusted_peers_0conf_0reserve: Vec::new(),
probing_liquidity_limit_multiplier: DEFAULT_PROBING_LIQUIDITY_LIMIT_MULTIPLIER,
anchor_channels_config: Some(AnchorChannelsConfig::default()),
tor_config: None,
Expand Down
18 changes: 10 additions & 8 deletions src/event.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ use lightning::events::{
ReplayEvent,
};
use lightning::impl_writeable_tlv_based_enum;
use lightning::ln::channelmanager::PaymentId;
use lightning::ln::channelmanager::{PaymentId, TrustedChannelFeatures};
use lightning::ln::types::ChannelId;
use lightning::routing::gossip::NodeId;
use lightning::sign::EntropySource;
Expand Down Expand Up @@ -1258,7 +1258,6 @@ where
let user_channel_id: u128 = u128::from_ne_bytes(
self.keys_manager.get_secure_random_bytes()[..16].try_into().unwrap(),
);
let allow_0conf = self.config.trusted_peers_0conf.contains(&counterparty_node_id);
let mut channel_override_config = None;
if let Some((lsp_node_id, _)) = self
.liquidity_source
Expand All @@ -1284,11 +1283,14 @@ where
});
}
}
let res = if allow_0conf {
self.channel_manager.accept_inbound_channel_from_trusted_peer_0conf(
let is_trusted_peer =
self.config.trusted_peers_0conf_0reserve.contains(&counterparty_node_id);
let res = if is_trusted_peer {
self.channel_manager.accept_inbound_channel_from_trusted_peer(
&temporary_channel_id,
&counterparty_node_id,
user_channel_id,
TrustedChannelFeatures::ZeroConfZeroReserve,
channel_override_config,
)
} else {
Expand All @@ -1305,21 +1307,21 @@ where
log_info!(
self.logger,
"Accepting inbound{}{} channel of {}sats from{} peer {}",
if allow_0conf { " 0conf" } else { "" },
if is_trusted_peer { " 0conf, 0reserve" } else { "" },
if anchor_channel { " Anchor" } else { "" },
funding_satoshis,
if allow_0conf { " trusted" } else { "" },
if is_trusted_peer { " trusted" } else { "" },
counterparty_node_id,
);
},
Err(e) => {
log_error!(
self.logger,
"Error while accepting inbound{}{} channel from{} peer {}: {:?}",
if allow_0conf { " 0conf" } else { "" },
if is_trusted_peer { " 0conf, 0reserve" } else { "" },
if anchor_channel { " Anchor" } else { "" },
counterparty_node_id,
if allow_0conf { " trusted" } else { "" },
if is_trusted_peer { " trusted" } else { "" },
e,
);
},
Expand Down
72 changes: 51 additions & 21 deletions src/lib.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1196,27 +1196,57 @@ impl Node {
self.keys_manager.get_secure_random_bytes()[..16].try_into().unwrap(),
);

match self.channel_manager.create_channel(
peer_info.node_id,
channel_amount_sats,
push_msat,
user_channel_id,
None,
Some(user_config),
) {
Ok(_) => {
log_info!(
self.logger,
"Initiated channel creation with peer {}. ",
peer_info.node_id
);
self.peer_store.add_peer(peer_info)?;
Ok(UserChannelId(user_channel_id))
},
Err(e) => {
log_error!(self.logger, "Failed to initiate channel creation: {:?}", e);
Err(Error::ChannelCreationFailed)
},
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(
Copy link
Copy Markdown
Collaborator

@tnull tnull Mar 31, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor Author

@tankyleo tankyleo Mar 31, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Collaborator

@tnull tnull Apr 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

peer_info.node_id,
channel_amount_sats,
push_msat,
user_channel_id,
None,
Some(user_config),
) {
Ok(_) => {
log_info!(
self.logger,
"Initiated 0reserve channel creation with peer {}. ",
peer_info.node_id
);
self.peer_store.add_peer(peer_info)?;
Ok(UserChannelId(user_channel_id))
},
Err(e) => {
log_error!(
self.logger,
"Failed to initiate 0reserve channel creation: {:?}",
e
);
Err(Error::ChannelCreationFailed)
},
}
} else {
match self.channel_manager.create_channel(
peer_info.node_id,
channel_amount_sats,
push_msat,
user_channel_id,
None,
Some(user_config),
) {
Ok(_) => {
log_info!(
self.logger,
"Initiated channel creation with peer {}. ",
peer_info.node_id
);
self.peer_store.add_peer(peer_info)?;
Ok(UserChannelId(user_channel_id))
},
Err(e) => {
log_error!(self.logger, "Failed to initiate channel creation: {:?}", e);
Err(Error::ChannelCreationFailed)
},
}
}
}

Expand Down
16 changes: 8 additions & 8 deletions tests/common/mod.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -381,20 +381,20 @@ macro_rules! setup_builder {
pub(crate) use setup_builder;

pub(crate) fn setup_two_nodes(
chain_source: &TestChainSource, allow_0conf: bool, anchor_channels: bool,
chain_source: &TestChainSource, allow_0conf_0reserve: bool, anchor_channels: bool,
anchors_trusted_no_reserve: bool,
) -> (TestNode, TestNode) {
setup_two_nodes_with_store(
chain_source,
allow_0conf,
allow_0conf_0reserve,
anchor_channels,
anchors_trusted_no_reserve,
TestStoreType::TestSyncStore,
)
}

pub(crate) fn setup_two_nodes_with_store(
chain_source: &TestChainSource, allow_0conf: bool, anchor_channels: bool,
chain_source: &TestChainSource, allow_0conf_0reserve: bool, anchor_channels: bool,
anchors_trusted_no_reserve: bool, store_type: TestStoreType,
) -> (TestNode, TestNode) {
println!("== Node A ==");
Expand All @@ -405,8 +405,8 @@ pub(crate) fn setup_two_nodes_with_store(
println!("\n== Node B ==");
let mut config_b = random_config(anchor_channels);
config_b.store_type = store_type;
if allow_0conf {
config_b.node_config.trusted_peers_0conf.push(node_a.node_id());
if allow_0conf_0reserve {
config_b.node_config.trusted_peers_0conf_0reserve.push(node_a.node_id());
}
if anchor_channels && anchors_trusted_no_reserve {
config_b
Expand Down Expand Up @@ -789,8 +789,8 @@ pub async fn splice_in_with_all(
}

pub(crate) async fn do_channel_full_cycle<E: ElectrumApi>(
node_a: TestNode, node_b: TestNode, bitcoind: &BitcoindClient, electrsd: &E, allow_0conf: bool,
expect_anchor_channel: bool, force_close: bool,
node_a: TestNode, node_b: TestNode, bitcoind: &BitcoindClient, electrsd: &E,
allow_0conf_0reserve: bool, expect_anchor_channel: bool, force_close: bool,
) {
let addr_a = node_a.onchain_payment().new_address().unwrap();
let addr_b = node_b.onchain_payment().new_address().unwrap();
Expand Down Expand Up @@ -864,7 +864,7 @@ pub(crate) async fn do_channel_full_cycle<E: ElectrumApi>(

wait_for_tx(electrsd, funding_txo_a.txid).await;

if !allow_0conf {
if !allow_0conf_0reserve {
generate_blocks_and_wait(&bitcoind, electrsd, 6).await;
}

Expand Down
2 changes: 1 addition & 1 deletion tests/integration_tests_rust.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -71,7 +71,7 @@ async fn channel_full_cycle_force_close_trusted_no_reserve() {
}

#[tokio::test(flavor = "multi_thread", worker_threads = 1)]
async fn channel_full_cycle_0conf() {
async fn channel_full_cycle_0conf_0reserve() {
let (bitcoind, electrsd) = setup_bitcoind_and_electrsd();
let chain_source = random_chain_source(&bitcoind, &electrsd);
let (node_a, node_b) = setup_two_nodes(&chain_source, true, true, false);
Expand Down
Loading