Reintroduce cfg(dual_funding) for handling of open_channel2 messages#3485
Conversation
490b2ac to
d67c00a
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3485 +/- ##
==========================================
+ Coverage 89.71% 90.17% +0.45%
==========================================
Files 130 129 -1
Lines 107625 114866 +7241
Branches 107625 114866 +7241
==========================================
+ Hits 96553 103576 +7023
- Misses 8672 8998 +326
+ Partials 2400 2292 -108 ☔ View full report in Codecov by Sentry. |
d67c00a to
e774784
Compare
e774784 to
e8cf37e
Compare
e8cf37e to
e5f6e4e
Compare
|
Note: previously splicing branches used |
TheBlueMatt
left a comment
There was a problem hiding this comment.
LGTM except we need to remove features.set_dual_fund_optional(); in provided_init_features too.
We will not support accepting V2 channels in the v0.1 release, but we do need to document the API change for push_msats -> channel_negotiation_type.
e5f6e4e to
76608f7
Compare
So here I've been quite conservative and have only cfg flagged the parts (message handling) that are definitely just for dual-funding, and which splicing shouldn't be using. If that's not the case then would you mind introducing the |
| }, | ||
| wire::Message::OpenChannelV2(msg) => { | ||
| self.message_handler.chan_handler.handle_open_channel_v2(their_node_id, &msg); | ||
| wire::Message::OpenChannelV2(_msg) => { |
There was a problem hiding this comment.
Ha, this doesn't seem required :)
There was a problem hiding this comment.
Oh yup. Ended up removing the cfg flag in the branch...
There is still some work to be done here (like #3423) and it probably makes sense to release this (around v0.2) with the ability to open V2 channels too. This would also make our functional tests for dual-funding more complete.