Bitcoin has a process for proposing consensus changes but nothing that says when one's actually ready to activate. No required review period, no code maturity bar, no method for estimating chain split risk, no agreed activation threshold. I wrote a paper trying to fill that gap and I'd rather have it argued with here than ignored.
The part I most want people to poke at is the risk math. The worst thing that can happen in an activation is a permanent chain split, and how likely that is comes down almost entirely to how much hashrate enforces the new rules when it goes live. Run the standard chain race math and it's not a gentle slope, it's a cliff. Around 55% enforcement you get roughly a 30% chance of a six block reorg during activation. At 90% or higher it basically vanishes, several orders of magnitude lower. So a lot of the governance fighting is really a fight over one number the math already gives us. If I've got that wrong I want to know where.
The paper also lays out a 20 point readiness scorecard across proposal quality, code quality, activation safety and community process, and scores three real changes with it. Taproot comes out 17/17 on the criteria that apply, after about four years of review and no split. SegWit2x lands around 5/17, the 2017 hard fork that miners and exchanges backed and then pulled. BIP-110 scores 3/20, with a 55% threshold and about six weeks from proposal to activation client.
It grades how a change was pushed, not whether it should happen, so the same test applies whether a change tightens the rules or loosens them. Pull it apart if it doesn't hold up.
Free PDF, 98 pages. https://github.com/asaffulks/consensus-change-standards/raw/main/consensus_change_standards_v4.pdf
why?
please do not interpret my question as an ad hominem attack, despite wondering about your own world of ideas; I'm building a mental model of the author before deciding whether to store only the PDF or clone for getting a better idea of your thought process and its evolution ....
... are you familiar with why some electrical circuits have multiple capacitors in parallel, despite Kerchoffs's Law ruling quite unambiguously that they're just one huge liability?
The capacitor analogy's worth testing — but it breaks on what you're putting in parallel.
Parallel hardware — capacitors, nodes, software implementations — is redundancy, and yeah, Bitcoin wants more of it. But the ledger isn't hardware. Its whole value is that there's only one of it. Every node keeping its own copy of the same history is the good kind of parallel. A chain split is the opposite: not many copies of one ledger, but two ledgers that disagree about what happened. That's not a backup, it's a divorce — coins stop being interchangeable, a payment on one chain can be replayed on the other, the users and the money split in two, and you lose the one thing all that redundancy was protecting: everyone agreeing on a single history.
So: parallel hardware, yes. Parallel truth, no. That's why a permanent split is the worst case — it wrecks the thing all the other redundancy exists to defend.
The Bitcoin blockchain is not anyone's ledger of truth, yet. I've had various ideas over time, including even consulting once for a project that wanted to upload the Pentateuch [first five books of the old testament, aka "Torah"] to the blockchain... however if you look at actual usage today, the "truth" in the blockchain is an economical ledger, which is important within its domain, lots of private data, which is best considered a backup rather than shared truth, and mostly lots of "art", which is an interesting use of the datastructure, although not the same kind of "truth".
I do look forwards to a future where Bitcoin is much more widely used for timestamping of all kinds of publications, and has a much more fundamental role in helping humanity agree upon shared truths, although I believe it is decades away, and requires a greater social/political trust in a system that will have matured significantly by then.
Fair point on what's actually on the chain today. But look at your own list — it helps my argument.
If the chain splits, the art and the data survive. Both chains keep the full history up to the split, so none of it gets erased. The thing that actually breaks is the money. Your coins now exist on two chains that disagree with each other. A payment you make on one chain can get copied onto the other. And every exchange has to pick which chain to call "Bitcoin." So I don't need Bitcoin to be some grand ledger of truth — I just need it to be money, which is the one use you agree is real today. And money is exactly what a split destroys.
Funny you mention timestamping, because I'm building that right now — Bitcoin timestamping in legal case software, so I can prove a case file existed on a certain date without trusting anyone's server. That's actually the use a split damages least — the proof would survive on both chains. But even there it costs you: in court I'd have to argue about which of the two "Bitcoins" counts before anyone even looks at the proof. So that's the full picture: the money breaks outright, and the data survives but gets harder to use. Nothing on your list comes out of a split better off.
there still is reduced strength, because timestamping draws its power from the cost of rewriting history; and after a fork, the divided hashpower produces weaker separate histories, and any given attacker with some amount of equipment is thus correspondingly more powerful in an attempt to rewrite either individual chain.
I hope you're building on top of OpenTimestamps?
You're right — that's a second cost on top of the courtroom one. A timestamp is only as strong as the mining work stacked on top of it, and a split cuts that in half for each side.
One wrinkle: it hits old and new proofs differently. A stamp made before the split lives in the history both chains share, so erasing it means rewriting both. It's the stamps made after the split that land on a weakened chain. And that's not theory — Ethereum Classic ended up the minority chain after its split, and in 2020 it got 51%-attacked three times in one month. One attack rewrote about 7,000 blocks, roughly a day of history.
And yes — OpenTimestamps. Official library, public calendars, no coins or keys on my side. No point reinventing that. What I'm actually building is the court-facing layer: a proof only helps if a judge and opposing counsel can follow what it proves.
the verdict: I can afford cloning the repo, and thanks for all the "free" PDFs
Git is not just any old database, so please lose the habit of storing all your old renders... this isn't your mom's album of her kids' graded homework.
The old renders are there on purpose. Early reviewers have links pinned to specific filenames, and a few citations point at specific editions — pull the old PDFs and all of that breaks. Keeping them live is just the cost of not 404'ing people who already cited the thing.
You're right that binaries in git isn't pretty, and Git LFS is the cleaner fix — I'll get to it. But it's a deliberate tradeoff, not me treating the repo like a photo album.
your title doesn't even have a question and the answer is "no"
A headline doesn't need a question mark to make a claim. And the claim holds up: the one part of an activation that can actually split the chain comes down to a single number — how much of the hashrate runs the new rule on day one. That's not politics, it's arithmetic, and people fight over it like it's a matter of taste.
"No" isn't an argument, though. Which part do you actually think is wrong — the math, or that people ignore it?
I really don't like such radical oversimplifications. Even if you insist on looking only at some "day one", don't you think the interesting questions are slightly more complex than the one-dimensional integral of hashrate allocation across that day?
Even if you are only interested in which chain wins and how much "work" is lost during the forking noise, it is an evolving self-aware process, where some actors might modify their behavior in response to political pressures or price movements, rather than some sterilized game-theoretical situation where people pick a column from a matrix, go to sleep, and check their payoff after waking up.
Fair — my one-liner oversimplified it. But the paper doesn't. Section 3.4 says straight out that the model is a snapshot, that miners will jump to whichever chain pays more, and that the 30% number is the best case, not the worst. The dynamics you're talking about are in there — and they make a low threshold look worse, not better. Miners drift to the majority chain, and 55% signaling doesn't mean 55% will actually enforce. It could be under half on day one.
So why use one number at all? Because it's the only thing you can measure before you pull the trigger. You can see the signaling share before activation. You can't see how miners will react to price and politics once it's live. A safety rule has to run on what you can actually measure, so you measure the worst case and set the bar there. Same reason a bridge gets rated for max load — you don't assume traffic will sort itself out.
And history backs that up. In 2017 miners kept jumping back and forth between BTC and BCH chasing profits, and it made things messier, not cleaner. Chains that were supposed to die off — ETC, BCH — are still around years later. "The market will fix it" is not something you can count on when you're deciding whether an activation is safe.
All the political, human stuff you're describing is real. That's what the other 19 items on the scorecard cover. The math only covers the one part that math can cover. But fair point — the next edition will say all this more directly.
I think you'll find that lots of maximalists are still only maximalists relative to altcoins, and consider Bitcoin itself young and experimental technology. I'm grateful that I had the mostly-squandered opportunity of watching Bitcoin mature from its early days, although I sometimes wish I could see how the ship will look in 2140, rather than work to bail it out in 2040...
My point is like 'what does not kill you, makes you stronger"; except in this case, I believe that us maximalists need the maturity of preferring a stronger Bitcoin in 2040, that has weathered some terrible storms over a few decades of chaos, over naively hoping for painless growth while all the developers sit around singing kum-ba-ya and not fixing what isn't broken.
True maximalism does not believe in unicorns, it worships the phoenix and recognizes the importance of the flames.
I'll take that framing. Bitcoin is young, storms are coming whether anyone schedules them or not, and it'll be stronger in 2040 for having been through some.
The line I'd draw: weathering a fire is not the same as setting one. 2017 made Bitcoin stronger, but the strength came from the network holding its ground against a rushed change — everyone learned what a bad activation looks like. The scorecard is that lesson written down. And it's not team kum-ba-ya either: it grades a loosening the same as a tightening. It doesn't say don't change Bitcoin. It says know your odds first.
I'm fine with the phoenix. I just don't think it should light its own nest.
I'm curious why you call this a "legal framework." What does legal mean in this context?
Fair question — two different things are bundled in that paper, and you're right to separate them.
The part that matters here is the technical one: the readiness standard and the chain-split math. That stands on its own, no law required.
"Legal" is the other half, for a different audience. It asks a narrow thing: if a handful of people push a consensus change that splits the chain and wipes out value — after ignoring every red flag to do it — does existing law already have something to say about that? Negligence, fiduciary duty, that kind of analysis. It's not "code is law," and it's not a call to go sue developers. It's mapping what existing law would probably already say if an activation went badly and people lost money — so the exposure is visible before anyone acts, not after.
I kept that half deliberately out of the scorecard. A readiness test shouldn't carry liability theory — it should just tell you whether a change is ready.
probably, "all of the consensus fight is over one disputable strike" [of the gavel]
Ha — but the whole point is the gavel should never strike. That half's about staying out of court, not dragging Bitcoin into one.
Individual people [including even developers] have ended up in court, or at least, threatened. Bitcoin doesn't exist in a legal or political vacuum.
No disagreement — that's where the paper starts, not something it missed. Tulip Trading already put developers in front of the England & Wales Court of Appeal, and the court said both claims — fiduciary duty and negligence — were strong enough to go to trial. The case itself later fell apart, but the door it opened is still open: courts will hear these claims against developers.
Which is exactly why process matters. If a court can look, the question becomes what it finds when it does. A change that clears a careful, documented process gives a negligence claim very little to grab. A change that rushes past red flags writes the plaintiff's brief for them. The framework is the difference between those two.
So, basically, the process of launching this
scamis worse than either of the previous massive softfork episodes??On process, yeah — by the scorecard it grades worse than either: 3/20, a 55% threshold, ~6 weeks from proposal to activation client, the client failing its own tests. That's the finding.
I'd leave "scam" out of it, though. The framework grades how a change is pushed, not whether it should exist or what's in anyone's heart. A change I personally liked could score just as badly if it were rushed the same way. The point is the process bar, not the motive.
Is it 69?
90, but I respect the guess.