The six taproot input fields say "Finalizers should remove this field
after PSBT_IN_FINAL_SCRIPTWITNESS is constructed", and so does the
output field PSBT_OUT_TAP_BIP32_DERIVATION. An output has no
PSBT_IN_FINAL_SCRIPTWITNESS, the clause names no input, and its two
neighbours in the output table carry no such clause. Drop it; Bitcoin
Core does not clear output fields on finalization.
BIP 174 tells the Input Finalizer to clear all other data except the
UTXO and unknown fields from a finalized input. It was written when the
unsigned transaction was a global field. PSBTv2 moves the data that
defines the input into the input map, and a finalizer that follows the
sentence literally removes it: without PSBT_IN_PREVIOUS_TXID or
PSBT_IN_OUTPUT_INDEX the result is invalid, and without
PSBT_IN_SEQUENCE and the locktime fields the Transaction Extractor
builds a different transaction.
BIP 370 amends Creator, Updater, Signer and Transaction Extractor for
PSBTv2, adds the Constructor, and says nothing about the Input
Finalizer. Add the section: the five fields are kept. Bitcoin Core
does this today: at 19b0ff2fa0, PSBTInput::Serialize in src/psbt.h
writes them for every PSBTv2 input, finalized or not.
create_outputs and scanning declare expected with a default of None but
dereference it unconditionally (expected.get(...)), so calling either
without it raises AttributeError, although the parameter is documented
optional. Guard the expected-value checks with `if expected is not None:`.
The self-test, which always passes expected, is unaffected.
The self-test reads time.clock_gettime_ns(time.CLOCK_MONOTONIC) for
extra_in on even iterations. CPython documents both symbols
"Availability: Unix", so the attribute lookup raises AttributeError on
Windows and python3 reference.py does not run there.
Take extra_in from secrets instead, at a random length, so the self-test
also exercises extra_in of varying length. time has no other use in the
file, so its import goes too.
The base58 example address has an intentionally invalid checksum, but
the bech32 and bech32m examples added later have valid checksums, so
they are spendable addresses that a reader may pay by accident -- the
very hazard that motivated the invalid base58 address in #119. Two of
them are mainnet:
bc1qufgy354j3kmvuch987xe4s40836x3h0lg8f5n2 (bech32, witness v0)
bc1p5swkugezn...vep9m4p7339x5qzyrh4g (bech32m, witness v1)
tb1qghfhmd4zh7ncpmxl3qzhmq566jk8ckq4gafnmg (bech32, testnet)
Alter the final checksum character of each, and document the intent
with the note BIP 21 received in #1861. Bech32 detects any
single-character substitution, so the modified strings cannot be valid
addresses. The human-readable part, charset and length are unchanged,
so the examples remain structurally representative of P2WPKH and P2TR.
The uppercase QR-code variants are updated to match, and the changed
testnet address in the "Invalid URIs" section still demonstrates the
same point (a `tb` address in the `bc` parameter).
Alternative to #2228, which leaves the addresses untouched and instead
words the note to match them.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ferdinando Ametrano
