Skip to content

Conversation

@dergoegge
Copy link
Member

The script_flags harness aims to test that our script verification flags are soft-forks (i.e. applying flags can only tighten the verification rules and not widen them). SigVersion::WITNESS_V0 and SigVersion::TAPSCRIPT scripts are currently not covered by this test, as fuzzers are blocked from e.g. creating a valid taproot script path spend commitment.

This PR:

  • Moves the taproot commitment and witness script hash checks to BaseSignatureChecker (real impl in GenericTransactionSignatureChecker)
  • Introduces a second script flags harness script_flags_mocked which uses a BaseSignatureChecker mock, unblocking fuzzers from reaching segwit v{0,1} interpreter code (as well as paths relating to valid signatures)

@DrahtBot
Copy link
Contributor

DrahtBot commented Dec 10, 2024

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

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/31460.

Reviews

See the guideline for information on the review process.

Type Reviewers
Concept ACK darosior

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #32080 (OP_CHECKCONTRACTVERIFY by bigspider)
  • #31989 (BIP-119 (OP_CHECKTEMPLATEVERIFY) (regtest only) by jamesob)
  • #31868 ([IBD] specialize block serialization by l0rinc)
  • #31519 (refactor: Use std::span over Span by maflcko)

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 DrahtBot added the Tests label Dec 10, 2024
@dergoegge dergoegge force-pushed the 2024-06-improve-script-tests branch from 54b6ec7 to ddec30a Compare December 10, 2024 15:03
@dergoegge
Copy link
Member Author

@reardencode @0xBEEFCAF3 @EthanHeilman Perhaps this is interesting for you all to review as it is relevant to testing your soft-fork proposals (i.e. #29247, #29269).

@bitcoin bitcoin deleted a comment from JoesSon72 Jan 7, 2025
Span<const unsigned char> program,
const CScript& exec_script) const
{
assert(program.size() >= uint256::size());
Copy link
Contributor

Choose a reason for hiding this comment

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

In 70ec9f2: Instead of asserting that the program size is greater or equal to uint256 size, could we assert that the program size is exactly the WITNESS_V0_SCRIPTHASH_SIZE?

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 mostly added that assertion to prevent a buffer overflow in the memcmp below, which won't happen as long as the program span is 32 bytes in size or larger.

I can see the value in asserting that program is an actually a v0 script hash (i.e. 32 bytes exactly). I'll consider changing it if I retouch.

@brunoerg
Copy link
Contributor

SigVersion::WITNESS_V0 and SigVersion::TAPSCRIPT scripts are currently not covered by this test, as fuzzers are blocked from e.g. creating a valid taproot script path spend commitment.

The same applies to signature_checker and eval_script harnesses?

@darosior
Copy link
Member

An alternative to touching consensus code to test this is to fuzz EvalScript directly. We already have a target for it, eval_script. It could be adapted to also be ran under a Tapscript context by filling dummy ScriptExecutionData, and the soft fork check could be added to this target. The downside of this approach is that it would not cover the VerifyScript logic, but in the context of making sure proposed opcodes are indeed soft forks what we really care about it EvalScript.

@dergoegge
Copy link
Member Author

We already have a target for it, eval_script. It could be adapted...

Yes that would be an alternative to some extend but I want to keep this test to VerifyScript as that function uses the flags as well.

The same applies to signature_checker and eval_script harnesses?

That is possible but I would consider that out of scope for this PR.

@EthanHeilman
Copy link
Contributor

@dergoegge This PR encouraged me to break the unit testing improvements I made to the Tapscript unit tests out the OP_CAT PR and into their own PR here: #31640

Copy link
Member

@darosior darosior left a comment

Choose a reason for hiding this comment

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

Concept ACK.

Comment on lines +38 to +40
FuzzedSignatureChecker(const CTransaction* tx, unsigned int in,
const CAmount& amount, const PrecomputedTransactionData& tx_data,
MissingDataBehavior mdb) {}
Copy link
Member

Choose a reason for hiding this comment

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

This seems unnecessary, none of that is used.

SigVersion sig_version, ScriptExecutionData& exec_data,
ScriptError* script_error = nullptr) const override
{
uint64_t fuzz_hash{HashSig(sig)};
Copy link
Member

Choose a reason for hiding this comment

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

What does hashing adds here? If you need more than one bit why not take it out of sig directly (and have a default value if it's too small)?

}
bool CheckLockTime(const CScriptNum& lock_time) const override
{
return HashScriptNum(lock_time);
Copy link
Member

Choose a reason for hiding this comment

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

Same here, you could just variate based on the value itself?

@DrahtBot
Copy link
Contributor

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

@dergoegge dergoegge marked this pull request as draft April 24, 2025 09:32
@DrahtBot
Copy link
Contributor

⌛ There hasn't been much activity lately and the patch still needs rebase. What is the status here?

  • Is it still relevant? ➡️ Please solve the conflicts to make it ready for review and to ensure the CI passes.
  • Is it no longer relevant? ➡️ Please close.
  • Did the author lose interest or time to work on this? ➡️ Please close it and mark it 'Up for grabs' with the label, so that it can be picked up in the future.

1 similar comment
@DrahtBot
Copy link
Contributor

⌛ There hasn't been much activity lately and the patch still needs rebase. What is the status here?

  • Is it still relevant? ➡️ Please solve the conflicts to make it ready for review and to ensure the CI passes.
  • Is it no longer relevant? ➡️ Please close.
  • Did the author lose interest or time to work on this? ➡️ Please close it and mark it 'Up for grabs' with the label, so that it can be picked up in the future.

@dergoegge
Copy link
Member Author

Can be marked up for grabs. Happy to review!

@dergoegge dergoegge closed this Aug 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants