Bitcoin Forum

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.

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?

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.

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.

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

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.

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.

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

http://nathblog.com/wp-content/uploads/2010/05/shark-surprise-attack.jpg

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

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.

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.

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

Thanks for this wonderful pic.

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

Yes, if we found a way for the big organizations to subsidize the P2Pool miners (more than compensate their loss in choosing P2Pool), then maybe it's network share will increase.

Nonetheless, since my proposal does not cause any hard fork, so it can be added and removed (once p2pool rules the mining world) without causing too much troubles. It will also be fine to keep it in the code forever.

OK but what can you do once you are warned if they control the hashing power? Lets say someone takes control of BTCGuild and Ghash.io and get 60% of the total hashing power. They change the address. We get the warning but what can we do? They have 60% of the hashing power?

Is the idea that enough of their hashing power comes from external hashers, who once the warning goes off can direct their hashing power to a different pool?

I have asked this before without an answer.

We have all heard of botfarms created by trojans that mine for bitcoin. It is my understanding that the combined cpu power makes it worthwhile with simple machines. If this is true could we not all (or at least some of us) volunteer into such a "botnet" for p2Pool? Do we need high powered miner machines to contribute?

I am more concerned about the 51% issue that the piddling amount I could make mining on my own.

Yes, exactly the miners could choose to reject mining to a different address.

But in your example, if the one controls both BTCGuild and Ghash.io, they don't need to change the mining address even with my proposed patch. My proposal cannot prevent multiple pools to double spend together, unfortunately.

We could run a cpu miner and join the p2pool now, but currently the hashing rate of CPU mining is negligible.

Normal i5 - i7 can mine at around 10MH/s, and currently the total network hashing rate is 15 PH ( = 15,000,000,000 MH) and still increases fast. Therefore, even we found 1 billion volunteers, the total CPU hash rate is only 10 PH.

OK, thanks--that answers my question.  :'(

Nobody is "supposed to" do anything.  Bitcoin can be used by anyone any way they see fit.  They have the ability to use different addresses if that is what they want to do.

:) I think this is already debated in Luke's own thread for months already. I agree that his reasons make sense in many scenarios.
However, I think knowing from which pool coins are mined does not affect the anonymity too much. Moreover, most pools do use one fix mining address now.

Can you choose which pool you want to process your transaction?

I mean, is the problem now that if you made a 'patch' to the protocol that favoured P2Pool,  the big mining pools would never switch over to that version of Bitcoin and as they control the hashing power, they control Bitcoin. 

But what if the 5 biggest exchanges as well as Bitpay, Blockchain.info and Satoshi dice all said from this date and this time we are only sending our transactions to P2Pool?  Maybe those big players make up such a big % of the total transactions that the the big pools will be processing such a small % of transactions, and will be so totally against the will of the community, that the smaller fork will be the real fork.   

If it is pre-announced, hashers should pre-emptively switch to P2Pool anyway and enough of the friendly big pools, BTC Guild and Eligius might reluctantly point their own equipment into P2Pool too, maybe giving the new Bitcoin patch 51% of the hashing power anyway.

Leaving a 'potentially' nefarious Ghash.io stranded? 

In a P2P network, you cannot control where you send the transaction. You announce your transaction to the nodes connecting with you and they will relay it to their neighbours and go on.

Moreover, I don't think there can be a 'patch' to favour P2Pool. Bitcoin protocol itself has no favour to any miner as long as they can create a correct block.

Random thought... not to derail your topic (sorry)


Could government or banks have an incentive to pay pools like CEX.IO billions of dollars for them to do a 51% attack and jeopardize the value and integrity of network in order to destroy bitcoin?

If the price is right it could be worth doing for CEX.IO...... billions of $ sounds like a lot for something like this, but for central banks and governments it would be worth it to kill off the threat of bitcoin if you think about it.

With that amount of money, they could just secretly buy enough hashing power and do the 51% attack. No need to do it in public (you can never trust CEX.IO to keep the secret).

However, killing BTC secretly does not help much if cryptocurrency is a thread to them. It will only help the GPU coins (litecoin) and CPU coins (primecoin) to emerge. A safer way for them is to own BTC and try to control BTC just like they regulate the gold, and in my opinion it is also easier.

Thanks! I really appreciate you taking the time to give me that response. I know a non technical guy like me actually helping to find a solution to this problem, would be akin to Homer Simpson helping to find a cure for cancer, but you never know! I guess I want to show that I'm not just complaining about the problem, but I am trying to get involved/help as limited as that help might be.   

Yes you can because you can control which nodes you connect to if you want.  You can start Bitcoin-QT with options to connect to specific nodes and only those specific nodes.  Most users probably just connect without those options but you can do it pretty easily. 

But  how can  anyone get a 51% besides Ghash.io at this moment?

You can control who you connect, but cannot control who your connectors connect.

Sure, any suggestion and discussion is welcome. I'm just explain why your idea does not work. In my opinion, no idea is useless or stupid.

Cool, if you're bored, dumb idea no.2, could someone tell me why just speeding up the blocks isn't an option?

As I understand it a big incentive of pool mining is consistency of earnings.
The blocks come around so infrequently that unless you're in a decent size pool you will experience a lot of volatility.

How hard is it to change the block reward to 0.25 and have a new block found every 6 seconds?

That way you're 100X more likely to find a block and it will decrease volatility of earnings, thereby dis-incentivising pool mining.
(Of course you would probably need to wait for 300 confirmations vs. 3 but it would take the same amount of time.)

When you solve a block, all the other nodes on the network aren't instantaneously aware of it through any sort of quantum entanglement.  Instead, you have to broadcast the block to your peers (who then relay it to their peers, who then relay it to ...).  This means it can take a little bit of time for the entire network to hear about a recently solved block.

Until they've heard about the recent block any miner (or mining pool) will still be diligently working on their own block.  If difficulty is such that blocks come very quickly, then it is far more likely that several people will all solve blocks before all the solved blocks have been relayed throughout the entire network.

This then creates a temporary fork in the blockchain with various sections of the network each working on a block for a different fork.  Eventually one of the forks will win out, but in the meantime, anyone who put any effort into any of the other forks will have wasted effort on orphaned chains.

Cool, thanks for the clear reply. Appreciate it! 

So I guess, 6 seconds is pretty crazy. But Litecoin seems to do OK with 2.5 minute blocks? Is something in this range possible for Bitcoin and do you think it would help with decreasing volatility in smaller pools or not really enough of a difference to justify such a major change.