New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PSBT BIP32 keys using to Secp256k1 keys instead of bitcoin ECDSA #591
Conversation
Rebased. Should be reviewed after #590 |
Concept ACK for this. But the interesting part is how do we deal with partial_sigs part. Since, we would have sigs for |
@sanket1729 the goal of this PR is not to add Taproot support to PSBT, but just make existing PSBT more logical. For Taproot support we clearly need a new PR adding new key types according to the latest changes. So, current signatures for already defined keys should remain to be ECDSA signatures |
Sorry, I should read the description/code 🤦 . Will review after the other related PRs |
utACK b8105e9 |
Fourth step in implementation of Schnorr key support after #588. While PSBT BIP174 does not specify whether uncompressed keys are supported in BIP32-related fields, from BIP32 it follows that it is impossible to use uncompressed keys within the extended keys. This PR fixes this situation and is a companion to BIP174 PR clarifying key serialization: bitcoin/bips#1100
Re-based after #590 merge, ready for review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK a6e8f58
I kinda feel that we should PR to the Bitcoin BIPs repo to suggest this, but it's almost obvious (since BIP32 does not support uncompressed keys) so it's probably fine.
@apoelstra did BIP PR last April, but it has stuck: bitcoin/bips#1100 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK a6e8f58. Not sure which order to merge since there are many ready PRs which that would break each other.
Can we pls merge this in front of other approved PRs? |
This changes the type of secp signature from secp256k1::Signature to bitcoin::PublicKey. Psbt allows storing signatures for both compressed as well as uncompressed keys. This bug was introduced in rust-bitcoin#591 while trying to change the type of BIP32 keys from bitcoin::PublicKey to secp256k1::PublicKey.
…coin key 4e19973 Add a breaking test (sanket1729) 69c6eb6 Bug: Change type of pbst partial sig from secp key to bitcoin key (sanket1729) Pull request description: This changes the type of secp signature from secp256k1::PublicKey to bitcoin::PublicKey. Psbt allows storing signatures for both compressed as well as uncompressed keys. This bug was introduced in #591 while trying to change the type of BIP32 keys from bitcoin::PublicKey to secp256k1::PublicKey. ACKs for top commit: Kixunil: ACK 4e19973 apoelstra: ACK 4e19973 Tree-SHA512: 2a326bafc050cd101e75899c32224a9ac2fcb2ec0b9f7f173404a46f2b3a92ecb78d0002db252a5af06705566bdc10102d20f4718eaeeebd3730fdb5ee89ff5a
Fourth step in implementation of Schnorr key support after #588. This PR is a follow-up to non-API breaking #589 and API-breaking #590, which must be reviewed and merged first.
(The current PR includes all commits from #589 and #590, which should be reviewed there. The only commit specific to this PR is b8105e9)UPDATE: All related PRs are merged now and this PR is ready for the review
PR description:
While PSBT BIP174 does not specify whether uncompressed keys are supported in BIP32-related fields, from BIP32 it follows that it is impossible to use uncompressed keys within the extended keys. This PR fixes this situation and is a companion to BIP174 PR clarifying key serialization: bitcoin/bips#1100