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

Thanks for this wonderful pic.

Added more explanation about why my proposal works, and wish it helps

Yes if you could make p2Pool more attractive for hashers, it would make a big difference. I'm surprised none of the big guys like Bitpay/Gox/BTC-E etc. are putting funds into something like that.

They make more profit than the mining pools, and the biggest threat to their business (Bitcoin obv.) is the risks caused by centralisation of mining but they don't address it.

As I explained above, even there're three trusted monitors, they have to be alerted before the double spending is confirmed. It's hard to be found before it happens, but with my proposal, once a big pool changes a mining address, every one is warned.

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.

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?

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.

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.
 

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?

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.

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

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.

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

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.

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

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.

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

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.

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.

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?

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