The whitepaper describes nodes validating transactions and blocks before extending the proof-of-work chain.
Consensus & securitySourced answer
Can nodes reject a longer proof-of-work chain and still claim Bitcoin rules?
“Honest nodes follow the longest proof-of-work chain. Rejecting a reorganization because it is called dishonest replaces consensus with authority.”
Answer with conditions · Updated 2026-10-05 · Next review 2026-11-05
By BSV.place / Project Babbage. Editorial review; source access dates below. No independent product retest is implied.
Short answer
The short answer
Block production, independent verification and economic acceptance are different jobs. A non-miner can check and refuse a result; it cannot produce replacement blocks or force everyone else to agree. Credible, coordinated rejection can reduce a profit-seeking attack’s payoff, conditional on enforcement, compatible settlement policies and continued accepted mining. The current BSV rules also assign institutional directive powers that need separate scrutiny.
Mechanism and practical meaning
Production, verification and acceptance work together
A non-mining verifier can check evidence and refuse a payment without producing blocks. A business can delegate checking to a wallet or service while depending on its policies. Miners still supply work and continuing blocks. Successful settlement needs the relevant participants to apply compatible policies.
Our economic argument is conditional: if effective rejection denies the targeted payoff and recognition of attack-branch rewards in the target economy, accepted mining can be more attractive. Local refusal does not compel others. Sustained sabotage, outside incentives, disagreements and interrupted production remain material.
SV Node’s protective mechanisms and the Association’s published directives document possible responses, not guaranteed convergence. Judge honesty by identifiable rules and conduct, not agreement with a preferred conclusion.
What is true
The objection's strongest ground
- The whitepaper's node steps require transactions and blocks to be valid before proof-of-work ordering matters.
- BSV's published rules add an explicit legal and institutional layer to node conduct.
- A post-hoc label is not a usable security control; detection thresholds, authority, communications, and recovery behavior must be known in advance.
What remains unresolved
Do not claim more than the evidence
- This brief does not determine whether a particular historical reorganization contained invalid transactions or breached a contract.
- Following more work alone does not solve eclipse attacks, double-spend exposure, or application confirmation policy.
Inspect it yourself
What to inspect next
- Compare whitepaper steps 1–6 with the node's current chain-selection code and configuration.
- Read which NAR events can lead to block invalidation and who may issue the directive.
- For every historical incident, publish block hashes, chainwork, invalidity claim, decision authority, timing, and operator action.
Open to better evidence
What would change this answer?
Clear ex-ante rules, public incident data, and independently reproducible node behavior would reduce ambiguity. Secret, retroactive, or inconsistently applied rules would make the criticism stronger.
Evidence behind the answer
What the cited sources establish
The current NAR permits directives that can include invalidating specified blocks after defined events.
Source desk
Read the underlying material
PrimaryBitcoin: A Peer-to-Peer Electronic Cash SystemThe original paper; read its proof-of-work, incentives, privacy, and SPV claims in their own terms.Satoshi Nakamoto · Source access 2026-10-05PrimaryNetwork Access Rules — Part III, Enforcement RulesDirective events, restrictions, and permitted steps including freezes, reassignment, peer controls, and block invalidation.BSV Association · Source access 2026-10-05PrimaryBSV Alert System documentationTechnical description of signed informational and directive messages delivered to nodes.BSV Association · Source access 2026-10-05PrimarySV Node configuration referenceCurrent operator-facing configuration surface, including chain and policy controls.BSV Association · Source access 2026-10-05