user4154: 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?

user15412: 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). 

user575: 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.

user16926: 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.

user85: 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.

4154: <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>
 15412: <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>
 575: <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>
 16926: <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>
 85: <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>
