Bitcoin Forum
December 06, 2016, 09:59:02 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: [RFC] P2P pooled mining  (Read 3851 times)
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
February 14, 2011, 04:42:39 PM
 #1

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.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481061543
Hero Member
*
Offline Offline

Posts: 1481061543

View Profile Personal Message (Offline)

Ignore
1481061543
Reply with quote  #2

1481061543
Report to moderator
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
February 14, 2011, 11:40:46 PM
 #2

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:

So this means a single core today can probably, with tuning and the block chain held in RAM but no special hardware beyond that, verify and accept about 80 transactions/sec.

A solved block [for a VISA-size network] will then be around (1kb * 2000tps * 60 * 10) / 1024 / 1024 = 1.14 gigabytes per block.

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

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
comboy
Sr. Member
****
Offline Offline

Activity: 247



View Profile
February 15, 2011, 12:11:14 AM
 #3


  • 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.


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.

Variance is a bitch!
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
February 15, 2011, 12:13:54 AM
 #4

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

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
comboy
Sr. Member
****
Offline Offline

Activity: 247



View Profile
February 15, 2011, 12:19:30 AM
 #5

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

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.

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?

Variance is a bitch!
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
February 15, 2011, 12:26:37 AM
 #6

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?

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.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
February 15, 2011, 12:29:45 AM
 #7

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:

So this means a single core today can probably, with tuning and the block chain held in RAM but no special hardware beyond that, verify and accept about 80 transactions/sec.

A solved block [for a VISA-size network] will then be around (1kb * 2000tps * 60 * 10) / 1024 / 1024 = 1.14 gigabytes per block.

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

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.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
February 15, 2011, 01:37:42 AM
 #8

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.

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
February 15, 2011, 08:10:31 AM
 #9

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.

Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
February 15, 2011, 08:57:31 AM
 #10

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.
grondilu
Legendary
*
Offline Offline

Activity: 1134


View Profile
February 15, 2011, 09:08:10 AM
 #11


I need an aspirin before trying to understand that.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!