Skip to content

Conversation

theuni
Copy link
Member

@theuni theuni commented Sep 15, 2022

This is intended to be a safer way for functions to accept only a subset of sigversion values.

It's intended to solve the uninitialized value warning seen here: #25972 (comment)

Now that all possible values in the enum class are tested, there's no need for a default case and thus the compiler should be able to deduce that there's no way for this value to be used uninitialized.

Sadly it's not possible to do any type of inheritance with an enum class, so instead it's faked by using std::underlying_type_t<SigVersion>, which should ensure that it's in sync with SigVersion even if it changes in the future.

Imo this is safe enough that there's no need for a default case as suggested here: #25972 (comment) , but that's up for discussion here.

The second commit is simply a cleanup that removes the need to pass a sigversion to EvalChecksigTapscript because it's only intended to ever be used with... tapscript.

@theuni
Copy link
Member Author

theuni commented Sep 15, 2022

ping @sipa . Curious if you dislike this as it ties these functions to this subset of sigversions, though it could easily be ranamed/expanded later to mean "non-v0" if necessary.

@theuni
Copy link
Member Author

theuni commented Sep 15, 2022

Whoops, apparently I missed a few cases. Converting to draft for now.

Concept ACKs/NACKs welcome.

@theuni theuni marked this pull request as draft September 15, 2022 15:46
Some functions only accept a subset of script versions, leaving them with
undefined behavior when called with v0 scripts. Instead, define a type that
is a subset of ScriptVersion and use it when applicable.
@theuni theuni force-pushed the explicit-v1-scriptver branch from 58c08d7 to 0ba2daa Compare September 15, 2022 19:57
@theuni theuni marked this pull request as ready for review September 16, 2022 12:28
@theuni
Copy link
Member Author

theuni commented Sep 16, 2022

Fixed up now.

Ironically this doesn't actually eliminate the warning as I'd hoped. I will leave this open in case anyone finds it interesting, but no need to think of it in terms of #25972 (comment).

@DrahtBot
Copy link
Contributor

DrahtBot commented Sep 17, 2022

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #24149 (Signing support for Miniscript Descriptors by darosior)
  • #23502 (wallet: Avoid underpaying transaction fees when signing taproot spends by achow101)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

@DrahtBot
Copy link
Contributor

🐙 This pull request conflicts with the target branch and needs rebase.

@achow101 achow101 closed this Apr 25, 2023
@bitcoin bitcoin locked and limited conversation to collaborators Apr 24, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants