BIP346: reject truncated long-form TxFieldSelectors #2327

Description

The BIP-346 reference implementation in bip-0346/ref-impl accepts truncated long-form TxFieldSelectors.

calculate_txhash parsed the global byte and the input/output-fields byte, then treated the input and output selection bytes as optional: when absent it defaulted to an empty selection (NONE). As a result:

• a 2-byte selector [global, fields] was silently treated as input=NONE, output=NONE
• a 3-byte selector [global, fields, input-selector] was silently treated as output=NONE

This invents NONE semantics the spec does not define. bip-0346.md states ("For both inputs and then outputs, expect an additional byte") that both selection bytes belong to the long form, and the OP_TXHASH precondition requires the TxFieldSelector to be valid, failing otherwise.

Change

Make the input and output selection bytes mandatory in calculate_txhash, returning an error when they are missing. The generated test vectors (txhash_vectors.json) and the vector generator were updated to use explicit 4-byte long-form selectors; all 150 txhash values are unchanged.

Test plan

• Added reject_truncated_long_form_txfs regression test (2-byte and 3-byte selectors are rejected; an explicit 4-byte NONE/NONE selector is accepted).
• cargo test passes; cargo run regenerates the vectors with identical hashes.

The description says all 150 txhash values are unchanged, but 60 of them change. They are the vectors whose selector gets padded (8000 becomes 80000000) and has TXFS_CONTROL (0x80) set, since that bit commits the selector bytes to the hash. The code is consistent: cargo run regenerates this PR's file byte for byte.

The PR also rejects 2- and 3-byte selectors, which were accepted until now. That changes which selectors are valid, so I think the BIP authors should confirm it.