A simple method to (probably) prevent big pools from 51% attacking

[BitThink]

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.

[Remember remember the 5th of November]

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

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), we no longer need to worry about them any more.

Any thoughts about that? May I add this suggestion to the hard-fork wishlist?

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.

[BitThink]

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

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), we no longer need to worry about them any more.

Any thoughts about that? May I add this suggestion to the hard-fork wishlist?

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.

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.

[Holliday]

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

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), we no longer need to worry about them any more.

Any thoughts about that? May I add this suggestion to the hard-fork wishlist?

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.

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.

So it would just ease everyone's nerves until they were finally ready to attack? Err... great?

[BitThink]

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

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), we no longer need to worry about them any more.

Any thoughts about that? May I add this suggestion to the hard-fork wishlist?

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.

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.

So it would just ease everyone's nerves until they were finally ready to attack? Err... great?

Once GBT is used, miners of a pool could reject a block if it's output address of coinbase tx is changed.

Anyone knows that in Stratum protocol whether the miner can know the mining address from the coinbase1 and coinbase2 sent from the pool?

Moreover, may I ask currently whether the pool operator can secretly changes its mining address for one block and avoid paying for that block?

[cr1776]

Go ahead and create your alt-bitcoind and see how many people want to use it. That will tell you if people think it is a good idea or not.

[BitThink]

Go ahead and create your alt-bitcoind and see how many people want to use it. That will tell you if people think it is a good idea or not.

No, I just want to contribute to rather than compete with the coin I like. Moreover, most people buy altcoin for pump and dump, and don't care about its feature at all. Finally, this is a quick and dirty fix based on the self decipiline of pool operators and miners, not an elegant solution worth a new altcoin.

EDIT:
Maybe I misunderstood what you say. Do you mean I create the bitcoind myself and ask others to use it. No, without being accepted by main pools, it will cause a hard fork. My bitcoind will never get the main chain once one main pool generates more than 6 blocks in a row and most miners accept it.

As long as the top 4 mining pools accept this patch, it will be safe. I think only Gavin and ops of those pools can do this.

EDIT
Changed reject to discourage. Now there's no hard fork issue.

[Luke-Jr]

Yes, but if a pool tends to use alternate address in mining, it proves itself malicious.

Not at all. Pools are supposed to use a new address for every transaction, just like everyone else.

[DannyHamilton]

Yes, but if a pool tends to use alternate address in mining, it proves itself malicious.

Not at all. Pools are supposed to use a new address for every transaction, just like everyone else.

Apparently we aren't allowed to demonstrate agreement with an opinion or add emphasis to a fact with a simple "+1".  I've recently had my "+1" posts removed.  Therefore, I'm typing out this message to indicate that I believe the quoted information needs extra emphasis to avoid being unnoticed in the rest of the chatter in this discussion. I may (or may not) also have added bold or underline tags to the text in the quote above to further emphasize the parts that I think are important to understand or be aware of.

[Kungfucheez]

You can't just tell a pool not to mine to an address. That's not how it works.

[BitThink]

Yes, but if a pool tends to use alternate address in mining, it proves itself malicious.

Not at all. Pools are supposed to use a new address for every transaction, just like everyone else.

Yes I know where you come from. My context, however, is if the patch is applied and all miners decided to use a fix address (at least never change address frequently, like they did now) to protect the bitcoin.

In this case, with your GBT, miners can easily forbid (at least discourage) the pool to change mining address frequently.

My proposal is create a version of cgminer, which rejects mining address change in a session. So if pool has to change mining address, it has to restart and let all the miners to reconnect.

Knowing that a coin is mined by which pool does not hurt the anonymity too much. Moreover, with a fix mining address helps in being transparent in pool running. People can easily verify the total hash rate, for example.

[BTC-TK]

There are different PoS-PoW hybrids that prevent 51% attacks, why reinvent the wheel?

[BitThink]

There are different PoS-PoW hybrids that prevent 51% attacks, why reinvent the wheel?

They cannot be introduced in BTC without causing hard forks. PoS is a dramatic change to the whole system. My proposal, however, is just a minor change and will not cause subtle issues.

[FandangledGizmo]

I'm not very technical, but it doesn't sound like your solution will do the job. But please keep trying to think of a solution, we need one!  

Pools look innocent but we must protect BTC against...

[BitThink]

Yes, but if a pool tends to use alternate address in mining, it proves itself malicious.

Not at all. Pools are supposed to use a new address for every transaction, just like everyone else.

+1

I also agree that using a new address for every transaction should be encouraged. Using one fix address for mining pool, however, does less harm and is commonly used now anyway.

[FandangledGizmo]

I know very little about how pool mining works.

Is it possible for a big mining pool to split their hashing power into 4 sections, but let 3 seperate Bitcoin Foundation members control access to 3 of the sections? So Ghash.io still gets all the profits but their control is a bit more decentralised.

E.g. Ghash.io has 40% of the network, but they give the 'keys' to 30% of the network to 3 different Bitcoin Foundation members who live in 3 seperate countries. so that in the event of a double spend attack the three trusted Bitcoin friendly parties holding the keys can turn off 75% of their hashing power at least in a process that lasts 24 hours or something giving the rest of the community enough time to create a defense if necessary?

This way no-one entity can control more than 10% of the hashing power but they can still get the profit from having 40% of the hashing power if their business model is the most popular?

[BitThink]

I know very little about how pool mining works.

Is it possible for a big mining pool to split their hashing power into 4 sections, but let 3 seperate Bitcoin Foundation members control access to 3 of the sections? So Ghash.io still gets all the profits but their control is a bit more decentralised.

E.g. Ghash.io has 40% of the network, but they give the 'keys' to 30% of the network to 3 different Bitcoin Foundation members who live in 3 seperate countries. so that in the event of a double spend attack the three trusted Bitcoin friendly parties holding the keys can turn off 75% of their hashing power at least in a process that lasts 24 hours or something giving the rest of the community enough time to create a defense if necessary?

This way no-one entity can control more than 10% of the hashing power but they can still get the profit from having 40% of the hashing power if their business model is the most popular?

The problem is that the bitcoin is supposed to be decentralized, so the foundation cannot be trusted. Otherwise, a much simpler way is just to introduce more official checkpoints or even official blockchain.

The essence of the decentralized network is that only the majority decides which is the valid chain and no need to trust any person or any organization.

Moreover, the double spend normally happens without alert, and cannot be easily reverted without causing a lot of messy.

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 annouce 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 reversed. 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 create a long private chain, and that will give us the alert. Moreover, if miners choose reject changing the mining address, the double spending will never work.
 

[FandangledGizmo]

I know very little about how pool mining works.

Is it possible for a big mining pool to split their hashing power into 4 sections, but let 3 seperate Bitcoin Foundation members control access to 3 of the sections? So Ghash.io still gets all the profits but their control is a bit more decentralised.

E.g. Ghash.io has 40% of the network, but they give the 'keys' to 30% of the network to 3 different Bitcoin Foundation members who live in 3 seperate countries. so that in the event of a double spend attack the three trusted Bitcoin friendly parties holding the keys can turn off 75% of their hashing power at least in a process that lasts 24 hours or something giving the rest of the community enough time to create a defense if necessary?

This way no-one entity can control more than 10% of the hashing power but they can still get the profit from having 40% of the hashing power if their business model is the most popular?

The problem is that the bitcoin is supposed to be decentralized, so the foundation cannot be trusted. Otherwise, a much simpler way is just to introduce more official checkpoints or even official blockchain.

I absolutely agree.

In the short term though 4 different people, 3 of them 'trusted' splitting Ghash.io hashing power is still better than the current system.

But yes we need to find a real, decentralised solution to this.

[gortonc]

From my very limited point of view the best way to thwart the 51% attack is to bolster p2Pool. If it were ever to grow to 51% the problem disappears--or am I misunderstanding something?

[BitThink]

From my very limited point of view the best way to thwart the 51% attack is to bolster p2Pool. If it were ever to grow to 51% the problem disappears--or am I misunderstanding something?

Yes, this is the best way to solve the problem. However, most miners are profit-driven so they all go to GHash.IO even when it has more than 40% of network hashing rate. This happened again and again before for deepbit, BTCGuild.

P2Pool cannot provide the same advantage of merge mining and it's efficiency is also an issue.

EDIT:

My mistake. P2Pool does provide merge mining.