Topic: Simple adjustment to prevent mining pools - page 2. (Read 2450 times)
Mining Pools are not bad and do not need to be prevented.
So first thing I would point out if Bitcoin will never be changed that radically so all this is academic but it may have some merit in an alt-coin.
It is an interesting idea. It would kill mining pools as the exist today and greatly raise the barrier for organizing in a trust free (or reduced trust) manner but there would be ways around it. The "way around" would be a method where the miner can sign (under limited conditions) without having access to the key itself.
This is a problem which already exists in PKI systems and there are solutions such as Trusted Platform Module, Smart Cards, and Hardware Security Modules which could be adapted to the problem this would prevent. While keys can be extracted from these technologies the cost is generally prohibitive and pools could change the coinbase key periodically to ensure the cost of key recovery is always greater than the value of a recovered key.
One thing to consider (once again academically) is the effect this would have on botnets. Any coin using this would be a "CPU coin" and botnets would dominate the network hashrate. The signing protocol could be tweaked by using two nonces (an inner nonce which is signed, and an outer nonce which isn't). By having difficulty control the average number of hashes that would be needed for a solution there would be two parameters that could be used to strike a balance between decentralization and node resources (i.e. making average node controlled by botnet ill suited to mining).
Even if it didn't completely remove pools if mining pools were smaller and more fragmented it would resolve most of the concerns anyways.
It is an interesting idea. It would kill mining pools as the exist today and greatly raise the barrier for organizing in a trust free (or reduced trust) manner but there would be ways around it. The "way around" would be a method where the miner can sign (under limited conditions) without having access to the key itself.
This is a problem which already exists in PKI systems and there are solutions such as Trusted Platform Module, Smart Cards, and Hardware Security Modules which could be adapted to the problem this would prevent. While keys can be extracted from these technologies the cost is generally prohibitive and pools could change the coinbase key periodically to ensure the cost of key recovery is always greater than the value of a recovered key.
One thing to consider (once again academically) is the effect this would have on botnets. Any coin using this would be a "CPU coin" and botnets would dominate the network hashrate. The signing protocol could be tweaked by using two nonces (an inner nonce which is signed, and an outer nonce which isn't). By having difficulty control the average number of hashes that would be needed for a solution there would be two parameters that could be used to strike a balance between decentralization and node resources (i.e. making average node controlled by botnet ill suited to mining).
Even if it didn't completely remove pools if mining pools were smaller and more fragmented it would resolve most of the concerns anyways.
In calculating the hash of a block, currently the following data is hashed :
Block version number, previous block hash, hash merkle root, time, difficulty, nonce
Mining pools outsource this work to clients, for example by altering the coinbase transaction (and thus the merkle root) for each client (this transaction not require tx input, and may contain random data), thereby avoiding duplication of effort between different clients.
When the clients are hashing and they reach the difficulty set by the mining pool (lower than the official Bitcoin difficulty), they send this hash to the server to prove that they have performed work. Once in a while, this hash is sufficient to mine a real block : anyone who has previously shown to have performed work will receive their proportional ratio of Bitcoins. First the Bitcoins in the new block will be send to the Bitcoin address of the mining pool (coinbase transaction), and subsequently the mining pool itself divides the amount among the clients.
The problem of mining pools is the risk of 51 % attacks because of the centralization of mining power.
With a simple adjustment, I believe it is possible to prevent mining pools:
Calculating the hash of a block is done in a slightly different way.
First, the following data will be signed by the address listed in the coinbase transaction:
Block version number, previous block hash, hash merkle root, time, difficulty, nonce
Then, the final block hash will be calculated on the basis of the following data:
Block version number, previous block hash, hash merkle root, time, difficulty, nonce, signature + public key coinbase address
This signature + public key is included in the block so that it can be verified that the owner of the private key of the coinbase address has signed this data. This also means that there is a sign operation at each hash calculation.
benefits :
If mining pools want to outsource their work to clients, they constantly receive sign requests from the clients, causing an enormous increase in server load (proportional to the amount of work done by clients). Since the sign operation is the slowest operation, the majority of the work cannot be performed on anonymous clients anymore. Or they send the private keys of the coinbase address to their clients, which means that all these clients can claim the coins when a block is found.
cons:
Miners must constantly keep their private keys in memory because they are constantly signing and this may increase the chance that these keys are stolen. But miners are obviously no ordinary users and a greater awareness of security can be expected.
This change causes a compatibility break with old blocks and could trigger the development of ASICs that can execute elliptic curve operations. It is quite radical in that sense, but in terms of implementation in the Bitcoin protocol the change would be minor.
Block version number, previous block hash, hash merkle root, time, difficulty, nonce
Mining pools outsource this work to clients, for example by altering the coinbase transaction (and thus the merkle root) for each client (this transaction not require tx input, and may contain random data), thereby avoiding duplication of effort between different clients.
When the clients are hashing and they reach the difficulty set by the mining pool (lower than the official Bitcoin difficulty), they send this hash to the server to prove that they have performed work. Once in a while, this hash is sufficient to mine a real block : anyone who has previously shown to have performed work will receive their proportional ratio of Bitcoins. First the Bitcoins in the new block will be send to the Bitcoin address of the mining pool (coinbase transaction), and subsequently the mining pool itself divides the amount among the clients.
The problem of mining pools is the risk of 51 % attacks because of the centralization of mining power.
With a simple adjustment, I believe it is possible to prevent mining pools:
Calculating the hash of a block is done in a slightly different way.
First, the following data will be signed by the address listed in the coinbase transaction:
Block version number, previous block hash, hash merkle root, time, difficulty, nonce
Then, the final block hash will be calculated on the basis of the following data:
Block version number, previous block hash, hash merkle root, time, difficulty, nonce, signature + public key coinbase address
This signature + public key is included in the block so that it can be verified that the owner of the private key of the coinbase address has signed this data. This also means that there is a sign operation at each hash calculation.
benefits :
If mining pools want to outsource their work to clients, they constantly receive sign requests from the clients, causing an enormous increase in server load (proportional to the amount of work done by clients). Since the sign operation is the slowest operation, the majority of the work cannot be performed on anonymous clients anymore. Or they send the private keys of the coinbase address to their clients, which means that all these clients can claim the coins when a block is found.
cons:
Miners must constantly keep their private keys in memory because they are constantly signing and this may increase the chance that these keys are stolen. But miners are obviously no ordinary users and a greater awareness of security can be expected.
This change causes a compatibility break with old blocks and could trigger the development of ASICs that can execute elliptic curve operations. It is quite radical in that sense, but in terms of implementation in the Bitcoin protocol the change would be minor.
Jump to: