Split out EcdsaChannelSigner method from BaseSign, and rename it to ChannelSigner
#1967
Conversation
arik-so
force-pushed
the
2023-01-rename-signer-traits
branch
4 times, most recently
from
897f881
to
48aca53
Compare
Codecov ReportBase: 90.71% // Head: 90.97% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #1967 +/- ##
==========================================
+ Coverage 90.71% 90.97% +0.26%
==========================================
Files 97 98 +1
Lines 50677 52857 +2180
Branches 50677 52857 +2180
==========================================
+ Hits 45971 48086 +2115
- Misses 4706 4771 +65
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
arik-so
force-pushed
the
2023-01-rename-signer-traits
branch
from
48aca53
to
2539e40
Compare
| @@ -90,7 +90,7 @@ impl EnforcingSigner { | |||
| } | |||
| } | |||
|
|
|||
| impl BaseSign for EnforcingSigner { | |||
| impl EcdsaChannelSigner for EnforcingSigner { | |||
There was a problem hiding this comment.
Also rename EnforcingSigner to EnforcingEcdsaChannelSigner?
There was a problem hiding this comment.
good point. My bigger question is actually what to do with Sign. Should it perhaps be gone entirely and the writeable trait should be required explicitly where Sign is required?
There was a problem hiding this comment.
That sounds good to me. ECDSA signers still require Writeable for compatibility reasons, but the taproot signer shouldn't require it since it'll never be stored and we'll always re-derive.
There was a problem hiding this comment.
Maybe we can just make EcdsaChannelSigner inherit Writeable instead?
There was a problem hiding this comment.
yeah if they all require it, that would probably be nicer. I'll see how many compilation errors that's gonna produce.
There was a problem hiding this comment.
I actually wonder whether we might wanna parametrize EnforcingSigner with an ECDSA and a Taproot signer subvariant. If it's ok, I'll punt on this to a PR where we introduce actual Taproot types.
arik-so
force-pushed
the
2023-01-rename-signer-traits
branch
from
2539e40
to
6d2d526
Compare
|
Please wrap commit titles and messages at around 80 chars long |
| /// Returns the holder's channel public keys and basepoints. | ||
| fn pubkeys(&self) -> &ChannelPublicKeys; | ||
|
|
There was a problem hiding this comment.
Wont pubkeys potentially be different with taproot? Presumably it may have a different set of keys?
There was a problem hiding this comment.
Why? As far as I can tell, only the signatures will be different.
There was a problem hiding this comment.
I guess I'm surprised it doesn't need some kind of additional data for key construction, but ok.
There was a problem hiding this comment.
Nope, nothing has changed here. We'll need to handle the nonces separately as part of the taproot signer trait.
| @@ -249,12 +246,35 @@ pub trait BaseSign { | |||
| /// irrelevant or duplicate preimages. | |||
| fn validate_holder_commitment(&self, holder_tx: &HolderCommitmentTransaction, | |||
| preimages: Vec<PaymentPreimage>) -> Result<(), ()>; | |||
|
|
|||
There was a problem hiding this comment.
Won't validate_holder_commitment potentially be different on taproot channels? The preimage set will need to include some PTLC secrets, which would require a different signer?
There was a problem hiding this comment.
I think you might be right. I wasn't really considering PTLCs yet, but perhaps it should indeed be moved. However, I think the more important question is whether the method signature would actually change. I know @wpaulino is planning a bunch of commitment-builder-related refactors, any thoughts?
There was a problem hiding this comment.
I see this PR as a starting point for the base ChannelSigner trait. We should hold off on moving any items we are not 100% sure will also apply to the taproot signer. Once we start getting through the bulk of the changes, we'll have a better idea of what should go where.
There was a problem hiding this comment.
I guess so, I'm just really not a fan of moving-removing-unmoving-and-then-moving-again over and over. It causes a bunch of churn for downstream code, which isn't so nice. If we're confident this PR is where we'll want stuff for taproot-v1, though, I'm okay with that.
There was a problem hiding this comment.
To be fair, the introduction of PTLCs (unclear if it'll even happen this year) will require a few changes from users anyway, so moving this back to the ECDSA signer will be just a small part of that.
arik-so
force-pushed
the
2023-01-rename-signer-traits
branch
from
642d4dc
to
712c60e
Compare
No description provided.