Taproot semantics unenforced for signet challenges #36162

Probably should be activated for custom signets

diff --git a/src/signet.cpp b/src/signet.cpp
index 87e9f79c27..d9d263ebad 100644
--- a/src/signet.cpp
+++ b/src/signet.cpp
@@ -27,7 +27,7 @@
 
 static constexpr uint8_t SIGNET_HEADER[4] = {0xec, 0xc7, 0xda, 0xa2};
 
-static constexpr script_verify_flags BLOCK_SCRIPT_VERIFY_FLAGS = SCRIPT_VERIFY_P2SH | SCRIPT_VERIFY_WITNESS | SCRIPT_VERIFY_DERSIG | SCRIPT_VERIFY_NULLDUMMY;
+static constexpr script_verify_flags BLOCK_SCRIPT_VERIFY_FLAGS = SCRIPT_VERIFY_P2SH | SCRIPT_VERIFY_WITNESS | SCRIPT_VERIFY_TAPROOT | SCRIPT_VERIFY_DERSIG | SCRIPT_VERIFY_NULLDUMMY;
 
 static bool FetchAndClearCommitmentSection(const std::span<const uint8_t> header, CScript& witness_commitment, std::vector<uint8_t>& result)
 {

diff --git a/src/test/validation_tests.cpp b/src/test/validation_tests.cpp
--- a/src/test/validation_tests.cpp
+++ b/src/test/validation_tests.cpp
@@ -96,6 +96,14 @@ BOOST_AUTO_TEST_CASE(signet_parse_tests)
     block.vtx.at(0) = MakeTransactionRef(cb);
     BOOST_CHECK(SignetTxs::Create(block, challenge));
     BOOST_CHECK(CheckSignetBlockSolution(block, signet_params->GetConsensus()));
+
+    // A Taproot challenge must not be treated as an unknown, anyone-can-spend
+    // witness version when no solution is provided.
+    CScript taproot_challenge{OP_1};
+    taproot_challenge << std::vector<uint8_t>(32, 0x42);
+    auto taproot_params = signet_params->GetConsensus();
+    taproot_params.signet_challenge.assign(taproot_challenge.begin(), taproot_challenge.end());
+    BOOST_CHECK(!CheckSignetBlockSolution(block, taproot_params));
 
     // no data after header, valid
     std::vector<uint8_t> witness_commitment_section_325{0xec, 0xc7, 0xda, 0xa2};

cc @ajtowns

This is a soft-fork for signet, so should probably be accompanied by an update to BIP 325, even if the current spec isn't very detailed on the subject. I think the only benefit to having a taproot challenge today is it allows use of BIP340 signatures and the potential for musig/frost.

seems hard to "get wrong" except a custom signet accidentally being no-op challenge. Could also just guard against such a misconfig 🤷

i'm interested in fixing this, starting with the regression test to check the empty challenge case. is this moving forward with the BIP 325 update or the custom signet configuration for now?