user33: Within the coming weeks both Namecoin and SolidCoin have been threatened with the same attack. What can be done by the users, pool operators and developers of these forks to either;
A. Minimise damage.
B. Stop it altogether.

user307: The Bitcoin network is currently the worlds fastest distributed computing network.  It gains security through size.  
The large pool issue is real however it can be overcome without flawed centrally controled digital currencies.
One example is p2pool.  It is a pool where miners share rewards but each miner independently generates their own block header including only valid transactions.
https://en.bitcoin.it/wiki/P2Pool 
The only risk that large pools represent is the fact that currently miners are "dumb".  The pool generates header and submit the merkle tree hash to the miner which "blindly" hashes it.  If the pool has nefarious goals it can use the miner's hashing power against the network.  Now it is unlikely this would happen because large pools have a vested interest in keeping the network and thus coins valuable and continuing their existance.  Still the network would be improved if the miner generates the header rather than the pool.
Now p2pool is a completely decentralized mining pool.  They don't even have a website.  Miners simply join the peer to peer network and are compensated for their work.
Still many miners may like the advantages of a more traditional pool.  This doesn't mean the header generation can't be distributed.  Using algorithms implemented in p2pool a traditional pool could decentralize the header generation.  With decentralized header generation each miner is working indendepdently.  The purpose of the pool is merely to reduce volatility.  
This would complete eliminate the small risk of a pool operator using miner's to work against the network.
Bitcoin users who are concerned about the influence of large pools and the risk that centralized header generation represent should either use p2pool or push for other pools to adopt a distributed block generation mechanism similar to p2pool.  If blocker header generation is decentralized then there is no risk of subversion even if a single pool has 100% of hashing power.

user85: There are two basic fronts on which they can defend, and they really do have to do both.
First, they need to increase their total hashing power. 51% of a very large number is much harder for an attacker to muster than 51% of a small number. Merged mining is probably the most realistic way for these currencies to accomplish this.
Second, they need to fix specific vulnerabilities in their difficulty adjusting algorithms. Some of these attacks requires less than 51% of the hashing power or do more damage than they should because of specific weaknesses in the difficulty-adjusting algorithm.
Alternative currencies are vulnerable to hash rate decrease attacks. To resist them, they've adjusted their difficulty algorithms so that difficulty can drop rapidly. Unfortunately, these algorithms have been found to have unexpected defects. Because strict timestamp accuracy can't be enforced, an attacker can maliciously inject false timestamps into mined blocks to cause the difficulty to drop very, very quickly. This allows a malicious group of coordinated miners to extract a very large number of coins in a very small period of time with relatively little hashing power.
Effort will be needed to fix these algorithms so that they still provide protection against a hash rate decrease attack but don't create even more serious new vulnerabilities.
It may well be a rocky road these next few weeks. The 51% attack is fundamental to the decentralized nature of these currencies -- the only solution is more hashing power. But the difficulty algorithm attack issues will likely be solved by fixing the algorithms.

33: <p>Within the coming weeks both Namecoin and SolidCoin have been threatened with the same attack. What can be done by the users, pool operators and developers of these forks to either;</p>

<p>A. Minimise damage.</p>

<p>B. Stop it altogether.</p>
 307: <p>The Bitcoin network is currently the worlds fastest distributed computing network.  It gains security through size.  </p>

<p>The large pool issue is real however it can be overcome without flawed centrally controled digital currencies.</p>

<p>One example is p2pool.  It is a pool where miners share rewards but each miner <strong>independently generates their own block header</strong> including only valid transactions.</p>

<p><a href="https://en.bitcoin.it/wiki/P2Pool" rel="nofollow">https://en.bitcoin.it/wiki/P2Pool</a> </p>

<p>The only risk that large pools represent is the fact that currently miners are "dumb".  The pool generates header and submit the merkle tree hash to the miner which "blindly" hashes it.  If the pool has nefarious goals it can use the miner's hashing power against the network.  Now it is unlikely this would happen because large pools have a vested interest in keeping the network and thus coins valuable and continuing their existance.  Still the network would be improved if the miner generates the header rather than the pool.</p>

<p>Now p2pool is a completely decentralized mining pool.  They don't even have a website.  Miners simply join the peer to peer network and are compensated for their work.</p>

<p>Still many miners may like the advantages of a more traditional pool.  This doesn't mean the header generation can't be distributed.  Using algorithms implemented in p2pool a traditional pool could decentralize the header generation.  With decentralized header generation each miner is working indendepdently.  The purpose of the pool is merely to reduce volatility.  </p>

<p><strong>This would complete eliminate the small risk of a pool operator using miner's to work against the network.</strong></p>

<p>Bitcoin users who are concerned about the influence of large pools and the risk that centralized header generation represent should either use p2pool or push for other pools to adopt a distributed block generation mechanism similar to p2pool.  If blocker header generation is decentralized then there is no risk of subversion even if a single pool has 100% of hashing power.</p>
 85: <p>There are two basic fronts on which they can defend, and they really do have to do both.</p>

<p>First, they need to increase their total hashing power. 51% of a very large number is much harder for an attacker to muster than 51% of a small number. <a href="https://bitcoin.stackexchange.com/questions/273/merged-mining-how-will-it-work">Merged mining</a> is probably the most realistic way for these currencies to accomplish this.</p>

<p>Second, they need to fix specific vulnerabilities in their difficulty adjusting algorithms. Some of these attacks requires less than 51% of the hashing power or do more damage than they should because of specific weaknesses in the difficulty-adjusting algorithm.</p>

<p>Alternative currencies are vulnerable to <a href="https://bitcoin.stackexchange.com/questions/289/what-happens-if-hash-rate-decreases-rapidly">hash rate decrease</a> attacks. To resist them, they've adjusted their difficulty algorithms so that difficulty can drop rapidly. Unfortunately, these algorithms have been found to have unexpected defects. Because strict timestamp accuracy <a href="https://bitcoin.stackexchange.com/questions/915/why-dont-the-timestamps-in-the-block-chain-always-increase/973#973">can't be enforced</a>, an attacker can maliciously inject false timestamps into mined blocks to cause the difficulty to drop very, very quickly. This allows a malicious group of coordinated miners to extract a very large number of coins in a very small period of time with relatively little hashing power.</p>

<p>Effort will be needed to fix these algorithms so that they still provide protection against a hash rate decrease attack but don't create even more serious new vulnerabilities.</p>

<p>It may well be a rocky road these next few weeks. The 51% attack is fundamental to the decentralized nature of these currencies -- the only solution is more hashing power. But the difficulty algorithm attack issues will likely be solved by fixing the algorithms.</p>
