Topic: A simple method to (probably) prevent big pools from 51% attacking - page 3. (Read 3041 times)

Yes, but if a pool tends to use alternate address in mining, it proves itself malicious. I suppose all pools are eager to prove themselves are good guys now.

Just because a pool uses the same address to mine blocks, doesn't mean it is forced to do it. If what you are suggesting is implemented(and it won't for obvious reasons), the pool will just change the address.

If a hard-fork is allowed,In bitcoind 0.9, could we forbid discourage one address to mine more than N (maybe = 6) blocks in a row? In other words, the new bitcoin clients will give lower weight to (N + 1)th block mined by address A if the previous N blocks mined by A.

Normally we calculate chain length by sum(difficulty), but if a block is a 6th block mined by the same address in a row, we give it a 0.5 weight, then 0.25 for 7th, 0.125 for 8th... In this case, a long chain mined by the same address always has less sum(diff) than a normal 6 chain.

This certainly will not prevent general 51% attacking since the attacker can change the mining address easily, but considering currently most mining pools are using one mining address, it will be useful to avoid panic caused by big mining pools. As long as the big mining pool promise to use one address (easily verifiable and maybe can be guaranteed (see 3)), we no longer need to worry about them any more.

Any thoughts about that?

EDIT: Maybe we can include this patch into 0.9 already. Suppose we include this in 0.9, what will happen?
1) Will pools will be affected? I've checked the history, it is very rare for a pool to mine more than 6 blocks in a row now, therefore pools don't need to worry that they have to give up mining a block frequently.
2) Will hard fork caused by this patch? As long as all the big pools installed the new version, it is almost impossible for small miners to mine 6 blocks in a row. Therefore, as long as Gavin has the consensus from the main pool operators, it's safe to include in 0.9 without causing problem.
    Changed from 'reject' to 'discourage', and no need to worry about hard fork any more.

3) For Stratum and GBT protocol, a new pool miner software can be released so that a pool has a pre-configured mining address and the miner will reject any task having a different coinbase output address.

EDIT:
One main drawback is this cannot prevent multiple pools (probably run by the same person) work together to double spend. Nonetheless, it's still better than now.


EDIT: added an example to show why my proposal helps preventing pool from double spending
Here's an example:

Suppose a big pool P has 51% of network hashing rate, and decides to double spend. He spend a large number of BTC in block 300000, and then his pool secretly quit the main chain and mining his own 300000'. He mined 300000', 300001', ..., but keep it secret without publishing. Once the main chain arrives 300005, his spending has got 6 confirmation already and he get whatever he bought, he announces his private chain (at that time, it's longer than 6 due to his higher hashing rate than others). Only at this time, people will notice the double spending, but according to the rule of bitcoin protocol, the longer chain always wins, so 300000' - 300006' wins. There will be a reorganization, and the block 300000 to 300005 are orphaned. No one can fix this without causing hard forks.

If my proposal is approved, this pool cannot double spend without changing his mining address. Otherwise, his 7-chain (or even 8-chain, 10-chain, 100-chain) has less sum(diff) than the main 6-chain so it cannot replace the main chain at all. Therefore, the pool has to change the mining address when he secretly mines a long private chain, and that will give us the alert. Moreover, if miners choose to reject changing the mining address for a pool, this kind of double spending will never work.