Standardness and policy

Wonder

1. Why does a valid transaction sometimes get rejected by a wallet before it ever reaches a miner?
2. What happens if a counterparty runs different software than you do, but both are ‘correct’?
3. How can keeping unused opcodes off the relay path protect future upgrades?

Explore

1. Consensus rules define validity; they determine what may appear in a block and be accepted by every node. Standardness is a separate, local policy that dictates which transactions a specific node relays to its peers and keeps in its memory pool. A transaction can be perfectly valid under consensus yet non-standard according to default relay policies. When a user broadcasts such a transaction, their own node may discard it immediately, even though miners could technically include it.
2. Standard output types are strictly limited to protect nodes from denial-of-service attacks and resource exhaustion. These include P2PKH, P2SH, P2WPKH, P2WSH, P2TR, small bare multisig scripts (up to three keys), and OP_RETURN data outputs of a specific size. Scripts using reserved or unknown opcodes, or exceeding size limits, are not relayed by default. This filtering ensures the mempool remains manageable and prevents malicious actors from flooding the network with complex, computationally expensive garbage.
3. Policy is not static; it evolves per node implementation. In 2025, Bitcoin Core developers decided to relax the default size limit on OP_RETURN data outputs. This change sparked debate among node operators, some of whom opposed the expansion and switched to alternative software like Bitcoin Knots to maintain stricter legacy limits. This divergence illustrates that standardness is a local setting: two nodes running different versions or forks can relay different subsets of valid transactions without violating consensus.
4. A non-standard but valid transaction can still be confirmed if it bypasses the default relay network entirely. Miners have offered direct submission services, allowing users to send transactions straight into their blocks regardless of node policy. If a wallet relies on standardness rejection for security—assuming an invalid-looking script will never propagate—it faces a risk: a counterparty using direct miner access could confirm that transaction. This creates a fork in behavior, not truth, potentially leading to unexpected fund movements or loss.
5. Standardness acts as a safety valve for future soft-fork upgrades. By enforcing stricter rules now—such as treating reserved upgradable NOP opcodes as non-standard during relay—the protocol ensures a smooth transition when an upgrade tightens consensus rules. Because transactions that use the reserved opcodes are not relayed or mined by default, few or none exist when a soft fork gives those opcodes meaning, so the new rules invalidate nothing that people were relying on, and un-upgraded miners are unlikely to mine a block the new rules reject.
6. Read the policy checks yourself: in Bitcoin Core’s source, policy/policy.cpp contains IsStandard and IsStandardTx, which list the accepted output types and size limits; Bitcoin Optech’s ‘Waiting for confirmation’ series explains the reasoning behind them. Compare them with the consensus rules in validation code, and note how much narrower the relay rules are.

Key facts

Exercise nine, six, three, one

Fact check

Dates, figures and claims checked against the published sources listed below.

• Bitcoin Core source code, policy/policy.cpp
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023)
• Bitcoin Optech, 'Waiting for confirmation' series (2023)