BITCOIN'S RUDE AWAKENING

One program, both roles

Satoshi Nakamoto's Bitcoin 0.1 release told a user to run BITCOIN.EXE, which automatically connected to other nodes, and to turn on Generate Coins to run a node and generate blocks. A typical PC could initially find a block in a few hours. Validation and competitive production were available in one program on one ordinary computer.

Source: Bitcoin v0.1 release announcement.

The split first appears as a warning

When GPU mining was proposed, Satoshi asked participants to postpone the GPU arms race and said CPU-only competition made it easier to bring new users into the network. Faster work made Bitcoin harder to attack; it also raised the equipment threshold for participating in that work.

Source: Satoshi Nakamoto, "A few suggestions," post #10.

Pools make rewards steadier

Slush announced cooperative mining after describing how GPUs had made solo CPU block-finding punishingly unlikely. A pool could distribute work and divide a 50 BTC reward proportionally. It welcomed smaller hashers back into a reward stream, while placing a coordinator between individual machines and the block.

Source: Slush's original Bitcoin Pooled Mining announcement.

The work becomes a machine of its own

Avalon announced a Bitcoin-specific SHA-256d ASIC in September 2012 and shipped its first batch in January 2013. Specialized hardware dramatically increased the work protecting Bitcoin. It also made competitive mining a fabrication, capital, power, cooling, and operations business that ordinary node software could no longer perform.

Sources: Avalon ASIC announcement and Batch #1 shipment.

The UASF precedent contains two kinds of power

BIP-148 specified that participating nodes would reject non-signaling blocks beginning August 1 if SegWit had not already locked in. BIP-91 supplied an 80% miner-coordination path capable of locking it in first. The episode became lore about users making miners follow, but the specifications preserve both parts of the result: node-enforced pressure and coordinated block production converged.

Sources: BIP-148 and BIP-91.

Core changes the default data-carrier policy

Bitcoin Core merged an uncapped-by-default aggregate data-carrier policy, then shipped it in Core 30.0 with a 100,000-byte aggregate ceiling and multiple OP_RETURN outputs permitted by default. Operators could override the setting. This changed relay and mining policy, not Bitcoin consensus validity.

Sources: Bitcoin Core PR #32406 and Core 30.0 release notes.

RDTS becomes BIP-110

The Reduced Data Temporary Softfork was proposed as a temporary consensus restriction on several forms of arbitrary data and assigned BIP-110. Its modified BIP9 deployment used bit 4, a 55% threshold, and a mandatory-signaling window beginning at block 961,632.

Sources: BIP pull request #2017 and BIP-110 specification.

The first observed bit-4 block

OCEAN and Barefoot Mining mined block 938,903 with bit 4 set. It is the first signal in bip110.run's branch-aware record. Signaling showed miner participation; it did not itself establish economic adoption or command later miners.

Source: house signal record, hash 0000000000000000000161...4654.

Node power becomes the public test

On the eve of mandatory signaling, supporters described BIP-110 as a decentralization audit and argued that miners did not decide consensus. Those statements record the expectation about to be tested; they are not proof that any actor held sovereign power over every other actor.

Sources: Anton BTC and Dathon Ohm.

The last common block obeys the new rule

Roughnecks, mining through OCEAN, found block 961,632 with bit 4 set. Both histories share it. It was the first block required to signal under BIP-110 and retained Bitcoin's inherited SHA-256d difficulty of 127,479,855,693,691.4.

Source: house RDTS record, hash 0000000000000000000169...bc16.

Roughnecks extends the RDTS-valid history

Roughnecks, through OCEAN, found the competing block 961,633 with bit 4 set. This was the first post-split continuation accepted by BIP-110 nodes. The same height on two branches is not a duplicate; the hashes name different blocks with different parents and validation outcomes.

Source: house RDTS record, hash 0000000000000000000139...0968.

Refusal does not produce liveness

The non-BIP-110 history continued near Bitcoin's ordinary cadence. The RDTS history stalled after 961,633. Its nodes had enforced exactly what their operators selected, but validation did not compel miners, exchanges, buyers, or markets to extend or recognize that history. A node is sovereign over its own acceptance; it is not a remote control for production.

Sources: branch records in signal-map.json and carrier-map.json.

The BIP closes; the question moves to proof of work

BIP-110 was marked Closed following a chain split with stalled mining. In the Bitcoin Knots hard-fork discussion, Luke Dashjr set criteria for replacement proof of work, including day-one security, independently controlled hashpower, resistance to first-manufacturer capture, cheap rejection, and conservative cryptography. These are criteria, not a selected algorithm.

Sources: BIP status commit and the repository-preserved hard-fork forum record.

Roughnecks returns

After 286,782 seconds without a valid successor, Roughnecks mined block 961,634 through OCEAN. Block 961,635 followed 13,759 seconds later. The difficulty did not change: proof of work is probabilistic, so a long wait followed by a short one is not evidence of new consensus rules.

Source: house RDTS records for blocks 961,634 and 961,635.

The rude awakening

The strongest skeptical answer remains that BIP-110 lacked enough support. That is fair, but it describes the outcome rather than closing the inquiry. The event separated four things often compressed into one word, consensus: local validation, block production, economic recognition, and social legitimacy.

No meeting is required for the structural risk to exist. There is no evidence of a secret Teams or Zoom meeting among pool executives or Michael Saylor. Concentrated producers responding to aligned incentives can exercise a practical veto without a conspiracy. The live question is whether proof of work can reconnect production with the people who run and defend Bitcoin's rules without trading that problem for botnet or manufacturer capture.

Source: Star Heartsong, "BIP-110 was a rude awakening"; factual boundary in the repository claim ledger.