Bitcoin Forum

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.

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.

Mining Pools are not bad and do not need to be prevented. 8)

I do like this idea very much. its another step to keep crypto decentralized.

luke-jr already made a similar proposal using getblocktemplate, where miners decide which transactions are to be included.

https://i.imgur.com/cKeVu3a.png

Not bait at all. Pools were created to solve a problem. The problem being that if everyone solo-mined very many would get no reward for their efforts. Sure, kill the pools, and then watch the number of miners dwindle as well because the big miners would be the only ones finding any coins regularly. Saying that pools have 51% attack potential is one thing. Saying that the potential goes away with the death of pools is quite another.

I mean really imagine a world where your 2Th/s machine only gets income maybe once a year(no i didn't do the math). How many would stay with it? If people were really concerned about the pools being bad, they would stop using them.

Annoyingly, the obvious 'replacement' for pooled mining is not non-pooled mining, it's cloud mining that puts the hardware in the physical control of the pooling party. Thats a step down.

Instead we /just/ need to improve the tools so that people can pool for variance reduction without turning over their consensus controls. It's straight forward: the pool gives you a coinbase txn specification (e.g. "must pay these addresses") and you mine whatever block content you want, returning shares to the pool. Then you get low variance payout, but without handing over control.

GBT was supposed to enable it, but it was supplanted by stratum before it could get adoption.  I'm not sure of how to break out of the status quo.

Actually, each client could be given a different coinbase address. There would still be the problem that the individual client could run off with the entire block reward, but it would reduce the exposure to just the single client.

Furthermore, each client could be required by the pool to put up 50 BTC earnest money that the client would forfeit to the rest of the pool members if they failed to share the reward of a solved block with the rest of the pool.

This would allow each client to continue signing and hashing without needing to bother the pools servers, and would provide an incentive for each client to share the block rewards appropriately.

Therefore, since this doesn't seem to prevent pools, there doesn't seem to be much benefit to making such a disruptive change to the protocol.

This will also kill all ASIC-based mining because the bottleneck becomes the ECDSA signing operation. A mining gig would only produce MH/s instead of TH/s or GH/s today.

No it wouldn't, it would just require different hardware.

I wonder if a p2p system for mining could be implemented.

P2pool pools hashing but each node still requires bitcoind.  It pools hashing but not mining.

I think a system based on fraud proofs might work.  All nodes would be mining the same block, but it would be created in a p2p way.

This is the same idea as in:
https://bitcointalk.org/index.php?topic=309073.0

First of all DSA signatures don't work since it's easy to create a new valid DSA signature from an old one and some partial state, so you could easily outsource a partial attempt and the pool participant could keep iterating without needing to know the key.

The other thing is that the "non outsourceable puzzle" focuses on preventing the outsourcer from just posting a bond "I promise 2x the reward of a block never to steal the reward" by using zero knowledge proofs. If this is too exotic, and the goal is just to discourage pools (rather than hosted mining as well), then maybe using just a (deterministic, strongly unforgeable) signature may be enough.

This is undesirable as it disallows users control of their own transaction selection.

They could join a different miner pool.  The inclusion rules could be set by the creator of the pool.

A miner pool with 1% of the hash rate would share the load of block creation over lots of miners, rather than each miner running his own node.

Block-creation is basically free however. More costly is block validation— after all we want mining to be evidence that the chain is valid for SPV nodes... but that also means not having miners skipping out on the validation. Forrest has been working on some improvements to make it possible to mine with very low resources, but I think I disrupted his progress somewhat by pointing out that validation is really important.

The point is to share validation over a swarm of nodes.  The main problem is that to create a new block immediately after a block is found is hard. 

A swarm would likely have latency problems.

An option would be something like

Create 2MB block with valid transactions and commit to that block while mining the currency block.

When a new block comes in, delete the transactions that are included in the new block.

The result will have at least 1MB worth of transactions, so a 1MB block can be created using the first 1MB worth of transactions.

If the "draft" block is restricted so that there are no transaction's that depend on other transactions in the block, then dropping transactions is safe.

While the minting fee dominates, an even easier method would be to switch to empty blocks for 1-2 minutes after a new block is found.

- new block detected
- immediately switch to mining an empty block with just a coinbase
- verify the new block
- create/verify next block for miner pool

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.

Centralized pools are not, however. (P2Pool is an existence proof that there are other options)

there is no need to prevent mining pools, let the free markets sort this out.
as bitcoin becomes more popular and pools start making more money running a pool will become a more lucrative business venture,
naturally more pools will be created and the hashing power will be more distributed between them.

I'm afraid you must not be very experienced with this ecosystem. There have been hundreds of pools created. Operating a pool, especially a small one, is not a business that has many barriers; and large pools have had revenue at times in excess of $100k/mo, so it's not like any more income is needed to justify running one.  Just having a choice of centralization does not result in Bitcoin being decenteralized, and the major reason you see consolidation in pools isn't because there aren't people running them but because pools do their job (reducing variance) when they are large.

but even if we had 100 pools each with 1% of hashing power the variance would be low enough for 99 percent of people (the pool would find approximately 1.44 blocks each day and thus people would get paid every day).
i would say people go to a certain pool not because of slightly better variance but because of a better web interface.

My opinion is that a rather significant percentage of hashers are actually really bad at mathematics (which is why they are mining at a loss relative to simply purchasing the bitcoins directly).

As such, they don't understand variance, or how pools reduce variance.  Instead they just assume "bigger is better".  They figure that the largest pools must be the best pools, relying on the idea that enough other people have done the investigation as to which pool is best and therefore by going with the majority they are benefiting from the research of others (just like people who aren't very good at computer programming assume that enough other people have already reviewed the bitcoin source, so they choose the wallet that they believe most people are using).

Furthermore, because larger pools get blocks more often, many of these hashers believe that more blocks = more bitcoins, and therefore think that larger pools will earn them more money.

This sounds like a great idea to me. Pools are necessary for Bitcoin, but they are improperly applied to altcoins.