Checkpoint security — limiting deep chain rewrites

An attacker can change their own software, but they cannot change the rules enforced by everyone else. Honest nodes independently inspect every block and reject one whose reward pays any address other than the pool-controlled address.

Hashpower does not make an invalid block valid. A miner producing wrong-address rewards creates a private fork that only their modified nodes recognize. The real risk begins only when their alternative blocks remain fully valid under TEXITcoin’s existing rules.

A miner can quietly build a different sequence of valid blocks. If that branch later has more accumulated work than the public branch, ordinary nodes switch to it automatically. Blocks removed by that switch are a chain reorganization, or reorg.

That can reverse the attacker’s recent payment to an exchange, delay selected transactions, or create disruption. It still cannot redirect block rewards: every accepted replacement block must obey the same pool-address rule.

Reaching the same block height is not enough. The alternative must exceed the public chain’s accumulated proof of work while the public chain continues growing. Rebuilding from genesis means reproducing years of work, not merely creating the same number of blocks.

Attackers therefore normally branch from a recent block. With more than half of active hashpower they can gain on the public chain; with less, catching up becomes less likely as confirmations accumulate. The realistic concern is recent payments and short reorgs, not silently recreating TEXITcoin’s entire history overnight.

A hard-coded checkpoint records a known block height and hash in a release. A node then refuses any competing history that does not contain that exact block. This makes history at and before the checkpoint final for nodes running that release.

• It blocks deep rewrites and alternate histories starting before the checkpoint.
• It protects new nodes while they download and verify older history.
• It does not stop a recent reorg after the checkpoint or replace confirmation policies.
• Every checkpoint must be selected from a widely agreed, deeply buried block.

Add one recent, deeply confirmed mainnet checkpoint to the normal checkpoint table and test that the release accepts the canonical chain while rejecting a mismatched block at that height. The exact height and hash are intentionally not chosen yet.

Before shipping, confirm the block independently from multiple owned nodes, publish the chosen height and hash with the release notes, and keep exchange confirmation requirements unchanged. Checkpoints reduce the blast radius; they do not make majority-hash attacks impossible.

Verified on node-omni using the combined build that also carries Send To Many and the smoother difficulty rule. A checkpoint was added at test-chain block 20, the node was restarted on the patched binary, and a rewrite of history below the checkpoint was attempted.

• The patched node restarted and accepted the existing 104-block chain unchanged.
• The rewrite attempt was refused: bad-fork-prior-to-checkpoint — “forked chain older than last checkpoint (height 15)”.
• No new blocks could be mined on the rewritten branch; the canonical chain was restored intact.

Conclusion: the existing checkpoint mechanism works as designed. The v0.26.0 change is only a new entry in the checkpoint table — no new consensus logic is required.