Topic: [RFC] P2P pooled mining (Read 4262 times)

I need an aspirin before trying to understand that.

By the way, for the statistical attack in which you leave when you earned more than your fair share, the identity pass system I proposed in a different thread might be a useful countermeasure. Before being able to mine at all, you have to solve a very hard PoW over a key, which then allows you to prove (A) that you did create a block and (B) that you haven't simply invented a new mining personality instantly. That would rate limit the quantity of such attacks you could do.

I quite like this idea. I've been concerned about the concentration of mining power into the hands of only a few people for a while. Slush, ArtForz and the rest are certainly very trustworthy people but BitCoin was designed to not rely on trust in central authorities. It'd be a shame to lose that just because mining difficulty rose.

If ECDSA verification could be made significantly cheaper then scalability would be less of an issue. Hal has been investigating batched verification that could potentially result in huge CPU savings here. It is a probabilistic technique, but if the batch verify returns "valid" when it should have returned "invalid" that will be caught when the final block solution is found and every signature is verified by the successful node.

The network bandwidth required could also be reduced using m0mchils suggestion. I didn't recalculate the 1.14GB figure based on that, but if only the merkle tree was distributed block size on the network would be negligible for well connected nodes that already saw all the transactions it includes.

The quoted bandwidth is for 2000 transactions per second. 80 tx/s is for verification of transactions on a CPU core, which will probably become a factor sooner.

The pool needs to somehow spread around block verification so that each node doesn't have to receive and verify every block and transaction.

I admit this is something i did not think about. Maybe part of the bandwidth can be prevented by only sending the list of tx ids + the block header over the pool-network as proof-of-work, instead of the full blocks. However, this will still be a significant amount of bandwidth (at 80 tx/s), and increase the difficulty of verifying the proof-of-works.

Each time a low-difficulty block is found by someone, everyone's distribution tables should be updated, yes. However, this does not mean an immediate getwork is necessary. People can keep mining using slightly outdated tables.

Oh, haven't seen that in the original post. Interesting. So to work on the proper block, everybody should receive a getwork after anybody finds this smaller share? Am I getting it right?

You can't change the block after you've mined it, and the block contains payouts to all pool participants. So your choices are either: report it and get only your share, or don't report it and get nothing.

So knowing that most people who use bitcoin are rational, why would anybody report a block that he just mined?

You cannot hope for other people good will, when it's anonymous.

I think the scheme can work, but I don't think it could remain popular for too long. One of the main benefits of pooled mining is the ability to mine without verifying transactions or downloading/storing blocks. This will become a huge factor in the future:



Adding a flood of pool-related bandwidth on top of that doesn't help.

This is an idea that originally grew on #bitcoin-dev and in PM's between me and marioxcc some time ago. After mentioning it the past few days again on IRC, I thought about writing it out.

The idea is to make a server-less pool that is not controlled by a single individual (or group) like traditional pools are. Everything is done by the mining nodes themselves.

1. The concept

We combine some ideas from slush's pool and from puddinpop's earlier pool:

• Everyone mines real bitcoin blocks.
• The generation transaction has multiple outputs, one for each participant in the pool.
• Miners do not only report blocks that beat the "real" difficulty, but also those beating only a lower difficulty.

Contrary to centralized pools however, the miners are only connected to eachother. This is done through a secondary p2p network (disconnected from the real bitcoin network). Through this network, they show their low-difficulty blocks to eachother.

Each node maintains a table with how the reward from his blocks should be distributed to other pool members. When miner X sees a (low difficulty) block by miner Y that contains address X as generation transaction output, X updates his own table to increase Y's share. The intent is that this reaches an equilibrium proportional to the hashing speed of all players.

Since one has to decide what the generation transaction outputs are before actually starting to mine, a low-difficulty block is an unfakeable proof that one did intend to distribute gains according the way encoded in the transaction. If Y would stop including X as output, X would notice and can retaliate by removing Y from his own outputs.

2. Issues

There are some possible issues with this:

• Everyone needs to see all low-difficulty blocks by everyone. This quickly leads to rather high bandwidth usage. One solution is to let miners decide their own (low) target difficulty, and encode that in their blocks as well (it can be stored in the coinbase of the generating transaction, for example). A block with target difficulty D (and hash which matches that difficulty, of course) then counts as D diffculty-1 blocks for the speed estimation.
• Attacks: like all pools, this system is vulnerable to a vandalism attack: a miner is able to just not report a block he found that beats the real difficulty, decreasing the joint income of the whole pool. If people were free to join and leave a P2P pool like described here, this would be very hard to detect. A second possible attack is waiting for a opportune time (where you have earned more than you deserve, which will always happen through statistical variation), leave the pool, and return under a different name.
• Bootstrapping: someone new who joins the pool should be able to bootstrap - get an initial distribution table for his blocks, before anyone in the network is including him in their blocks. One possibility is using measured block frequencies (in general, not just the part mentioning him) of other nodes for this.
  

3. Implementation

One possible way of implementing this, is as a patch for bitcoind, with RPC calls:

• updatedist(), which sets a new distribution table and difficulty to be used in the generation transactions used by getwork()
• getwork(), modified to incorporate the distribution table set by updatedist()
• getshares(), returning information about recent blocks found by miners (including low-difficulty ones)

The rest of the implementation is then done in a separate pool client, which connects to bitcoind and uses these calls, as well as connecting to other pool clients and forwarding low-difficulty blocks.

An alternative is to incorporate everything into bitcoind, and possibly even use the bitcoin p2p network itself to communicate with other pool nodes. Initially however, it is probably better to let the communication between pool nodes happen through a simple multiplexing server, which forwards blocks between different nodes, adding some authentication as well.

There are further details that are already worked out as well. I'll write those out later, if there is interest.

PS: thanks to molecular for starting this text.