SigHashType: add a method to error on non-standard hashtypes by darosior · Pull Request #573 · rust-bitcoin/rust-bitcoin

darosior · 2021-02-18T21:13:08Z

Right now, any sighash type could be parsed without error, which matches
consensus rules. However most of them would be invalid by standardness,
so it's a bit footgun-y (even more so for pre-signed transactions
protocols for which standardness is critical).

This adds from_u32_standard(), which takes care to error if we are
passed an invalid-by-current-policy-rules SIGHASH type.

(Happy to bikeshed the method name)

Super nit, but a hashtype is not specific to a transaction but a signature. Signed-off-by: Antoine Poinsot <darosior@protonmail.com>

sgeisler

concept ACK

src/blockdata/transaction.rs

sanket1729

We should note that this being applicable only to pre-tapscript ECDSA signatures and not for Schnorr Sigs. This can also be addressed when we actually implement Taproot into rust-bitcoin.

src/blockdata/transaction.rs

darosior · 2021-02-18T21:56:38Z

We should note that this being applicable only to pre-tapscript ECDSA signatures and not for Schnorr Sigs

Yes, as these rules actually become Consensus rules with BIP341.

sanket1729 · 2021-02-18T22:01:48Z

I think we may be mixing two things here. The sighash appears in two contexts when dealing with bitcoin transactions.

It is serialized as 4 bytes u32 when used as a signature message in the ECDSA sig algorithm
It is appended as a single byte when it is appended to the ECDSA sig to form a bitcoin signature.

I think what we want is SighashType from u8?

darosior · 2021-02-18T22:05:30Z

I think what we want is SighashType from u8?

I believe so (see #rust-bitcoin), but it's a bit of a mess on bitcoind itself:

You can't have a >1byte SIGHASH type
But it's then treated as a signed integer
It's also serialized as an int32_t in the sighash

I believe @apoelstra wanted to mimic Bitcoin-Core behaviour in 38b2cac

Signed-off-by: Antoine Poinsot <darosior@protonmail.com> Co-Authored-by: sanket1729 <sanket1729@gmail.com>

darosior · 2021-02-18T23:34:19Z

Ok, i think i either responded or adressed all the review comments. Thanks everyone!

Added another documentation commit after a nice deep dive with @sanket1729 about the rationale of masking with 0x9f. This was apparently meant to be an extension mechanism in a precedent era of Bitcoin, at least from what we could get off the source code fossils :)

sanket1729

tACk 196030b445e18104b51ec51d2e6a07f04f6e323a. Left a minor nit about adding Hash

src/blockdata/transaction.rs

Right now, any sighash type could be parsed without error, which matches consensus rules. However most of them would be invalid by standardness, so it's a bit footgun-y (even more so for pre-signed transactions protocols for which standardness is critical). This adds `from_u32_standard()`, which takes care to error if we are passed an invalid-by-current-policy-rules SIGHASH type. Signed-off-by: Antoine Poinsot <darosior@protonmail.com>

…sensus Signed-off-by: Antoine Poinsot <darosior@protonmail.com>

sgeisler

tACK e36f3a3

sgeisler · 2021-02-19T10:53:37Z

src/blockdata/transaction.rs

+             0x81 => Ok(SigHashType::AllPlusAnyoneCanPay),
+             0x82 => Ok(SigHashType::NonePlusAnyoneCanPay),
+             0x83 => Ok(SigHashType::SinglePlusAnyoneCanPay),
+             _ => Err(NonStandardSigHashType)


E.g. in the PSBT API we'd include the input that was considered invalid in the error, but I don't think we are consistent about it. It's probably the right thing to do for new code though. I'm sorry I only see this now.

sanket1729

tACK e36f3a3 .

This was challeging than adding a simple function :) , but it was good learning experience.

apoelstra

ack e36f3a3

doc: correct SigHashType doc comment

7f73d5f

Super nit, but a hashtype is not specific to a transaction but a signature. Signed-off-by: Antoine Poinsot <darosior@protonmail.com>

darosior mentioned this pull request Feb 18, 2021

Explicitly error on non-standard sighash types rust-bitcoin/rust-miniscript#233

Merged

sgeisler reviewed Feb 18, 2021

View reviewed changes

src/blockdata/transaction.rs Outdated Show resolved Hide resolved

src/blockdata/transaction.rs Outdated Show resolved Hide resolved

src/blockdata/transaction.rs Outdated Show resolved Hide resolved

src/blockdata/transaction.rs Outdated Show resolved Hide resolved

dpc reviewed Feb 18, 2021

View reviewed changes

src/blockdata/transaction.rs Outdated Show resolved Hide resolved

sanket1729 reviewed Feb 18, 2021

View reviewed changes

src/blockdata/transaction.rs Outdated Show resolved Hide resolved

src/blockdata/transaction.rs Outdated Show resolved Hide resolved

transaction: document why we mask sighash types with 0x9f

466f161

Signed-off-by: Antoine Poinsot <darosior@protonmail.com> Co-Authored-by: sanket1729 <sanket1729@gmail.com>

darosior force-pushed the standard_sighash branch from 2db2b49 to 196030b Compare February 18, 2021 23:30

sanket1729 reviewed Feb 18, 2021

View reviewed changes

src/blockdata/transaction.rs Outdated Show resolved Hide resolved

darosior force-pushed the standard_sighash branch from 196030b to fe66d3b Compare February 18, 2021 23:47

sanket1729 reviewed Feb 19, 2021

View reviewed changes

src/blockdata/transaction.rs Outdated Show resolved Hide resolved

darosior force-pushed the standard_sighash branch from fe66d3b to bf98d9f Compare February 19, 2021 10:12

transaction: deprecate SigHashType::from_u32 in favor of from_u32_con…

e36f3a3

…sensus Signed-off-by: Antoine Poinsot <darosior@protonmail.com>

darosior force-pushed the standard_sighash branch from bc6f54f to e36f3a3 Compare February 19, 2021 10:37

sgeisler added this to the 0.26.1 milestone Feb 19, 2021

sgeisler approved these changes Feb 19, 2021

View reviewed changes

sanket1729 approved these changes Feb 19, 2021

View reviewed changes

apoelstra approved these changes Feb 21, 2021

View reviewed changes

apoelstra merged commit 2414c5b into rust-bitcoin:master Feb 21, 2021

darosior deleted the standard_sighash branch February 21, 2021 15:35

Conversation

darosior commented Feb 18, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sgeisler left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

sanket1729 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

darosior commented Feb 18, 2021

Uh oh!

sanket1729 commented Feb 18, 2021

Uh oh!

darosior commented Feb 18, 2021

Uh oh!

darosior commented Feb 18, 2021

Uh oh!

sanket1729 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

sgeisler left a comment

Choose a reason for hiding this comment

Uh oh!

sgeisler Feb 19, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sanket1729 left a comment

Choose a reason for hiding this comment

Uh oh!

apoelstra left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

darosior commented Feb 18, 2021 •

edited

Loading

sgeisler Feb 19, 2021 •

edited

Loading