I'll be briefing the local meetup on some of the soft simulation results! View quoted note →

One thing the simulation makes viscerally clear: a contested fork doesn't resolve gradually. It stalls... then it doesn't. Here's what the timeline actually looks like across 2,694 scenarios. After the split, two chains run in parallel and when it breaks, it breaks fast. In the cascade scenarios, the decisive hashrate shift often happens within the first 500 blocks.. Profit-seeking pools drift toward whichever fork the price signal favors. Ideologically-committed pools hold their ground. For a stretch, it looks like a standoff, both chains viable, neither winning cleanly. What the chart doesn't show is what breaks the standoff. One chain accumulates 2016 blocks first. Its difficulty adjusts sharply down, its blocks become far cheaper to mine. The profitability math flips for every pool still on the other side. Resolution happens fast. The race that matters in a contested soft fork isn't block-by-block. It's who reaches the difficulty adjustment first. That single event is a cascade trigger and it's why most observable action happens in a compressed window once that threshold is crossed. Three outcome shapes visible in the data: a clean win for one side, a cascade win for the other, and a contested equilibrium where neither chain breaks through. General findings and useful frame for any contested fork. Full picture at UW BRI, July 13–17. #Bitcoin #softfork #UWBRI

A few people asked how the fork simulation actually works. The modeling choices matter, and I'd rather they be on the table before I start sharing results. Here's the short version... A contested soft fork (one where a chain split occurs because there isn't agreement in the network) is a decision problem for the entities who run Bitcoin's infrastructure. So the model represents them as three classes of actor, using the stakeholder taxonomy from the Blockchain Consensus Analysis Protocol (BCAP) as a starting point.

GitHub

GitHub - bitcoin-cap/bcap: Repo for Analyzing Bitcoin Consensus: Risks in Protocol Upgrades

Repo for Analyzing Bitcoin Consensus: Risks in Protocol Upgrades - bitcoin-cap/bcap

Economic nodes: exchanges, institutional custodians, payment processors, merchants: weighted by the BTC they hold or the volume they transact. Mining pools: weighted by hashrate, each with its own ideology and tolerance for losses. User nodes: retail operators running their own full nodes with some amount of custodied Bitcoin and option to have hashrate representing solo miners. Each actor re-evaluates the same way: first the rational choice (which fork is worth more / which do I hold), then ideology (am I committed enough to eat a loss), then inertia (is the gap big enough to justify moving). One pipeline, applied independently by every actor. Then we vary what we can't know in advance, how adoption splits, how committed the pools are, how much conviction each actor has across thousands of scenarios on real Bitcoind nodes using warnet and watch what the network does.

GitHub

GitHub - bitcoin-dev-project/warnet: Monitor and analyze the emergent behaviors of Bitcoin networks

Monitor and analyze the emergent behaviors of Bitcoin networks - bitcoin-dev-project/warnet

Results coming this week. Full picture at UW BRI, July 13–17. #softfork #Bitcoin #UWBRI

Nostr accounts are free, create as many as you like :)