feat: expose channel_reserve_satoshis via ChannelParameters
#3910
Conversation
|
I've assigned @wpaulino as a reviewer! |
exposes channel_reserve_satoshis by adding it to CommonAcceptChannelFields for the user to ascertain the value set by the counterparty
Prabhat1308
force-pushed
the
probot/expose_csr
branch
from
2933e6a to
8332a7a
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3910 +/- ##
==========================================
- Coverage 88.82% 88.80% -0.03%
==========================================
Files 165 165
Lines 119075 119083 +8
Branches 119075 119083 +8
==========================================
- Hits 105774 105749 -25
- Misses 10981 11006 +25
- Partials 2320 2328 +8 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| @@ -3072,6 +3078,7 @@ impl LengthReadable for OpenChannelV2 { | |||
| let dust_limit_satoshis: u64 = Readable::read(r)?; | |||
| let max_htlc_value_in_flight_msat: u64 = Readable::read(r)?; | |||
| let htlc_minimum_msat: u64 = Readable::read(r)?; | |||
| let channel_reserve_satoshis: u64 = Readable::read(r)?; | |||
There was a problem hiding this comment.
We can't do this, as OpenChannelV2 doesn't have that field, see https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#the-open_channel2-message
It's also not a 'common' field per se as per spec:
Note that open_channel's channel_reserve_satoshi has been omitted. Instead, the channel reserve is fixed at 1% of the total channel balance (open_channel2.funding_satoshis + accept_channel2.funding_satoshis) rounded down to the nearest whole satoshi or the dust_limit_satoshis, whichever is greater.
There was a problem hiding this comment.
The best bet would be to have a new top-level field in OpenChannelRequest for channel_reserve_satoshis and then set that in channelmanager like:
channel_reserve_satoshis: match msg {
OpenChannelMessageRef::V1(msg) => msg.channel_reserve_satoshis,
OpenChannelMessageRef::V2(msg) => get_v2_channel_reserve_satoshis(
channel_value_satoshis, msg.common_fields.dust_limit_satoshis
);
},The get_v2_channel_reserve_satoshis exists in the channel module. You'd need to make that pub(super).
This would be a breaking change and also would need docs and shouldn't be backported.
There was a problem hiding this comment.
The best bet would be to have a new top-level field in
OpenChannelRequest
Hmm, while that would be pretty easy, I'm not super happy about exposing such a detail at the top level API, especially if we have sub-structs in-place. can't we reuse ChannelParameters still, but apply above rules for v2 channels? Or, maybe it would be the right time to refactor OpenChannelRequest (or ChannelParameters) to discern between V1 and V2 channels?
There was a problem hiding this comment.
Yeah you could reuse ChannelParameters and just have the field there, update the doc comment for it as it currently mentions being a subset of the common fields. It will just need to be initialised as 0 in CommonOpenChannelFields::channel_parameters and then set like above when creating the OpenChannelRequest event. I'm not sure an Option is worth the effort as it'll always end up being Some() when accessed by the user.
Refactoring is fine, but we'd want to still have a single OpenChannelRequest event.
|
🔔 1st Reminder Hey @wpaulino! This PR has been waiting for your review. |
fixes #3909
exposes
channel_reserve_satoshisby adding it toChannelParametersandCommonAcceptChannelFieldsfor the user to ascertain the value set by the counterparty