Refactor ChannelTransactionParameters into FundingScope
#3604
Conversation
|
@wpaulino This primarily moves fields from The drawback is we'd be duplicating fields that wouldn't change. But this seems better than duplicating fields that would change and risk having inconsistent data. Also, it could prevent us from needing to worry about changing other uses of What are your thoughts? |
|
I was thinking we could deprecate the funding scope related fields from |
Yeah, this PR takes that approach. But when removing the fields we'd need to update all uses to take both For instance, writing an There's also I haven't looked exhaustively to see all usages, but it seems simpler to keep |
|
Hm, I'm not opposed to always writing As for |
|
Here's the alternative approach: https://github.com/jkczyz/rust-lightning/tree/2025-02-channel-funding-pubkeys-alt |
Yeah this looks pretty simple, and would also allow us to handle transitioning to new channel types in a splice since it already tracks the channel type features. I don't think the duplicate data is all that bad here once we have multiple scopes since it will eventually go away when the splice confirms. We should at least be able to avoid persisting the duplicate data, if we choose to, by cloning it from the "main" (currently confirmed) scope when reading. Thoughts on either of these approaches @TheBlueMatt? |
|
@TheBlueMatt Added some more commits to the alternative branch after pairing with @wpaulino yesterday. They move |
|
Discussed this being supersceded by an alternative that tries to keep signer operations (across many splice versions) together as one call. |
jkczyz
force-pushed
the
2025-02-channel-funding-pubkeys
branch
2 times, most recently
from
df840cb to
aff70ae
Compare
jkczyz
changed the title
FundingScopeChannelTransactionParameters into FundingScope
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3604 +/- ##
==========================================
- Coverage 88.60% 88.59% -0.02%
==========================================
Files 151 151
Lines 118409 118404 -5
Branches 118409 118404 -5
==========================================
- Hits 104918 104900 -18
+ Misses 10972 10968 -4
- Partials 2519 2536 +17 ☔ View full report in Codecov by Sentry. |
|
Updated the branch to use the alternative version. See updated PR description for details. |
jkczyz
force-pushed
the
2025-02-channel-funding-pubkeys
branch
3 times, most recently
from
339e0ca to
a55149f
Compare
| @@ -882,7 +882,9 @@ pub struct ChannelTransactionParameters { | |||
| pub funding_outpoint: Option<chain::transaction::OutPoint>, | |||
| /// This channel's type, as negotiated during channel open. For old objects where this field | |||
| /// wasn't serialized, it will default to static_remote_key at deserialization. | |||
There was a problem hiding this comment.
Since we're providing these to the signer on every call now (and there's so much redundant data) I wonder if (I guess it could happen when we do splicing) we shouldn't have some partial-comparator for these that just checks that two of them are equal for the fields that shouldn't change across a splice?
|
CI is sad |
jkczyz
force-pushed
the
2025-02-channel-funding-pubkeys
branch
from
a55149f to
888e658
Compare
Fixed now, I think. Will make add pending CHANGELOG item in a bit. For now, PTAL. |
Rather than moving relevant fields of ChannelTransactionParameters to FundingScope, move the entire struct there instead. This prevents API churn wherever ChannelTransactionParameters is used, which otherwise would need a FundingScope in addition.
Since the funding transactions changes for each new FudningScope, include it there instead of ChannelContext.
InMemorySigner no longer holds channel_value_satoshis and channel_parameters. Instead of writing 0 and None, respectively, drop (de-)serialization support entirely since InMemorySigner hasn't been serialized since SERIALIZATION_VERSION 2.
Since channel_value_satoshis is needed by the signer and may change for each new FundingScope, included it in ChannelTransactionParameters so it can be passed to each signer call in the upcoming commits.
Now that ChannelTransactionParameters are in FundingScope, channel_value_satoshis can be dropped from the latter.
Now that channel_value_satoshis has been moved to ChannelTransactionParameters, pass the entire parameters when calling each method on EcdsaChannelSigner. This will remove the need for ChannelSigner::provide_channel_parameters. Instead, the parameters from the FundingScope will be passed in to each method. This simplifies the interaction with a ChannelSigner when needing to be called for more than one FundingScope, which will be the case for pending splices and RBF attempts.
Now that channel_value_satoshis has been moved to ChannelTransactionParameters, pass the entire parameters when calling each method on EcdsaChannelSigner. This will remove the need for ChannelSigner::provide_channel_parameters. Instead, the parameters from the FundingScope will be passed in to each method. This simplifies the interaction with a ChannelSigner when needing to be called for more than one FundingScope, which will be the case for pending splices and RBF attempts.
Now that channel_value_satoshis has been moved to ChannelTransactionParameters, pass the entire parameters when calling each method on EcdsaChannelSigner. This will remove the need for ChannelSigner::provide_channel_parameters. Instead, the parameters from the FundingScope will be passed in to each method. This simplifies the interaction with a ChannelSigner when needing to be called for more than one FundingScope, which will be the case for pending splices and RBF attempts.
Now that channel_value_satoshis has been moved to ChannelTransactionParameters, pass the entire parameters when calling each method on EcdsaChannelSigner. This will remove the need for ChannelSigner::provide_channel_parameters. Instead, the parameters from the FundingScope will be passed in to each method. This simplifies the interaction with a ChannelSigner when needing to be called for more than one FundingScope, which will be the case for pending splices and RBF attempts.
Now that channel_value_satoshis has been moved to ChannelTransactionParameters, pass the entire parameters when calling each method on EcdsaChannelSigner. This will remove the need for ChannelSigner::provide_channel_parameters. Instead, the parameters from the FundingScope will be passed in to each method. This simplifies the interaction with a ChannelSigner when needing to be called for more than one FundingScope, which will be the case for pending splices and RBF attempts.
Now that channel_value_satoshis has been moved to ChannelTransactionParameters, pass the entire parameters when calling each method on EcdsaChannelSigner. This will remove the need for ChannelSigner::provide_channel_parameters. Instead, the parameters from the FundingScope will be passed in to each method. This simplifies the interaction with a ChannelSigner when needing to be called for more than one FundingScope, which will be the case for pending splices and RBF attempts.
Now that channel_value_satoshis has been moved to ChannelTransactionParameters, pass the entire parameters when calling each method on EcdsaChannelSigner. This will remove the need for ChannelSigner::provide_channel_parameters. Instead, the parameters from the FundingScope will be passed in to each method. This simplifies the interaction with a ChannelSigner when needing to be called for more than one FundingScope, which will be the case for pending splices and RBF attempts.
Now that channel_value_satoshis has been moved to ChannelTransactionParameters, pass the entire parameters when calling each method on EcdsaChannelSigner. This will remove the need for ChannelSigner::provide_channel_parameters. Instead, the parameters from the FundingScope will be passed in to each method. This simplifies the interaction with a ChannelSigner when needing to be called for more than one FundingScope, which will be the case for pending splices and RBF attempts.
Now that channel_value_satoshis has been moved to ChannelTransactionParameters, InMemorySigner no longer needs a copy. Remove uses of the copy from sign_counterparty_payment_input.
Now that channel_value_satoshis has been moved to ChannelTransactionParameters, InMemorySigner no longer needs a copy. Remove indirect uses of the copy from TestChannelSigner.
Now that the copy of ChannelTransactionParameters is no longer used by InMemorySigner, remove it and all remaining uses. Since it was set by ChannelSigner::provide_channel_parameters, this method is no longer needed and can also be removed.
Now that channel_value_satoshis has been moved to ChannelTransactionParameters, it no longer needs to be used when deriving a signer. This is a breaking API change, though InMemorySigner did not make use of channel_value_satoshis when being derived.
The custom derive_channel_signer methods on AnchorDescriptor and HTLCDescriptor simply delegate to the passed SignerProvider now that providing ChannelTransactionParameters is no longer needed. Drop these methods and replace them with the method bodies at the call sites.
|
Needs a rebase |
jkczyz
force-pushed
the
2025-02-channel-funding-pubkeys
branch
from
3ce8659 to
0d127cf
Compare
|
Rebased to resolve merge conflicts. |
| @@ -10311,21 +10327,6 @@ impl<'a, 'b, 'c, ES: Deref, SP: Deref> ReadableArgs<(&'a ES, &'b SP, u32, &'c Ch | |||
|
|
|||
| let latest_monitor_update_id = Readable::read(reader)?; | |||
|
|
|||
| let mut keys_data = None; | |||
| if ver <= 2 { | |||
There was a problem hiding this comment.
We should explicitly reject reads of channels <= version 2.
| // ChannelTransactionParameters::channel_value_satoshis defaults to 0 prior to version 0.2. | ||
| channel_parameters.channel_value_satoshis = channel_value_satoshis; |
There was a problem hiding this comment.
This can be dropped now.
| pub(crate) fn make_funding_redeemscript(&self) -> ScriptBuf { | ||
| make_funding_redeemscript( | ||
| &self.holder_pubkeys.funding_pubkey, | ||
| &self.counterparty_parameters.as_ref().unwrap().pubkeys.funding_pubkey |
There was a problem hiding this comment.
I'm really not a fan of a hidden unwrap. In general I think we should reconsider ChannelTransactionParameters to remove the many unwraps it generates - we should probably have something that requires the counterparty parameters as the type we use everywhere, with Channel having its own internal type which has them optional where required. This is quite old code so needs some refreshing...
There was a problem hiding this comment.
Yeah, agreed. @wpaulino discussed a future refactor where ChannelTransactionParameters becomes two structs, where one transitions to the other when the counterparty's keys are obtained in order to avoid the Option.
Continues the work of #3592 by moving fields related to the funding transaction into
FundingScope.This includes fields fromChannelContextfor the funding transaction andChannelTransactionParametersfor the funding outpoint and pubkeys.This primarily involves moving the entire
ChannelTransactionParametersintoFundingScopeandchannel_value_satoshisintoChannelTransactionParameters. The latter result in less API churn at the cost of duplicating parameters that don't change across eachFundingScope. To that end, this PR also updates theEcdsaChannelSignerto takeChannelTransactionParameterswhich removes the need forChannelSigner::provide_channel_parameters.Since
ChannelTransactionParameterscontainschannel_value_satoshis, implementation likeInMemorySignerno longer need it. Thus, theNodeSignertrait is updated to no longer take the value when deriving signers, which is a breaking change.