What happened
On 17 August 2026,
pull request #2253 was merged into Bitcoin's
proposal repository, correcting the reference validator for
BIP-375, the draft
specification for sending
silent payments with
PSBTs. The validator had
been treating any output script whose first byte falls between OP_2 and OP_16 as a SegWit
version 2 or later output. Most scripts that begin with those bytes are nothing of the kind.
What it changes
Silent payments let a receiver publish one static address that never appears on chain: the sender derives a fresh output from it using a shared secret computed from the transaction's own inputs. Because the recipient has to find those payments by scanning, BIP-352 restricts which transactions are in scope. One condition is that the transaction "does not spend an output with SegWit version > 1", and the specification is explicit about why: skipping unknown output scripts "allows us to have a clean upgrade path for silent payments by avoiding the need to scan the same transaction multiple times with different rule sets."
The cost of getting this wrong falls on the receiver, who has no say in it. A sender who includes an input the rule excludes produces a payment that the recipient's wallet, or the index server it relies on, will simply never look at. BIP-375 carries the restriction into the signing flow so it fails early: "If any input is spending an output with script using Segwit version > 1, the Signer must fail."
Recognising such an input is where the validator was wrong. It asked whether the first byte
of the script was OP_2 or higher. A
witness program is not a
byte, it is a shape: a version opcode followed by a single direct push of 2 to 40 bytes, and
nothing after it. The
replacement
checks the shape, requiring the total length to be 4 to 42 bytes and the second byte to equal
the length of what remains. A bare OP_2 is an ordinary script that pushes the number two,
and the pull request adds a test vector saying exactly that.
What it does not change
This is a reference validator for a draft specification, not a consensus rule and not a released wallet. Nothing on the network behaved differently on 17 August, and whether any shipping implementation copied the same shortcut is a question the pull request does not answer.
The restriction itself stands, and it is the part with a real cost: coins sitting in a future witness version cannot be spent into a silent payment under the current rules, by design, and that is a limitation the sender absorbs so the receiver's scan stays cheap.
It is also worth naming which direction the bug failed in. The old check refused things it should have allowed, not the reverse. A validator that wrongly rejects a valid PSBT is a bug; one that wrongly accepts an invalid one is a different and worse kind of bug.
Context
Every piece of Bitcoin software has to decide what to do with a script it does not recognise, because a soft fork's whole method is to give new meaning to patterns that older software treats as unconstrained. Writing that decision as a range check on the first byte is the shortcut that ages badly, and it does so precisely when the upgrade it anticipated arrives. The proposal repository has had a busy fortnight: this is the same stretch in which BIP-85 gained a Nostr application and BIP-89 advanced to Deployed.