Skip to content
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

Change EcdsaSig hash type deser in psbt #776

Merged
merged 4 commits into from Jan 17, 2022

Conversation

sanket1729
Copy link
Member

@sanket1729 sanket1729 commented Jan 13, 2022

Changes the parsing behavior in PSBT on non-standard sighash types to give an explicit error, rather than silently mangling the parsed value

Copy link
Collaborator

@Kixunil Kixunil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks correct. How hard would it be to introduce a new type? I guess not even urgent for Taproot, right?

/// This might cause unexpected behavior because it does not roundtrip. That is,
/// `EcdsaSigHashType::from_u32_consensus(n) as u32 != n` for non-standard values of
/// `n`. While verifying signatures, the user should retain the `n` and use it compute the
/// signature hash message.
pub fn from_u32_consensus(n: u32) -> EcdsaSigHashType {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't it be better to have a separate type allowing this? (One a newtype over the other.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if people are dealing with non-standard stuff, they better know what they are doing. So, I don't think we should concern ourselves by adding more code to safeguard non-standard users.

It is not an effort to introduce a new type, but I think I would be more comfortable with less code bloat about a code that no one is using. Document the non-standard stuff, and if someone wants it they can PR one and raise an issue.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We still need non-standard to validate consensus/process valid block, right? Couldn't it be a problem?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we need it. Our code for legacy_signature_hash does take input a sighash_u32 that we expect the user to provide correctly!

However, our code for bip143 segwitv0 sighash does not support signature verification of non-standard transactions! This is a bug and should be addressed independently.

src/util/ecdsa.rs Outdated Show resolved Hide resolved
}
_ => Err(encode::Error::ParseFailed("Invalid Schnorr signature len"))
Err(schnorr::SchnorrSigError::InvalidSchnorrSigSize(_)) =>
Err(encode::Error::ParseFailed("Invalid Schnorr signature len")),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: I'd prefer not to abbreviate "length" in an error message.

Err(encode::Error::from(psbt::Error::NonStandardSigHashType(flag))),
Err(EcdsaSigError::Secp256k1(..)) =>
Err(encode::Error::ParseFailed("Invalid Ecdsa signature")),
Err(EcdsaSigError::HexEncoding(..)) => unreachable!("Decoding from slice, not hex")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unrelated but this is why I don't like catch-all error types.

@sanket1729 sanket1729 force-pushed the psbt_sighash_ty branch 2 times, most recently from f3134b8 to 2a91e4a Compare January 14, 2022 00:06
@dr-orlovsky dr-orlovsky added this to In progress in PSBT via automation Jan 14, 2022
dr-orlovsky
dr-orlovsky previously approved these changes Jan 14, 2022
Copy link
Collaborator

@dr-orlovsky dr-orlovsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK efbeba0

dr-orlovsky added a commit that referenced this pull request Jan 14, 2022
ebdeed0 Cleanup imports (sanket1729)
382c8f9 Introduce PsbtSigHashType (sanket1729)

Pull request description:

  We cannot really use `Psbt` for taproot because the sighash type is currently EcdsaSigHashType. We could introduce an enum with two options but then deser is not really clear, so I chose the approach in the current PR. Feedback or other ways to do this welcome :)

  This is NOT related to #776

ACKs for top commit:
  apoelstra:
    ACK ebdeed0
  dr-orlovsky:
    ACK ebdeed0

Tree-SHA512: f9424cf3db09098d73f0d431a45ff86a47f11f7d40785bf95e58991fd4d16f0db0a9a3a63f898628b29c95bbd2ca901312a6a44ac6d8aec73a6a34710f6354a2
@dr-orlovsky
Copy link
Collaborator

Needs rebase after #779 merge

PSBT automation moved this from In progress to Review in progress Jan 15, 2022
Copy link
Collaborator

@dr-orlovsky dr-orlovsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK abe52f6

@dr-orlovsky
Copy link
Collaborator

@Kixunil let's get this closed and ship taproot! 🥇

@dr-orlovsky dr-orlovsky added code quality Makes code easier to understand and less likely to lead to problems documentation one ack PRs that have one ACK, so one more can progress them labels Jan 15, 2022
PSBT automation moved this from Review in progress to Ready for merge Jan 15, 2022
Copy link
Member

@apoelstra apoelstra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK abe52f6

@sanket1729 can you change the description from "borderline trivial" to "Changes the parsing behavior in PSBT on non-standard sighash types to give an explicit error, rather than silently mangling the parsed value"?

My first thought was to NACK this PR because we didn't have agreement on what the correct behavior was, but after studying it, I realized that our current behavior is definitely wrong and that this is at least an improvement.

@sanket1729
Copy link
Member Author

@apoelstra changed the description.

@dr-orlovsky dr-orlovsky added this to Ready for merge in Taproot Jan 15, 2022
@dr-orlovsky dr-orlovsky mentioned this pull request Jan 16, 2022
@dr-orlovsky
Copy link
Collaborator

We already have 2 ACKs, but I assume it would be nice to hear from @Kixunil reviewing this previously that all his comments are addresses before merging this

Copy link
Collaborator

@Kixunil Kixunil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK abe52f6

Go ahead and merge this, we can make a trivial followup issue/PR to rewrite to map_err

Err(schnorr::SchnorrSigError::InvalidSchnorrSigSize(_)) =>
Err(encode::Error::ParseFailed("Invalid Schnorr signature length")),
Err(schnorr::SchnorrSigError::Secp256k1(..)) =>
Err(encode::Error::ParseFailed("Invalid Schnorr signature")),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could've been map_err which would communicate the intent a bit better. Only realized it now.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Issue: #793

@dr-orlovsky dr-orlovsky merged commit d5686ee into rust-bitcoin:master Jan 17, 2022
Taproot automation moved this from Ready for merge to Done Jan 17, 2022
PSBT automation moved this from Ready for merge to Done Jan 17, 2022
apoelstra added a commit that referenced this pull request Jan 18, 2022
1b2dbd7 0.28.0-rc.1 release (Dr Maxim Orlovsky)

Pull request description:

  We still have quite a few issues and PRs pending to be addressed/merged before full 0.28 release: see https://github.com/rust-bitcoin/rust-bitcoin/milestone/10

  Most important, we have to find a way to address #777; additionally it will be desirable to get #587, #786, #776.

  We also have quite of work to write CHANGELOG in #785

  Nevertheless I propose to start with a `beta-1` subrelease to unlock ability for `miniscript` release and downstream testing. The Taproot API looks final, and the pending PRs are addresses internal issues/bugs which is perfectly fine for beta releases.

ACKs for top commit:
  Kixunil:
    ACK 1b2dbd7

Tree-SHA512: a7bd6dd3e7a489f7fd758fb0d7a60103bfe0cdf88997b2163f163841fa1c12e7b31fa8f03b9f817a671379578dbc10a2ca583f49b64d2d2de4a9ebb57b2b9bd5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug code quality Makes code easier to understand and less likely to lead to problems one ack PRs that have one ACK, so one more can progress them
Projects
PSBT
Done
Development

Successfully merging this pull request may close these issues.

None yet

4 participants