Funding signed event #3024
Funding signed event #3024
Conversation
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #3024 +/- ##
==========================================
- Coverage 89.16% 89.15% -0.02%
==========================================
Files 118 118
Lines 97726 97947 +221
Branches 97726 97947 +221
==========================================
+ Hits 87137 87320 +183
- Misses 8348 8381 +33
- Partials 2241 2246 +5 ☔ View full report in Codecov by Sentry. |
| /// [`ChannelManager::create_channel`]: crate::ln::channelmanager::ChannelManager::create_channel | ||
| /// [`ChannelManager::accept_inbound_channel`]: crate::ln::channelmanager::ChannelManager::accept_inbound_channel | ||
| /// [`UserConfig::manually_accept_inbound_channels`]: crate::util::config::UserConfig::manually_accept_inbound_channels | ||
| user_channel_id: u128, |
There was a problem hiding this comment.
You should give the funding tx to broadcast
jbesraa
force-pushed
the
funding-signed-event
branch
from
999fc5a
to
f9f087a
Compare
Add a new flag to `UserConfig` and `ChannelContext` to allow users to broadcast an outbound channel funding transaction manually and halt the automatic broadcasting from LDK.
jbesraa
force-pushed
the
funding-signed-event
branch
2 times, most recently
from
e9ffefc
to
d48453a
Compare
| @@ -2864,6 +2865,23 @@ macro_rules! send_channel_ready { | |||
| } | |||
| }} | |||
| } | |||
| macro_rules! emit_funding_signed_event { | |||
| ($locked_events: expr, $channel: expr) => { | |||
| let funding_tx = $channel.context.get_funding_transaction(); // hmm.. this is always none? | |||
There was a problem hiding this comment.
the funding_transaction is None while it should be defined at this stage as we are after FundingCreated.. what could be the reason for this?
| @@ -646,6 +646,7 @@ mod state_flags { | |||
| pub const LOCAL_SHUTDOWN_SENT: u32 = 1 << 11; | |||
| pub const SHUTDOWN_COMPLETE: u32 = 1 << 12; | |||
| pub const WAITING_FOR_BATCH: u32 = 1 << 13; | |||
| pub const FUNDING_SIGNED: u32 = 1 << 14; | |||
There was a problem hiding this comment.
FUNDING_SIGNED is added as part of AwaitingChannelReadyFlags and not a whole new thing
jbesraa
force-pushed
the
funding-signed-event
branch
from
d48453a
to
cb5e32f
Compare
If `manually_broadcast_outbound_channels` is set, LDK will emit this event after the counterparty node send the `FundingSigned` msg without broadcasting the funding transaction.
jbesraa
force-pushed
the
funding-signed-event
branch
from
cb5e32f
to
20313c8
Compare
| expect_funding_signed_event(&nodes[0]); | ||
| nodes[0].node.get_and_clear_pending_msg_events(); | ||
| mine_transaction(&nodes[0], &tx); | ||
| expect_channel_ready_event(&nodes[0], &nodes[1].node.get_our_node_id()); |
There was a problem hiding this comment.
As you can see here, the channel goes from FundingSigned to ChannelReady and does not go to ChannelPending. the main reason I followed this as that ChannelPending expects the funding transaction to broadcastable.
| @@ -810,6 +810,8 @@ pub struct UserConfig { | |||
| /// | |||
| /// [`ChannelManager`]: crate::ln::channelmanager::ChannelManager | |||
| pub accept_mpp_keysend: bool, | |||
| /// broadcast funding transaction manually | |||
| pub manually_broadcast_outbound_channels: bool, | |||
There was a problem hiding this comment.
Hmm, is it best to do this via a config or via a different method to pass LDK the funding transaction? A config seems to imply people might want to just turn this on, but really its a totally differnet flow, and maybe thus makes sense as a different method since it'll change the programming entirely?
There was a problem hiding this comment.
Ok ill give that a try to see how that works.
What do you think about the next event after FundingSigned? In the current implementation its going from FundingSigned to ChannelReady ie skips the ChannelPending. I did that because in the code ChannelPending = "funding is ready and signed, just wait for confirmations", but that is not accurate for all cases. in payjoin scenario we never really know that the funding is fully signed and broadcasted.
There was a problem hiding this comment.
Hmm, we should probably keep ChannelPending, I think - its pending from the lightning POV, just something else is dealing with broadcasting.
resolves #3023