An earlier walkthrough of Bitcoin consensus changes separates specification, implementation, activation, and adoption. This post asks a narrower operational question: what evidence should a miner, node operator, exchange, custodian, wallet developer, or Lightning operator require before enabling production use of a newly active soft-fork feature?
Primary research question: What evidence threshold should each actor require before relying on a newly active rule in production?
The current answer is not a miner-signaling percentage, a public node count, or a list of organizations saying they are ready. Readiness belongs to a specific actor making a specific decision. That actor should be able to identify the active consensus state, reproduce the relevant workflow, detect a failure, and limit initial exposure.
A version bit is not a deployment certificate.
Signaling, lock-in, and enforcement are different states
Under the BIP9 state machine, signaling can move a deployment from STARTED to LOCKED_IN. The new consensus rules are enforced only when the deployment reaches ACTIVE.
That distinction matters because miners are encouraged to continue signaling during LOCKED_IN, but those signals have no effect on the consensus rules. A quiet lock-in period with no visible rule violation therefore does not prove that miners, wallets, exchanges, or other infrastructure are correctly enforcing or using the new rule.
BIP8 deployment parameters add minimum_activation_height and an optional lockinontimeout setting. When lockinontimeout is enabled, mandatory signaling can ensure transition to LOCKED_IN by the timeout height. When it is disabled, the deployment can instead fail at timeout. In either configuration, the new rule is enforced only after the deployment becomes ACTIVE.
The activation mechanism answers one question:
At which block do upgraded nodes begin applying the new consensus rule?
It does not answer another:
When should each business, wallet, miner, or Lightning implementation expose the affected feature to production funds?
Readiness must name the actor and the decision
The word “operators” is too vague for a useful go/no-go rule. Different participants control different systems and can pause different actions.
| Actor | Production decision | Evidence before enabling it | Stop or pause condition |
|---|---|---|---|
| Full-node operator | Upgrade and rely on the new rule for validation | Verified software release, correct deployment parameters, fully synchronized node, expected activation state, monitoring of chain tip and validation errors | Unexpected block rejection, persistent chain-tip disagreement, parameter mismatch, or implementation-specific validation failure |
| Miner or pool | Construct production blocks compatible with the active rule | Deployment-aware block-template system, upgraded failover infrastructure, proposal or candidate-block tests against independent validating nodes | Candidate template rejected by a trusted validator, incompatible fallback templates, or disagreement between production validation systems |
| Exchange or custodian | Enable deposits, withdrawals, accounting, or a new output type | Complete deposit and withdrawal cycle, script recognition, signing, fee handling, rescan behavior, accounting reconciliation, and documented recovery | Address or script mismatch, failed withdrawal, incomplete rescan, accounting divergence, or inability to reconstruct the wallet configuration |
| Wallet or hardware signer | Expose the new feature to users | Valid and invalid test vectors, accurate device display, signing tests, watch-only reconstruction, backup compatibility, and controlled restoration | Device display mismatch, signing disagreement, descriptor incompatibility, or restoration failure |
| Lightning operator | Use an affected commitment, close, fee-bump, or monitoring path | Controlled channel lifecycle tests, commitment-transaction handling, close-path testing, fee reserves, chain monitoring, backup behavior, and implementation-specific recovery | Failed force close, missed spend, stale channel-state handling, ineffective fee bump, or chain-monitor disagreement |
Bitcoin Core exposes deployment status through getdeploymentinfo. An operator can use it to verify whether a deployment is defined, started, locked_in, active, or failed at a particular chain tip.
That is useful protocol-state evidence. It is not evidence that an exchange can process withdrawals, that a hardware signer displays the new transaction correctly, or that a Lightning implementation can recover an affected close transaction.
Controlled testing should exercise the failure path
A readiness test should not merely demonstrate the happy path.
The Signet specification describes a network designed for longer-running integration tests involving multiple independent parties. A custom Signet or controlled regtest environment can deliberately produce valid and invalid cases without risking mainnet funds.
For consensus enforcement, a useful controlled test should include:
- A block or transaction that remains valid before activation.
- A boundary case at the activation transition.
- A case that violates the new rule after activation.
- Independent nodes agreeing on acceptance or rejection.
- A reorganization or restart during the test.
- Monitoring that records the expected rejection reason.
- The same test repeated against the exact production release.
The result provides evidence about the tested implementation and conditions. It does not prove that every untested implementation, wallet, miner, or service behaves correctly.
For wallet and custody systems, the relevant test includes more than producing one valid transaction. The recovery drill procedure shows why a working seed alone is insufficient when the system also depends on descriptors, derivation paths, signer information, watch-only data, or application-specific metadata.
If a newly activated feature creates a new script or output type, the operator should prove that the wallet can:
- create it;
- recognize it after a rescan;
- sign the intended spending path;
- reconstruct it from documented recovery material;
- display it correctly on the signing device;
- spend it after software restart or migration.
Consensus can work perfectly while a wallet loses the information needed to spend. The chain will not file a support ticket.
For Lightning systems, readiness depends on the exact transaction path affected by the rule. The channel close and fee constraints illustrate why a production test may need to cover force closes, timelocked outputs, fee reserves, monitoring, backups, and recovery behavior rather than only successful payments.
A change that does not touch those paths does not require invented Lightning concerns. A change that does touch them should be tested explicitly.
Silence on mainnet is weak evidence
Suppose a deployment becomes ACTIVE, and no rule-violating block appears for thirty days.
What has been established?
Only that no visible violation was observed.
It does not establish that:
- every signaling miner would reject an invalid candidate;
- every pool failover system uses the upgraded validator;
- every economically important node is enforcing;
- every wallet can use the feature safely;
- every exchange can recover from a failed integration;
- the relevant boundary condition was ever exercised.
Positive consensus-enforcement testing belongs in a controlled environment where a known-invalid candidate can be generated and independently rejected.
Deliberately producing an invalid mainnet block is not a sensible readiness test. Mainnet evidence is therefore layered and indirect:
- the deployment is
ACTIVE; - the production software contains the reviewed enforcement code;
- controlled invalid cases were rejected;
- mining templates were checked by upgraded validators;
- independent nodes remain on the same chain tip;
- no unexpected validation errors appear;
- real use begins with limited exposure;
- operational incidents remain within documented stop conditions.
A lack of incidents increases confidence over time. It does not convert absence of evidence into proof.
A practical six-gate rule
The first five gates should pass before limited production begins. Gate 6 should pass before exposure limits are removed.
1. State gate
The actor verifies the actual deployment state at the relevant chain tip.
For a BIP9-style deployment:
STARTED is not ready.
LOCKED_IN is not enforcement.
ACTIVE means upgraded nodes apply the new rules.
2. Implementation gate
The exact production release, configuration, activation parameters, and dependencies match the versions that were reviewed and tested.
A test against a development branch does not validate a different production binary.
3. Workflow gate
The actor reproduces the complete operation it intends to perform:
- mine a compatible candidate block;
- process a deposit and withdrawal;
- display and sign a transaction;
- rescan and reconstruct a wallet;
- close and recover a channel;
- detect and respond to the relevant failure.
The workflow should include at least one expected failure case.
4. Observability gate
The actor can detect when the assumption has failed.
That normally requires defined signals such as:
- deployment status;
- block rejection logs;
- chain-tip disagreement;
- failed signing or display checks;
- withdrawal errors;
- rescan discrepancies;
- monitoring gaps;
- failed close or fee-bump paths.
“Someone would probably notice” is not monitoring.
5. Exposure gate
Initial production use is deliberately limited.
That may mean:
- insignificant test funds;
- a restricted user cohort;
- disabled automatic rollout;
- capped deposits or withdrawals;
- a feature flag that can be turned off;
- a documented pause procedure.
A consensus rule cannot be rolled back by an exchange help desk. A product feature can still be paused before it creates a larger operational problem.
6. Graduation gate
Removing exposure limits requires evidence that the system survives stress, not just success. An operator should graduate to unrestricted use only after:
- Zero stop-condition events during the initial bounded window;
- Successful recovery drill proving funds can be reconstructed from documented backups under the new rules;
- Fixed observation window covering at least one difficulty adjustment and varied fee-rate conditions;
- Edge-case coverage where boundary conditions (reorgs, high fees, partial spends) were explicitly tested.
Unrestricted use is not a reward for uptime; it is a conclusion drawn from surviving the failure paths that limited exposure was designed to reveal.
What should be published as readiness evidence?
A useful public readiness statement should be specific enough for another operator to evaluate. At minimum, it could identify:
- actor and system;
- exact software version;
- deployment and activation parameters;
- production action being enabled;
- controlled tests completed;
- invalid cases tested;
- recovery or rollback procedure;
- monitoring signals;
- known untested conditions;
- initial exposure limit;
- date of the test.
A statement that says only “ready” contains no reproducible information.
Current conclusion
Miner signaling can help coordinate activation. It does not establish operational readiness.
ACTIVE establishes that an upgraded node applies the new consensus rule. It does not establish that every service layered above that node can safely use the affected feature.
The durable decision rule is actor-specific:
Enable production use only after the relevant deployment is active, the exact operational workflow has been reproduced, a concrete failure signal is monitored, and initial exposure is limited.
The unresolved part is how much evidence should be public and standardized.
What is the smallest reproducible evidence package that would let an independent operator verify readiness for one specific production action without relying on miner signaling or a self-reported “ready” flag?