Good point, I hadn't considered that, that would be the opposite of the desired effect.
It makes me see mining pools in a different light: possibly a necessity to form a block against server farms.

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.

I would like to contribute the following post to https://bitcointalk.org/index.php?topic=114664.40 :

As you can hopefully see, I have a significant amount of knowledge about the different coins.

Thanks in advance,


My post:

Bitcoin is brilliant except for to senseless calculations everybody is performing to mine a block.  It's great to see that this single oddity has also been resolved using coin age in PPCoin.  However, it's clear that there's still the issue of missing incentive to process transactions when minting a new block.

Many possible solutions have been suggested already, hereby another one:

Let's say that for example on average 2880 coin days per day (24 hour) are destroyed in transactions, and let's also say that it is desired that every 5 minutes a new block is minted for fast transaction processing, on average every block should then process transactions worth 10 coin days.

The system could then mandate that only blocks that process transactions worth at least 10 coin days are valid blocks.  Just like Bitcoin's difficulty this amount could be adjusted every x blocks: if it turns out after x blocks that there are not enough coin days destroyed in transactions to reach a 5 minute average, the mandatory amount is lowered and vice versa.  There is no need to pay any incentives to minters, to earn your 1% interest you must process transactions.

There is also no need to process more than (in this example) 10 coin days, because this will not increase the amount of interest you will receive.
The amount of coin age contributed to the blockchain by a block is the sum of destroyed coin age of the processed transactions and the destroyed coin age of the minted coins (interest receiving coins).  This will ensure that every minter will still be able to collect its 1% in due course and that older transactions will have a higher likelyhood of being processed because of the building up of coin age the longer they are not processed.

However, there is one problem with this scenario (or perhaps more that I'm not aware of).  A minter could decide to process more than the required amount of transaction coin days, to increase his chances of ending up in the blockchain or to perform a little bit of sabotage by submitting a block with lots of transactions forcing a reorganization of the blockchain. 

This problem can be a countered with the following measure:
The amount of coin age contributed to the blockchain by a block is the minimum required amount of processed transactions (in my example 10 coin days), regardless of the actual amount of processed transactions + the destroyed coin age of the minted coins (interest receiving coins) + fixed amount per block (this is not a reward to anyone, but only a contribution to the total coin age of the blockchain).

Let's look at an example to see what this will achieve:
Let's say we have 30 coin days worth of transactions to process, and the minimum required amount is 10 coin days.  Let's say the fixed amount per block is 5 coin days, and all the actors combined per fork have the same amount of coin days to mint, for example 7.

In fork A they only process the minimum required amount of coin day transactions per block (10 coin days), in fork B they process more (15 coin days).

The total amount of coin days contributed to the blockchain in fork A is: 10 + 5 + 10 + 5 + 10 + 5 + 7 = 52 coin days.
The total amount of coin days contributed to the blockchain in fork B is: 10 + 5 + 10 + 5 + 7 = 37 coin days.

One can even do without the fixed amount per block (5 coin days in my example), but including the fixed amount will indicate sooner which fork will win.

It is clear that in this scenario, to maximize his chances of ending up in the blockchain, it is in the minters best interest to stay as close as possible to the minimum required amount of coin day transactions per block.

One exception is necessary: when a single transaction exceeds the minimum required amount of coin day transactions per block, the full amount of coin days of this single transaction should contribute to the blockchain, to prevent this transaction from never being processed (it will now be first in line to be processed).