Lesson learned from the Classic coup attempt or why Core needs to prepare a GPU only PoW

The Classic coup

11 min readJan 23, 2016

The Classic coup attempt orchestrated by the Classic Kabal (Marshall Long, Olivier Janssens, Jonathan Toomim, Michael Toomin, Gavin Andresen and Jeff Garzik) demonstrated how an organized and determined small group of individuals came very close to be able to change Bitcoin development governance model, riding the popular demand to increase the block size limit.

In the beginning of January Olivier Janssens and Mashall Long asked Jonathan Toomim to be the lead maintainer of a “simple” 2MB Hard Fork, called BitcoinClassic, after Gavin Andresen and Jeff Garzik refused the role.

(Disclaimers: Olivier is an investors in Spondoolies-Tech, we had business relations with Marshall Long and his company FinalHash and Jonathan Toomim is a customer and hosting partner of Spondoolies-Tech)

I conducted an impromptu interview with Jonathan Toomim in a Chinese Miners WeChat group called “MinerInWorld”. The chat log can be found here.
In the interview (4.5 hours long…) Jonathan describes the chain of events leading to the forming of Classic and he also explains Classic governance model, which involved around democratic vote on issues using a site his brother Michael is one of the creators. Excerpt from this long interview:

Jonathan Toomim:2016–01–20 06:57:54:then i talked with marshall and olivier
Guy Corem:2016–01–20 06:58:02:What did they want / suggested ?
Jonathan Toomim:2016–01–20 06:58:16:and they said they wanted to make a client that would be a 2MB hardfork
Jonathan Toomim:2016–01–20 06:58:26:and they asked me if i was interested
Guy Corem:2016–01–20 06:58:27:Just that ?
Guy Corem:2016–01–20 06:58:35:”Simple” 2MB Hard Fork ?
Jonathan Toomim:2016–01–20 06:58:36:i told them that i already wanted to do that
Guy Corem:2016–01–20 06:58:38:Nothing else ?
Jonathan Toomim:2016–01–20 06:59:01:they told me that they didn’t like how core was controlling bitcoin
Jonathan Toomim:2016–01–20 06:59:09:i agreed, i don’t like how core was controlling bitcoin either
Guy Corem:2016–01–20 06:59:19:Please explain what they said
Jonathan Toomim:2016–01–20 07:00:13:they thought that it seemed that everybody could get behind 2 MB, so if we got it done and got a good team around the project, we might be able to break the monopoly of core, or something like that
Jonathan Toomim:2016–01–20 07:00:54:they were in a more us-vs-them mindset than i was, though
Jonathan Toomim:2016–01–20 07:00:59:which i didn’t really like, but i understood
…
Jonathan Toomim:2016–01–20 07:03:59:and i thought that an opposition client would make core come to their senses, and agree to what the miners wanted
Guy Corem:2016–01–20 07:04:02:In retrospect, do you think that it was more important to them to do 2MB increase or “break core monopoly” ?
Jonathan Toomim:2016–01–20 07:04:08:and then we could collaborate, and it would be great
Guy Corem:2016–01–20 07:04:22:(I have followup question later)
Jonathannathan Toomim:2016–01–20 07:04:33:i’m not sure
Jonathan Toomim:2016–01–20 07:04:47:i know the 2–4–8 or 2–4 or 2 was more important to me, so that’s what i heard
Jonathan Toomim:2016–01–20 07:05:06:but my brother and i had had ideas for how bitcoin could be governed in a more balanced way for a long time
Jonathan Toomim:2016–01–20 07:05:12:we wanted to bring democracy into bitcoin
Guy Corem:2016–01–20 07:05:24:sec
Guy Corem:2016–01–20 07:05:28:At that point,
Guy Corem:2016–01–20 07:05:34:You said two opposing thing
Guy Corem:2016–01–20 07:05:43:On one hand you said (your words):
Guy Corem:2016–01–20 07:06:02:- “i thought that an opposition client would make core come to their senses, and agree to what the miners wanted” and “and then we could collaborate, and it would be great”
Guy Corem:2016–01–20 07:06:08:And on the other hand you said:
Jonathan Toomim:2016–01–20 07:06:10:increasing the blocksize was the most important thing for me, but i was also interested in trying to add some democracy to bitcoin
Jonathan Toomim:2016–01–20 07:06:15:i had both interests
Guy Corem:2016–01–20 07:06:22:- but my brother and i had had ideas for how bitcoin could be governed in a more balanced way for a long time
Guy Corem:2016–01–20 07:06:26:I understand
Jonathan Toomim:2016–01–20 07:06:33:i think that consider.it has a lot of potential to help settle arguments between developers with data
Guy Corem:2016–01–20 07:06:34:Which one was more important to you ?
Jonathan Toomim:2016–01–20 07:06:39:block size
…
Jonathan Toomim:2016–01–20 07:23:29:olivier did most of the manager tasks for creating a team and organizing them, marshall did most of the talking to miners and businesses

I don’t know if there were any companies involved in the Classic coup attempt, but I’m guessing without any proof that Coinbase was in on the details from the beginning, judging from the Classic ACK list here and Coinbase’s CEO tweets (few examples: 1,2, 3).

Regarding Marshall Long (CTO of FinalHash, Cryptsy, and a board member and CTO of Mintsy), it is interesting to note that he had a 180 degree change of attitude regarding a blocksize increase. When I’ve asked Jonathan about Marshall Long involvement (in another chat we had, not the interview in “MinerInWorld” WeChat group) he told me:

[1/20/2016 10:42:02 AM] Jonathan Toomim: marshall opposed the blocksize increase earlier in december
[1/20/2016 10:42:14 AM] Jonathan Toomim: and was actually rather hostile to me at first
[1/20/2016 10:42:25 AM] Jonathan Toomim: i’m not sure what changed his mind

The Classic Kabal were initially successful in enlisting the Chinese Mining pools, BitmainTech, Genesis Mining and later Bitfury and KNC announced support as well, probably riding the popular wave as well, without fully understanding the implications. Later, after the matter sunk in, Bitfury CEO published a more balanced post.
At least in the case of the Chinese Mining pools and BitmainTech, there was no full disclosure from Classic regarding the implied change of development governance.

The jury is still out and we don’t know if the Classic coup attempt will be successful or not.

On January 19th Olivier Janssens published the following victory statement:

Janssens’s (premature?) victory statement

(Janssens’s full statement can be found here)

Coindesk published an article claiming big miners support Classic (here, however I’ve talked with BitmainTech and it seems that they’re on the fence now) while Bitcoin Magazine author Aaron van Wirdum claims Chinese pools are still undecided (full article here):

Updated on Jan. 22, 2016 at 11:50 EST:
Bitcoin Magazine received a response from major Chinese Bitcoin exchange Huobi, which indicated that the situation was still evolving. According to Huobi, there was not yet consensus among the Chinese mining community about whether to run Bitcoin Classic or Bitcoin Core. This contradicts the earlier information from F2Pool and HaoBTC indicating that a decision had been reached. “We all feel it’s not appropriate for us to give comments at the moment because Evan Mo and other miners are still discussing this issue and haven’t come to a consensus. We will continuously pay attention to this issue and make official comment on it when the time is right,” said a Huobi spokesperson in an emailed statement to Bitcoin Magazine.
Original article:
Shortly after the sensational public break-up between Bitcoin and R3CEV — hire Mike Hearn, and the launch of several alternative Bitcoin implementations, the block-size dispute is reaching fever pitch. Bitcoin Classic, in particular, has been gathering support among companies, users and some developers. Significantly, a number of mining pools has also publicly come out in support of the Bitcoin Corefork led by Jonathan Toomim.
The second largest mining pool on the Bitcoin network, with some 23 percent of hashing power, China-based F2Pool, was said to be among the pools prepared to switch to Bitcoin Classic. Yesterday, however, rumors started to surface claiming that the Chinese pools had changed position, and will stick with Bitcoin Core.
Speaking to Bitcoin Magazine, F2Pool operator Wang Chun confirmed this is indeed the case.
“The rumors are true,” Chun said. “Miners in China were scared by Luke Dashjr’s proof-of-work changing pull request.”
…

So, as I write these words, it seems that Classic has a good chance of meeting its activation Threshold. Jonathan is aiming for Classic to be activated when 75% of the last 2,016 (currently coded 1,000 but he said in the interview that he might increase to 2,016) mined blocks indicate support of the Classic fork, meaning the miners that mined them are ready to do a 2MB Hard Fork and leave behind everyone on Core.

What will happen to Core chain if Classic will be activated?

Will Classic activation mean the end to the Core chain ?
Not necessarily; Careful planning on behalf of Core will allow it survive.

I believe that Core developers will split into three camps: Some will join Classic Chain (and fork), some will quit Bitcoin altogether, and some will continue development on Core Chain (and fork).

I tend to believe that most Core developers will remain and implement the Core scalability road-map as planned. I simply don’t see Core following Classic’s governance model in which the users vote on issues.

Mainly, Core needs to replace its PoW function, preferably to a function which make any effort to create ASIC for it economically nonviable. I’ll discuss such a proposal below.
The other thing Core needs to do is to change the Transaction ID, in order to create a complete split of coins.

By implementing the above, upon Classic activation, each Bitcoin will be split to ClassicCoin and CoreCoin. Each coin will be transact-able separately and will have a different market value. Most of the exchanges will probably support both Chains, hence each Coin will have different market value based on supply and demand.

From the user perspective, she will needs to install both wallets (Core and Classic) and import the old private key into both wallets. It makes sense that multi chains wallets will be created, so the user will be able to transact easily with wallets on both Coins. These wallets may even present the following arithmetic: 1 CoreCoin + 1 ClassicCoin = 1 BTC, so if you have 80 CoreCoins and 73 ClassicCoins it would show up as 73 BTC + 7 CoreCoins. It might be able to transact in that way as well, sending CoreCoins and ClassicCoins with one wallet “Send” action to the receiver.

Meni Rosenfeld already described such a future when BitcoinXT was launched:

I’ve talked with Meni recently and he believes such an outcome is likely.

Andreas Antonopouos seems unconcerned if such an outcome will happen:

Source: Core Slack #general. Core doesn’t have funds of its own, so Core Slack is using the free version, saving only the last 10,000 messages. This link might not work soon, which is pity. The rest of Andreas’s comments are very enlightening as well (I found out later that the logs are exported here).

Suggestion for GPU only PoW change for Core

In order to survive, Core needs to change its PoW or else Core miners won’t be able to mine at all or Core chain will be susceptible to 51% attacks from Classic miners. I purpose the following, in order to prevent mining centralization, and prevent the possibility of such a governance coup in the future:

Core will prepare a large set of cryptographic hash functions, at least 100 or more initially. Any simple (not memory hard) function will do
Every 3 months (12,096 blocks), the PoW change automatically, by random data hashed from the last block before the change
A selection of 10 or more functions is made from the large set, selected deterministically from last block data
If the functions have tunable parameters and or constants then those are also selected deterministically from the last block data
Those 10 or more functions are constructed in a stack (e.g. X11)
The Stack of functions with their new constants and parameters (all selected deterministically by hashing last block data) is the NewPoW
In order to prevent Hash-Rate oscillation (very bad…), The OldPoW and the NewPoW coexist for one month (4,032 blocks)
Each PoW function actually serves for 5 months:
- One month of Phase In period in which it co-exists with it’s predecessor
- Three months in which it serves alone as the only PoW
- One month of Phase Out period in which it co-exists with it’s successor
During the Phase In period, the NewPoW difficulty is set initially to a very low value, to incentivize miners to mine it.
However, During the first 252 blocks (1/16 of the phase in period), only one block with the NewPoW is allowed every 16 blocks. If more then one block with the NewPoW is mined during this period, the rest will be discarded.
There will be a lot of miners trying to mine the new PoW since its difficulty was set to a low value, there will be a lot of soft forks. To avoid it, the block with NewPoW with minimum BlockHash is accepted as the winner, all the rest are discarded.
In the next 252 blocks (second 1/16 of the phase in period), only two blocks with the NewPoW are allowed every 16 blocks.
Every subsequent 252 blocks of the phase-in period, one more block with NewPoW will be allowed.
After each 252 blocks of the phase-in period, the difficulty of the NewPoW will be adjusted based on the time it took to create blocks with NewPoW from the beginning of each 16 blocks period.
By the end of the phase-in period, the OldPoW will be retired and the only acceptable blocks will be blocks with the NewPoW

This proposal if implemented correctly, will bring a never ending GPU mining on Core chain. It will also reduce the hash-rate oscillation between each PoW change. In order to make sure an ASIC effort will be uneconomic, the initial set of functions needs to be large enough. In addition, on every future Hard Fork of Core Chain, additional hash functions need to be added to this set (assuming CoreCoin price increase).

Why not use memory hard functions ? For example, John Tromp’s Cuckoo Cycle proposal (https://github.com/tromp/cuckoo) also prevents an attempt to create an ASIC, by requiring huge amount of memory (the limiting factor isn’t calculation but memory). However, I believe memory hard functions are more susceptible to BotNets then GPU only functions. BotNets are much less of an issue with GPU based PoWs.

The mining playing field will be leveled again and the barrier of entry for mining will be lowered. Everyone with money and access to low cost electricity will be able to mine.

Final thoughts

In the long term, in case of chain split, I think that Core’s better governance model and far better technical team will cause it to have a higher market cap.

We’ll have an interesting dichotomy:

Classic will have (kind of) democratic governance but centralized, ASIC based mining.

Core will have (kind of) meritocratic governance but democratic, GPU based mining.

In the event that the Classic activation threshold is not met, Core should remain with its current PoW algorithm. As the older members of our community may remember, when faced with Global Thermonuclear War, “the only winning move is not to play”; a GPU only PoW hard-fork is Bitcoin’s response to a politically driven consensus break, and should the hostile hard-fork not gain traction, we do not need the self-defensive one, either.

Miners and pool operators, friends and partners, I urge you to rescind support for this hostile political takeover and keep Bitcoin growing within its existing consensus-based governance.

Acknowledgments

Thanks goes to:

Adlai Chandrasekhar for suggesting the automatic method of replacing PoW parameters using Blockchain data
Benny Gorlick for suggesting to select the next PoW from a large set of predefined functions
Emin Gün Sirer for suggesting the mechanism to prevent hash-rate oscillation after each PoW change
James Hilliard for creating a tool that generates a transcript from the WeChat group “MinerInWorld”
Vitalik Buterin for reviewing the proposal
Luke-Jr for reviewing the proposal