How to Disincentivize Large Bitcoin Mining Pools

Pool

Recently, the GHash mining pool breached Bitcoin etiquette to become a 55% miner for Bitcoin [*]. This collapsed the key value proposition of Bitcoin, namely, its decentralization. In turn, there has been considerable criticism and backlash. Many people in the community, including us, have noted that etiquette or the good will of miners are not sufficient to keep monopolies at bay, and called for technical measures to disincentivize large mining pools.

In this post, we present a specific technical fix, called Two Phase Proof of Work (2P-PoW), to disincentivize large mining pools. We first describe the problem, outline the requirements for a good solution, and then present the simplest solution that we know of that meets those requirements.

The critical property of our solution that sets it apart from previous ideas is that it preserves the current investment in Bitcoin by both existing users and by existing miners. It provides a seamless, smooth transition from the current PoW to the modified, large-miner-deterring 2P-PoW. Yet it enables the existing miners to continue to use their mining hardware; in fact, it extends the lifetime of this hardware. Overall, it provides a gentle fix to the recent GHash fiasco and makes it highly unlikely that we'll find ourselves at the mercy of a single entity, without perturbing the existing economies and investments in place.

The Problem and Background

Pool

Today, large pools are built out of independent entities that place their hashing power under the control of a pool manager that coordinates their efforts, collects rewards, and redistributes those rewards to the participants in proportion to their effort. When pools grow to be large, they pose a risk: Pools over 25% can cheat the system with selfish mining and earn more than their fair share, over 33% presents risk of unilaterally successful selfish mining, large pools risk double-spends with low confirmations, and over 50% is an unmitigated disaster. Such majority miners are toxic: not only can they engage in subtle attacks, but their mere presence, even when they are not engaging in any attacks at all, damages the Bitcoin value proposition, kills the critical features that make Bitcoin interesting and exciting, and therefore hinders Bitcoin adoption. Mining pools over 25% are not good for Bitcoin.

In order to disincentivize large pools, we propose a small, backwards-compatible change to Bitcoin's Proof of Work (PoW) mechanism that retains both the current blockchain and miners' current investments in mining hardware. The key insight behind this change is to make it difficult to delegate proofs of work, for as long as the proof of work can be delegated, huge pools can be built, leading to a winner-takes-all GHash-at-51% sort of scenario.

Bitcoin's puzzles are sometimes compared to scratch-off lottery tickets [permacoin], with the miner's name at the top. A miner scratches one ticket after another until he finds a winning ticket and publishes it to receive its rewards. But a lone miner working alone can be scratching for months before he finds a winning ticket. For instance, A $1500 mining card, available for preorder from Butterfly Labs, will need an expected time of over 6 years to mine a single block, if it were available today. That's a long time to wait in between winning tickets. To reduce this variance, people form pools.

With pools, the pool manager takes a stack of tickets and distributes it among a set of pool members in such a way that the winnings can only be deposited to the pool operator's address. Together they have a lot of scratching power (aka mining power). Whenever one of the members gets a winning ticket, it publishes it, awarding the pool manager with the reward. There is no opportunity for the finder to say "finders keepers!" and keep the money for itself, because the PoW mechanism is set up to send the winnings directly to, and only to, the pool manager. The pool manager then distributes the winnings among all members of the pool, in accordance with how much they contributed to the pool.

This kind of proof of work is inherently distributable. We need a slightly different proof of work that cannot be easily outsourced to others. What does such a PoW look like?

Requirements

Pool

Before we go on to answer that question, let's discuss some must-have features of any good solution.

  • Any solution in this space must preserve the existing blockchain, and with it, the existing Bitcoin balances.

  • Any good solution in this space must also preserve the large investments many miners have made and are planning to make in their equipment.

  • A great solution in this space would provide a seamless transition from the existing system to the new one, and provide adjustable knobs that can be fine-tuned for a desired tradeoff that fits the community's needs.

The first requirement is a must have, and the reasons for it should be self-evident. The third one is the cherry on top. But the second requirement is absolutely critical. Bitcoin's security relies on the size of the mining infrastructure. The massive amounts of specialized hardware wielded by miners makes it difficult for all but a state-power to obtain a majority all by itself. The miners have made extensive investments in this infrastructure, and they play a critical role in the Bitcoin ecosystem by maintaining the Bitcoin blockchain. A pool-prevention mechanism should therefore maintain this existing power and knowledge. It would be a huge mistake to propose a new crypto-mechanism (e.g. zero knowledge proofs, "moon math" and the like) that would cause miners to throw out their existing rigs and start from scratch. In fact, the political resistance would be so great that no one would implement it. We believe it is possible to retain the existing infrastructure and layer the protection on top, and describe it below.

As an aside, the overall network hash rate has been doubling every 3-4 weeks, and therefore, mining equipment has been losing half its production capability within the same time frame. After 21-28 weeks (7 halvings), mining rigs lose 99.3% of their value. So there is very high equipment turnover in the mining industry. This helps us greatly in two ways: there is constant obsolescence within this industry, and therefore we can plan for a smooth transition, say, 12 months from now, which would give miners plenty of lead time to factor the change into their financial planning. At the same time, our proposal actually extends the life of the existing rigs by shifting work around, and therefore should provide a boost to existing miners.

Solution

Pool

Here's a new PoW mechanism that we call Two-Phase PoW. It disincentivizes large pools, retains the current investment in mining infrastructure and allows for a smooth transition. It's technical, so if you're not familiar with how the current cryptopuzzles work, you may want to skip to the next section.

A two-phase PoW consists of a block that has two separate cryptopuzzles in it. Under a two-phase PoW:

  1. The double hash of the header (SHA256(SHA256(header))) is smaller than a difficulty parameter X, and

  2. The header is signed with the coinbase transaction's private key, and the hash (SHA256(SIG(header, privkey))) of that signature is smaller than a second difficulty parameter Y.

The first phase (i.e. point 1 above) is identical to the existing Bitcoin cryptopuzzle. Our solution retains that mechanism in its entirety. The existing mining rigs are all geared to solve the first puzzle, which they can do very efficiently. X is the value of the current variable known as "difficulty" in the Bitcoin software. So we change absolutely nothing that already exists.

The twist here is that we introduce a second cryptopuzzle. In effect, phase 1 requires our miners to do the work that miners have always been doing. But then, when they think they have a viable solution, we now ask them to sign the block with the private key that controls the payment address, and see if the result, when hashed, is below a second difficulty parameter Y.

This mechanism allows miners to use existing rigs, albeit with a lower difficulty value (X) than the difficulty value currently in effect. This would enable miners to produce a lot more potential solutions; that is, headers that pass phase 1, which we call half-solutions. For each such half-solution, miners use a second device, perhaps a CPU or a specialized card, to perform the second check until a full solution is found.

Note that, if Y is sufficiently small (i.e. difficult), the pool operator cannot just collect all the first-stage solutions and discover a solution to the second stage by himself. The second stage requires performing a sign and hash, which is comparable in cost to the first stage's double-hash, and therefore needs to be distributed just as widely.

The key insight that makes this work is that the second phase is not outsourceable to untrustworthy third parties. It requires a pool participant to be in possession of the private key, which, in turn, would enable the participant to immediately usurp all the newly minted coins from the pool operator. Pool operators, being so vulnerable to being robbed, would not be able to admit untrusted individuals into their pools.

Not Centralizable: A pool that wants to keep the secret to itself would need to receive all the partial solutions. Making the first phase easier and the second phase more difficult would make this infeasible. Outsourcing the key to the pool participants would enable a participant to steal the newly minted bitcoins.

Retains Existing Mining Infrastructure: Existing hardware would greatly speed up finding a solution. The current miners would start out from their current position.

Smooth Transition: The solution is highly tunable: if we start out with X=current difficulty, Y=infinity, then we have precisely the same Bitcoin system as we have now. If we increase X (thus making first phase cryptopuzzles less difficult to solve) and reduce Y (thus make the second stage more selective), work can be smoothly shifted between the two phases, from Bitcoin as we know it to Bitcoin with the new measure in place.

2P-PoW is completely agnostic to how the miners determine the contents of a block. In particular, it would work well with GetBlockTemplate, and it would work just as well without. We need not solve the GBT adoption problem to deploy 2P-PoW.

Implementing This Change

Pool

We suspect that implementing this change would require just a few hundreds of lines of code to the Bitcoin reference client. After a community discussion with various stakeholders and a thoroughly tested reference implementation, we'd pick a block number that is sufficiently ahead in the future when the change would be enacted with X=current and Y=infinity. The self-adjustment algorithms would take off from there at that block number, much in the same way that the difficulty parameter is adjusted today. This would build on the existing blockchain, retain all balances until that time, and enable a seamless switchover to the new world.

This is indeed a hard fork, where Bitcoin users must switch to the new 2P-PoW on the agreed-upon date. This is not very different from the day in March 2013 when a hard fork unintentionally appeared in the blockchain, and majority consensus had to be achieved on the fly on which fork to follow. Except this particular roll out would be planned months in advance, and on the date of the rollout, none of the mining economics would be affected.

As with all things Bitcoin, this rests on a community decision. If the community does not accept it, and no one upgrades, nothing would happen. But it is possible to make the change, and by carefully selecting X and Y, to retain exactly the same system dynamics as we have now. We could then tweak the parameters to deter large pools.

Issues

There are some known issues with this proposal, none of which are really significant:

  • This mechanism does not address the case of a single large miner who owns all of his own equipment. In such a case, he can simply trust all of his machines to not leak the secret, and amass power. We not only have never heard of any technique that can address this issue, but we do not believe it needs to be addressed. The problem at hand stems from open, public pools. The costs of acquiring sufficient hardware to own 51% of the Bitcoin network put it out of the reach of most non-governmental single actors.

  • The adjustment of X and Y is a delicate issue that requires some simulation. We have deliberately chosen not to be overly prescriptive in this post. The X adjustment would need to be gradual to rule out graphics cards for the first phase. The Y adjustment would need to compensate to yield a solution every 10 minutes on average. This mechanism is easy to devise following a community discussion that establishes the principles that govern the politically-feasible tradeoffs. In fact, this is perhaps the greatest strength of this proposal: an appropriate selection of X and Y can accommodate any point in the space of possibilities, including where we are now and where we might want to be in the future.

Call To Arms

Will this fix the GHash problem? Yes, we expect so. GHash reportedly owns 25% of their own mining rigs, which corresponds to only 14% of the overall hash rate. They would not be able to launch a 51% attack.

We are making this proposal public in the hope of stirring some much needed discussion. The Bitcoin value proposition, the promise offered by the currency, is too precious to lose to the greed of the masses or the ambitions of a single mining operator. The latest GHash 51% episode has shown to everyone that simple-minded arguments around "but a miner would never to something to hurt Bitcoin, they would themselves be hurt" are empirically wrong. We can avoid the GHash 51% drama, the corresponding calls to boycott, the much-needed-but-also-deeply-upsetting on-the-fly GHash miner shaming, the DDoS attacks against GHash, and other passionate activities that took place this week. The strength of Bitcoin stemmed from its revolutionary use of crypto, and just a simple modification can render the "too big for comfort" miners infeasible through the power of slightly enhanced crypto.

Clarification (June 21, 2014)

Some people seem to misunderstand our proposal by thinking that it will eliminate all pools. Perhaps the biggest strength of this proposal is the smooth tradeoff it provides between the first and second phases of proof-of-work. By choosing X and Y appropriately, we can preserve exactly the dynamics we have now (which permit GHash at 51%), or we can gradually disincentivize large pools. Unless we were to choose extreme values for X and Y, this proposal does not prevent all pools! It's quite possible to pick values that would deter large (>25%) pools, while allowing the small miners to combine their resources into small pools in order to control their variance.


Footnotes

[*]

Actually, it became a 55% miner for almost a day. And prior to that, it seems to have tested the waters over a period of 10 days or so, perhaps gauging the public's reaction. Their full sequence of actions are as follows:

They first had a 51% majority on 2014-06-03 04:10:07 GMT for 12 hours.

Then again 53% on 2014-06-07 02:44:03 GMT for 12 hours and 30 minutes.

Then again 53% on 2014-06-09 21:35:14 GMT for 12 hours and 50 minutes.

Then again 51% on 2014-06-10 14:40:58 GMT for 13 hours and 20 minutes.

Then they got brazen at 55% from 2014-06-12 11:53:05 until 2014-06-13 09:45:24 GMT, for almost 24 hours.


comments powered by Disqus