Dubious cases in script_assets

bbrtj commented at 1:45 pm on November 8, 2025: none

I’m trying to use file script_assets_test.json mentioned in BIP341 to test my bitcoin software (not core). I am having trouble with some cases, especially those with comment inactive/*.

Some of the cases seem impossible even without trying to run them, like inactive/keypath_empty tests that have success cases with empty both scriptSig and witness. Others, like inactive/keypath_invalidsig I’m figuring out right now, only deliver success cases (in contrary to their comment), and these cases don’t get verified successfully by my software (even though vast majority of the rest of the cases is), making me think these should be failure cases instead.

I’ve tried reading bitcoin core code to figure out if these cases will somehow get filtered out - I can’t find such condition, but I’m not that good at reading C++. I haven’t tried running them with bitcoin core since I don’t know much about it code-wise and don’t have everything set up to run it. Please let me know if these cases are wrong, or if they should in fact work as they are written.

maflcko commented at 8:57 am on November 10, 2025: contributor

I’ve tried reading bitcoin core code to figure out if these cases will somehow get filtered out - I can’t find such condition, but I’m not that good at reading C++.

The test vectors are generated in Python. See the test/functional/feature_taproot.py file and the function for some context:

 0def spenders_taproot_nonstandard():
 1    """Spenders for testing that post-activation Taproot rules may be nonstandard."""
 2
 3    spenders = []
 4    
 5    sec = generate_privkey()
 6    pub, _ = compute_xonly_pubkey(sec)
 7    scripts = [
 8        ("future_leaf", CScript([pub, OP_CHECKSIG]), 0xc2),
 9        ("op_success", CScript([pub, OP_CHECKSIG, OP_0, OP_IF, CScriptOp(0x50), OP_ENDIF])),
10    ]
11    tap = taproot_construct(pub, scripts)
12    
13    # Test that features like annex, leaf versions, or OP_SUCCESS are valid but non-standard
14    add_spender(spenders, "inactive/scriptpath_valid_unkleaf", key=sec, tap=tap, leaf="future_leaf", standard=False, inputs=[getter("sign")])
15    add_spender(spenders, "inactive/scriptpath_invalid_unkleaf", key=sec, tap=tap, leaf="future_leaf", standard=False, inputs=[getter("sign")], sighash=bitflipper(default_sighash))
16    add_spender(spenders, "inactive/scriptpath_valid_opsuccess", key=sec, tap=tap, leaf="op_success", standard=False, inputs=[getter("sign")])
17    add_spender(spenders, "inactive/scriptpath_valid_opsuccess", key=sec, tap=tap, leaf="op_success", standard=False, inputs=[getter("sign")], sighash=bitflipper(default_sighash))
18    
19    return spenders

bbrtj commented at 9:28 am on November 10, 2025: none

@maflcko thanks for pointing that out. The inactive tests you showed above are in fact valid and passed successfully by my software. At first glance, I can’t find the dubious tests inactive/keypath_empty, inactive/scriptpath_invalidsig and inactive/keypath_invalidsig generated in this file - these were the only test cases that I could not make pass. I will look a bit deeper into the file and its git history

maflcko commented at 9:40 am on November 10, 2025: contributor

I’ve removed those in commit cccc1e70b8a14430cc94143da97936a60d6c83d3. The main question is whether you want to enforce the script flags from genesis (with the single exception block), or want to start the script flags at some point when you consider the deployment active.

bbrtj commented at 9:55 am on November 10, 2025: none

Ah okay, so these tests were success cases before the taproot was deployed, correct? I see - probably the existence of TAPROOT flag controls whether the test should be tested using taproot rules (enabled after taproot deployment). It makes sense now, thanks.

bbrtj closed this on Nov 10, 2025

Dubious cases in script_assets_test.json #243