Wait to create a channel until after accepting. (channel, ChannelManager)
Host: dunxen -
- LDK allows a user to manually accept inbound channels from other peers when the corresponding
UserConfig::manually_accept_inbound_channelsfield is set to
true. This results in an
Event::OpenChannelRequestbeing triggered by a new inbound request for a channel via receiving an
OpenChannelmessage. At this point, the user needs to manually call
ChannelManager::accept_inbound_channelor similar before an
AcceptChannelwill be sent back to the peer.
- This feature gives the user an opportunity to make a decision on accepting or rejecting the channel with their own logic. Importantly, it also allows a user
to assign their own custom identity to the inbound channel using the
user_channel_idfield, but currently there’s a bit of a problem with that…
- Currently, LDK’s
OpenChannelmessage handler will always attempt to construct an
InboundV1Channelobject before the
OpenChannelRequestevent is even triggered. Consequently, cryptographic material is immediately requested from signer objects using a randomly generated
user_channel_idand not one the user selected.
- This PR fixes this bug by deferring construction of an
InboundV1Channelobject until after the user actually manually accepts the channel and has the opportunity to provide a custom identity.
- Did you review the PR? Concept ACK, approach ACK, tested ACK, or NACK?i
- What is an important use of a custom
user_channel_idfield when it comes to requesting cryptographic material? Hint: Take a look at
- What object is introduced to represent inbound channels awaiting a user to accept or reject it? Why would or wouldn’t you consider this object a channel at this point?
- A new map,
inbound_channel_request_by_idis introduced for
PeerState. How do we treat and limit the entries of this map when it comes to denial-of-service mitigations?
- Why should we or why should we not still ignore any contributions that inbound 0conf channel requests make to the overall unfunded channel counts?
- Which fields/methods in
ChannelContextare made obsolete by this PR?