One known way to prevent an incentive for a malicious 51% attack is to introduce a PoS innovation to the mining algorithm. In other words, the more BTC you own, the less hashing you need to do. Thus, miners would need to be stakeholders in BTC and thus creating network disruptions would be clearly against their interests. They have 'skin in the game'. Another effect would be that the demand for BTC would increase significantly(which would cause an increase in price).
The most well known problem with PoS is something called Nothing At Stake. If we had hybrid algo, there is something at stake(computation resource) which does not eliminate the problem of N@S altogether but would probably effectively mitigate it. N@S suggests that you can create many alternative timelines at once and exploit that, however with a hybrid model, these alternative timelines cost computing power(and thus introduce a net disadvantage).
I think some of these ideas about preventing mining pools are somewhat awkward.
This solution would be generally non-disruptive and most certainly would have a very positive effect on the price of BTC.
-bm
Topic: Preventing Pool Mining - page 2. (Read 3441 times)
Pool mining centralization is a serious issue. Some think this can be solved by changing the reward system (Multi PPS as an example), or by finding an ASIC resilient hash function (no known good candidate).
I would like to discuss the option of changing the protocol to prevent pool mining.
I have an idea to start with, please say what you think of it. My suggestion is to add to the header, two new fields:
In addition, the mining reward should be automatically given to the above public address, and transactions involving this address as input shall be forbidden in this block (to prevent a more sophisticated share distributions).
Adding these two fields, at least naively, should prevent pool mining, since in order to mine a block, you must know the private key corresponding to the rewarded public address. (I think it could work also with M=0, but I think M>0 makes it much riskier to use any trust-based pool)
P.S. I recognize the need in pool mining (mining reward variance etc.), but I think such issues can be solved by decreasing the block time substantially (to, say, 1 second, instead of 10 minutes, using GHOST).
I would like to discuss the option of changing the protocol to prevent pool mining.
I have an idea to start with, please say what you think of it. My suggestion is to add to the header, two new fields:
- A bitcoin public address, which owns some minimal amount M of BTCs
- A signature of the header (excluding, of-course, this field - the signature itself) using the private key corresponding to the above public address
In addition, the mining reward should be automatically given to the above public address, and transactions involving this address as input shall be forbidden in this block (to prevent a more sophisticated share distributions).
Adding these two fields, at least naively, should prevent pool mining, since in order to mine a block, you must know the private key corresponding to the rewarded public address. (I think it could work also with M=0, but I think M>0 makes it much riskier to use any trust-based pool)
P.S. I recognize the need in pool mining (mining reward variance etc.), but I think such issues can be solved by decreasing the block time substantially (to, say, 1 second, instead of 10 minutes, using GHOST).
Jump to: