13

Now that mining pools are starting to hit the 51% cusp of total mining power, what would need to happen to the Bitcoin protocol to reduce their success, and encourage distributed mining power over pools?

3

It doesn't matter if a mining pool has 100% of the total mining power so long as that mining pool can't choose which transactions its users work on, prevent them from submitting blocks that they find, or choose which blocks they build from. No change is needed to the Bitcoin protocol as far as I know. Only the protocol used between pools and their clients needs to be changed.

  • Can't some mining pools do these things though? Don't some mining pools work by having miners work on the same block? And when that block is solved isn't it submitted by the pool's system and not broadcast directly to the network? Or how do they work then? – Fraggle Jun 15 '14 at 12:28
  • 1
    The answer to all your questions is yes. My point is that the problem is not mining pools themselves but the way mining pools are designed today. – David Schwartz Jun 15 '14 at 14:59
  • 2
    Isn't the problem, though, that the mining pools would have to opt in to a system such as the one you describe? If you have a 51% pool that isn't interested in playing by those rules, aren't you sunk? It would follow, then, that the Bitcoin protocol itself would have to change to require pools to change, not just suggest it. – fbrereto Jun 16 '14 at 17:22
1

AFAIK there is nothing that can be done within the protocol to prevent 51% attacks. The best way to prevent such attacks from mining pools is to ditch that pool, and mine somewhere else. This happened earlier this year, when GHash.io almost reached 51% (source).

1

Mining pools are an important part of the Bitcoin ecosystem and I don't believe they should be disincentivized.

What does need to be done is to eliminate the inherent preference to mine only in the largest pool. This can be done with new mining pool reward frameworks such as Multi-PPS.

1

Ok, I'll take a shot at this.

We would need some kind of 'start work message' in the bitcoin system. For instance when miners start working on a block, they would have to broadcast a partial blockheader (minus the nonce) to the bitcoin network. This indicates that they have started to work on that block. Nodes (non-mining nodes) would store that partial header in memory (I guess) and if they receive an identical partial header from another miner then that indicates pooled mining with central authority, so they would flag those headers.

When a block is solved, if the partial header was flagged (received more than once), then the block rejected. If no partial header was received, it is rejected.

Ok, so not saying I have all the details worked out, but the above might be a start. For mining pools that work by having miners work on identical blocks where each miner is just trying a range of nonce values, this might work, because if any miner broadcasts the 'start work message' then that would prevent any other miner in the pool from doing so. Now it's not perfect. If all miners in the pool cooperated, they would just wait till the block is solved, then the mining pool just broadcasts the start work message followed by the solved block. But a single defector would ruin this for them.

  • This is not a good idea. A - there is no way to know which miner initially distributed a certain block header. B - No one would have to broadcast anything until they solve a block, they just broadcast the 'partial' header right before broadcasting the full block. C - It would be easy to DDOS such a system with block headers. D - mining pools could just give slightly altered work to each member, as can be done by changing the coinbase tx's script sig and resulting in a different merkle root. – morsecoder Jan 4 '15 at 23:37
0

Staying within the bounds of the current Bitcoin protocol, there is really no way to do this. As it stands now, miners get rewarded regularly for their work if they pool together, and infrequently if they mine individually. And since most would rather be rewarded more than once every 100 years, miners are incentivized to pool together.

It is probably worth noting that if pool mining really were made impossible, then it might have a negative effect on the security of the system. This is because smaller miners would likely not contribute, as they would not see rewards frequently enough.

There are a few proposals for limiting mining centralization. I'll describe two of them here. Multi-PPS (https://bitcointalk.org/index.php?topic=281180.0) is another, but I am not as familiar with this.


2P-PoW

Ittay Eyal, and Emin Gün Sirer have a proposal called Two Phase Proof of Work (2P-PoW) that attempts to address mining centralization - http://hackingdistributed.com/2014/06/18/how-to-disincentivize-large-bitcoin-mining-pools/. This quote shows how it works:

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.

Part 1 is exactly how mining is done now in Bitcoin. Part 2 makes it so that only a single key can be used to collect rewards in the coinbase transaction, and the block header is repeatedly signed with that key after part 1 is done until finding something that hashes low enough.

Part 1 can be done by many miners pooling together, while part 2 would mainly be done by 1 person (or one small group of people that trust each other enough to share the mining private key with one another -- this key gets all the profits of mining, so you want to make sure that anyone who has it is not going to take the money and run).

By adjusting the difficulties of these two components, it can be made easier/harder to pool mine. Since only the pool operator(s) can do phase 2, if phase 2 is made more and more difficult, then fewer pool operators will be able to complete the second part of the 2P-PoW, even if they have millions of miners doing Part 1.

This seems like a very good idea, except for one thing. How can we, in a decentralized way, determine how the difficulties should change? Ideally, you could have a way to see how much pool mining is going on, and if one pool has a large percentage of the mining power, then make the Part 2 difficulty higher. This could be done in a centralized way easily, but this starts to defeat the entire point of using cryptocurrency. It could be done with a hard coded parameters about the difficulty schedule, but what if we get it wrong and it either (1) makes the block chain extremely hard to mine and everyone just has to mine solo or (2) makes it extremely easy to do Part 2, and doesn't have the intended effect of limiting pool mining at all.

I don't know of any 2P-PoW coins. It is an interesting idea, but there doesn't seem to be a good way to alter the difficulty parameters in a decentralized way, and to be sure to meet the intended goal of limiting pool centralization.


Sign to Mine

In a sense, Sign to Mine is similar to just having the second phase of 2P-PoW, although it is implemented quite differently.

Sign to Mine (first implemented by ziftrCOIN) basically eliminates the nNonce field of block headers and replaces it with an ECDSA signature (R, S). As always, valid blocks must hash (hash of whole header, including signature) to a low enough value to satisfy the difficulty parameter. There is an additional rule, however, that blocks must also have a valid signature of the other parts of the block header, validated with the public key receiving payments in the coinbase (block reward) transaction. Essentially, Sign to Mine uses cryptography to ensure that the miner is able to spend the rewards for the mined block.

Sign to Mine makes it so that the person who mined the block (produced the right (R,S) pair to make the block header has low enough) has to also be able to spend the reward for that block. So, you can't really mine for the pool operator anymore, as you need a private key to mine and only the public key for the mining private key can be used to reap the profit from mining.

Miners who wish to pool together would likely mine individually and split up the rewards. This is problematic, though, because a member may accept rewards according to shares when he/she is not the one to solve the block, but then may steal the whole block reward when he/she is the one to solve the block. Hence, pooled mining is disincentivized.

If one is to participate in Sign to Mine pooled mining, then he/she would want to make sure that the other members of the pool are trustworthy and will fairly distribute the reward when they solve blocks.


Conclusion

There are sort of three levels of pooled mining disincentivization.

  1. (Bitcoin) No disincentives. Incentivize pooled mining through limiting variance of rewards.
  2. (2P-PoW) Some disincentives. Allow some pooled mining, but make it difficult to create unnecessarily large pools.
  3. (Sign to Mine) Completely disincentivized.

The middle ground, 2P-PoW, would be great if we could (in a decentralized way) determine how much pooled mining is going on. While it would be nice to be somewhere in the middle, the only complete solutions that exist are polarized. Either pool mining is completely allowed (Bitcoin), or it is mostly eliminated (Sign to Mine).

Bitcoin is unlikely to change, and centralization will likely be limited by conscientious miners choosing not to join excessively large pools. Unfortunately, this doesn't seem to limit centralization all that much. https://blockchain.info/pools

-2

Something like that: https://bitcointalk.org/index.php?topic=652443.msg7314429#msg7314429

Introducing some changes to the protocol, which would make it impossible for the pool and the miner to create a trust based contract.

  • I think that people might have downvoted because SE answers shouldn't be just a link, And the 2nd paragraph isn't specific. (The same could be said about my own answer, now that I think of it...) – Meni Rosenfeld Jun 15 '14 at 21:44
  • Thanks for noting that to me, I am not familiar with SE common law. – itamarhason Jan 18 '16 at 13:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.