The release pin
You are looking at an old version of this page: revision #65 by zoobc.how, 2026-10-26 20:39 UTC. See the current version
A ZooBC release can ship a spine pin: a small public file that names one block of the spine chain by its height and hash. At start-up a node compares its own spine with the pin and refuses to run on a spine that contradicts it. The pin gives every installation one trusted anchor that comes with the software itself, so a forged spine history is refused before the node builds anything on it.
Why a pin helps
The spine is the anchor a node trusts for two things: which snapshot of the chain's state to load, and which node keys belong to the registry (see snapshots and fast sync). A running node that has followed the chain for months has its own history to judge the spine by. A brand-new installation has none. It must start from somewhere, and an attacker who could feed it a whole forged spine, for example one built with the old keys of nodes that left the registry long ago, could steer it to a forged state.
The pin closes that gap. It is part of the release the operator installs, so the new node knows at least one genuine spine block before it talks to any peer. Any spine history that does not contain that exact block is refused.
What the pin is
The file is named spine-pin.txt and sits beside the node's database. It holds one line: a spine height and the 64-character hexadecimal hash of the spine block at that height.
Nothing in it is secret. It is a public hash that anyone can compare with the spine of their own node. Without the file there is no pin, and the spine's other defences apply as usual.
What the node does with it
- At start-up, the node compares its own stored spine block at the pinned height with the pin. If the hashes differ, the node is on a forked or tampered spine history and does not run on it. Under the rules decided for version 0.5.8, it rebuilds itself from the network instead of restarting in a loop.
- While running, a spine block that contradicts the pin is refused when it arrives.
- When spines compete, a node never rolls its spine back below the pin.
How releases use it
Version 0.5.8 tightens how the pin is used:
- The installer stops when the release lists a pin that it cannot fetch, instead of carrying on without one.
- Later releases pin a recent spine block, not only the first one, so the anchor moves forward with the chain.
- A node whose stored spine conflicts with the pin rebuilds itself rather than refusing to start again and again.
The release itself is protected separately. The release authority registers each release on the chain with the hash of its manifest, the installer checks the release's signature and manifest hash against the chain, and two thirds of the seats can veto a release (see releases and updates and checking a downloaded file).
What the pin is not
- It does not tie the node to a fixed peer: the node syncs from any registered peers as usual.
- It does not freeze the node's software: updates continue as the operator has chosen.
- It holds no key, private or public: only a block height and a block hash.
Its place among the defences
The pin is one of several defences against a long-range attack, an attempt to rewrite history from far in the past. Running nodes are protected by the 720-block rollback limit and by the spine checkpoint floor (see finality and rollback); new nodes by the two-thirds co-signatures on the spine, by the spine's own record of which keys joined and left, and by the pin. See what Proof of Participation defends against.