BIP 115 Anti-Replay Script: Closed Proposal Explained

This guide explains BIP 115 anti-replay protection in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.

The replay problem

When two chains share transaction and script history, a valid spend on one may also be valid on the other. Users can unintentionally move assets on both. Replay protection introduces a chain-specific condition, but coordination, wallet labelling and adversarial transaction handling remain operational requirements.

Proposed opcode inputs

The stack provided a block height and a truncated block-hash value. The opcode checked that the active chain contained the matching block at that height, subject to encoding and depth rules. Minimal numeric encoding and maximum hash length were consensus-critical rejection conditions.

Depth boundary

The proposal only enforced commitments within 52,596 blocks of the spending context; deeper and negative values completed as a no-op under its defined rule. This bounded historical lookup but creates a sharp semantic boundary. Tests must cover exact depth edges and reorganisation effects.

Soft-fork deployment model

Reinterpreting a NOP can be a soft fork because older nodes treat it as no operation while upgraded nodes impose the extra condition. Activation would still require a defined coordination mechanism. Writing the BIP did not activate the rule, and an old node accepting a block would not prove upgraded validity.

Hash truncation and chain identity

Allowing up to 28 bytes balanced script size with collision resistance for the intended use. The commitment identified a particular chain history, not a brand, ticker or network name. Wallet interfaces would need to show which anchor and confirmation depth they were enforcing.

Closed status and safety

BIP 115 was not deployed. Experimental parsers belong on isolated networks, and wallets should reject or clearly quarantine unknown script assumptions. A bilateral agreement cannot make a consensus opcode active for Bitcoin or guarantee miners will enforce it.

Operational lessons

Replay protection should be designed before a split, use unambiguous chain context, define reorganisation and expiry behaviour, and be supported across wallets, signers, explorers and exchanges. Confirmation policy alone does not stop replay of an otherwise identical transaction. Build a version-pinned evidence pack on an isolated node.

Conclusion

BIP 115 is a closed historical proposal for script-level chain anchoring. Its useful lesson is that replay protection needs deployed consensus semantics and complete operational support, not merely a transaction label.