The Untold Story of ditto-b
The fourth Bitcoin halving just triggered a few hours ago, ushering in the 5th mining epoch. As such, this seems like a good time to tell the tale of a little-known Bitcoin contributor who had a massive effect upon the halving algorithm.
The story takes place 10 years ago when an anonymous developer with no reputation managed to make a significant change to the Bitcoin consensus rules.
The Timeline
A user by the handle "ditto-b" joined GitHub on April 8, 2011.
In 2013 they forked OpenTransactions but didn't seem to do anything with it.
Ditto-b was a fan of Runescape as we can see from this table of Experience Point Levels. https://gist.github.com/ditto-b/933800
Ditto-b also built a basic funds sending script for interacting witih Bitcoin compatible RPC nodes. https://gist.github.com/ditto-b/9360868
On March 10, 2014 they created a pull request to change 4 lines of code in the Bitcoin repository.
These four lines of code are consensus critical and are not to be trifled with!
Long story short: ditto-b discovered a common type of software flaw known as a value overflow bug. No one in Bitcoin's first 5 years of existence had thought through how this function would operate when the blockchain was at a height of 13,440,000 after 64 halvings.
A few weeks later, Pieter Wuille used the timing of the pull request to publish BIP-42 as an April Fool's Day joke that was simultaneously satirical and dead serious.
Ditto Who?
Does "ditto-b" mean anything? The first hit I could come up with is a particular Windows virus dating back to 2007 called Ditto.B.
Then I discovered that "Ditto" is a Pokemon character, and Ditto's attributes are... interesting.
To use Ditto you have to know a weakness when you see a Pokémon, so you can choose the best possible move at all times. Ditto can only run one set usefully.
It's just interesting, and perhaps coincidental, that this character is related to knowing / exploiting weaknesses. Who knows if the username was chosen with the intention of conveying any meaning; it seems unlikely since the account was created 3 years before the pull request was made.
My Speculative Take
The history on ditto-b's account is suspiciously sparse. It's uncharacteristic, to say the least, for a developer with practically no real contribution activity to simply appear and propose a patch for such a niche edge case in an extremely complex software project.
It's incredibly unlikely that ditto-b was just a random person with no history of contributing to Bitcoin who happened to run across these crazy edge case. Ditto-b is most like a well-known "Bitcoin wizard" who, upon noticing this edge case, decided that it was too sensitive an issue to want to have their reputation linked to the proposed change. As such, they chose to report the issue via an alternate pseudonymous account.
We only ever got 2 sentences out of ditto-b, so there's no point attempting any sort of stylometric analysis, but this snarky comment certainly lends credence to my claim that it was a seasoned Bitcoin developer who was very familiar with the wider ecosystem.
Lessons Learned
In one respect, it's interesting that there were no activation parameters suggested for this consensus change. A soft fork will be executed at block height 13,440,000 without any signaling whatsoever. This leads me to conclude that:
- Consensus changes that are considered "bug fixes" are assumed to have such strong consensus that the effort to write and test signaling activation logic is considered wasteful.
- Uncontroversial consensus changes that don't activate for an extremely long period of time are similarly considered not worth the effort for activation logic, as it's assumed that everyone will have updated their code long before the soft fork activates.
Pieter phrased it a bit more humorously in BIP-42:
Given the moderate time frame over which this change is to be implemented, we expect all miners to choose to screw themselves and deploy this change before 2214.
If they don't, and a minority remains on the old code base, a fork may occur. Essentially, they'll be mining fool's gold after that time.
This has some tie-ins to my previous analysis of non-backwards compatible changes to Bitcoin client code:
As well as a relationship to my more recent analysis of node operator upgrade trends:
Perhaps most importantly, the anonymity and lack of history held by ditto-b shows us that this proposed change was considered completely upon the merits of the code, not upon the reputation of the person who proposed the change.