<p>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.</p>

CC BY-SA 3.0
2014-06-15T12:28:39.043Z
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
CC BY-SA 3.0
2014-06-15T14:59:18.120Z
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
CC BY-SA 3.0
2014-06-16T17:22:30.450Z
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
CC BY-SA 3.0
2014-06-15T09:39:05.593Z
2014-06-15T09:39:05.593Z
David Schwartz
<p>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% (<a href="http://www.coindesk.com/bitcoin-miners-ditch-ghash-io-pool-51-attack/" rel="nofollow">source</a>). </p>

CC BY-SA 3.0
2014-06-14T13:00:38.293Z
2014-06-14T13:00:38.293Z
Mathias711
<p>Ok, I'll take a shot at this.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2015-01-04T23:37:13.460Z
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
CC BY-SA 3.0
2014-06-15T12:59:24.363Z
2014-06-15T12:59:24.363Z
Fraggle
<p>Mining pools are an important part of the Bitcoin ecosystem and I don't believe they should be disincentivized.</p>

<p>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 <a href="https://bitcointalk.org/index.php?topic=281180.0" rel="nofollow">Multi-PPS</a>.</p>

CC BY-SA 3.0
2014-06-15T12:22:45.123Z
2014-06-15T12:22:45.123Z
Meni Rosenfeld
<p><strong>Staying within the bounds of the current Bitcoin protocol, there is really no way to do this.</strong> 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.</p>

<p>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.</p>

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

<hr>

<h1>2P-PoW</h1>

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

<blockquote>
  <p>A two-phase PoW consists of a block that has two separate cryptopuzzles in it. Under a two-phase PoW: </p>
  
  <ol>
  <li>The double hash of the header (SHA256(SHA256(header))) is smaller than a difficulty parameter X, and </li>
  <li>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.</li>
  </ol>
</blockquote>

<p>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. </p>

<p>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). </p>

<p>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. </p>

<p>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. </p>

<p>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.</p>

<hr>

<h1>Sign to Mine</h1>

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

<p>Sign to Mine (first implemented by <a href="https://www.ziftrcoin.com/what-is-ziftrcoin/coin-specifications/" rel="nofollow">ziftrCOIN</a>) basically eliminates the <code>nNonce</code> 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. <strong>Essentially, Sign to Mine uses cryptography to ensure that the miner is able to spend the rewards for the mined block.</strong></p>

<p>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 <em>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</em>. </p>

<p>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. </p>

<p>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. </p>

<hr>

<h1>Conclusion</h1>

<p>There are sort of three levels of pooled mining disincentivization.</p>

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

<p>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).</p>

<p><strong>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. <a href="https://blockchain.info/pools" rel="nofollow">https://blockchain.info/pools</a></strong></p>

CC BY-SA 3.0
2015-01-05T00:48:46.857Z
2015-01-05T03:11:08.173Z
2015-01-05T03:11:08.173Z
morsecoder
<p>Mining pools are the biggest problem of Bitcoin and I'm surprised by the fact no one cares. You cannot force a mining pool to follow the rules. This would break the paradigm of trustlessness which is the Bitcoin's main strength point. It would be ridiculous if after tons of gigawatt hours spent in hashing you should beg a mining pool admin to be honest and not to make up the next block with fake transactions. Mining pools will be the Bitcoin's doom but too few people are aware of it. As of now Bitcoin is strongly centralized and its protocol is not designed to prevent pools from doing damages.</p>

CC BY-SA 4.0
2019-08-09T14:55:12.247Z
2019-08-09T14:55:12.247Z
Viktor Joras
<p>This came to me while I was sleeping, and I don't know if somebody else has proposed this:</p>
<ol>
<li><p>the miner calculates the nonce in the regular way, however, instead of adding his normal public key in the block, he is required to add an unsafe public key, for example sake i'll assume a public key generated using a string of just 32 ones and zeroes, the difficulty to search the private key through a premade database(Fastest way), should be about 5-10 seconds.</p>
</li>
<li><p>when the miner successfully mines the block, he/she announces the block and Then immediately fires a transaction order using the unsafe private key to move his reward to a normal address he/she has. the network transfers the coins from the unsafe key to the  secure/normal, taking the first order it receives as valid.</p>
</li>
</ol>
<p>this will prevent large groups of miners who do not trust each other, if one of the miners in a pool cracks the nonce, he/she can easily get the private key and announce it as his own and fire the transaction first, thus claiming the reward.</p>
<p>the private key length would have to be decided by the community to keep the time to get the private key within a certain limit, making it too small would mean multiple people announcing it for themselves without actually mining the block, and making it too long would mean miners in pools disincentivized to claim it for for themselves.</p>

CC BY-SA 4.0
2021-02-27T23:59:25.027Z
There is no such thing as an "md5 public key". Md5 is a hash function.
Pieter Wuille
CC BY-SA 4.0
2021-02-28T05:14:25.827Z
@PieterWuille Thanks, I corrected it, if there are any further mistakes, ill fix them. if you find any flaws in the method, please tell me.
MiqdaadIndori
CC BY-SA 4.0
2021-02-28T11:11:45.937Z
Welcome to bitcoin.stackexchange.com This isn't a suitable place to hold *discussions* concerning suggestions for changes to Bitcoin protocols etc. You might like to produce working code, an example database and mathematical proofs and submit them to a more suitable forum.
RedGrittyBrick
CC BY-SA 4.0
2021-02-28T13:23:26.213Z
@RedGrittyBrick Ok, where can I discuss/ask these kinds of things? Btw is there a obvious flaw in the above?
MiqdaadIndori
CC BY-SA 4.0
2021-02-27T14:42:00.283Z
2021-02-28T06:46:51.563Z
2021-02-28T06:46:51.563Z
MiqdaadIndori
<p>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?</p>

CC BY-SA 3.0
2014-06-15T16:16:22.013Z
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.
itamarhason
<mining-pools><weaknesses><wealth-distribution>
What would be required to disincentivize mining pools?
fbrereto
# What would be required to disincentivize mining pools?

(Asked by: username_0 on 2014-06-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?

**Tags:** mining-pools, weaknesses, wealth-distribution

> **Comments:**
> **username_1**: 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.  

---

## 7 answers

### Answer by username_2 on 2014-06-15. Score: 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.

> **Comments:**
> **username_3**: 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?  
> **username_2**: 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.  
> **username_0**: 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.  

---

### Answer by username_4 on 2014-06-14. Score: 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](http://www.coindesk.com/bitcoin-miners-ditch-ghash-io-pool-51-attack/)).


---

### Answer by username_3 on 2014-06-15. Score: 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.

> **Comments:**
> **username_5**: 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.  

---

### Answer by username_6 on 2014-06-15. Score: 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](https://bitcointalk.org/index.php?topic=281180.0).


---

### Answer by username_5 on 2015-01-05. Score: 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](https://www.ziftrcoin.com/what-is-ziftrcoin/coin-specifications/)) 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>**


---

### Answer by username_7 on 2019-08-09. Score: 0

Mining pools are the biggest problem of Bitcoin and I'm surprised by the fact no one cares. You cannot force a mining pool to follow the rules. This would break the paradigm of trustlessness which is the Bitcoin's main strength point. It would be ridiculous if after tons of gigawatt hours spent in hashing you should beg a mining pool admin to be honest and not to make up the next block with fake transactions. Mining pools will be the Bitcoin's doom but too few people are aware of it. As of now Bitcoin is strongly centralized and its protocol is not designed to prevent pools from doing damages.


---

### Answer by username_8 on 2021-02-27. Score: -2

This came to me while I was sleeping, and I don't know if somebody else has proposed this:

1. the miner calculates the nonce in the regular way, however, instead of adding his normal public key in the block, he is required to add an unsafe public key, for example sake i'll assume a public key generated using a string of just 32 ones and zeroes, the difficulty to search the private key through a premade database(Fastest way), should be about 5-10 seconds.
2. when the miner successfully mines the block, he/she announces the block and Then immediately fires a transaction order using the unsafe private key to move his reward to a normal address he/she has. the network transfers the coins from the unsafe key to the secure/normal, taking the first order it receives as valid.

this will prevent large groups of miners who do not trust each other, if one of the miners in a pool cracks the nonce, he/she can easily get the private key and announce it as his own and fire the transaction first, thus claiming the reward.

the private key length would have to be decided by the community to keep the time to get the private key within a certain limit, making it too small would mean multiple people announcing it for themselves without actually mining the block, and making it too long would mean miners in pools disincentivized to claim it for for themselves.

> **Comments:**
> **username_9**: There is no such thing as an "md5 public key". Md5 is a hash function.  
> **username_8**: @username_9 Thanks, I corrected it, if there are any further mistakes, ill fix them. if you find any flaws in the method, please tell me.  
> **username_10**: Welcome to bitcoin.stackexchange.com This isn't a suitable place to hold *discussions* concerning suggestions for changes to Bitcoin protocols etc. You might like to produce working code, an example database and mathematical proofs and submit them to a more suitable forum.  
> **username_8**: @username_10 Ok, where can I discuss/ask these kinds of things? Btw is there a obvious flaw in the above?  

---

