-
Notifications
You must be signed in to change notification settings - Fork 8
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
refactor: use SIGHASH_ALL
explicitly
#840
base: main
Are you sure you want to change the base?
Conversation
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.
Looks fine 👍
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.
LGTM, about whether we should make the change or not I am not sure: it is a relatively small increase in cost and we remove some potentially risky thing, but otoh I'm not sure what's the actual possibility of bitcoin lib changing this without a major release and big warnings all around.
Yeah, maybe we can have Asymmetric weigh in here? |
Description
This was discussed in #782, and came up as part of #798.
Changes
TapSighashType::All
, which maps toSIGHASH_ALL
. This makes the sighash type explicit, which appears to increase the transaction size by at least one byte.Before we used
TapSighashType::Default
, which isTapSighashType::All
already. But I have a preference for making the sighash type explicit, and unfortunately this preference has a cost of increasing the transaction size by one byte. Bitcoin usually doesn't change that much and changing the default here seems like a big change so maybe we can rely on the default behavior. If someone else has an opinion here, let me know.Testing Information
This is just a refactor, if tests pass then we're good.
Checklist: