Changes to “The release pin”
#65 (zoobc.how, 2026-10-26 20:39 UTC) → #109 (zoobc.how, 2026-10-26 20:44 UTC): Seed article updated
+ A ZooBC release can ship a **spine pin**: a small public file that names one block of the [[spine-chain|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 an installation one trusted anchor that comes with the software itself, so a forged spine history is refused before the node builds anything on it.
− A ZooBC release can ship a **spine pin**: a small public file that names one block of the [[spine-chain|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
…
## 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 then rebuilds itself from the network.
− - **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
+ Two rules govern how releases carry the pin:
− Version 0.5.8 tightens how the pin is used:
+ - The installer stops when the release lists a pin that it cannot fetch.
+ - Each later release pins a recent spine block, so the anchor moves forward with the chain.
− - 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 [[verifying-downloads]]).
…
## What the pin is not
+ - It does not tie the node to a fixed peer: the node syncs from its peers as usual.
− - 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.
…