Currently miners that mine for a pool have to trust the pool to pay them for the work they have done. Work is typically proven by creating a weaker POW problem that if solved the miner gets paid. Specifically, the POW problem could be to find the block whose hash has 16 leading zeros, which is easier than the current POW problem (say 30 zeros), and still verifies to the pool operator that work is done. The pool doesn’t have to trust the miner because the miner cannot change the coinbase output of the block of the header they receive.
What would happen if this trust was reversed: pools had to trust their miners? If this was possible then pools would likely not form. This can be framed as analogous to the economic cartel problem: cartels are hard to form because everyone is incentivized to cheat. Less people would mine for a cryptocurrency which does not have pools because the interval between payout would be large. Therefore, the cryptocurrency would be more vulnerable to the 51% attack because it would take less computing power to get more than 50% of the resources (because there are less miners). Pools have also gotten close to the 50% threshold, as in GHASH incident of 2013. However, it is in miner’s interests to stop 51% attacks, so when a pool gets too large, miners simply switch to another pool, as was also seen in the GHASH incident.
One possible way to eliminate pool mining is by having the signature of the block be “mined” rather than the block itself. Imagine if POW was constructed such that the POW was only valid if a hash of a signature signing a hash of the entire block (including nonce) was sufficiently small (more than x amount of leading zeros in binary). The money would be was awarded to the address of the public key that is used to check the signature. If this was the case, the only way that pool mining would be possible is if the pool sent signed block nonce pairs to miners to calculate — and this is infeasible because of bandwidth speeds.
The anti-pool mining inequality:
hash(signature(hash(full_block))) < target
Bandwidth likely makes it too slow to send pairs of signed block/nonce pairs, but any other way a pool could operate would enable cheating. Say if the pool sent blocks, what would the miner sign with? The pool would want the miner to sign with their private key, but the pool couldn’t send their private key to the miner! Even if they did, the miner could mine with it and then if a block was found the miner could spend the transaction before the pool operator did. The pool cannot share their private key.
The entire block must be hashed with the nonce because otherwise a pool could share incomplete parts of the block that would be sufficient for mining purposes but not sufficient for validation by full nodes, because it is the incomplete block. More specifically, the hash being signed has to be of the entire block (and nonce) rather than just a header of the block. Data sent across the network would be the block and the signature. The “coinbase” transaction would be assumed by full nodes to be sent to the address of the public key, which is traditionally the double hash of the public key. In order to spend his reward, there would be a new system for referencing coinbase transactions, but this seems easy to do.
There are two concerns of anti-pool POW: long time intervals between payouts that lead to (1) less utility for miners and consequently to (2) less mining power on the network, which causes a lower mining difficulty. To estimate the change in mining power (hashrate) if a currency like Bitcoin were to switch to anti-pool mining is difficult. One possible way is to start by asking what is the range of acceptable reward intervals a miner is fine with. Miners have difference preferences and situations, so the question of how much hashrate a network would have is entirely empirical. Despite this, it seems we can still gauge some constraints without seeing empirical data. It seems reasonable that a miner would wants to be confident that they will be paid in a month, because of the monthly electricity bill. A month seems like a reasonable cap that catches >95% of miners. For a miner to be 95% confident that they will mine a block in 31 days, what percentage of the network resources does the miner have to have? The calculation:
minimum percentage of resources = x = .95/(blocksPerDay * 31) maximum number of miners = n = 1/x