P2Pool
P2Pool is a decentralized Bitcoin mining pool that works by creating a P2P network of miner nodes.
Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin, avoids the risk of difficult to detect theft by pool operators, and is has better fundamental resistance to DOS attacks than centralized pools.
Miners are configured to connect to a P2Pool node that can be run locally, alongside the miner. P2Pool users must run a full Bitcoin node which serves the purpose of the purpose of independently validating transactions and the bitcoin blockchain. P2Pool also supports merged mining and several alternative blockchains.
P2Pool nodes work on a chain of shares similar to Bitcoin's blockchain. Each node works on a block that includes payouts to the previous shares' owners and the node itself.
Because of the importance of strengthening Bitcoin's decentralization some Bitcoin supporters donate to P2Pool miners, resulting in payouts above 100% of the expected reward.
Overview
P2Pool shares form a "sharechain" with each share referencing the previous share's hash. Each share contains a standard Bitcoin block header, some P2Pool-specific data that is used to compute the generation transaction (total subsidy, payout script of this share, a nonce, the previous share's hash, and the current target for shares), and a merkle branch linking that generation transaction to the block header's merkle hash.
The chain continuously regulates its target to keep generation around one share every ten seconds.
Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 17280 shares (the last day's worth). In order to prevent an attacker from working on a chain in secret and then releasing it, overriding the existing chain, chains are judged by how much work they have since a point in the past. To ascertain that the work has been done since that point, nodes look at the Bitcoin blocks that the shares reference, establishing a provable timestamp. (If a share points to a block, it was definitely made after that block was made.)
Payout logic
Each share contains a generation transaction that pays out to the previous n shares, where n is the number of shares whose total work is equal to 3 times the average work required to solve a block, or 17280, whichever is smaller. Payouts are weighted based on the amount of work each share took to solve - proportional to the p2pool difficulty at that time.
The block reward (currently 50BTC) and the transaction fees are combined and apportioned according to these rules:
A subsidy of 0.5% is sent to the node that solved the block in order to discourage not sharing solutions that qualify as a block. (A miner with the aim to harm others could withhold the block, thereby preventing anybody from getting paid. He can NOT redirect the payout to himself.) The remaining 99.5% is distributed evenly to miners based on work done recently.
In the event that a share qualifies as a block, this generation transaction is exposed to the Bitcoin network and takes effect, transferring each node its payout.
Stales
P2Pool stales don't work the same way as stales on centralized pools. On a centralized pool a stale is work which is too old to be accepted by the pool's bitcoin node, this kind of stale is very rare in P2Pool because each user runs their own local bitcoin.
On P2Pool stales refer to shares which can't make it into the sharechain. Because the sharechain is 60 times faster than the bitcoin chain many stales are common and expected. However, because the payout is PPLNS the absolute amount of of stales is irrelevant, only your stale rate relative to other nodes.
The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
When you first start P2Pool claimed efficiency will be low and the error bounds on this estimate will be large, but as it runs the numbers will converge to their correct values.
If your efficiency is unusually low, make sure your network connection isn't overloaded, that your miners support long polling and are not set to work for excessive amounts of time, and that your bitcoin has multiple connections.
Joining the pool
Follow these steps to join the pool:
- Run bitcoin with the RPC interface enabled: put rpcuser=USER, rpcpassword=PASS, and server=1 in bitcoin.conf
- Bitcoin 0.5 or later is required
- It's important that your Bitcoin client be fully synchronized before starting. It's also better if you have the bitcoin port forwarded
- Download p2pool:
- Windows binary: See http://forum.bitcoin.org/index.php?topic=18313.0
- Source download: https://github.com/forrestv/p2pool/tags
- git: git clone git://github.com/forrestv/p2pool.git
- Run p2pool: (See below for additional options.)
- Windows py2exe: run_p2pool.exe USER PASS
- Source: python run_p2pool.py USER PASS
- Run a miner daemon with long polling connecting to 127.0.0.1 (or the IP of the host running p2pool if you're mining remotely) on port 9332 with any username and password
- cgminer -O u:p -o http://127.0.0.1:9332/
Dependencies if running from source:
- Python 2.6 or higher - with sqlite support
- python-argparse for Python 2.6 and lower
- Twisted (Ubuntu package python-twisted)
Miners
This is all for the latest p2pool version, as it includes several new workarounds. With all miners, using a high FPS target (100?) or a low aggression, and waiting for p2pool to completely start (line shows > 35000 shares) helps a lot with reducing stales.
Works as-is
cgminer
Works very well as is.
ufasoft
Works as is.
Needs patch to reduce stales
DiabloMiner
Has a bug where it waits half a second after receiving a long polling response. There is a 10% chance that a p2pool share will be generated in that window, resulting in that hashing being useless.
A fork of DiabloMiner on GitHub that fixes this: https://github.com/forrestv/DiabloMiner Make sure to get the fast_long_polling branch!
git clone git://github.com/forrestv/DiabloMiner.git cd DiabloMiner git checkout fast_long_polling
Built with JAR and Windows binary: http://u.forre.st/u/xsvenrwa/DiabloMiner_2e73cc.zip
Poclbm
Has a similar bug, but it waits a full second.
GitHub fork: https://github.com/forrestv/poclbm Pull request: https://github.com/m0mchil/poclbm/pull/41
git clone git://github.com/forrestv/poclbm.git cd poclbm git checkout fast_long_polling
Windows binary: http://u.forre.st/u/wodukkea/p2pool-poclbm_win32_5590e7c.zip
Phoenix
Has a similar bug (waiting a full second).
GitHub fork: https://github.com/forrestv/phoenix-miner
Windows binary: http://u.forre.st/u/ycvzejfm/phoenix-miner-fba48d2-5.zip
Not-compatible
puddinpop's RPC Miners
Does not have long polling so will not work at all.
Option Reference
usage: run_p2pool.py [-h] [--version] [--net {bitcoin, litecoin, namecoin}] [--testnet] [--debug] [-a ADDRESS] [--logfile LOGFILE] [--merged-url MERGED_URL] [--merged-userpass MERGED_USERPASS] [--give-author DONATION_PERCENTAGE] [--p2pool-port PORT] [-n ADDR[:PORT]] [--disable-upnp] [-w PORT] [-f FEE_PERCENTAGE] [--bitcoind-address BITCOIND_ADDRESS] [--bitcoind-rpc-port BITCOIND_RPC_PORT] [--bitcoind-p2p-port BITCOIND_P2P_PORT] [BITCOIND_RPCUSER] BITCOIND_RPCPASSWORD p2pool (version 31cbeea) optional arguments: -h, --help show this help message and exit --version show program's version number and exit --net {bitcoin, litecoin, namecoin} use specified network (default: bitcoin) --testnet use the network's testnet --debug enable debugging mode -a ADDRESS, --address ADDRESS generate payouts to this address (default: <address requested from bitcoind>) --logfile LOGFILE log to this file (default: data/<NET>/log) --merged-url MERGED_URL call getauxblock on this url to get work for merged mining (example: http://127.0.0.1:10332/) --merged-userpass MERGED_USERPASS use this user and password when requesting merged mining work (example: ncuser:ncpass) --give-author DONATION_PERCENTAGE donate this percentage of work to author of p2pool (default: 0.5) --disable-upnp don't attempt to use UPnP to forward p2pool's P2P port from the Internet to this computer p2pool interface: --p2pool-port PORT use port PORT to listen for connections (forward this port from your router!) (default: bitcoin:9333, litecoin:9338, namecoin:9334) -n ADDR[:PORT], --p2pool-node ADDR[:PORT] connect to existing p2pool node at ADDR listening on port PORT (defaults to default p2pool P2P port) in addition to builtin addresses worker interface: -w PORT, --worker-port PORT listen on PORT for RPC connections from miners (default: bitcoin:9332, litecoin:9327, namecoin:9331) -f FEE_PERCENTAGE, --fee FEE_PERCENTAGE charge workers mining to their own bitcoin address (by setting their miner's username to a bitcoin address) this percentage fee to mine on your p2pool instance. Amount displayed at http://127.0.0.1:WORKER_PORT/fee (default: 0) bitcoind interface: --bitcoind-address BITCOIND_ADDRESS connect to this address (default: 127.0.0.1) --bitcoind-rpc-port BITCOIND_RPC_PORT connect to JSON-RPC interface at this port (default: bitcoin:8332, litecoin:9332, namecoin:8332) --bitcoind-p2p-port BITCOIND_P2P_PORT connect to P2P interface at this port (default: bitcoin:8333, litecoin:9333, namecoin:8334) BITCOIND_RPCUSER bitcoind RPC interface username (default: <empty>) BITCOIND_RPCPASSWORD bitcoind RPC interface password
Protocol description
P2Pool's protocol mirrors Bitcoin's P2P protocol in many ways. It uses the same framing (prefix, command, length, checksum, payload) and similar commands:
- version - sent to establish a connection - contains (version, services, addr_to, addr_from, nonce, sub_version, mode, best_share_hash)
- setmode - sent to update the mode sent in the version message - contains (mode)
- ping - sent to keep connection alive - contains ()
- addrme - request that the receiving node send out an addr for the sending node - contains (port)
- addrs - broadcast list of nodes' addresses - contains (addrs)
- getaddrs - request that the receiving node send count addrs - contains (count)
- getshares - request that the receiving node send the shares referenced by hashes and parents of their parents, stopping at any share referenced by stops - contains (hashes, parents, stops)
- share0s - broadcast message of the hashes of shares - contains (hashes)
- share1as - broadcast message of the contents of shares that do not qualify as bitcoin blocks - contains (share1as)
- share1bs - broadcast message of the contents of shares that qualify as bitcoin blocks - contains (share1bs)
The mode is 0 for low-bandwidth mode, which sends the hash of a share first before sending the entire share, or 1 for low-latency (default) mode, which forwards the entire (~170 byte) share always. The two nodes on either side of a connection use the minimum of their two preferences for that connection.
History
This project was announced on June 17, 2011 by Forrest Voight[1].
The began testing against mainnet in mid-July, 2011. The pool was reviewed on a Bitcoin Miner post on July 26, 2011[2].
The software author's address for donations can be found in the signature section of his forum profile.
Donating to P2Pool miners
In order to encourage people to mine to P2Pool you can donate to the recent miners in proportion using a sendmany:
E.g. a bash script to donate 10 btc is:
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany?total=10.0)"
You can replace "" with "accountname" if you want to pay from some specific bitcoind account, and you can replace forre.st with 127.0.0.1 if you're running a P2Pool node locally, so you don't have to trust that the URL gives accurate figures.
If you decide to donate you should announce it on the forums so that your donations provide the most incentive possible.
See Also
External Links
- P2Pool forum
- p2pool project on GitHub
- IRC Web #p2pool discussion and support