8000 Check for SIGHASH_SINGLE bug in writer fn by tcharding · Pull Request #897 · rust-bitcoin/rust-bitcoin · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Check for SIGHASH_SINGLE bug in writer fn #897

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

Merged

Conversation

tcharding
Copy link
Member
@tcharding tcharding commented Mar 21, 2022

Recently we moved the logic for checking for the SIGHASH_SINGLE bug to
the signature_hash() function. Although this left users of the
encode_signing_data_to() function without correct handling of the bug
there is not much else we can do but alert users to this behaviour.

Add documentation to highlight the behaviour of encdoe_signing_data_to
in regards to the sighash single bug. Requires updating docs for
signature_hash also.

Please note, uses non-conventional markdown header # Warning.

Closes: #817

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.

Are we sure that the right way here is to error and not panic?

@dr-orlovsky dr-orlovsky added this to the 0.28.0 milestone Mar 22, 2022
@apoelstra
Copy link
Member

On further reflection I think we should just document that this function does the wrong thing with the SIGHASH_SINGLE bug, and that if the user intends to care about this, they should either call signature_hash or write their own logic.

Changing an infallible function to a fallible one, without changing the type signature, seems like a bad change to make to the library.

@elichai
Copy link
Member
elichai commented Mar 22, 2022

I might've asked this already on IRC and I don't remember the answer.
What's the use case of calling encode_signing_data_to and not signature_hash?
if there's no real use case then the best solution IMHO is to make this function private

@apoelstra
Copy link
Member

I think the original author #485 just made it public and nobody noticed or complained. I don't remember explicitly thinking about this ever.

@RCasatta
Copy link
Collaborator

Author of #485 needed for implementing logic in the HSM, see #483

@apoelstra
Copy link
Member
apoelstra commented Mar 22, 2022

Ah, great, thanks for finding this.

So -- if we added an error case, and the author has .expect()ed the output of this function, in theory this could result in his HSM being crashable from the outside, by a user providing a transaction that tries to use the SIGHASH_SINGLE bug. Contrast that with the current behavior where the HSM will harmlessly sign a bad sighash.

So I think we should just document "does the wrong thing given the sighash single bug". Maybe we should even make this explicit, by feeding b"[not a transaction] SIGHASH_SINGLE bug" into the writer or something.

@tcharding tcharding force-pushed the handle-sighash-single-bug-in-writer branch from 27a5818 to 63d689c Compare March 23, 2022 01:48
@tcharding
Copy link
Member Author

Total re-write of PR including update of PR description. I built the docs and they look ok to me but please not the Warning heading is non-conventional.

Recently we moved the logic for checking for the SIGHASH_SINGLE bug to
the `signature_hash()` function. Although this left users of the
`encode_signing_data_to()` function without correct handling of the bug
there is not much else we can do but alert users to this behaviour.

Add documentation to highlight the behaviour of `encdoe_signing_data_to`
in regards to the sighash single bug. Requires updating docs for
`signature_hash` also.

Please note, uses non-conventional markdown header `# Warning`.
@tcharding tcharding force-pushed the handle-sighash-single-bug-in-writer branch from 63d689c to 83dda74 Compare March 24, 2022 00:40
Copy link
Member
@sanket1729 sanket1729 left a comment

Choose a reason for hiding this comment

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

ACK 83dda74. This is much cleaner

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 83dda74

Not merging: waiting for @apoelstra approval as well, since he was the main person addressing this issue in the previous PR version and elsewhere

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 83dda74

Thank you for waiting for me!

@apoelstra apoelstra merged commit 734b1de into rust-bitcoin:master Mar 26, 2022
@tcharding tcharding deleted the handle-sighash-single-bug-in-writer branch March 28, 2022 00:41
@apoelstra apoelstra mentioned this pull request May 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Encoding a TX with the SIGHASH_SINGLE bug
6 participants
0