[Splicing] Signer extended with method to sign prev funding transaction input #3316
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3316 +/- ##
==========================================
- Coverage 89.61% 89.56% -0.05%
==========================================
Files 127 127
Lines 103534 103560 +26
Branches 103534 103560 +26
==========================================
- Hits 92781 92756 -25
- Misses 8053 8101 +48
- Partials 2700 2703 +3 ☔ View full report in Codecov by Sentry. |
optout21
force-pushed
the
signer_extend
branch
from
b7de01f
to
2c2f9f1
Compare
lightning/src/sign/ecdsa.rs
Outdated
| /// The previous funding transaction becomes an input to the new funding transaction, | ||
| /// and it is a multisig, which we also need to sign. | ||
| fn sign_transaction_input( | ||
| &self, tx: &Transaction, input_index: u16, input_value: u64, input_redeem_script: &Script, |
There was a problem hiding this comment.
The input_redeem_script, input_index, and input_value should all be redundant, right? The InMemorySigner should know the channel value and funding outpoint.
There was a problem hiding this comment.
Hm, I haven't thought about that.
The redeem script can be derived by the signer as well, true (funding pubkeys don't change).
The input_index is the index of the prev funding in the new funding (splicing) transaction, that's outside of the signer's scope.
The previous channel value could be used from the signer, unless already updated! The signing happens after the initial negotiation handshake, and in the current proto implementation (not set in stone) by that time the signer is already updated to the new channel value. However, I would keep this as a parameter, as it's more general, not to limit the space of possible implementations. (Another option would be to keep the whole previous signer.)
In conclusion, I remove the script parameter, but keep the value and index parameters.
There was a problem hiding this comment.
Doesn't the signer need to keep track of all previous funding values anyway, since it has to sign for multiple commitment transactions on both sides of the splice until the splice confirms?
There was a problem hiding this comment.
Mmm, I guess to keep our implementation simple we'd have to have some scheme like the CommitmentTransaction's trust method that gives access to "trusted" data. I guess I'm fine with leaving it.
optout21
force-pushed
the
signer_extend
branch
from
8cfd5d9
to
09d4590
Compare
optout21
force-pushed
the
signer_extend
branch
from
09d4590
to
84c739f
Compare
|
Documentation updated per the suggestions |
optout21
force-pushed
the
signer_extend
branch
from
84c739f
to
f22b011
Compare
Changed (also rebased) |
Fixes #3312 . (#1621 )
New method to sign an input of a transaction with our funding key.
Used for splicing, when signing the previous funding transaction. The previous funding transaction becomes an input to the new funding transaction, and it is a multisig, which we also need to sign.