You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to help with this issue. Should this event be triggered when a node calls ChannelManager::accept_inbound_channel, when both sides of the channel have locked funding?
For ChannelConfirmed we should do it on funding-locked. For ChannelOpened (if we want one) we'd want to do it when the AcceptChannel message is either received or sent. The above schema looks good to me for the first, for the second we won't have a user id for inbounds, and the channel id will be the temporary_channel_id instead.
I have been taking a look at implementing ChannelConfirmed. From my understanding, the event should be emitted for incoming and outgoing channels when channel_ready messages have been both sent and received and the channel becomes usable. However, since it is possible to receive multiple channel_ready messages with different alias values, it's probably desirable to only emit the event when the channel state changes from non-usable to usable. To achieve that, it might be helpful to refactor the result of Channel::channel_ready but can be done without such a change as well. Does that sound correct?
@wvanlint sounds good to me. We may want to reconsider the event name ChannelConfirmed now that we have support for 0-conf channels and their channel_ready messages are exchanged while the funding transaction remains unconfirmed.
Activity
godsmith99x commentedon Mar 31, 2022
I would like to help with this issue. Should this event be triggered when a node calls ChannelManager::accept_inbound_channel, when both sides of the channel have locked funding?
godsmith99x commentedon Mar 31, 2022
Should the event look something like: ChannelOpened {
channel_id: [u8; 32],
user_channel_id: u64,
counterparty_node_id: PublicKey,
channel_type: ChannelTypeFeatures,
},
TheBlueMatt commentedon Apr 1, 2022
For
ChannelConfirmed
we should do it on funding-locked. ForChannelOpened
(if we want one) we'd want to do it when theAcceptChannel
message is either received or sent. The above schema looks good to me for the first, for the second we won't have a user id for inbounds, and the channel id will be thetemporary_channel_id
instead.ChannelAccepted
andChannelConfirmed
Events #1489wvanlint commentedon Jul 8, 2022
I have been taking a look at implementing
ChannelConfirmed
. From my understanding, the event should be emitted for incoming and outgoing channels whenchannel_ready
messages have been both sent and received and the channel becomes usable. However, since it is possible to receive multiplechannel_ready
messages with differentalias
values, it's probably desirable to only emit the event when the channel state changes from non-usable to usable. To achieve that, it might be helpful to refactor the result ofChannel::channel_ready
but can be done without such a change as well. Does that sound correct?wpaulino commentedon Jul 8, 2022
@wvanlint sounds good to me. We may want to reconsider the event name
ChannelConfirmed
now that we have support for 0-conf channels and theirchannel_ready
messages are exchanged while the funding transaction remains unconfirmed.tnull commentedon Sep 8, 2022
@wvanlint Do you still intend to pick this up? Asking since it would be nice to expose the
ChannelConfirmed
event downstream inLdkLite
.ChannelReady
event lightningdevkit/ldk-node#20godsmith99x commentedon Sep 8, 2022
tnull commentedon Sep 8, 2022
Alright, no problem!
ChannelReady
event #1743