Bitcoin Wiki - User contributions [en]

P2Pool

2015-06-12T13:17:28Z

Forrestv:

{{Infobox company
|name=P2Pool
|trading_name=P2Pool
|industry=[[Mining pool]]
|foundation=July 17, 2011
|hashrate=1.6 Phash/s
|website= http://p2pool.in
}}
[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]

'''P2Pool''' is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

<blockquote>P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 30 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target. Whenever a peer announces a new share found (new block in the P2Pool block chain), it is received by the other peers, and the other peers verify that this block contains payouts for all the previous miners who found a share (and announced it) that made it into the P2Pool share chain. This continues until some peer finds a block that has a difficulty that meets the Bitcoin network's difficulty target. This peer announces this block to the Bitcoin network and miners who have submitted shares for this block are paid in the generation transaction, proportionally to how many shares they have found in the last while. - Unknown author</blockquote>

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin and avoids the risk of hard to detect theft by pool operators.

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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization, some Bitcoin supporters donate to P2Pool miners, resulting in average returns above 100% of the expected reward.
However, it should be noted that there are other pools (such as [[BitPenny]] and [[Eligius]]) which can provide this same level of decentralization.

== 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 thirty seconds, just as Bitcoin regulates it to generate one block every ten minutes.
This means that finding shares becomes more difficult (resulting in higher variance) the more people mine on P2Pool, though large miners have the option to raise their difficulty, and so reduce the impact of their mining on P2Pool's minimum difficulty.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 shares (the last 3 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 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 8640 (= 24 hours of shares), whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is proportional to the p2pool difficulty at that time.

The block reward (currently 25BTC) 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 ===

On P2Pool stales refer to shares which can't make it into the sharechain. Because the sharechain is 20 times faster than the Bitcoin chain many stales are common and expected. However, because the payout is [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: edit bitcoin.conf to include:
rpcuser=USER
rpcpassword=LONG_RANDOM_SECRET_VALUE
server=1
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** Bitcoin 0.8.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
** Source: python run_p2pool.py
* Run a miner daemon with long polling connecting to 127.0.0.1 (or the IP of the host running p2pool if it isn't on the same computer as the miner) on port 9332 with any username and password
** bfgminer -O u:p -o http://127.0.0.1:9332/ --submit-stale
* Subscribe to the [https://groups.google.com/forum/#!forum/p2pool-notifications P2Pool notifications] mailing list for urgent pool status updates

Dependencies if running from source:
* Python 2.6 or higher (but not 3.x)
* python-argparse
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does my miner report so many longpoll events when mining on p2pool? - P4Man" 
'''A:''' "Once every ~30 seconds is normal. That is how often p2pool shares are generated (as opposed to ~10 min for bitcoin blocks) - cabin"

'''Q:''' "Do the 'orphan' and 'dead' shares in P2Pool's status display hurt me?" 
'''A:''' They shouldn't - It's normal for some fraction of everyone's shares to end up orphaned or dead. Because payouts are calculated by counting how many shares you have relative to others, everyone with normal configurations is equally "hurt" by this. However, if you have a large proportion of stales, your payout will be hurt. You can see how well you're doing by looking at P2Pool's "Efficiency" (ex: ''Efficiency: ~110.6% (40-111%)''). If 100% doesn't lie within the [http://en.wikipedia.org/wiki/Confidence_interval confidence interval] at the end, something is probably wrong (with 95% confidence).

'''Q:''' "What do I do if my efficiency is low?" 
'''A:''' Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. If you have a lot of dead shares or the "Local dead on arrival" number is higher than a few percent, that means that something is wrong with your miner. Check to make sure that it is one of the working versions in the ''Miners'' section on this page. Lower the intensity or raise the FPS of your miner. If you have a lot of orphan shares, something is wrong with P2Pool's P2P connection. Decrease the load on your internet connection or enable QoS (Quality of Service) on your router.

'''Q:''' What is PPLNS? 
'''A:''' Pay-Per-Last-N-Shares is a payout method that is completely resistant to pool hoppers.

'''Q:''' Why am I not getting very many shares?! 
'''A:''' The P2Pool difficulty is hundreds of times higher than on other pools. It can take time to get a share. P2Pool displays an estimate of how long you have to wait in the console output.

'''Q:''' Why does my miner say it has found a lot of shares but p2pool say I have only found a few?! 
'''A:''' The real P2Pool difficulty is hundreds of times higher than on normal pools, but p2pool essentially lies to your miner and tells it to work on relatively easy shares so that it submits shares every few seconds instead of every few hours. P2Pool then ignores any submitted shares that don't match the real share difficulty. By doing this, P2Pool can more accurately report your local hash rate and you can see if you are having problems with too many stale shares quickly

'''Q:''' Why am I getting so many rejects? 
'''A:''' You're using an incompatible miner. See the miners section here, increase your FPS on the miner, decrease the intensity, upgrade your miner, or try a different miner.

'''Q:''' What stops the pool operator or the block finder from stealing a block? 
'''A:''' A block solution is only worth anything because its hash matches Bitcoin's target. Altering anything within the block will change its hash and make it worthless. If you are concerned about the pool operator stealing a block, you should try to inspect the source code of each new version.

'''Q:''' Why does it say "Generated?" I want to spend my coins now! 
'''A:''' P2Pool includes payouts in generation transactions, which must mature (taking 120 blocks or 20 hours) before they can be spent. The reason for this is that a block could be orphaned, which would make its payout invalid and could reverse transactions.

'''Q:''' Do I get paid transaction fees? 
'''A:''' Yes. They are split among P2Pool miners.

'''Q:''' What are these payments I'm getting that aren't generated? 
'''A:''' These are subsidies that people who support the idea of P2Pool send to miners.

'''Q:''' Cool Subsidies sound like an awesome idea! How do I send some BTC to these awesome miners? 
'''A:''' See end of this page.

'''Q:''' Do I really need the WHOLE blockchain? 
'''A:''' Yes. Your node needs to be able to independently make decisions about what transactions to mine.

'''Q:''' How do merged mining payments work? 
'''A:''' Merged mining is handled entirely by namecoind, so you're solo mining and payouts will go into namecoind's wallet.

=== 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 intensity (8 for bfgminer?) helps a lot with reducing stales.

* bfgminer, cgminer, and ufasoft work perfectly without any extra options.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

====Tips to configure bfgminer to reduce stale/doa:====
* "gpu-threads" : "1", (2 by default)
* "queue" : "0", (1 by default)

Because of fast longpooling in p2pool it is better not NOT fetch work ahead.

On non-dedicated machines intensity=3 allows normal usage of PC, set it to 7 or more to get full hashrate.

On most cards best is diablo and phatk kernel, looks like poclbm kernel have unstable rate.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seamless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.
* You can make P2Pool use a configuration file by running run_p2pool.py @FILENAME, with FILENAME being the path to a file containing the command-line arguments (newlines are ignored) Example:
<pre>
--net bitcoin
-n 1.2.3.4
</pre>
* Setting the username of your miner connecting to P2Pool to a Bitcoin address will make it mine to that address instead of the one requested from bitcoind or set by -a
* Appending "/1000" to a miner's username will increase the difficulty of producing a P2Pool share to at most 1000. This is useful to large miners because doing this can make it easier for small miners while minimally impacting the large miners themselves. See [https://bitcointalk.org/index.php?topic=18313.msg816322#msg816322 recommended values].
** Appending "+1" (for example) after that will make P2Pool always give your miners work with a difficulty of 1

=== Web interface ===

Lots of data and useful tools are available at http://127.0.0.1:9332/something:
* /static/ - Lots of information from shares to graphs to payouts.
* /rate
* /users
* /fee
* /current_payouts
* /patron_sendmany - Gives sendmany outputs for fair donations to P2Pool
* /global_stats
* /local_stats
* /peer_addresses
* /payout_addr
* /recent_blocks
* /uptime
* /web/log - Some different stats collected over the last day

=== Included README ===
<pre>Requirements:
Generic:
Bitcoin >=0.6.0rc4 or Bitcoin >=0.5.4 (for BIP16 support) or Litecoin
Python
Twisted
python-argparse (for Python <=2.6)

Linux:
sudo apt-get install python-zope.interface python-twisted python-twisted-web
sudo apt-get install python-argparse # if on Python 2.6 or older

Windows:
Install Python 2.7: http://www.python.org/getit/
Install Twisted: http://twistedmatrix.com/trac/wiki/Downloads
Install Zope.Interface: http://pypi.python.org/pypi/zope.interface/3.8.0
Unzip the files into C:\Python27\Lib\site-packages

Running P2Pool:
To use P2Pool, you must be running your own local bitcoind. For standard
configurations, using P2Pool should be as simple as:

python run_p2pool.py

Then run your miner program, connecting to 127.0.0.1 on port 9332 with any
username and password.

If you are behind a NAT, you should enable TCP port forwarding on your
router. Forward port 9333 to the host running P2Pool.

Run "python run_p2pool.py --help" for additional options.

Notes for Litecoin:
Requirements:
In order to run P2Pool with the Litecoin network, you would need to build and install the
ltc_scrypt module that includes the scrypt proof of work code that Litecoin uses for hashes.

Linux:
cd litecoin_scrypt
sudo python setup.py install

Windows:
Install MinGW: http://www.mingw.org/wiki/Getting_Started
Install Python 2.7: http://www.python.org/getit/

cd litecoin_scrypt
C:\Python27\python.exe setup.py build --compile=mingw32 install

If you run into an error with unrecognized command line option '-mno-cygwin', see this:
http://stackoverflow.com/questions/6034390/compiling-with-cython-and-mingw-produces-gcc-error-unrecognized-command-line-o

Running P2Pool:
Run P2Pool with the "--net litecoin" option.
Run your miner program, connecting to 127.0.0.1 on port 9327.
Forward port 9338 to the host running P2Pool.

Litecoin's use of ports 9332 and 9332 conflicts with P2Pool running on
the Bitcoin network. To avoid problems, add these lines to litecoin.conf
and restart litecoind:
rpcport=10332
port=10333
</pre>

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin,litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--give-author DONATION_PERCENTAGE] [--iocp]
[--irc-announce] [--no-bugreport] [--p2pool-port PORT]
[-n ADDR[:PORT]] [--disable-upnp] [--max-conns CONNS]
[-w PORT or ADDR:PORT] [-f FEE_PERCENTAGE]
[--bitcoind-address BITCOIND_ADDRESS]
[--bitcoind-rpc-port BITCOIND_RPC_PORT]
[--bitcoind-p2p-port BITCOIND_P2P_PORT]
[BITCOIND_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version 0.11.1-8-ged9359d)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin,litecoin}
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>)
--datadir DATADIR store data in this directory (default: <directory
run_p2pool.py is in>/data)
--logfile LOGFILE log to this file (default: data/<NET>/log)
--merged MERGED_URLS call getauxblock on this url to get work for merged
mining (example:
http://ncuser:ncpass@127.0.0.1:10332/)
--give-author DONATION_PERCENTAGE
donate this percentage of work towards the development
of p2pool (default: 0.5)
--iocp use Windows IOCP API in order to avoid errors due to
large number of sockets being open
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--no-bugreport disable submitting caught exceptions to the author
--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)
-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
--max-conns CONNS maximum incoming connections (default: 40)

worker interface:
-w PORT or ADDR:PORT, --worker-port PORT or ADDR:PORT
listen on PORT on interface with ADDR for RPC
connections from miners (default: all interfaces,
bitcoin:9332, litecoin:9327)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== Interoperability table ==
P2pool works fine with most hardware. This lists some of the hardware confirmed to work and any special configuration required.

* ASICminer blade 10GH/s (Requires adding +1 to username or proxy)
* Avalon 110nm 60-110 GH/s (All batches)
* Avalon based 55nm 200 GH/s (specific makers?)
* Avalon prototype 55nm 120GH/s (~ 20 exist)
* Icarus FPGA
* Bitfury strikes back H-card and M-card ([https://bitcointalk.org/index.php?topic=18313.msg4424081#msg4424081 instructions])
* Bitmain Antminer S1 180GH/s ([https://github.com/AntMiner/AntGen1/tree/master/firmware Requires 20131226 firmware.])
* Bitmain Antminer S3 440GH/s
* BFL SC Jalapeno, SC Single 30, 50, & 60 GH/s
* Spondoolies Tech SP 10
* Spondoolies Tech SP 30

(Various GPU and most FPGAs other than BFL single FPGAs work fine too)

This is a list of hardware with known issues that should not be used on p2pool.

* Cointerra Terraminer IV (10-20% hash rate loss when mining on p2pool)
* Btimain Antminer S2 (10-20% hash rate loss when mining on p2pool, the S1 & S3 both work well on p2pool)

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The pool began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:

For example, a bash script to donate 10 btc is:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://127.0.0.1:9332/patron_sendmany/10)"
</pre>

You can replace "" with "accountname" if you want to pay from some specific bitcoind account, and you need to replace 127.0.0.1 with the address of your P2Pool node if you're not running one locally.

Note that the amount you donate will be allocated to recent miners in proportion to the amount of work they've done in the last 24 hours or so, but all the miner whose shares of the donated amount are less than 0.01 BTC will have their shares combined into a single amount which is awarded to one of them at random, with the chance of winning this 'lottery' weighted by the miner's recent amount of work done. You can change this 0.01 BTC threshold like this, for example, which says to pay 10 BTC, but to share it amongst more miners that the default, cutting off at 0.001 BTC instead of at 0.01 BTC.
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://127.0.0.1:9332/patron_sendmany/10/0.001)"
</pre>

If you decide to donate you should announce it on the forums so that your donations provide the most incentive possible.

==Sponsors==

Thanks to:

* The [https://bitcoinfoundation.org/ Bitcoin Foundation] for its generous support of P2Pool
* The [https://litecoin.org/ Litecoin Project] for its generous donations to P2Pool

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]
* [[P2Pool code documentation]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support
* [http://p2pool.info/ p2pool.info] stats page
* Up-to-date P2Pool mining stats: [http://minefast.coincadence.com/p2pool-stats.php Minefast.CoinCadence.com P2Pool stats]
* [http://p2pool.hostv.pl p2pool.hostv.pl] Public list of P2Pool BTC/LTC nodes.
* [http://p2pool-nodes.info/ p2pool-nodes.info] Another public list of P2Pool (BTC) nodes.
* [http://whatisp2pool.com whatisp2pool.com] An easy introduction to mining and P2Pool.
* [https://bitcointalk.org/index.php?topic=18313 Bitcointalk thread]
* [http://organofcorti.blogspot.com/2012/11/52-p2pool-achieving-expectations.html?m=1 Statistical analysis of P2Pool from Neighborhood Pool Watch]
* [http://chimera.labs.oreilly.com/books/1234000001802/ch08.html#mining_pools P2Pool section] of [[Mastering Bitcoin]] by [[Wikipedia:Andreas Antonopoulos|Andreas M. Antonopoulos]]

==References==
<references />

[[Category:Pool Operators]]
{{Pools}}

P2Pool

2014-08-23T01:40:19Z

Forrestv: p2pool.info has been fixed for a while now

{{infobox company|name=P2Pool
|trading_name=P2Pool
|industry=[[Mining pool]]
|foundation=July 17, 2011
|hashrate=1.6 Phash/s
}}
Links: http://p2pool.in/ - https://github.com/forrestv/p2pool - https://en.bitcoin.it/wiki/P2Pool - https://bitcointalk.org/index.php?topic=18313

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

<blockquote>P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 30 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target. Whenever a peer announces a new share found (new block in the P2Pool block chain), it is received by the other peers, and the other peers verify that this block contains payouts for all the previous miners who found a share (and announced it) that made it into the P2Pool share chain. This continues until some peer finds a block that has a difficulty that meets the Bitcoin network's difficulty target. This peer announces this block to the Bitcoin network and miners who have submitted shares for this block are paid in the generation transaction, proportionally to how many shares they have found in the last while. - Unknown author</blockquote>

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin and avoids the risk of hard to detect theft by pool operators.

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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization, some Bitcoin supporters donate to P2Pool miners, resulting in average returns above 100% of the expected reward.
However, it should be noted that there are other pools (such as [[BitPenny]] and [[Eligius]]) which can provide this same level of decentralization.

== 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 thirty seconds, just as Bitcoin regulates it to generate one block every ten minutes.
This means that finding shares becomes more difficult (resulting in higher variance) the more people mine on P2Pool, though large miners have the option to raise their difficulty, and so reduce the impact of their mining on P2Pool's minimum difficulty.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 shares (the last 3 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 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 8640 (= 24 hours of shares), whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is proportional to the p2pool difficulty at that time.

The block reward (currently 25BTC) 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 ===

On P2Pool stales refer to shares which can't make it into the sharechain. Because the sharechain is 20 times faster than the Bitcoin chain many stales are common and expected. However, because the payout is [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: edit bitcoin.conf to include:
rpcuser=USER
rpcpassword=LONG_RANDOM_SECRET_VALUE
server=1
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** Bitcoin 0.8.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
** Source: python run_p2pool.py
* Run a miner daemon with long polling connecting to 127.0.0.1 (or the IP of the host running p2pool if it isn't on the same computer as the miner) on port 9332 with any username and password
** bfgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher (but not 3.x)
* python-argparse
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does my miner report so many longpoll events when mining on p2pool? - P4Man" 
'''A:''' "Once every ~30 seconds is normal. That is how often p2pool shares are generated (as opposed to ~10 min for bitcoin blocks) - cabin"

'''Q:''' "Do the 'orphan' and 'dead' shares in P2Pool's status display hurt me?" 
'''A:''' They shouldn't - It's normal for some fraction of everyone's shares to end up orphaned or dead. Because payouts are calculated by counting how many shares you have relative to others, everyone with normal configurations is equally "hurt" by this. However, if you have a large proportion of stales, your payout will be hurt. You can see how well you're doing by looking at P2Pool's "Efficiency" (ex: ''Efficiency: ~110.6% (40-111%)''). If 100% doesn't lie within the [http://en.wikipedia.org/wiki/Confidence_interval confidence interval] at the end, something is probably wrong (with 95% confidence).

'''Q:''' "What do I do if my efficiency is low?" 
'''A:''' Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. If you have a lot of dead shares or the "Local dead on arrival" number is higher than a few percent, that means that something is wrong with your miner. Check to make sure that it is one of the working versions in the ''Miners'' section on this page. Lower the intensity or raise the FPS of your miner. If you have a lot of orphan shares, something is wrong with P2Pool's P2P connection. Decrease the load on your internet connection or enable QoS (Quality of Service) on your router.

'''Q:''' What is PPLNS? 
'''A:''' Pay-Per-Last-N-Shares is a payout method that is completely resistant to pool hoppers.

'''Q:''' Why am I not getting very many shares?! 
'''A:''' The P2Pool difficulty is hundreds of times higher than on other pools. It can take time to get a share. P2Pool displays an estimate of how long you have to wait in the console output.

'''Q:''' Why does my miner say it has found a lot of shares but p2pool say I have only found a few?! 
'''A:''' The real P2Pool difficulty is hundreds of times higher than on normal pools, but p2pool essentially lies to your miner and tells it to work on relatively easy shares so that it submits shares every few seconds instead of every few hours. P2Pool then ignores any submitted shares that don't match the real share difficulty. By doing this, P2Pool can more accurately report your local hash rate and you can see if you are having problems with too many stale shares quickly

'''Q:''' Why am I getting so many rejects? 
'''A:''' You're using an incompatible miner. See the miners section here, increase your FPS on the miner, decrease the intensity, upgrade your miner, or try a different miner.

'''Q:''' What stops the pool operator or the block finder from stealing a block? 
'''A:''' A block solution is only worth anything because its hash matches Bitcoin's target. Altering anything within the block will change its hash and make it worthless. If you are concerned about the pool operator stealing a block, you should try to inspect the source code of each new version.

'''Q:''' Why does it say "Generated?" I want to spend my coins now! 
'''A:''' P2Pool includes payouts in generation transactions, which must mature (taking 120 blocks or 20 hours) before they can be spent. The reason for this is that a block could be orphaned, which would make its payout invalid and could reverse transactions.

'''Q:''' Do I get paid transaction fees? 
'''A:''' Yes. They are split among P2Pool miners.

'''Q:''' What are these payments I'm getting that aren't generated? 
'''A:''' These are subsidies that people who support the idea of P2Pool send to miners.

'''Q:''' Cool Subsidies sound like an awesome idea! How do I send some BTC to these awesome miners? 
'''A:''' See end of this page.

'''Q:''' Do I really need the WHOLE blockchain? 
'''A:''' Yes. Your node needs to be able to independently make decisions about what transactions to mine.

'''Q:''' How do merged mining payments work? 
'''A:''' Merged mining is handled entirely by namecoind, so you're solo mining and payouts will go into namecoind's wallet.

=== 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 intensity (8 for bfgminer?) helps a lot with reducing stales.

* bfgminer, cgminer, and ufasoft work perfectly without any extra options.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

====Tips to configure bfgminer to reduce stale/doa:====
* "gpu-threads" : "1", (2 by default)
* "queue" : "0", (1 by default)

Because of fast longpooling in p2pool it is better not NOT fetch work ahead.

On non-dedicated machines intensity=3 allows normal usage of PC, set it to 7 or more to get full hashrate.

On most cards best is diablo and phatk kernel, looks like poclbm kernel have unstable rate.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seamless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.
* You can make P2Pool use a configuration file by running run_p2pool.py @FILENAME, with FILENAME being the path to a file containing the command-line arguments (newlines are ignored) Example:
<pre>
--net bitcoin
-n 1.2.3.4
</pre>
* Setting the username of your miner connecting to P2Pool to a Bitcoin address will make it mine to that address instead of the one requested from bitcoind or set by -a
* Appending "/1000" to a miner's username will increase the difficulty of producing a P2Pool share to at most 1000. This is useful to large miners because doing this can make it easier for small miners while minimally impacting the large miners themselves. See [https://bitcointalk.org/index.php?topic=18313.msg816322#msg816322 recommended values].
** Appending "+1" (for example) after that will make P2Pool always give your miners work with a difficulty of 1

=== Web interface ===

Lots of data and useful tools are available at http://127.0.0.1:9332/something:
* /static/ - Lots of information from shares to graphs to payouts.
* /rate
* /users
* /fee
* /current_payouts
* /patron_sendmany - Gives sendmany outputs for fair donations to P2Pool
* /global_stats
* /local_stats
* /peer_addresses
* /payout_addr
* /recent_blocks
* /uptime
* /web/log - Some different stats collected over the last day

=== Included README ===
<pre>Requirements:
Generic:
Bitcoin >=0.6.0rc4 or Bitcoin >=0.5.4 (for BIP16 support) or Litecoin
Python
Twisted
python-argparse (for Python <=2.6)

Linux:
sudo apt-get install python-zope.interface python-twisted python-twisted-web
sudo apt-get install python-argparse # if on Python 2.6 or older

Windows:
Install Python 2.7: http://www.python.org/getit/
Install Twisted: http://twistedmatrix.com/trac/wiki/Downloads
Install Zope.Interface: http://pypi.python.org/pypi/zope.interface/3.8.0
Unzip the files into C:\Python27\Lib\site-packages

Running P2Pool:
To use P2Pool, you must be running your own local bitcoind. For standard
configurations, using P2Pool should be as simple as:

python run_p2pool.py

Then run your miner program, connecting to 127.0.0.1 on port 9332 with any
username and password.

If you are behind a NAT, you should enable TCP port forwarding on your
router. Forward port 9333 to the host running P2Pool.

Run "python run_p2pool.py --help" for additional options.

Notes for Litecoin:
Requirements:
In order to run P2Pool with the Litecoin network, you would need to build and install the
ltc_scrypt module that includes the scrypt proof of work code that Litecoin uses for hashes.

Linux:
cd litecoin_scrypt
sudo python setup.py install

Windows:
Install MinGW: http://www.mingw.org/wiki/Getting_Started
Install Python 2.7: http://www.python.org/getit/

cd litecoin_scrypt
C:\Python27\python.exe setup.py build --compile=mingw32 install

If you run into an error with unrecognized command line option '-mno-cygwin', see this:
http://stackoverflow.com/questions/6034390/compiling-with-cython-and-mingw-produces-gcc-error-unrecognized-command-line-o

Running P2Pool:
Run P2Pool with the "--net litecoin" option.
Run your miner program, connecting to 127.0.0.1 on port 9327.
Forward port 9338 to the host running P2Pool.

Litecoin's use of ports 9332 and 9332 conflicts with P2Pool running on
the Bitcoin network. To avoid problems, add these lines to litecoin.conf
and restart litecoind:
rpcport=10332
port=10333
</pre>

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin,litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--give-author DONATION_PERCENTAGE] [--iocp]
[--irc-announce] [--no-bugreport] [--p2pool-port PORT]
[-n ADDR[:PORT]] [--disable-upnp] [--max-conns CONNS]
[-w PORT or ADDR:PORT] [-f FEE_PERCENTAGE]
[--bitcoind-address BITCOIND_ADDRESS]
[--bitcoind-rpc-port BITCOIND_RPC_PORT]
[--bitcoind-p2p-port BITCOIND_P2P_PORT]
[BITCOIND_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version 0.11.1-8-ged9359d)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin,litecoin}
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>)
--datadir DATADIR store data in this directory (default: <directory
run_p2pool.py is in>/data)
--logfile LOGFILE log to this file (default: data/<NET>/log)
--merged MERGED_URLS call getauxblock on this url to get work for merged
mining (example:
http://ncuser:ncpass@127.0.0.1:10332/)
--give-author DONATION_PERCENTAGE
donate this percentage of work towards the development
of p2pool (default: 0.5)
--iocp use Windows IOCP API in order to avoid errors due to
large number of sockets being open
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--no-bugreport disable submitting caught exceptions to the author
--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)
-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
--max-conns CONNS maximum incoming connections (default: 40)

worker interface:
-w PORT or ADDR:PORT, --worker-port PORT or ADDR:PORT
listen on PORT on interface with ADDR for RPC
connections from miners (default: all interfaces,
bitcoin:9332, litecoin:9327)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== Interoperability table ==
P2pool works fine with most hardware. This lists some of the hardware confirmed to work and any special configuration required.

* ASICminer blade 10GH/s (Requires adding +1 to username or proxy)
* Avalon 110nm 60-110 GH/s (All batches)
* Avalon based 55nm 200 GH/s (specific makers?)
* Avalon prototype 55nm 120GH/s (~ 20 exist)
* Icarus FPGA
* Bitfury strikes back H-card and M-card ([https://bitcointalk.org/index.php?topic=18313.msg4424081#msg4424081 instructions])
* Bitmain Antminer S1 180GH/s ([https://github.com/AntMiner/AntGen1/tree/master/firmware Requires 20131226 firmware.])
* Bitmain Antminer S3 440GH/s
* BFL SC Jalapeno, SC Single 30, 50, & 60 GH/s
* Spondoolies Tech SP 10
* Spondoolies Tech SP 30

(Various GPU and most FPGAs other than BFL single FPGAs work fine too)

This is a list of hardware with known issues that should not be used on p2pool.

* Cointerra Terraminer IV (10-20% hash rate loss when mining on p2pool)
* Btimain Antminer S2 (10-20% hash rate loss when mining on p2pool, the S1 & S3 both work well on p2pool)

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The pool began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:

For example, a bash script to donate 10 btc is:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://127.0.0.1:9332/patron_sendmany/10)"
</pre>

You can replace "" with "accountname" if you want to pay from some specific bitcoind account, and you need to replace 127.0.0.1 with the address of your P2Pool node if you're not running one locally.

Note that the amount you donate will be allocated to recent miners in proportion to the amount of work they've done in the last 24 hours or so, but all the miner whose shares of the donated amount are less than 0.01 BTC will have their shares combined into a single amount which is awarded to one of them at random, with the chance of winning this 'lottery' weighted by the miner's recent amount of work done. You can change this 0.01 BTC threshold like this, for example, which says to pay 10 BTC, but to share it amongst more miners that the default, cutting off at 0.001 BTC instead of at 0.01 BTC.
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://127.0.0.1:9332/patron_sendmany/10/0.001)"
</pre>

If you decide to donate you should announce it on the forums so that your donations provide the most incentive possible.

==Sponsors==

Thanks to:

* The [https://bitcoinfoundation.org/ Bitcoin Foundation] for its generous support of P2Pool
* The [https://litecoin.org/ Litecoin Project] for its generous donations to P2Pool

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]
* [[P2Pool code documentation]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support
* [http://p2pool.info/ p2pool.info] stats page
* [http://p2pool.hostv.pl p2pool.hostv.pl] Public list of P2Pool BTC/LTC nodes.
* [http://p2pool-nodes.info/ p2pool-nodes.info] Another public list of P2Pool (BTC) nodes.
* [http://whatisp2pool.com whatisp2pool.com] An easy introduction to mining and P2Pool.

==References==
<references />

[[Category:Pool Operators]]
{{Pools}}

P2Pool

2014-01-10T23:26:50Z

Forrestv: removed mentions of http://127.0.0.1:9332/ , which isn't actively maintained

Links: http://p2pool.in/ - https://github.com/forrestv/p2pool - https://en.bitcoin.it/wiki/P2Pool - https://bitcointalk.org/index.php?topic=18313

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

<blockquote>P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 10 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target. Whenever a peer announces a new share found (new block in the P2Pool block chain), it is received by the other peers, and the other peers verify that this block contains payouts for all the previous miners who found a share (and announced it) that made it into the P2Pool share chain. This continues until some peer finds a block that has a difficulty that meets the Bitcoin network's difficulty target. This peer announces this block to the Bitcoin network and miners who have submitted shares for this block are paid in the generation transaction, proportionally to how many shares they have found in the last while. - Unknown author</blockquote>

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin and avoids the risk of hard to detect theft by pool operators.

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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization, some Bitcoin supporters donate to P2Pool miners, resulting in average returns above 100% of the expected reward.
However, it should be noted that there are other pools (such as [[BitPenny]] and [[Eligius]]) which can provide this same level of decentralization.

== 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 thirty seconds, just as Bitcoin regulates it to generate one block every ten minutes.
This means that finding shares becomes more difficult (resulting in higher variance) the more people mine on P2Pool, though large miners have the option to raise their difficulty, and so reduce the impact of their mining on P2Pool's minimum difficulty.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640 (= 24 hours of shares), whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is proportional to the p2pool difficulty at that time.

The block reward (currently 25BTC) 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 ===

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: edit bitcoin.conf to include:
rpcuser=USER
rpcpassword=LONG_RANDOM_SECRET_VALUE
server=1
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** Bitcoin 0.8.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
** Source: python run_p2pool.py
* Run a miner daemon with long polling connecting to 127.0.0.1 (or the IP of the host running p2pool if it isn't on the same computer as the miner) on port 9332 with any username and password
** bfgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher (but not 3.x)
* python-argparse
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does my miner report so many longpoll events when mining on p2pool? - P4Man" 
'''A:''' "Once every ~10 seconds is normal. That is how often p2pool shares are generated (as opposed to ~10 min for bitcoin blocks) - cabin"

'''Q:''' "Do the 'orphan' and 'dead' shares in P2Pool's status display hurt me?" 
'''A:''' They shouldn't - It's normal for some fraction of everyone's shares to end up orphaned or dead. Because payouts are calculated by counting how many shares you have relative to others, everyone with normal configurations is equally "hurt" by this. However, if you have a large proportion of stales, your payout will be hurt. You can see how well you're doing by looking at P2Pool's "Efficiency" (ex: ''Efficiency: ~110.6% (40-111%)''). If 100% doesn't lie within the [http://en.wikipedia.org/wiki/Confidence_interval confidence interval] at the end, something is probably wrong (with 95% confidence).

'''Q:''' "What do I do if my efficiency is low?" 
'''A:''' Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. If you have a lot of dead shares or the "Local dead on arrival" number is higher than a few percent, that means that something is wrong with your miner. Check to make sure that it is one of the working versions in the ''Miners'' section on this page. Lower the intensity or raise the FPS of your miner. If you have a lot of orphan shares, something is wrong with P2Pool's P2P connection. Decrease the load on your internet connection or enable QoS (Quality of Service) on your router.

'''Q:''' What is PPLNS? 
'''A:''' Pay-Per-Last-N-Shares is a payout method that is completely resistant to pool hoppers.

'''Q:''' Why am I not getting very many shares?! 
'''A:''' The P2Pool difficulty is hundreds of times higher than on other pools. It can take time to get a share. P2Pool displays an estimate of how long you have to wait in the console output.

'''Q:''' Why does my miner say it has found a lot of shares but p2pool say I have only found a few?! 
'''A:''' The real P2Pool difficulty is hundreds of times higher than on normal pools, but p2pool essentially lies to your miner and tells it to work on relatively easy shares so that it submits shares every few seconds instead of every few hours. P2Pool then ignores any submitted shares that don't match the real share difficulty. By doing this, P2Pool can more accurately report your local hash rate and you can see if you are having problems with too many stale shares quickly

'''Q:''' Why am I getting so many rejects? 
'''A:''' You're using an incompatible miner. See the miners section here, increase your FPS on the miner, decrease the intensity, upgrade your miner, or try a different miner.

'''Q:''' What stops the pool operator or the block finder from stealing a block? 
'''A:''' A block solution is only worth anything because its hash matches Bitcoin's target. Altering anything within the block will change its hash and make it worthless. If you are concerned about the pool operator stealing a block, you should try to inspect the source code of each new version.

'''Q:''' Why does it say "Generated?" I want to spend my coins now! 
'''A:''' P2Pool includes payouts in generation transactions, which must mature (taking 120 blocks or 20 hours) before they can be spent. The reason for this is that a block could be orphaned, which would make its payout invalid and could reverse transactions.

'''Q:''' Do I get paid transaction fees? 
'''A:''' Yes. They are split among P2Pool miners.

'''Q:''' What are these payments I'm getting that aren't generated? 
'''A:''' These are subsidies that people who support the idea of P2Pool send to miners.

'''Q:''' Cool Subsidies sound like an awesome idea! How do I send some BTC to these awesome miners? 
'''A:''' See end of this page.

'''Q:''' Do I really need the WHOLE blockchain? 
'''A:''' Yes. Your node needs to be able to independently make decisions about what transactions to mine.

'''Q:''' How do merged mining payments work? 
'''A:''' Merged mining is handled entirely by namecoind, so you're solo mining and payouts will go into namecoind's wallet.

=== 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 intensity (8 for bfgminer?) helps a lot with reducing stales.

* bfgminer, cgminer, and ufasoft work perfectly without any extra options.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

====Tips to configure bfgminer to reduce stale/doa:====
* "gpu-threads" : "1", (2 by default)
* "queue" : "0", (1 by default)

Because of fast longpooling in p2pool it is better not NOT fetch work ahead.

On non-dedicated machines intensity=3 allows normal usage of PC, set it to 7 or more to get full hashrate.

On most cards best is diablo and phatk kernel, looks like poclbm kernel have unstable rate.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seamless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.
* You can make P2Pool use a configuration file by running run_p2pool.py @FILENAME, with FILENAME being the path to a file containing the command-line arguments (newlines are ignored) Example:
<pre>
--net litecoin
-n 1.2.3.4
</pre>
* Setting the username of your miner connecting to P2Pool to a Bitcoin address will make it mine to that address instead of the one requested from bitcoind or set by -a
* Appending "/1000" to a miner's username will increase the difficulty of producing a P2Pool share to at most 1000. This is useful to large miners because doing this can make it easier for small miners while minimally impacting the large miners themselves. See [https://bitcointalk.org/index.php?topic=18313.msg816322#msg816322 recommended values].
** Appending "+1" (for example) after that will make P2Pool always give your miners work with a difficulty of 1

=== Web interface ===

Lots of data and useful tools are available at http://127.0.0.1:9332/something:
* /static/ - Lots of information from shares to graphs to payouts.
* /rate
* /users
* /fee
* /current_payouts
* /patron_sendmany - Gives sendmany outputs for fair donations to P2Pool
* /global_stats
* /local_stats
* /peer_addresses
* /payout_addr
* /recent_blocks
* /uptime
* /web/log - Some different stats collected over the last day

=== Included README ===
<pre>Requirements:
Generic:
Bitcoin >=0.6.0rc4 or Bitcoin >=0.5.4 (for BIP16 support) or Litecoin
Python
Twisted
python-argparse (for Python <=2.6)

Linux:
sudo apt-get install python-zope.interface python-twisted python-twisted-web
sudo apt-get install python-argparse # if on Python 2.6 or older

Windows:
Install Python 2.7: http://www.python.org/getit/
Install Twisted: http://twistedmatrix.com/trac/wiki/Downloads
Install Zope.Interface: http://pypi.python.org/pypi/zope.interface/3.8.0
Unzip the files into C:\Python27\Lib\site-packages

Running P2Pool:
To use P2Pool, you must be running your own local bitcoind. For standard
configurations, using P2Pool should be as simple as:

python run_p2pool.py

Then run your miner program, connecting to 127.0.0.1 on port 9332 with any
username and password.

If you are behind a NAT, you should enable TCP port forwarding on your
router. Forward port 9333 to the host running P2Pool.

Run "python run_p2pool.py --help" for additional options.

Notes for Litecoin:
Requirements:
In order to run P2Pool with the Litecoin network, you would need to build and install the
ltc_scrypt module that includes the scrypt proof of work code that Litecoin uses for hashes.

Linux:
cd litecoin_scrypt
sudo python setup.py install

Windows:
Install MinGW: http://www.mingw.org/wiki/Getting_Started
Install Python 2.7: http://www.python.org/getit/

cd litecoin_scrypt
C:\Python27\python.exe setup.py build --compile=mingw32 install

If you run into an error with unrecognized command line option '-mno-cygwin', see this:
http://stackoverflow.com/questions/6034390/compiling-with-cython-and-mingw-produces-gcc-error-unrecognized-command-line-o

Running P2Pool:
Run P2Pool with the "--net litecoin" option.
Run your miner program, connecting to 127.0.0.1 on port 9327.
Forward port 9338 to the host running P2Pool.

Litecoin's use of ports 9332 and 9332 conflicts with P2Pool running on
the Bitcoin network. To avoid problems, add these lines to litecoin.conf
and restart litecoind:
rpcport=10332
port=10333
</pre>

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin,litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--give-author DONATION_PERCENTAGE] [--iocp]
[--irc-announce] [--no-bugreport] [--p2pool-port PORT]
[-n ADDR[:PORT]] [--disable-upnp] [--max-conns CONNS]
[-w PORT or ADDR:PORT] [-f FEE_PERCENTAGE]
[--bitcoind-address BITCOIND_ADDRESS]
[--bitcoind-rpc-port BITCOIND_RPC_PORT]
[--bitcoind-p2p-port BITCOIND_P2P_PORT]
[BITCOIND_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version 0.11.1-8-ged9359d)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin,litecoin}
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>)
--datadir DATADIR store data in this directory (default: <directory
run_p2pool.py is in>/data)
--logfile LOGFILE log to this file (default: data/<NET>/log)
--merged MERGED_URLS call getauxblock on this url to get work for merged
mining (example:
http://ncuser:ncpass@127.0.0.1:10332/)
--give-author DONATION_PERCENTAGE
donate this percentage of work towards the development
of p2pool (default: 0.5)
--iocp use Windows IOCP API in order to avoid errors due to
large number of sockets being open
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--no-bugreport disable submitting caught exceptions to the author
--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)
-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
--max-conns CONNS maximum incoming connections (default: 40)

worker interface:
-w PORT or ADDR:PORT, --worker-port PORT or ADDR:PORT
listen on PORT on interface with ADDR for RPC
connections from miners (default: all interfaces,
bitcoin:9332, litecoin:9327)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== Interoperability table ==
P2pool works fine with most hardware. This lists some of the hardware confirmed to work and any special configuration required.

* ASICminer blade 10GH/s (Requires adding +1 to username or proxy)
* Avalon 110nm 60-110 GH/s (All batches)
* Avalon based 55nm 200 GH/s (specific makers?)
* Avalon prototype 55nm 120GH/s (~ 20 exist)
* Icarus FPGA
* Bitfury strikes back H-card and M-card ([https://bitcointalk.org/index.php?topic=18313.msg4424081#msg4424081 instructions])
* Bitmain Antminer S1 180GH/s ([https://github.com/AntMiner/AntGen1/tree/master/firmware Requires 20131226 firmware.])
* BFL SC Jalapeno, SC Single 30, 50, & 60 GH/s

(Various GPU and most FPGAs other than BFL single FPGAs work fine too)

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The pool began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:

For example, a bash script to donate 10 btc is:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://127.0.0.1:9332/patron_sendmany/10)"
</pre>

You can replace "" with "accountname" if you want to pay from some specific bitcoind account, and you need to replace 127.0.0.1 with the address of your P2Pool node if you're not running one locally.

Note that the amount you donate will be allocated to recent miners in proportion to the amount of work they've done in the last 24 hours or so, but all the miner whose shares of the donated amount are less than 0.01 BTC will have their shares combined into a single amount which is awarded to one of them at random, with the chance of winning this 'lottery' weighted by the miner's recent amount of work done. You can change this 0.01 BTC threshold like this, for example, which says to pay 10 BTC, but to share it amongst more miners that the default, cutting off at 0.001 BTC instead of at 0.01 BTC.
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://127.0.0.1:9332/patron_sendmany/10/0.001)"
</pre>

If you decide to donate you should announce it on the forums so that your donations provide the most incentive possible.

==Sponsors==

Thanks to:

* The [https://bitcoinfoundation.org/ Bitcoin Foundation] for its generous support of P2Pool
* The [https://litecoin.org/ Litecoin Project] for its generous donations to P2Pool

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]
* [[P2Pool code documentation]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support
* [http://p2pool.info/ p2pool.info] stats page
* [http://p2pool.hostv.pl p2pool.hostv.pl] Public list of P2Pool BTC/LTC nodes.
* [http://whatisp2pool.com whatisp2pool.com] An easy introduction to mining and P2Pool.

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2013-11-07T23:57:12Z

Forrestv: added sponsors

Links: http://p2pool.in/ - https://github.com/forrestv/p2pool - https://en.bitcoin.it/wiki/P2Pool - https://bitcointalk.org/index.php?topic=18313

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

<blockquote>P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 10 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target. Whenever a peer announces a new share found (new block in the P2Pool block chain), it is received by the other peers, and the other peers verify that this block contains payouts for all the previous miners who found a share (and announced it) that made it into the P2Pool share chain. This continues until some peer finds a block that has a difficulty that meets the Bitcoin network's difficulty target. This peer announces this block to the Bitcoin network and miners who have submitted shares for this block are paid in the generation transaction, proportionally to how many shares they have found in the last while. - Unknown author</blockquote>

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin and avoids the risk of hard to detect theft by pool operators.

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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization, some Bitcoin supporters donate to P2Pool miners, resulting in average returns above 100% of the expected reward.
However, it should be noted that there are other pools (such as [[BitPenny]] and [[Eligius]]) which can provide this same level of decentralization.

== 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 thirty seconds, just as Bitcoin regulates it to generate one block every ten minutes.
This means that finding shares becomes more difficult (resulting in higher variance) the more people mine on P2Pool, though large miners have the option to raise their difficulty, and so reduce the impact of their mining on P2Pool's minimum difficulty.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640 (= 24 hours of shares), whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is proportional to the p2pool difficulty at that time.

The block reward (currently 25BTC) 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 ===

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: edit bitcoin.conf to include:
rpcuser=USER
rpcpassword=LONG_RANDOM_SECRET_VALUE
server=1
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** 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
** Source: python run_p2pool.py
* Run a miner daemon with long polling connecting to 127.0.0.1 (or the IP of the host running p2pool if it isn't on the same computer as the miner) on port 9332 with any username and password
** bfgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher (but not 3.x)
* python-argparse
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does my miner report so many longpoll events when mining on p2pool? - P4Man" 
'''A:''' "Once every ~10 seconds is normal. That is how often p2pool shares are generated (as opposed to ~10 min for bitcoin blocks) - cabin"

'''Q:''' "Do the 'orphan' and 'dead' shares in P2Pool's status display hurt me?" 
'''A:''' They shouldn't - It's normal for some fraction of everyone's shares to end up orphaned or dead. Because payouts are calculated by counting how many shares you have relative to others, everyone with normal configurations is equally "hurt" by this. However, if you have a large proportion of stales, your payout will be hurt. You can see how well you're doing by looking at P2Pool's "Efficiency" (ex: ''Efficiency: ~110.6% (40-111%)''). If 100% doesn't lie within the [http://en.wikipedia.org/wiki/Confidence_interval confidence interval] at the end, something is probably wrong (with 95% confidence).

'''Q:''' "What do I do if my efficiency is low?" 
'''A:''' Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. If you have a lot of dead shares or the "Local dead on arrival" number is higher than a few percent, that means that something is wrong with your miner. Check to make sure that it is one of the working versions in the ''Miners'' section on this page. Lower the intensity or raise the FPS of your miner. If you have a lot of orphan shares, something is wrong with P2Pool's P2P connection. Decrease the load on your internet connection or enable QoS (Quality of Service) on your router.

'''Q:''' What is PPLNS? 
'''A:''' Pay-Per-Last-N-Shares is a payout method that is completely resistant to pool hoppers.

'''Q:''' Why am I not getting very many shares?! 
'''A:''' The P2Pool difficulty is hundreds of times higher than on other pools. It can take time to get a share. P2Pool displays an estimate of how long you have to wait in the console output.

'''Q:''' Why does my miner say it has found a lot of shares but p2pool say I have only found a few?! 
'''A:''' The real P2Pool difficulty is hundreds of times higher than on normal pools, but p2pool essentially lies to your miner and tells it to work on relatively easy shares so that it submits shares every few seconds instead of every few hours. P2Pool then ignores any submitted shares that don't match the real share difficulty. By doing this, P2Pool can more accurately report your local hash rate and you can see if you are having problems with too many stale shares quickly

'''Q:''' Why am I getting so many rejects? 
'''A:''' You're using an incompatible miner. See the miners section here, increase your FPS on the miner, decrease the intensity, upgrade your miner, or try a different miner.

'''Q:''' What stops the pool operator or the block finder from stealing a block? 
'''A:''' A block solution is only worth anything because its hash matches Bitcoin's target. Altering anything within the block will change its hash and make it worthless. If you are concerned about the pool operator stealing a block, you should try to inspect the source code of each new version.

'''Q:''' Why does it say "Generated?" I want to spend my coins now! 
'''A:''' P2Pool includes payouts in generation transactions, which must mature (taking 120 blocks or 20 hours) before they can be spent. The reason for this is that a block could be orphaned, which would make its payout invalid and could reverse transactions.

'''Q:''' Do I get paid transaction fees? 
'''A:''' Yes. They are split among P2Pool miners.

'''Q:''' What are these payments I'm getting that aren't generated? 
'''A:''' These are subsidies that people who support the idea of P2Pool send to miners.

'''Q:''' Cool Subsidies sound like an awesome idea! How do I send some BTC to these awesome miners? 
'''A:''' See end of this page.

'''Q:''' Do I really need the WHOLE blockchain? 
'''A:''' Yes. Your node needs to be able to independently make decisions about what transactions to mine.

'''Q:''' How do merged mining payments work? 
'''A:''' Merged mining is handled entirely by namecoind, so you're solo mining and payouts will go into namecoind's wallet.

=== 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 intensity (8 for bfgminer?) helps a lot with reducing stales.

* bfgminer, cgminer, and ufasoft work perfectly without any extra options.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

====Tips to configure bfgminer to reduce stale/doa:====
* "gpu-threads" : "1", (2 by default)
* "queue" : "0", (1 by default)

Because of fast longpooling in p2pool it is better not NOT fetch work ahead.

On non-dedicated machines intensity=3 allows normal usage of PC, set it to 7 or more to get full hashrate.

On most cards best is diablo and phatk kernel, looks like poclbm kernel have unstable rate.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seamless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.
* You can make P2Pool use a configuration file by running run_p2pool.py @FILENAME, with FILENAME being the path to a file containing the command-line arguments (newlines are ignored) Example:
<pre>
--net litecoin
-n 1.2.3.4
</pre>
* Setting the username of your miner connecting to P2Pool to a Bitcoin address will make it mine to that address instead of the one requested from bitcoind or set by -a
* Appending "/1000" to a miner's username will increase the difficulty of producing a P2Pool share to at most 1000. This is useful to large miners because doing this can make it easier for small miners while minimally impacting the large miners themselves. See [https://bitcointalk.org/index.php?topic=18313.msg816322#msg816322 recommended values].
** Appending "+1" (for example) after that will make P2Pool always give your miners work with a difficulty of 1

=== Web interface ===

Lots of data and useful tools are available at http://127.0.0.1:9332/something:
* /static/ - Lots of information from shares to graphs to payouts.
* /rate
* /users
* /fee
* /current_payouts
* /patron_sendmany - Gives sendmany outputs for fair donations to P2Pool
* /global_stats
* /local_stats
* /peer_addresses
* /payout_addr
* /recent_blocks
* /uptime
* /web/log - Some different stats collected over the last day

=== Included README ===
<pre>Requirements:
Generic:
Bitcoin >=0.6.0rc4 or Bitcoin >=0.5.4 (for BIP16 support) or Litecoin
Python
Twisted
python-argparse (for Python <=2.6)

Linux:
sudo apt-get install python-zope.interface python-twisted python-twisted-web
sudo apt-get install python-argparse # if on Python 2.6 or older

Windows:
Install Python 2.7: http://www.python.org/getit/
Install Twisted: http://twistedmatrix.com/trac/wiki/Downloads
Install Zope.Interface: http://pypi.python.org/pypi/zope.interface/3.8.0
Unzip the files into C:\Python27\Lib\site-packages

Running P2Pool:
To use P2Pool, you must be running your own local bitcoind. For standard
configurations, using P2Pool should be as simple as:

python run_p2pool.py

Then run your miner program, connecting to 127.0.0.1 on port 9332 with any
username and password.

If you are behind a NAT, you should enable TCP port forwarding on your
router. Forward port 9333 to the host running P2Pool.

Run "python run_p2pool.py --help" for additional options.

Notes for Litecoin:
Requirements:
In order to run P2Pool with the Litecoin network, you would need to build and install the
ltc_scrypt module that includes the scrypt proof of work code that Litecoin uses for hashes.

Linux:
cd litecoin_scrypt
sudo python setup.py install

Windows:
Install MinGW: http://www.mingw.org/wiki/Getting_Started
Install Python 2.7: http://www.python.org/getit/

cd litecoin_scrypt
C:\Python27\python.exe setup.py build --compile=mingw32 install

If you run into an error with unrecognized command line option '-mno-cygwin', see this:
http://stackoverflow.com/questions/6034390/compiling-with-cython-and-mingw-produces-gcc-error-unrecognized-command-line-o

Running P2Pool:
Run P2Pool with the "--net litecoin" option.
Run your miner program, connecting to 127.0.0.1 on port 9327.
Forward port 9338 to the host running P2Pool.

Litecoin's use of ports 9332 and 9332 conflicts with P2Pool running on
the Bitcoin network. To avoid problems, add these lines to litecoin.conf
and restart litecoind:
rpcport=10332
port=10333
</pre>

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin,litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--give-author DONATION_PERCENTAGE] [--iocp]
[--irc-announce] [--no-bugreport] [--p2pool-port PORT]
[-n ADDR[:PORT]] [--disable-upnp] [--max-conns CONNS]
[-w PORT or ADDR:PORT] [-f FEE_PERCENTAGE]
[--bitcoind-address BITCOIND_ADDRESS]
[--bitcoind-rpc-port BITCOIND_RPC_PORT]
[--bitcoind-p2p-port BITCOIND_P2P_PORT]
[BITCOIND_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version 0.11.1-8-ged9359d)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin,litecoin}
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>)
--datadir DATADIR store data in this directory (default: <directory
run_p2pool.py is in>/data)
--logfile LOGFILE log to this file (default: data/<NET>/log)
--merged MERGED_URLS call getauxblock on this url to get work for merged
mining (example:
http://ncuser:ncpass@127.0.0.1:10332/)
--give-author DONATION_PERCENTAGE
donate this percentage of work towards the development
of p2pool (default: 0.5)
--iocp use Windows IOCP API in order to avoid errors due to
large number of sockets being open
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--no-bugreport disable submitting caught exceptions to the author
--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)
-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
--max-conns CONNS maximum incoming connections (default: 40)

worker interface:
-w PORT or ADDR:PORT, --worker-port PORT or ADDR:PORT
listen on PORT on interface with ADDR for RPC
connections from miners (default: all interfaces,
bitcoin:9332, litecoin:9327)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The pool began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:

For example, a bash script to donate 10 btc is:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany/10)"
</pre>

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.

Note that the amount you donate will be allocated to recent miners in proportion to the amount of work they've done in the last 24 hours or so, but all the miner whose shares of the donated amount are less than 0.01 BTC will have their shares combined into a single amount which is awarded to one of them at random, with the chance of winning this 'lottery' weighted by the miner's recent amount of work done. You can change this 0.01 BTC threshold like this, for example, which says to pay 10 BTC, but to share it amongst more miners that the default, cutting off at 0.001 BTC instead of at 0.01 BTC.
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany/10/0.001)"
</pre>

If you decide to donate you should announce it on the forums so that your donations provide the most incentive possible.

==Sponsors==

Thanks to:

* The [https://bitcoinfoundation.org/ Bitcoin Foundation] for its generous support of P2Pool
* The [https://litecoin.org/ Litecoin Project] for its generous donations to P2Pool

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]
* [[P2Pool code documentation]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support
* [http://p2pool.info/ p2pool.info] stats page
* [http://p2pool.hostv.pl p2pool.hostv.pl] Public list of P2Pool BTC/LTC nodes.

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2013-10-04T04:52:07Z

Forrestv: added links

Links: http://p2pool.in/ - https://github.com/forrestv/p2pool - https://en.bitcoin.it/wiki/P2Pool - https://bitcointalk.org/index.php?topic=18313

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

<blockquote>P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 10 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target. Whenever a peer announces a new share found (new block in the P2Pool block chain), it is received by the other peers, and the other peers verify that this block contains payouts for all the previous miners who found a share (and announced it) that made it into the P2Pool share chain. This continues until some peer finds a block that has a difficulty that meets the Bitcoin network's difficulty target. This peer announces this block to the Bitcoin network and miners who have submitted shares for this block are paid in the generation transaction, proportionally to how many shares they have found in the last while. - Unknown author</blockquote>

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin and avoids the risk of hard to detect theft by pool operators.

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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization, some Bitcoin supporters donate to P2Pool miners, resulting in average returns above 100% of the expected reward.
However, it should be noted that there are other pools (such as [[BitPenny]] and [[Eligius]]) which can provide this same level of decentralization.

== 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 thirty seconds, just as Bitcoin regulates it to generate one block every ten minutes.
This means that finding shares becomes more difficult (resulting in higher variance) the more people mine on P2Pool, though large miners have the option to raise their difficulty, and so reduce the impact of their mining on P2Pool's minimum difficulty.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640 (= 24 hours of shares), whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is proportional to the p2pool difficulty at that time.

The block reward (currently 25BTC) 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 ===

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: edit bitcoin.conf to include:
rpcuser=USER
rpcpassword=LONG_RANDOM_SECRET_VALUE
server=1
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** 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
** Source: python run_p2pool.py
* Run a miner daemon with long polling connecting to 127.0.0.1 (or the IP of the host running p2pool if it isn't on the same computer as the miner) on port 9332 with any username and password
** bfgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher (but not 3.x)
* python-argparse
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does my miner report so many longpoll events when mining on p2pool? - P4Man" 
'''A:''' "Once every ~10 seconds is normal. That is how often p2pool shares are generated (as opposed to ~10 min for bitcoin blocks) - cabin"

'''Q:''' "Do the 'orphan' and 'dead' shares in P2Pool's status display hurt me?" 
'''A:''' They shouldn't - It's normal for some fraction of everyone's shares to end up orphaned or dead. Because payouts are calculated by counting how many shares you have relative to others, everyone with normal configurations is equally "hurt" by this. However, if you have a large proportion of stales, your payout will be hurt. You can see how well you're doing by looking at P2Pool's "Efficiency" (ex: ''Efficiency: ~110.6% (40-111%)''). If 100% doesn't lie within the [http://en.wikipedia.org/wiki/Confidence_interval confidence interval] at the end, something is probably wrong (with 95% confidence).

'''Q:''' "What do I do if my efficiency is low?" 
'''A:''' Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. If you have a lot of dead shares or the "Local dead on arrival" number is higher than a few percent, that means that something is wrong with your miner. Check to make sure that it is one of the working versions in the ''Miners'' section on this page. Lower the intensity or raise the FPS of your miner. If you have a lot of orphan shares, something is wrong with P2Pool's P2P connection. Decrease the load on your internet connection or enable QoS (Quality of Service) on your router.

'''Q:''' What is PPLNS? 
'''A:''' Pay-Per-Last-N-Shares is a payout method that is completely resistant to pool hoppers.

'''Q:''' Why am I not getting very many shares?! 
'''A:''' The P2Pool difficulty is hundreds of times higher than on other pools. It can take time to get a share. P2Pool displays an estimate of how long you have to wait in the console output.

'''Q:''' Why does my miner say it has found a lot of shares but p2pool say I have only found a few?! 
'''A:''' The real P2Pool difficulty is hundreds of times higher than on normal pools, but p2pool essentially lies to your miner and tells it to work on relatively easy shares so that it submits shares every few seconds instead of every few hours. P2Pool then ignores any submitted shares that don't match the real share difficulty. By doing this, P2Pool can more accurately report your local hash rate and you can see if you are having problems with too many stale shares quickly

'''Q:''' Why am I getting so many rejects? 
'''A:''' You're using an incompatible miner. See the miners section here, increase your FPS on the miner, decrease the intensity, upgrade your miner, or try a different miner.

'''Q:''' What stops the pool operator or the block finder from stealing a block? 
'''A:''' A block solution is only worth anything because its hash matches Bitcoin's target. Altering anything within the block will change its hash and make it worthless. If you are concerned about the pool operator stealing a block, you should try to inspect the source code of each new version.

'''Q:''' Why does it say "Generated?" I want to spend my coins now! 
'''A:''' P2Pool includes payouts in generation transactions, which must mature (taking 120 blocks or 20 hours) before they can be spent. The reason for this is that a block could be orphaned, which would make its payout invalid and could reverse transactions.

'''Q:''' Do I get paid transaction fees? 
'''A:''' Yes. They are split among P2Pool miners.

'''Q:''' What are these payments I'm getting that aren't generated? 
'''A:''' These are subsidies that people who support the idea of P2Pool send to miners.

'''Q:''' Cool Subsidies sound like an awesome idea! How do I send some BTC to these awesome miners? 
'''A:''' See end of this page.

'''Q:''' Do I really need the WHOLE blockchain? 
'''A:''' Yes. Your node needs to be able to independently make decisions about what transactions to mine.

'''Q:''' How do merged mining payments work? 
'''A:''' Merged mining is handled entirely by namecoind, so you're solo mining and payouts will go into namecoind's wallet.

=== 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 intensity (8 for bfgminer?) helps a lot with reducing stales.

* bfgminer, cgminer, and ufasoft work perfectly without any extra options.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

====Tips to configure bfgminer to reduce stale/doa:====
* "gpu-threads" : "1", (2 by default)
* "queue" : "0", (1 by default)

Because of fast longpooling in p2pool it is better not NOT fetch work ahead.

On non-dedicated machines intensity=3 allows normal usage of PC, set it to 7 or more to get full hashrate.

On most cards best is diablo and phatk kernel, looks like poclbm kernel have unstable rate.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seamless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.
* You can make P2Pool use a configuration file by running run_p2pool.py @FILENAME, with FILENAME being the path to a file containing the command-line arguments (newlines are ignored) Example:
<pre>
--net litecoin
-n 1.2.3.4
</pre>
* Setting the username of your miner connecting to P2Pool to a Bitcoin address will make it mine to that address instead of the one requested from bitcoind or set by -a
* Appending "/1000" to a miner's username will increase the difficulty of producing a P2Pool share to at most 1000. This is useful to large miners because doing this can make it easier for small miners while minimally impacting the large miners themselves. See [https://bitcointalk.org/index.php?topic=18313.msg816322#msg816322 recommended values].
** Appending "+1" (for example) after that will make P2Pool always give your miners work with a difficulty of 1

=== Web interface ===

Lots of data and useful tools are available at http://127.0.0.1:9332/something:
* /static/ - Lots of information from shares to graphs to payouts.
* /rate
* /users
* /fee
* /current_payouts
* /patron_sendmany - Gives sendmany outputs for fair donations to P2Pool
* /global_stats
* /local_stats
* /peer_addresses
* /payout_addr
* /recent_blocks
* /uptime
* /web/log - Some different stats collected over the last day

=== Included README ===
<pre>Requirements:
Generic:
Bitcoin >=0.6.0rc4 or Bitcoin >=0.5.4 (for BIP16 support) or Litecoin
Python
Twisted
python-argparse (for Python <=2.6)

Linux:
sudo apt-get install python-zope.interface python-twisted python-twisted-web
sudo apt-get install python-argparse # if on Python 2.6 or older

Windows:
Install Python 2.7: http://www.python.org/getit/
Install Twisted: http://twistedmatrix.com/trac/wiki/Downloads
Install Zope.Interface: http://pypi.python.org/pypi/zope.interface/3.8.0
Unzip the files into C:\Python27\Lib\site-packages

Running P2Pool:
To use P2Pool, you must be running your own local bitcoind. For standard
configurations, using P2Pool should be as simple as:

python run_p2pool.py

Then run your miner program, connecting to 127.0.0.1 on port 9332 with any
username and password.

If you are behind a NAT, you should enable TCP port forwarding on your
router. Forward port 9333 to the host running P2Pool.

Run "python run_p2pool.py --help" for additional options.

Notes for Litecoin:
Requirements:
In order to run P2Pool with the Litecoin network, you would need to build and install the
ltc_scrypt module that includes the scrypt proof of work code that Litecoin uses for hashes.

Linux:
cd litecoin_scrypt
sudo python setup.py install

Windows:
Install MinGW: http://www.mingw.org/wiki/Getting_Started
Install Python 2.7: http://www.python.org/getit/

cd litecoin_scrypt
C:\Python27\python.exe setup.py build --compile=mingw32 install

If you run into an error with unrecognized command line option '-mno-cygwin', see this:
http://stackoverflow.com/questions/6034390/compiling-with-cython-and-mingw-produces-gcc-error-unrecognized-command-line-o

Running P2Pool:
Run P2Pool with the "--net litecoin" option.
Run your miner program, connecting to 127.0.0.1 on port 9327.
Forward port 9338 to the host running P2Pool.

Litecoin's use of ports 9332 and 9332 conflicts with P2Pool running on
the Bitcoin network. To avoid problems, add these lines to litecoin.conf
and restart litecoind:
rpcport=10332
port=10333
</pre>

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin,litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--give-author DONATION_PERCENTAGE] [--iocp]
[--irc-announce] [--no-bugreport] [--p2pool-port PORT]
[-n ADDR[:PORT]] [--disable-upnp] [--max-conns CONNS]
[-w PORT or ADDR:PORT] [-f FEE_PERCENTAGE]
[--bitcoind-address BITCOIND_ADDRESS]
[--bitcoind-rpc-port BITCOIND_RPC_PORT]
[--bitcoind-p2p-port BITCOIND_P2P_PORT]
[BITCOIND_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version 0.11.1-8-ged9359d)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin,litecoin}
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>)
--datadir DATADIR store data in this directory (default: <directory
run_p2pool.py is in>/data)
--logfile LOGFILE log to this file (default: data/<NET>/log)
--merged MERGED_URLS call getauxblock on this url to get work for merged
mining (example:
http://ncuser:ncpass@127.0.0.1:10332/)
--give-author DONATION_PERCENTAGE
donate this percentage of work towards the development
of p2pool (default: 0.5)
--iocp use Windows IOCP API in order to avoid errors due to
large number of sockets being open
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--no-bugreport disable submitting caught exceptions to the author
--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)
-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
--max-conns CONNS maximum incoming connections (default: 40)

worker interface:
-w PORT or ADDR:PORT, --worker-port PORT or ADDR:PORT
listen on PORT on interface with ADDR for RPC
connections from miners (default: all interfaces,
bitcoin:9332, litecoin:9327)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The pool began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:

For example, a bash script to donate 10 btc is:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany/10)"
</pre>

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.

Note that the amount you donate will be allocated to recent miners in proportion to the amount of work they've done in the last 24 hours or so, but all the miner whose shares of the donated amount are less than 0.01 BTC will have their shares combined into a single amount which is awarded to one of them at random, with the chance of winning this 'lottery' weighted by the miner's recent amount of work done. You can change this 0.01 BTC threshold like this, for example, which says to pay 10 BTC, but to share it amongst more miners that the default, cutting off at 0.001 BTC instead of at 0.01 BTC.
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany/10/0.001)"
</pre>

If you decide to donate you should announce it on the forums so that your donations provide the most incentive possible.

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]
* [[P2Pool code documentation]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support
* [http://p2pool.info/ p2pool.info] stats page
* [http://p2pool.hostv.pl p2pool.hostv.pl] Public list of P2Pool BTC/LTC nodes.

==References==
<references />

[[Category:Pool Operators]]

Avalon

2013-07-18T21:50:22Z

Forrestv: updated p2pool information

'''Avalon''' is a company that produces bitcoin mining hardware.

= Pictures =
[[File:Avalon-case.jpg | 320px]] [[File:Avalon-eth-wifi.jpg | 320px]] [[File:Avalon-side-1.jpg | 320px]]

[[File:Avalon-side-2.jpg | 320px]] [[File:Avalon-fan.jpg | 320px]] [[File:Avalon-modular-4.jpg | 320px]]

[[File:Avalon-detail.JPG | 320px]] [[File:Avalon-side-3.jpg | 320px]]

[[File:Avalon-IR-1.jpg | 320px]] [[File:Avalon-IR-2.jpg | 320px]]

= Hardware Information =
== [https://bitcointalk.org/index.php?topic=120184.msg1294416#msg1294416 Chip Specification] ==
[[File:Avalon-A3256-Q48-front.png | 320px]] [[File:Avalon-A3256-Q48-foot.png | 320px]] [[File:Avalon-A3256-Q48-foot-side.png | 320px]]

[[File:Avalon-A3256-Q48-foot-1.png | 320px]] [[File:Avalon-A3256-Q48-foot-detail.png | 320px]] [[File:Avalon-A3256-Q48-front-side-1.png | 320px]]

Technology Summary:
TSMC 0.11- micron G process
5 Metal
Core Voltage: 1.2 V
I/O Voltage: 3.3 V
Core Frequency: 256+ MHz
Number of Pads: 48
8 Data
40+1 Power
Package Type: QFN48 -0.5 Pitch
Packaged Chip Size: 7 mm x 7 mm

Chip Interface
Data Pins (8 in total):
Clock i
Serial Data In [2] i
Serial Data Out [2] o
Serial Data Bypass [2] o
Reserved [1] -

== Wafer ==
TSMC
TMEM91
Chip Size : X = 3.9760 ,Y = 4.0560 mm
Reticle Size : X/cell = 3 ,Y/cell = 3
Offset Value : X = -3.7668 ,Y = -2.2990 mm
Alignment Mark : (118.80,83.20),(-118.80,-83.20)
Alignment Mark Tolerant Distance : 1.6 mm
Notch Reserved Distance : 7.75 mm
Start Distance : 7.75 mm
Ring Edge : 3.0 mm
Photo Die Number: 4055

== Power ==
Chip power efficienty: 6.6W/GHs @ 1.15 V
Module power consumption: 149W @ 20GHs / 164W@ 22GHs
Machine power consumption: 595W @ 220V-AC / 620W @ 120V-AC

=== Comfirmed working PSU list ===
* [http://www.antec.com.cn/product.php?id=NzA0MjY0 ANTEC EA-650 GREEN]
* [http://www.enermax.cn/Products_Pages.asp?ID=188&SortID=1 Enermax GX650]
* [http://www.enermax.cn/Products_Pages.asp?ID=189&SortID=1 Enermax GX750]
* [http://www.corsair.com/cn/power-supply-units/gs-series-power-supply-units/gs-series-gs700-80-plus-bronze-certified-power-supply-840.html CORSAIR GS700]
* [http://www.corsair.com/cn/power-supply-units/gs-series-power-supply-units/gs-series-gs800-80-plus-bronze-certified-power-supply-841.html CORSAIR GS800]
* [http://www.super-flower.com.cn/gb/pro_detail.asp?id=212 Super-Flower(振华) SF-650P14XE(GX)]
* [http://www.enermax.cn/Products_Pages.asp?ID=145&SortID=1 Enermax 金魔冰核1000W(suit for 4 modules, a little bit long)]
* [http://ocz.com/consumer/psu/zx-series-850w-1250w-power-supply OCZ ZX Series 1250W]

=== The PSU Spec ===
* '''155mm''' recommend, MAX: 170mm
* For 3 module units: 650W, 48A 12V, at least. recommend for a 20% margin.
* For 4 module units: 750W, 60A 12V, at least. recommend for a 20% margin.
* Plugs:
** 1X ATX 24PIN
** 1X EPS 12V (8PIN)
** 2X PCIE 12V (8PIN)

== The TP-LINK WR703N ==
[[File:avalon-703n-back.JPG | 320px]] [[File:avalon-703n-front.JPG | 320px]]

== Control Unit ==
[[File:avalon-controlunit-v1.2.JPG | 320px]] [[File:avalon-controlunit-v1.2-fpga.JPG | 320px]] [[File:avalon-controlunit-v1.2-usb-serail-chip.JPG | 320px]]

[[File:avalon-controlunit-v1.2-spi-flash.JPG | 320px]] [[File:avalon-controlunit-v1.2-usb-connector.JPG | 320px]] [[File:avalon-temperature-sensor-1.JPG | 320px]]

[[File:avalon-controlunit-v1.2-P5.JPG | 320px]] [[File:avalon-controlunit-v1.2-by-ngzhang.JPG | 320px]]

== PDU ==
[[File:avalon-pdu-v1.2.JPG | 320px]]
[[File:avalon-pdu-v1.2-side.JPG | 320px]]

== Parts ==
[[File:avalon-fpga-controller-led-detail.JPG | 320px]] [[File:avalon-fpga-controller-led.JPG | 320px]]

[[File:avalon-modular-date-cable-head.JPG | 320px]] [[File:avalon-modular-date-cable.JPG | 320px]]

[[File:avalon-modular-power-cable-head.JPG | 320px]] [[File:avalon-modular-power-cable.JPG | 320px]]

[[File:avalon-temperature-sensor-detail.JPG | 320px]] [[File:avalon-temperature-sensor.JPG | 320px]]

= User Guide =
* Connect your laptop to the eithernet port of the Avalon
* Setup your laptop IP address 192.168.0.101
* Open http://192.168.0.100
* Make sure WR703N can access Internet, Configure WiFi: Network -> WIFI -> Scan(select your WIFI network) -> Join Network -> WPA passphrase -> Submit -> Save & Apply for connect to WIFI Internet
* setup your mining worker: Status -> Cgminer Configuration.
* Restart the cgminer service: System -> Startup,
* Check your avalon status: Status -> Cgminer Status
* Setup password/using ssh
ssh root@192.168.0.100 # Once you setup the password the telnet service will be stop. use ssh instead.

== Cgminer option ==
'''--avalon-options 115200:24:10:45:282'''. this is the default avalon option. here is the details:
'''115200''': the serial baud. this have to match the controller baud.
'''24''': the miner count.(there are 3 modulars in avalon. each modular have 8 miners), if your avalon have 4 modulars. change it to 32
'''10''': the chip count pre miner.
'''45''': the controller timeout parameter. the valid number: 50, 47, 45, 40.
'''282''': the chip clock. the valid number: 256, 270, 282, 300.

== Run cgminer manually ==
In case you need to run Cgminer in linux console please run the following command:
*Restart Cgminer:
# /etc/init.d/cgminer restart

If your avalon does not mine properly, please run Cgminer in debug mode with -D --verbose option. For example:
# cgminer -S /dev/ttyUSB0 -o stratum.btcguild.com:3333 -O xxxx:yyyy -D --verbose --avalon-options 115200:24:10:45:282 --api-allow "W:0/0" --api-listen 2>/tmp/cgminer-debug.log

== TP-LINK TL-WR703N ==
There is a modify version of TP-LINK TP-WR703N inside Avalon. cgminer running at 703n, this 703n have 64MB ram and modified power supply. it power from the usb-client side(we moved a 0R resistor from '''J1''' to '''R113''' for that)

Why there is a ugly USB HUB there? you can find more information about AR9331's usb stability issue [https://forum.openwrt.org/viewtopic.php?id=39956 here].

=== How to reflash ===
# Download latest Avalon [http://downloads.qi-hardware.com/people/xiangfu/avalon/latest/openwrt-ar71xx-generic-tl-wr703n-v1-squashfs-factory.bin image] to your PC.
# Goto:
System -> Backup / Flash Firmware -> Flash new firmware image (make sure '''Keep settings''' is checked)
# Select the image you just download. then compare the md5 in next page. if everything fine. click '''Proceed'''

'''Attention:''' To avoid your WR703N become a brick, during flash your WR703N be careful DO NOT power off avalon, and DO NOT break your network connection. Just wait there till you see OpenWrt login web page again.

'''Attention:''' If not essential please do not re-Flash your Avalon. Because not all of WR703N issue could be resolved by reset button. If you want to play WR703N I would like to recommend you order a standalone TP-LINK WR703N from ebay or somewhere for studying purpose.

== WIFI or Ethernet Cable ? ==
Avalon shipped with a 9db antenna after connect it to WR703N usually could establish good wireless connection with your WIFI router. But if for some reason you would like to use Ethernet Cable to connect Avalon with your network, please login OpenWrt and configure the LAN port:
Network -> Interfaces -> LAN -> Edit -> Common Configuration -> General Setup
Disable the DHCP on Lan port

'''Attention:''' You need to configure it correctly based on your own network enviroment. If anything wrong you might could not access your WR703N any more.

== Start to mine ==
To maximize your Avalon miner's performance, it is recommended that you choose pools with the stratum protocol supported. The default mining pool configured in Avalon is ozco.in. To change it login to OpenWrt:
Status -> Cgminer Configuration
Click "Save & Apply" to save your update and restart cgminer immediately

Currently the stratum pools that could work stable with Avalon are:
* [http://50btc.com/ 50BTC.com]
* [https://bitcointalk.org/index.php?topic=158105.0 Solo mining with Eloipool]
* [http://bitminter.com BitMinter]
* [http://eligius.st Eligius]
* [https://www.ozcoin.net Ozcoin]
* [http://www.btcguild.com btcguild]
* [http://mining.bitcoin.cz slush's pool]
* [http://www.triplemining.com Triplemining]

To get more information about how to configure specific pools, please check their website. If you run multiple Avalons, we recommend that you create a dedicated worker for each of them. This will make it easier to monitor your Avalons through the pool's website and identify possible problems.

== Source code ==
* https://github.com/BitSyncom/cgminer/tree/avalon
* https://github.com/BitSyncom/cgminer-openwrt-packages
* https://github.com/BitSyncom/luci/tree/cgminer-webui
* https://github.com/BitSyncom/avalon-extras

== FPGA controller ==
=== V1.0 ~ V1.2 ===
About '''P5''' jumper: close this jumper will supply 5V to the USB-B port. in this system, the controller board power the 703N from the client side. if you connect the controller itself to a PC, you better remove the jumper.

=== V1.5 ===
[[File:Avalon fpga controller v1.5.jpg | 320px]] [[File:Avalon fpga controller v1.5 usb hub.jpg | 320px]]
* Remove the '''[http://www3.picturepush.com/photo/a/13207881/1024/Anonymous/avf1.png F1(Fuse)]''' for fix the USB-HUB chip overheat,
# if you are batch2 user and your received Avalon between '''Apr 26 2013 ~ May 31 2013'''
# the FPGA controller is '''1.5'''
# your FPGA contoller board still have '''F1 mounted'''
you need do this by yourself. removing F1 will not make the usb hub stop working, F1 powers the USB-A1 plug (which is normally unused), more info please checkout [https://github.com/BitSyncom/avalon-ref/issues/5 here]

=== V1.51 ===
* Fixed USB-HUB chip overheat, NO NEEDS remove F1 anymore

== Update FPGA controller firmware (NOT FINISHED/FULL DOCUMENT YET) ==
[[File:Fpga-controller-jtag-pins.png]]

* Update under Avalon 703N: http://downloads.qi-hardware.com/people/xiangfu/avalon/fpga-controller/
* http://en.qi-hardware.com/w/images/f/ff/M1_JTAGserialpod_Pins.JPG

#mini-jtag load xc6slx16-2-ftg256.bscan_s6_spi_isf_ext.bit && sleep 1 && xc3sprog -c qi -v -I fpga_controller_2013-05-02-D.bit
xc3sprog -c qi xc6slx16-2-ftg256.bscan_s6_spi_isf_ext.bit && sleep 1 && xc3sprog -c qi -v -I fpga_controller_2013-05-02-D.bit
xc3sprog -c qi -v -I file.bin:R:0:bin
dd if=file.bin bs=68 skip=1 of=file2.bin
xc3sprog -c qi -v -I file2.bin:w:0:bin
rm -f file.bin file2.bin

== P2Pool Operation with Avalon ==

Doing anything special is no longer required as of commit 11d63ef66 (which is yet unreleased). Since the recent P2Pool hardfork, dead-on-arrival rates of about 6% are normal, close to normal GPU rates (1-2%), so mining is nearly as efficient as solo mining.

== About [usb 1-1: clear tt 1 (8030) error -71] ==
Not all 703n have this problem. ignore this section if you never meet this error

* There is a power issue with the 703N, The 703N is drawing to much power it caused the USB HUB chip on Senseless's FPGA controller to nearly destroy itself. See the destruction [ http://www.mysenselesslife.com/avalon/DSCN5212.JPG here]

* In order to fix it you need had to '''power down the WiFi modem by disable it''', use Eithernet instead. The kernel no long report -71 errors. thanks to senseless and others who help on identify the issue.

* If your avalon was far away from your router. eithernet cable not fit. you may want try those kind of devices
** TP-LINK TL-PA500(For mainland China) : http://www.tp-link.com.cn/product_adapter_263.html
** TP-LINK TL-PA511 : http://www.tp-link.com/en/products/details/?model=TL-PA511

== Others ==
* There is a pair of gloves in Avalon package. please put it on when assembling or carrying.

* About the plastic sheets: please '''remove them BEFORE''' mining. we design the case as a part of heatsink, so remove the plastic sheets is a must

* About FAN change: '''DO NOT''' change the fans to a low speed model. will cause over heat. '''DO NOT''' install extra fans at the rear "fan socket". will cause PSU over heat and nearly useless for module cooling.

* About install extra heat-sinks on each avalon chip: please do not do that. there is a air gap between the die and package top, install a heatsink on chip is useless. and will cause overheating. because the top PCB copper act as a heatsink too. do not cover them.

* About water cooling: yes, do it.

= [http://downloads.qi-hardware.com/people/xiangfu/avalon/ Firmware] =
* Check your firmware version by goto '''Cgminer Status''' page
* Latest Firmware is [http://downloads.qi-hardware.com/people/xiangfu/avalon/latest/openwrt-ar71xx-generic-tl-wr703n-v1-squashfs-factory.bin here]
* The Avalon firmware SDK: [http://downloads.qi-hardware.com/people/xiangfu/avalon/latest/OpenWrt-SDK-ar71xx-for-linux-x86_64-gcc-4.6-linaro_uClibc-0.9.33.2.tar.bz2 here]

== [http://downloads.qi-hardware.com/people/xiangfu/avalon/next-testing/ NEXT] ==
Please always using the latest testing image for testing.

* New options for Avalon
--avalon-auto Adjust avalon overclock frequency dynamically for best hashrate
--avalon-cutoff <arg> Set avalon overheat cut off temperature (default: 60)
--avalon-fan <arg> Set fanspeed percentage for avalon, single value or range (default: 20-100)
--avalon-freq <arg> Set frequency range for avalon-auto, single value or range
--avalon-options <arg> Set avalon options baud:miners:asic:timeout:freq
--avalon-temp <arg> Set avalon target temperature (default: 50)

== [http://downloads.qi-hardware.com/people/xiangfu/avalon/20130607/ 20130607] ==
* '''Update cgminer to 3.2.1''', we have the direct USB feature now.
* Add --lowmem by default
* cgminer-monitor: change the schedule from 5mins to 2mins
* cgminer-monitor: switch from Diff1 work to Last Valid Work
* Disable DHCP on lan port.
* Remove custom DNS (8.8.8.8)
* Some minor changes on web page

== [http://downloads.qi-hardware.com/people/xiangfu/avalon/20130519/ 20130519] ==
* '''Update cgminer to 3.1.1'''
* Add '''More Options''' on web configure page(you can add 4th,5th pool here now)
* Disable hotplug. useless on Avalon
* Include '''usbmon''' in firmware, prepare/debug for usb code, this was for developers
* Dynamic display [match_work_count*] base on Modular Count
* You may want add '''--real-quiet''' under Cgminer Configuration --> More Options after upgrade
* Change 300MHS timeout from 40 to 43
* Change Modular Count(3 ~ 4) to Miner Count(1 ~ 32) on webui
* Switch buildhost from Ubuntu 12.10 to Debian 7.0.0
* NOTE: If your Pool URLs have trailing slash '''remove the trailing slash''' (symptom is: [2013-06-04 19:05:30] Failed to resolve (?wrong URL) host.name.com:PORT/ and/or all Pools with trailing slash listed as DEAD in status)

== [http://downloads.qi-hardware.com/people/xiangfu/avalon/20130419 20130419] ==
* '''Merged to cgminer. BIG thanks to conman'''. so we have all cgminer's improvment
* Idle avalon chips after reset. for save power. (idle needs ~50W)
* Fix the cgminer restart bug.
* Fix temp/fan have wrong value(the wrong result from fpga controller)
* Fix the fan control. now base on the max value of temp2/3
* Fix no_matching_work only count in debug mode
* Update cgminer-monitor, replace [Accept] with [Diff1 Work], add killall before restart.
* Fix a typo on /usr/bin/cgminer-monitor
* '''More check/fliter on result. this make Avalon more stable'''
* New status page, new api log page.
* Improve the cgminer service. a restart takes ~2 seconds now. no needs ntpd when restart
* Quiet some improvments on software develop/codeing. compile Avalon firmware is much eaiser with [https://github.com/BitSyncom/avalon-extras/blob/master/scripts/build-avalon-image.sh build-avalon-image.sh]
* Frimware version:
[Firmware Version] => 20130419
cgminer-8e8313c
luci-28b4ff2
cgminer-openwrt-packages-f2bc5dc

== [http://downloads.qi-hardware.com/people/xiangfu/avalon/20130321/ 20130321] ==
*For fix the cgminer-monitor, please run this command after you reflash
'''sed -i 's/ $B / "$B" /' /usr/bin/cgminer-monitor'''

<source lang="c">
If you "check the Keep settings", you need fill API Allow to "W:127.0.0.1" after reflash, edit it here: "http://AVALON_IP/cgi-bin/luci/admin/status/cgminer/", "DO NOT" left it blank
</source>
<source lang="c">
If you "uncheck the Keep settings" when reflashing, Please "reconfigure your Avalon" after reflash
</source>

* Update Linux from 3.6 to 3.8.3
* Update OpenWrt to r36095
* When there is no network. automatic idle chip after detect avalon, save power and protect your avalon overheat
* Idle chip when cgminer close avalon
* Add device_reinit support
* Add frequency, modular configure on web ui
* Add API Allow on web ui
* Add pool balance on web ui, by default balance on all 3 pools
* Add stratum+tcp:// by default
* Display Frequency on status page
* Fix the [https://bitcointalk.org/index.php?topic=155455.0 kern.err kernel: ... ath: phy0: ...] bug
* Fliter >=100 degree result for debug
* Replace TempMax with No Matching Work

==[http://downloads.qi-hardware.com/people/xiangfu/avalon/openwrt-ar71xx-generic-tl-wr703n-v1-squashfs-factory-20130225.bin 20130225]==
* A new cgminer status page
* /etc/avalon_version include all repo commit
* Fix temp_history_count, make sure 2~3s call adjuest_fan

==[http://downloads.qi-hardware.com/people/xiangfu/avalon/openwrt-ar71xx-generic-tl-wr703n-v1-squashfs-factory-20130218.bin 20130218]==
* Update adjust_fan()
* Using avaon default worker

==[http://downloads.qi-hardware.com/people/xiangfu/avalon/openwrt-ar71xx-generic-tl-wr703n-v1-squashfs-factory-20130212.bin 20130212]==
* Update fan pwm

==[http://downloads.qi-hardware.com/people/xiangfu/avalon/openwrt-ar71xx-generic-tl-wr703n-v1-squashfs-factory-20130205.bin 20130205]==
* Update fan pwm MAX/MIN
* Sync with upstream, fix the memory leak bug
* Monitor the Accept number

==[http://downloads.qi-hardware.com/people/xiangfu/avalon/openwrt-ar71xx-generic-tl-wr703n-v1-squashfs-factory-20130127.bin 20130127]==
* Add overclock code
* Change the cgminer configure to UCI system
* Add the simple web ui

==20130117==
* Update OpenWRt to r35097
* Update cgminer to 2.10.4
* Remove /www/miner.php, change cgminer cron job to */5
* Start ntpd before start cgminer

== Test Plan ==
* New firmware don't break Avalon for sure
* New firmware don't use all flash. have to keep some space for save configuration
* Either and WiFI connect works fine
* Cgminer works fine(the kernel user driver, cgminer it self, cgminer-monitor and uci configurations files)
* After configure cgminer. [Save & Apply] can restart the cgminer
* The Status/API log page works fine
* Test mining
* Test the cgminer-monitor
* Make sure 80/22/4028 open on WAN.

== Unofficial Firmware ==
* [https://bitcointalk.org/?topic=78192.msg1566545#msg1566545 Untested BFGMiner 3.0 alpha1 for Avalon]

= How to Compile Your Own Firmware for Avalon =
1. First check if you have met the building prerequisites. Checkout this page first [http://wiki.openwrt.org/doc/howto/buildroot.exigence OpenWrt Buildroot – Installation]

For example, if your OS is Ubuntu/Debian, install the required packages like this:
sudo apt-get update
sudo apt-get install gawk flex quilt xsltproc unzip subversion git-core build-essential libxml-parser-perl libncurses5-dev zlib1g-dev libssl-dev liblua5.1-0-dev

2. Now get the source code, prepare the code and build. '''this needs ~6GB'''
wget https://raw.github.com/BitSyncom/avalon-extras/master/scripts/build-avalon-image.sh
chmod +x build-avalon-image.sh
./build-avalon-image.sh --clone #prepare the code and build, '''ONLY NEED ONCE'''
./build-avalon-image.sh

3. Update all repos
./build-avalon-image.sh --update

4. Only rebuild cgminer
./build-avalon-image.sh --cgminer

5. Finally you could get the freshly built firmware files under '''avalon/bin/'''

== Compile with kernel usbmon ==
* You need apply [https://lists.openwrt.org/pipermail/openwrt-devel/2013-May/020107.html this patch] to your OpenWrt for enable [https://www.kernel.org/doc/Documentation/usb/usbmon.txt usbmon]
* Run '''make menuconfig''' goto '''Kernel modules''' --> '''USB Support''' enable '''kmod-usb-mon'''

= IRC: #avalon @freenode.net =
'''#avalon @freenode.net''' Thanks to midnightmagic create that channel

= FAQ =
* Why there is a USB-HUB inside
[https://forum.openwrt.org/viewtopic.php?id=39956 AR9331's usb stability issue]

*Why ASIC bitcoin mining?
*Why Avalon?
*Who made Avalon?
*How to order one?
http://store.avalon-asics.com/

= Links =
* http://launch.avalon-asics.com/
* [https://bitcointalk.org/index.php?topic=140539.0;all Avalon ASIC users thread]
* http://garzikrants.blogspot.de/2013/01/avalon-asic-miner-review.html
* Jgarzik's solo mining [https://bitcointalk.org/index.php?topic=158105.0 configuration]
* [http://squonk42.github.io/TL-WR703N/ Reverse-Engineering work on the TL-WR703N 150M 802.11n Wi-Fi Router]
* http://3.14.by/en/read/avalon-bitcoin-microscope-photos

= Donation =
* Ngzhang0: [https://blockchain.info/address/1kBGUHDxmSAegACRB6fcE2vrnVAfPJarW 1kBGUHDxmSAegACRB6fcE2vrnVAfPJarW]
* Con Kolivas: [https://blockchain.info/address/15qSxP1SQcUX3o4nhkfdbgyoWEFMomJ4rZ 15qSxP1SQcUX3o4nhkfdbgyoWEFMomJ4rZ]
* Kanoi: [https://blockchain.info/address/1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb]
* Xiangfu: [https://blockchain.info/address/12h6gdGnThW385JaX1LRMA8cXKmbYRTP8Q 12h6gdGnThW385JaX1LRMA8cXKmbYRTP8Q]

[[zh-cn:阿瓦隆]]

[[Category:Hardware]]

P2Pool

2013-07-10T06:03:54Z

Forrestv:

IMPENDING HARDFORK - UPDATE P2POOL FROM THE FOLLOWING LINK
Download P2Pool from the forum thread: [https://bitcointalk.org/index.php?topic=18313.0 P2Pool]

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

<blockquote>P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 10 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target. Whenever a peer announces a new share found (new block in the P2Pool block chain), it is received by the other peers, and the other peers verify that this block contains payouts for all the previous miners who found a share (and announced it) that made it into the P2Pool share chain. This continues until some peer finds a block that has a difficulty that meets the Bitcoin network's difficulty target. This peer announces this block to the Bitcoin network and miners who have submitted shares for this block are paid in the generation transaction, proportionally to how many shares they have found in the last while. - Unknown author</blockquote>

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin and avoids the risk of hard to detect theft by pool operators.

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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization, some Bitcoin supporters donate to P2Pool miners, resulting in average returns above 100% of the expected reward.
However, it should be noted that there are other pools (such as [[BitPenny]] and [[Eligius]]) which can provide this same level of decentralization.

== 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, just as Bitcoin regulates it to generate one block every ten minutes.
This means that finding shares becomes more difficult (resulting in higher variance) the more people mine on P2Pool, though large miners have the option to raise their difficulty, and so reduce the impact of their mining on P2Pool's minimum difficulty.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640 (= 24 hours of shares), whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is proportional to the p2pool difficulty at that time.

The block reward (currently 25BTC) 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 ===

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: edit bitcoin.conf to include:
rpcuser=USER
rpcpassword=LONG_RANDOM_SECRET_VALUE
server=1
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** 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
** Source: python run_p2pool.py
* Run a miner daemon with long polling connecting to 127.0.0.1 (or the IP of the host running p2pool if it isn't on the same computer as the miner) on port 9332 with any username and password
** bfgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher (but not 3.x)
* python-argparse
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does my miner report so many longpoll events when mining on p2pool? - P4Man" 
'''A:''' "Once every ~10 seconds is normal. That is how often p2pool shares are generated (as opposed to ~10 min for bitcoin blocks) - cabin"

'''Q:''' "Do the 'orphan' and 'dead' shares in P2Pool's status display hurt me?" 
'''A:''' They shouldn't - It's normal for some fraction of everyone's shares to end up orphaned or dead. Because payouts are calculated by counting how many shares you have relative to others, everyone with normal configurations is equally "hurt" by this. However, if you have a large proportion of stales, your payout will be hurt. You can see how well you're doing by looking at P2Pool's "Efficiency" (ex: ''Efficiency: ~110.6% (40-111%)''). If 100% doesn't lie within the [http://en.wikipedia.org/wiki/Confidence_interval confidence interval] at the end, something is probably wrong (with 95% confidence).

'''Q:''' "What do I do if my efficiency is low?" 
'''A:''' Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. If you have a lot of dead shares or the "Local dead on arrival" number is higher than a few percent, that means that something is wrong with your miner. Check to make sure that it is one of the working versions in the ''Miners'' section on this page. Lower the intensity or raise the FPS of your miner. If you have a lot of orphan shares, something is wrong with P2Pool's P2P connection. Decrease the load on your internet connection or enable QoS (Quality of Service) on your router.

'''Q:''' What is PPLNS? 
'''A:''' Pay-Per-Last-N-Shares is a payout method that is completely resistant to pool hoppers.

'''Q:''' Why am I not getting very many shares?! 
'''A:''' The P2Pool difficulty is hundreds of times higher than on other pools. It can take time to get a share. P2Pool displays an estimate of how long you have to wait in the console output.

'''Q:''' Why does my miner say it has found a lot of shares but p2pool say I have only found a few?! 
'''A:''' The real P2Pool difficulty is hundreds of times higher than on normal pools, but p2pool essentially lies to your miner and tells it to work on relatively easy shares so that it submits shares every few seconds instead of every few hours. P2Pool then ignores any submitted shares that don't match the real share difficulty. By doing this, P2Pool can more accurately report your local hash rate and you can see if you are having problems with too many stale shares quickly

'''Q:''' Why am I getting so many rejects? 
'''A:''' You're using an incompatible miner. See the miners section here, increase your FPS on the miner, decrease the intensity, upgrade your miner, or try a different miner.

'''Q:''' What stops the pool operator or the block finder from stealing a block? 
'''A:''' A block solution is only worth anything because its hash matches Bitcoin's target. Altering anything within the block will change its hash and make it worthless. If you are concerned about the pool operator stealing a block, you should try to inspect the source code of each new version.

'''Q:''' Why does it say "Generated?" I want to spend my coins now! 
'''A:''' P2Pool includes payouts in generation transactions, which must mature (taking 120 blocks or 20 hours) before they can be spent. The reason for this is that a block could be orphaned, which would make its payout invalid and could reverse transactions.

'''Q:''' Do I get paid transaction fees? 
'''A:''' Yes. They are split among P2Pool miners.

'''Q:''' What are these payments I'm getting that aren't generated? 
'''A:''' These are subsidies that people who support the idea of P2Pool send to miners.

'''Q:''' Cool Subsidies sound like an awesome idea! How do I send some BTC to these awesome miners? 
'''A:''' See end of this page.

'''Q:''' Do I really need the WHOLE blockchain? 
'''A:''' Yes. Your node needs to be able to independently make decisions about what transactions to mine.

'''Q:''' How do merged mining payments work? 
'''A:''' Merged mining is handled entirely by namecoind, so you're solo mining and payouts will go into namecoind's wallet.

=== 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 intensity (8 for bfgminer?) helps a lot with reducing stales.

* bfgminer, cgminer, and ufasoft work perfectly without any extra options.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

====Tips to configure bfgminer to reduce stale/doa:====
* "gpu-threads" : "1", (2 by default)
* "queue" : "0", (1 by default)

Because of fast longpooling in p2pool it is better not NOT fetch work ahead.

On non-dedicated machines intensity=3 allows normal usage of PC, set it to 7 or more to get full hashrate.

On most cards best is diablo and phatk kernel, looks like poclbm kernel have unstable rate.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seamless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.
* You can make P2Pool use a configuration file by running run_p2pool.py @FILENAME, with FILENAME being the path to a file containing the command-line arguments (newlines are ignored) Example:
<pre>
--net litecoin
-n 1.2.3.4
</pre>
* Setting the username of your miner connecting to P2Pool to a Bitcoin address will make it mine to that address instead of the one requested from bitcoind or set by -a
* Appending "/1000" to a miner's username will increase the difficulty of producing a P2Pool share to at most 1000. This is useful to large miners because doing this can make it easier for small miners while minimally impacting the large miners themselves. See [https://bitcointalk.org/index.php?topic=18313.msg816322#msg816322 recommended values].
** Appending "+1" (for example) after that will make P2Pool always give your miners work with a difficulty of 1

=== Web interface ===

Lots of data and useful tools are available at http://127.0.0.1:9332/something:
* /static/ - Lots of information from shares to graphs to payouts.
* /rate
* /users
* /fee
* /current_payouts
* /patron_sendmany - Gives sendmany outputs for fair donations to P2Pool
* /global_stats
* /local_stats
* /peer_addresses
* /payout_addr
* /recent_blocks
* /uptime
* /web/log - Some different stats collected over the last day

=== Included README ===
<pre>Requirements:
Generic:
Bitcoin >=0.6.0rc4 or Bitcoin >=0.5.4 (for BIP16 support) or Litecoin
Python
Twisted
python-argparse (for Python <=2.6)

Linux:
sudo apt-get install python-zope.interface python-twisted python-twisted-web
sudo apt-get install python-argparse # if on Python 2.6 or older

Windows:
Install Python 2.7: http://www.python.org/getit/
Install Twisted: http://twistedmatrix.com/trac/wiki/Downloads
Install Zope.Interface: http://pypi.python.org/pypi/zope.interface/3.8.0
Unzip the files into C:\Python27\Lib\site-packages

Running P2Pool:
To use P2Pool, you must be running your own local bitcoind. For standard
configurations, using P2Pool should be as simple as:

python run_p2pool.py

Then run your miner program, connecting to 127.0.0.1 on port 9332 with any
username and password.

If you are behind a NAT, you should enable TCP port forwarding on your
router. Forward port 9333 to the host running P2Pool.

Run "python run_p2pool.py --help" for additional options.

Notes for Litecoin:
Requirements:
In order to run P2Pool with the Litecoin network, you would need to build and install the
ltc_scrypt module that includes the scrypt proof of work code that Litecoin uses for hashes.

Linux:
cd litecoin_scrypt
sudo python setup.py install

Windows:
Install MinGW: http://www.mingw.org/wiki/Getting_Started
Install Python 2.7: http://www.python.org/getit/

cd litecoin_scrypt
C:\Python27\python.exe setup.py build --compile=mingw32 install

If you run into an error with unrecognized command line option '-mno-cygwin', see this:
http://stackoverflow.com/questions/6034390/compiling-with-cython-and-mingw-produces-gcc-error-unrecognized-command-line-o

Running P2Pool:
Run P2Pool with the "--net litecoin" option.
Run your miner program, connecting to 127.0.0.1 on port 9327.
Forward port 9338 to the host running P2Pool.

Litecoin's use of ports 9332 and 9332 conflicts with P2Pool running on
the Bitcoin network. To avoid problems, add these lines to litecoin.conf
and restart litecoind:
rpcport=10332
port=10333
</pre>

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin,litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--give-author DONATION_PERCENTAGE] [--iocp]
[--irc-announce] [--no-bugreport] [--p2pool-port PORT]
[-n ADDR[:PORT]] [--disable-upnp] [--max-conns CONNS]
[-w PORT or ADDR:PORT] [-f FEE_PERCENTAGE]
[--bitcoind-address BITCOIND_ADDRESS]
[--bitcoind-rpc-port BITCOIND_RPC_PORT]
[--bitcoind-p2p-port BITCOIND_P2P_PORT]
[BITCOIND_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version 0.11.1-8-ged9359d)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin,litecoin}
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>)
--datadir DATADIR store data in this directory (default: <directory
run_p2pool.py is in>/data)
--logfile LOGFILE log to this file (default: data/<NET>/log)
--merged MERGED_URLS call getauxblock on this url to get work for merged
mining (example:
http://ncuser:ncpass@127.0.0.1:10332/)
--give-author DONATION_PERCENTAGE
donate this percentage of work towards the development
of p2pool (default: 0.5)
--iocp use Windows IOCP API in order to avoid errors due to
large number of sockets being open
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--no-bugreport disable submitting caught exceptions to the author
--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)
-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
--max-conns CONNS maximum incoming connections (default: 40)

worker interface:
-w PORT or ADDR:PORT, --worker-port PORT or ADDR:PORT
listen on PORT on interface with ADDR for RPC
connections from miners (default: all interfaces,
bitcoin:9332, litecoin:9327)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The pool began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:

For example, a bash script to donate 10 btc is:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany/10)"
</pre>

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.

Note that the amount you donate will be allocated to recent miners in proportion to the amount of work they've done in the last 24 hours or so, but all the miner whose shares of the donated amount are less than 0.01 BTC will have their shares combined into a single amount which is awarded to one of them at random, with the chance of winning this 'lottery' weighted by the miner's recent amount of work done. You can change this 0.01 BTC threshold like this, for example, which says to pay 10 BTC, but to share it amongst more miners that the default, cutting off at 0.001 BTC instead of at 0.01 BTC.
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany/10/0.001)"
</pre>

If you decide to donate you should announce it on the forums so that your donations provide the most incentive possible.

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]
* [[P2Pool code documentation]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support
* [http://p2pool.info/ p2pool.info] stats page
* [http://p2pool.hostv.pl p2pool.hostv.pl] Public list of P2Pool BTC/LTC nodes.

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2012-09-20T17:53:21Z

Forrestv: removed upgrade notice

Download P2Pool from the forum thread: [https://bitcointalk.org/index.php?topic=18313.0 P2Pool]

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

<blockquote>P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 10 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target. Whenever a peer announces a new share found (new block in the P2Pool block chain), it is received by the other peers, and the other peers verify that this block contains payouts for all the previous miners who found a share (and announced it) that made it into the P2Pool share chain. This continues until some peer finds a block that has a difficulty that meets the Bitcoin network's difficulty target. This peer announces this block to the Bitcoin network and miners who have submitted shares for this block are paid in the generation transaction, proportionally to how many shares they have found in the last while. - Unknown author</blockquote>

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin and avoids the risk of hard to detect theft by pool operators.

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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization, some Bitcoin supporters donate to P2Pool miners, resulting in average returns above 100% of the expected reward.
However, it should be noted that there are other pools (such as [[BitPenny]] and [[Eligius]]) which can provide this same level of decentralization.

== 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, just as Bitcoin regulates it to generate one block every ten minutes.
This means that finding shares becomes more difficult (resulting in higher variance) the more people mine on P2Pool, though large miners have the option to raise their difficulty, and so reduce the impact of their mining on P2Pool's minimum difficulty.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640 (= 24 hours of shares), whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is 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 ===

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: edit bitcoin.conf to include:
rpcuser=USER
rpcpassword=LONG_RANDOM_SECRET_VALUE
server=1
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** 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
** Source: python run_p2pool.py
* Run a miner daemon with long polling connecting to 127.0.0.1 (or the IP of the host running p2pool if it isn't on the same computer as the miner) on port 9332 with any username and password
** bfgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher (but not 3.x)
* python-argparse
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does my miner report so many longpoll events when mining on p2pool? - P4Man" 
'''A:''' "Once every ~10 seconds is normal. That is how often p2pool shares are generated (as opposed to ~10 min for bitcoin blocks) - cabin"

'''Q:''' "Do the 'orphan' and 'dead' shares in P2Pool's status display hurt me?" 
'''A:''' They shouldn't - It's normal for some fraction of everyone's shares to end up orphaned or dead. Because payouts are calculated by counting how many shares you have relative to others, everyone with normal configurations is equally "hurt" by this. However, if you have a large proportion of stales, your payout will be hurt. You can see how well you're doing by looking at P2Pool's "Efficiency" (ex: ''Efficiency: ~110.6% (40-111%)''). If 100% doesn't lie within the [http://en.wikipedia.org/wiki/Confidence_interval confidence interval] at the end, something is probably wrong (with 95% confidence).

'''Q:''' "What do I do if my efficiency is low?" 
'''A:''' Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. If you have a lot of dead shares or the "Local dead on arrival" number is higher than a few percent, that means that something is wrong with your miner. Check to make sure that it is one of the working versions in the ''Miners'' section on this page. Lower the intensity or raise the FPS of your miner. If you have a lot of orphan shares, something is wrong with P2Pool's P2P connection. Decrease the load on your internet connection or enable QoS (Quality of Service) on your router.

'''Q:''' What is PPLNS? 
'''A:''' Pay-Per-Last-N-Shares is a payout method that is completely resistant to pool hoppers.

'''Q:''' Why am I not getting very many shares?! 
'''A:''' The P2Pool difficulty is hundreds of times higher than on other pools. It can take time to get a share. P2Pool displays an estimate of how long you have to wait in the console output.

'''Q:''' Why does my miner say it has found a lot of shares but p2pool say I have only found a few?! 
'''A:''' The real P2Pool difficulty is hundreds of times higher than on normal pools, but p2pool essentially lies to your miner and tells it to work on relatively easy shares so that it submits shares every few seconds instead of every few hours. P2Pool then ignores any submitted shares that don't match the real share difficulty. By doing this, P2Pool can more accurately report your local hash rate and you can see if you are having problems with too many stale shares quickly

'''Q:''' Why am I getting so many rejects? 
'''A:''' You're using an incompatible miner. See the miners section here, increase your FPS on the miner, decrease the intensity, upgrade your miner, or try a different miner.

'''Q:''' What stops the pool operator or the block finder from stealing a block? 
'''A:''' A block solution is only worth anything because its hash matches Bitcoin's target. Altering anything within the block will change its hash and make it worthless. If you are concerned about the pool operator stealing a block, you should try to inspect the source code of each new version.

'''Q:''' Why does it say "Generated?" I want to spend my coins now! 
'''A:''' P2Pool includes payouts in generation transactions, which must mature (taking 120 blocks or 20 hours) before they can be spent. The reason for this is that a block could be orphaned, which would make its payout invalid and could reverse transactions.

'''Q:''' Do I get paid transaction fees? 
'''A:''' Yes. They are split among P2Pool miners.

'''Q:''' What are these payments I'm getting that aren't generated? 
'''A:''' These are subsidies that people who support the idea of P2Pool send to miners.

'''Q:''' Cool Subsidies sound like an awesome idea! How do I send some BTC to these awesome miners? 
'''A:''' See end of this page.

'''Q:''' Do I really need the WHOLE blockchain? 
'''A:''' Yes. Your node needs to be able to independently make decisions about what transactions to mine.

'''Q:''' How do merged mining payments work? 
'''A:''' Merged mining is handled entirely by namecoind, so you're solo mining and payouts will go into namecoind's wallet.

=== 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 intensity (8 for bfgminer?) helps a lot with reducing stales.

* bfgminer, cgminer, and ufasoft work perfectly without any extra options.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

====Tips to configure bfgminer to reduce stale/doa:====
* "gpu-threads" : "1", (2 by default)
* "queue" : "0", (1 by default)

Because of fast longpooling in p2pool it is better not NOT fetch work ahead.

On non-dedicated machines intensity=3 allows normal usage of PC, set it to 7 or more to get full hashrate.

On most cards best is diablo and phatk kernel, looks like poclbm kernel have unstable rate.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seamless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.
* You can make P2Pool use a configuration file by running run_p2pool.py @FILENAME, with FILENAME being the path to a file containing the command-line arguments (newlines are ignored) Example:
<pre>
--net litecoin
-n 1.2.3.4
</pre>
* Setting the username of your miner connecting to P2Pool to a Bitcoin address will make it mine to that address instead of the one requested from bitcoind or set by -a
* Appending "/1000" to a miner's username will increase the difficulty of producing a P2Pool share to at most 1000. This is useful to large miners because doing this can make it easier for small miners while minimally impacting the large miners themselves. See [https://bitcointalk.org/index.php?topic=18313.msg816322#msg816322 recommended values].
** Appending "+1" (for example) after that will make P2Pool always give your miners work with a difficulty of 1

=== Web interface ===

Lots of data and useful tools are available at http://127.0.0.1:9332/something:
* /static/ - Lots of information from shares to graphs to payouts.
* /rate
* /users
* /fee
* /current_payouts
* /patron_sendmany - Gives sendmany outputs for fair donations to P2Pool
* /global_stats
* /local_stats
* /peer_addresses
* /payout_addr
* /recent_blocks
* /uptime
* /web/log - Some different stats collected over the last day

=== Included README ===
<pre>Requirements:
Generic:
Bitcoin >=0.6.0rc4 or Bitcoin >=0.5.4 (for BIP16 support) or Litecoin
Python
Twisted
python-argparse (for Python <=2.6)

Linux:
sudo apt-get install python-zope.interface python-twisted python-twisted-web
sudo apt-get install python-argparse # if on Python 2.6 or older

Windows:
Install Python 2.7: http://www.python.org/getit/
Install Twisted: http://twistedmatrix.com/trac/wiki/Downloads
Install Zope.Interface: http://pypi.python.org/pypi/zope.interface/3.8.0
Unzip the files into C:\Python27\Lib\site-packages

Running P2Pool:
To use P2Pool, you must be running your own local bitcoind. For standard
configurations, using P2Pool should be as simple as:

python run_p2pool.py

Then run your miner program, connecting to 127.0.0.1 on port 9332 with any
username and password.

If you are behind a NAT, you should enable TCP port forwarding on your
router. Forward port 9333 to the host running P2Pool.

Run "python run_p2pool.py --help" for additional options.

Notes for Litecoin:
Requirements:
In order to run P2Pool with the Litecoin network, you would need to build and install the
ltc_scrypt module that includes the scrypt proof of work code that Litecoin uses for hashes.

Linux:
cd litecoin_scrypt
sudo python setup.py install

Windows:
Install MinGW: http://www.mingw.org/wiki/Getting_Started
Install Python 2.7: http://www.python.org/getit/

cd litecoin_scrypt
C:\Python27\python.exe setup.py build --compile=mingw32 install

If you run into an error with unrecognized command line option '-mno-cygwin', see this:
http://stackoverflow.com/questions/6034390/compiling-with-cython-and-mingw-produces-gcc-error-unrecognized-command-line-o

Running P2Pool:
Run P2Pool with the "--net litecoin" option.
Run your miner program, connecting to 127.0.0.1 on port 9327.
Forward port 9338 to the host running P2Pool.

Litecoin's use of ports 9332 and 9332 conflicts with P2Pool running on
the Bitcoin network. To avoid problems, add these lines to litecoin.conf
and restart litecoind:
rpcport=10332
port=10333
</pre>

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin,litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--give-author DONATION_PERCENTAGE] [--iocp]
[--irc-announce] [--no-bugreport] [--p2pool-port PORT]
[-n ADDR[:PORT]] [--disable-upnp] [--max-conns CONNS]
[-w PORT or ADDR:PORT] [-f FEE_PERCENTAGE]
[--bitcoind-address BITCOIND_ADDRESS]
[--bitcoind-rpc-port BITCOIND_RPC_PORT]
[--bitcoind-p2p-port BITCOIND_P2P_PORT]
[BITCOIND_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version 0.11.1-8-ged9359d)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin,litecoin}
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>)
--datadir DATADIR store data in this directory (default: <directory
run_p2pool.py is in>/data)
--logfile LOGFILE log to this file (default: data/<NET>/log)
--merged MERGED_URLS call getauxblock on this url to get work for merged
mining (example:
http://ncuser:ncpass@127.0.0.1:10332/)
--give-author DONATION_PERCENTAGE
donate this percentage of work towards the development
of p2pool (default: 0.5)
--iocp use Windows IOCP API in order to avoid errors due to
large number of sockets being open
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--no-bugreport disable submitting caught exceptions to the author
--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)
-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
--max-conns CONNS maximum incoming connections (default: 40)

worker interface:
-w PORT or ADDR:PORT, --worker-port PORT or ADDR:PORT
listen on PORT on interface with ADDR for RPC
connections from miners (default: all interfaces,
bitcoin:9332, litecoin:9327)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The pool began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:

For example, a bash script to donate 10 btc is:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany/10)"
</pre>

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.

Note that the amount you donate will be allocated to recent miners in proportion to the amount of work they've done in the last 24 hours or so, but all the miner whose shares of the donated amount are less than 0.01 BTC will have their shares combined into a single amount which is awarded to one of them at random, with the chance of winning this 'lottery' weighted by the miner's recent amount of work done. You can change this 0.01 BTC threshold like this, for example, which says to pay 10 BTC, but to share it amongst more miners that the default, cutting off at 0.001 BTC instead of at 0.01 BTC.
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany/10/0.001)"
</pre>

If you decide to donate you should announce it on the forums so that your donations provide the most incentive possible.

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]
* [[P2Pool code documentation]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support
* [http://p2pool.info/ p2pool.info] stats page
* [http://nodes.p2pmine.com nodes.p2pmine.com] Public list of P2Pool BTC/LTC nodes.

==References==
<references />

[[Category:Pool Operators]]

BIP 0022

2012-08-08T02:19:38Z

Forrestv: clarified handling of BIP 0034 block height

{{bip}}

<pre>
BIP: 22
Title: getblocktemplate - Fundamentals
Author: Luke Dashjr <luke+bip22@dashjr.org>
Status: Draft
Type: Standards Track
Created: 28-02-2012
</pre>

==Abstract==

This BIP describes a new JSON-RPC method for "smart" Bitcoin miners and proxies.
Instead of sending a simple block header for hashing, the entire block structure is sent, and left to the miner to (optionally) customize and assemble.

==Specification==

===JSON-RPC Method: getblocktemplate===

A JSON-RPC method is defined, called "getblocktemplate".
It accepts exactly one argument, which MUST be an Object of request parameters.
If the request parameters include a "mode" key, that is used to explicitly select between [[#Block Template Request|"template"]], [[BIP 0023#Block Proposal|"proposal"]], and [[#Block Submission|"submit"]] calls.
Otherwise, it defaults to [[#Block Submission|a submission]] if there is a "data" key (including the String-type argument mentioned above), and [[#Block Template Request|a template request]] if not.

===Block Template Request===
Block template creation can be influenced by various parameters:
{| class="wikitable"
!colspan=3|template request
|-
! Key !! Type !! Description
|-
| capabilities || Array of Strings || SHOULD contain a list of the following, to indicate client-side support: [[#Optional: Long Polling|"longpoll"]], "coinbasetxn", "coinbasevalue", [[BIP 0023#Block Proposal|"proposal"]], [[BIP 0023#Logical Services|"serverlist"]], "workid", and any of the [[BIP 0023#Mutations|mutations]]
|-
| mode || String || MUST be "template" or omitted
|}

getblocktemplate MUST return a JSON Object containing the following keys:
{| class="wikitable"
!colspan=3| template
|-
! Key !! Type !! Description
|-
| bits || String || the compressed difficulty in hexadecimal
|-
| curtime || Number || the current time as seen by the server (recommended for block time) - note this is not necessarily the system clock, and must fall within the mintime/maxtime rules
|-
| height || Number || the height of the block we are looking for
|-
| previousblockhash || String || the hash of the previous block, in big-endian hexadecimal
|-
| sigoplimit || Number || number of sigops allowed in blocks
|-
| sizelimit || Number || number of bytes allowed in blocks
|-
| transactions || Array of Objects || Objects containing [[#Transactions Object Format|information for Bitcoin transactions]] (excluding coinbase)
|-
| version || Number || always 1 or 2 (at least for bitcoin) - if 2, clients MUST comply with [[BIP 0034]]
|-
| coinbaseaux || Object || data that SHOULD be included in the coinbase's scriptSig content. Only the values (hexadecimal byte-for-byte) in this Object should be included, not the keys. This does not include the block height, which is required to be included in the scriptSig by [[BIP 0034]].
|-
| coinbasetxn || String or Object || coinbase transaction, format specified by "tx:cb" parameter
|-
| coinbasevalue || Number || total funds available for the coinbase (in Satoshis)
|-
| workid || String || if provided, this value must be returned with results (see [[#Block Submission|Block Submission]])
|}

==== Transactions Object Format ====

The Objects listed in the response's "transactions" key contains these keys:

{| class="wikitable"
!colspan=3|template "transactions" element
|-
! Key !! Type !! Description
|-
| data || String || transaction data encoded in hexadecimal (byte-for-byte)
|-
| depends || Array of Numbers || other transactions (by 1-based index in "transactions" list) that must be present in the final block if this one is; if key is not present, dependencies are unknown and clients MUST NOT assume there aren't any
|-
| fee || Number || difference in value between transaction inputs and outputs (in Satoshis); for coinbase transactions, this is a negative Number of the total collected block fees (ie, not including the block subsidy); if key is not present, fee is unknown and clients MUST NOT assume there isn't one
|-
| hash || String || hash/id encoded in little-endian hexadecimal
|-
| required || Boolean || if provided and true, this transaction must be in the final block
|-
| sigops || Number || total number of SigOps, as counted for purposes of block limits; if key is not present, sigop count is unknown and clients MUST NOT assume there aren't any
|}

Only the "data" key is required, but servers should provide the others if they are known.

===Block Submission===

When getblocktemplate is called with a "data" key, and "mode" either set to "submit" or omitted, it is interpreted as a potential block (or share).

{| class="wikitable"
!colspan=3|getblocktemplate parameters
|-
! Key !! Type !! Description
|-
| data || String || MUST be hex-encoded block data
|-
| mode || String || MUST be "submit" or omitted
|-
| workid || String || if the server provided a workid, it MUST be included with submissions
|}

This method MUST return either null (when a share is accepted), a String describing briefly the reason the share was rejected, or an Object of these with a key for each merged-mining chain the share was submitted to.

===Optional: Long Polling===

{| class="wikitable"
! colspan="3" | template request
|-
! Key !! Type !! Description
|-
| capabilities || Array of Strings || miners which support long polling SHOULD provide a list including the String "longpoll"
|-
| longpollid || String || "longpollid" of job to monitor for expiration; required and valid only for long poll requests
|}

{| class="wikitable"
! colspan="3" | template
|-
! Key !! Type !! Description
|-
| longpollid || String || unique identifier for long poll request; MUST be omitted if the server does not support long polling
|-
| longpolluri || String || if provided, an alternate URI to use for long poll requests
|-
| submitold || Boolean || only relevant for long poll responses: indicates if work received prior to this response remains potentially valid (default) and should have its shares submitted; if false, the miner may wish to discard its share queue
|}

If the server supports long polling, it MUST include a "longpollid" key in block templates.
It MAY supply the "longpolluri" key with a relative or absolute URI, which MAY specify a completely different resource than the original connection, including port number.
If "longpolluri" is provided by the server, clients MUST only attempt to use that URI for longpoll requests.

Clients MAY start a longpoll request with a standard JSON-RPC request (in the case of HTTP transport, POST with data) and same authorization, setting the "longpollid" parameter in the request to the value provided by the server.

This request SHOULD NOT be processed nor answered by the server until it wishes to replace the current block data as identified by the "longpollid".
Clients SHOULD make this request with a very long request timeout and MUST accept servers sending a partial response in advance (such as HTTP headers with "chunked" Transfer-Encoding), and only delaying the completion of the final JSON response until processing.

Upon receiving a completed response:
* Only if "submitold" is provided and false, the client MAY discard the results of past operations and MUST begin working on the new work immediately.
* The client SHOULD begin working on the new work received as soon as possible, if not immediately.
* The client SHOULD make a new request to the same long polling URI.

If a client receives an incomplete or invalid response, it SHOULD retry the request with an exponential backoff.
Clients MAY implement this backoff with limitations (such as maximum backoff time) or any algorithm as deemed suitable.
It is, however, forbidden to simply retry immediately with no delay after more than one failure.
In the case of a "Forbidden" response (for example, HTTP 403), a client SHOULD NOT attempt to retry without user intervention.

===Optional: Template Tweaking===

{| class="wikitable"
! colspan="3" | template request
|-
! Key !! Type !! Description
|-
| sigoplimit || Number or Boolean || maximum number of sigops to include in template
|-
| sizelimit || Number or Boolean || maximum number of bytes to use for the entire block
|}

For "sigoplimit" and "sizelimit", negative values and zero are offset from the server-determined block maximum.
If a Boolean is provided and true, the default limit is used; if false, the server is instructed not to use any limits on returned template.
Servers SHOULD respect these desired maximums, but are NOT required to:
clients SHOULD check that the returned template satisfies their requirements appropriately.

===Appendix: Example Rejection Reasons===
Possible reasons a share may be rejected include, but are not limited to:
{| class="wikitable"
!colspan=2| share rejection reasons
|-
! Reason !! Description
|-
| bad-cb-flag || the server detected a feature-signifying flag that it does not allow
|-
| bad-cb-length || the coinbase was too long (bitcoin limit is 100 bytes)
|-
| bad-cb-prefix || the server only allows appending to the coinbase, but it was modified beyond that
|-
| bad-diffbits || "bits" were changed
|-
| bad-prevblk || the previous-block is not the one the server intends to build on
|-
| bad-txnmrklroot || the block header's merkle root did not match the transaction merkle tree
|-
| bad-txns || the server didn't like something about the transactions in the block
|-
| bad-version || the version was wrong
|-
| duplicate || the server already processed this block data
|-
| high-hash || the block header did not hash to a value lower than the specified target
|-
| rejected || a generic rejection without details
|-
| stale-prevblk || the previous-block is no longer the one the server intends to build on
|-
| stale-work || the work this block was based on is no longer accepted
|-
| time-invalid || the time was not acceptable
|-
| time-too-new || the time was too far in the future
|-
| time-too-old || the time was too far in the past
|-
| unknown-user || the user submitting the block was not recognized
|-
| unknown-work || the template or workid could not be identified
|}

==Motivation==

bitcoind's JSON-RPC server can no longer support the load of generating the work required to productively mine Bitcoin, and external software specializing in work generation has become necessary.
At the same time, new independent node implementations are maturing to the point where they will also be able to support miners.

A common standard for communicating block construction details is necessary to ensure compatibility between the full nodes and work generation software.

==Rationale==
Why not just deal with transactions as hashes (txids)?
* Servers might not have access to the transaction database, or miners may wish to include transactions not broadcast to the network as a whole.
* Miners may opt not to do full transaction verification, and may not have access to the transaction database on their end.

What is the purpose of "workid"?
* If servers allow all mutations, it may be hard to identify which job it is based on. While it may be possible to verify the submission by its content, it is much easier to compare it to the job issued. It is very easy for the miner to keep track of this. Therefore, using a "workid" is a very cheap solution to enable more mutations.

Why should "sigops" be provided for transactions?
* Due to the [[BIP 0016]] changes regarding rules on block sigops, it is impossible to count sigops from the transactions themselves (the sigops in the scriptCheck must also be included in the count).

==Reference Implementation==

* [https://gitorious.org/bitcoin/eloipool Eloipool]
* [https://github.com/bitcoin/bitcoin/pull/936/files bitcoind]

==See Also==
* [[BIP 0023|BIP 23: getblocktemplate - Pooled Mining]]

[[Category:BIP|D]]

P2Pool code documentation

2012-06-24T21:45:25Z

Forrestv:

'''Ignore this page for the minute.''' Is just a scratch pad for documenting the p2pool code.
Feel free to add or correct errors if you are familiar with code.

Will tidy up once initial pass done.
==Files==
{| border=1
|+ '''Files'''
|-
!Files Name
!Description
|-
|p2pool/main.py
|Main startup and initialisation code
|-
|p2pool/data.py
|P2Pool data structures
|-
|p2pool/networks.py
|Definitions of P2Pool networks (eg. Bitcoin, Bitcoin-testnet, Litecoin, ...)
|-
|p2pool/p2p.py
|P2Pool P2P protocol implementation
|-
|p2pool/web.py
|P2Pool web interface
|-
|p2pool/bitcoin/
|Code related to Bitcoin and its clones. Contains nothing specific to P2Pool
|-
|p2pool/util/pack.py
|Handling of over the wire data structures
|-
|p2pool/util/variable.py
|Code to allow monitoring of when variables change and triggering events
|-
|[[p2pool_util_forest|p2pool/util/forest.py]]
|Contains Tracker class and other classes to track shares and which share is head/tail.
|}

==p2pool/main.py==
Makes extensive use of twisted.defer. This allows it to "yield" to allow long running network code to complete.
Read up on Python Generators and this before progressing!

Contains main startup code.

===Function run()===
This is the initially executed function.
# Parses arguments
# Reads user/password from bitcoin config file
# Sets up log file
# Sets up logger that reports errors to http://u.forre.st/p2pool_error.cgi (If you are concerned this is a privacy issue add --no-bugreport to command line.)
Finally it adds the main function to the Twister Reactor and start the reactor. (i.e. runs the function main!).

===Function main()===
This does all the startup tasks.
# Tests connection to bitcoind.
# Prints hash of latest block to show bitcoind is up to date.
# Tests connection to p2pool network.
# Gets address to use for payout either from file or bitcoind.
# Validates address and checks local bitcoind owns it.
# Create a "tracker" and loads know shares from files in data/bitcoin/sharesX where X is a number.
# poll_bitcoind then gets work from bitcoind (i.e. block header to hash). Does this by calling getwork function explained below.
# The work_poller() function then polls bitcoind every 15 seconds for new work.
# Check for work from peers. This is new code to try to reduce stales. It gets new block headers from peers if they arrive before they arrive from bitcoind.
# Set up merged work for merged mining.
# Sets up combined work.
# Sets up Longpoll to trigger when current_work changes (transitions).
# Creates Node class that handles connections to other p2pool nodes (see p2p.py also).
# Read p2pool node address from addrs file else use bootstrap addresses.
# Create node object and start it connecting/sending/receiving data.
# Setup loop to save shares to disk every 60 seconds.
# Create tunnel through routers using upnp if enabled.
# Start listening for workers using WorkerBridge Class (e.g. cgminers).
# Create web_root and start web server. This is the monitoring web pages. (see web.py)
# Start IRC connection for announcing blocks.
# Start Status process that output to screen data every 3 seconds.

====Function main/submit_block====
This is a critical function that watches for tracker.verified shares being added. If they meet the difficulty requirements it then submits the block to bitcoind using BOTH the p2p connection and the JSONRPC connection.

The _ function that calls it also send the share that contains the block solution out over the p2pool network to propagate the solution asap and so reduce orphans.

====Class main/WorkerBridge ====
This is the main communication between p2pool process and the workers (mining processes running cgminer or similar).
=====get_user_details=====
This allows clients to connect. Also parses out if this client wants a higher than normal pseudoshare difficulty.
=====get_work=====
This is the main method.
Creates a new share to solve from current data.
Create a "BlockAttempt" which is a bitcoin header for the miner to find a nonce for.
returns the BlockAttempt and a got_response function.

got_response is called when miner finds a solution. It checks that the solution is valid. If below block target we found a block. If below share target we found a share.

'''More debugging in here would be useful to find the "10%" issue'''

===Function getWork()===
This connects to the bitcoind process using the jsonrpc proxy. It calls the getmemorypool function (see [[API_reference_(JSON-RPC)|Bitcoin json-rpc API document]] and [[Original_Bitcoin_client/API_Calls_list|getmemorypool document]]) This returns all the data needed to create a new block (except the nounce obviously!).

getwork then unpacks this into a dictionary containing the header info, the transactions
, the merkel branch/root and the coinbase flags. This is everything that a miner needs to calculate a valid nonce/block.

===Class Node===
This also covers code in p2pool/p2p.py.
It is dependant on p2pool/util/p2protocol.py which is the Twisted.protocol class that handles low level network communication and passes on messages to the handle_xxx methods of the Client and Server factories and Node class.
This class is the main class that handles all the p2pool connections and message handling. It is the core of the p2p network for p2pool.

Is initialised with best_share_hash variable so it can update/monitor it, port, store of peer addresses.

Initially it starts up the client factory that connects to other nodes and a server factory that allows incoming connections.

Then it checks it has enough node addresses, if not asks random peers to send it 8 more addresses.

====Method Node.handle_shares====
Passes new shares onto tracker.
Update peer_heads
Calls compute_work if a new share.

==p2pool/data.py==
Contains the main data structures used in p2pool.
These are:
===hash_link_type===
Serialized SHA256 engine state, used to prove that a coinbase transaction contains some data near the end without sending the entire transaction.
{| border=1
|+ '''hash_link_type'''
|-
!Field
!Type
!Description
|-
|state
|String(32)
|?
|-
|extra_data
|String(0)
|Comments say this is a hack
|-
|length
|VarInt
|?
|}
===small_block_header===
Bitcoin block header, excluding the merkle root. Included in shares, where the merkle root is computed implicitly from the coinbase transaction and the merkle branch.
{| border=1
|+ '''small_block_header'''
|-
!Field
!Type
!Description
|-
|version
|VarInt
|?
|-
|previous_block
|None or Int(256)
|?
|-
|timestamp
|Int(32)
|?
|-
|bits
|FloatingInteger(32)
|?
|-
|nonce
|Int(32)
|?
|}

===share_data_type===
Information contained within a share that is only relevant to P2Pool and that the client has control over (i.e. its value isn't fixed by the protocol rules).
{| border=1
|+ '''share_data_type'''
|-
!Field
!Type
!Description
|-
|previous_share_hash
|None or int(256)
|?
|-
|coinbase
|VarString
|coinbase script
|-
|nonce
|Int(32)
|internal P2Pool nonce
|-
|pubkey_hash
|Int(160)
|pubkey hash of Bitcoin address that this share's payouts will go to
|-
|subsidy
|Int(64)
|total block value
|-
|donation
|Int(16)
|donation to authors. 0 = 0%, 65535 = 100%
|-
|stale_info
|String(32)
|Flag that tells whether the node that generated this share's last share was orphaned or dead. Used to compute pool statistics. Enum (orphan, dao, unk253, unk252...???
|-
|desired_version
|VarInt
|Vote for P2Pool version. Used to trigger upgrade warnings on other nodes
|}

===share_info_type===
Information contained within a share that is only relevant to P2Pool
{| border=1
|+ '''share_info_type'''
|-
!Field
!Type
!Description
|-
|share_data
|share_data_type (see above)
|?
|-
|far_share_hash
|none or int(256)
|Hash of 100th parent of this share. Not currently used for anything, but has applications in timestamping and more secure sharechain bootstrapping
|-
|max_bits
|Float Int
|Maximum share target allowed
|-
|bits
|Float Int
|Share target this share was mined at
|-
|timestamp
|Int(32)
|?
|}

===share_common_type===
Data common to both of the following two types of shares.
{| border=1
|+ '''share_common_type'''
|-
!Field
!Type
!Description
|-
|min_header
|small_block_header_type
|Block header of mined share
|-
|share_info
|share_info_type
|see above
|-
|ref_merkle_link
|ComposedType(branch:List(Int), index:VarInt)
|Merkle branch from hash(ref_type) to ref hash. Currently always empty in generated shares, but could be used by new merged mining implementations
|-
|hash_link
|hash_link_type
|Lets you compute the generation transaction hash as a function of this and the ref hash
|}

===share1a_type===
This is a share that isn't a block solution.
{| border=1
|+ '''share1a_type'''
|-
!Field
!Type
!Description
|-
|common
|share_common_type
|?
|-
|merkle_link
|ComposedType(branch:List(Int), index:VarInt)
|Merkle branch from generation transaction hash to block header's merkle root
|}

===share1b_type===
This is a share that is a block solution.
{| border=1
|+ '''share1b_type'''
|-
!Field
!Type
!Description
|-
|common
|share_common_type
|?
|-
|other_txs
|List(bitcoin_data.tx_type)
|List of transactions included in the block besides the generation transaction
|}
===ref_type===
Internal data structure, hashed to determine the "reference hash" at the end of generation transaction.
{| border=1
|+ '''ref_type'''
|-
!Field
!Type
!Description
|-
|identifier
|str(4)
|Value different for every P2Pool instance (Bitcoin, Bitcoin-testnet, Litecoin...)
|-
|share_info
|share_info_type
|see above
|}
===Class share===
Class used to store shares.
====Method generate_transaction====
Returns the share_info and the generation transations. These are all the transactions that pay the other p2pool users the generated coins and fees.
It include 2 special transactions
# The donation sent to the developers.
# A transaction that is not valid, but just has a value of zero and the hash of the share info. This is to prove that when a share is found it was whilst looking for a real p2pool block. This is computed from the ref_type data structure.

==p2pool/util/pack.py==
I think this handles all the binary data types used in the bitcoin protocol to send data over the network wire.
These are nasty as very low level and many big endian/little endian complications.
The p2pool network protocol uses these also.
Do not think you need to really understand this unless making changes at this low level.

==p2pool/__init__.py==
At bottom has DEBUG flag. Change to true to get more output. (running p2pool with --debug does this)
Other than that just returns version number from git if it can.

P2pool util forest

2012-06-24T21:37:08Z

Forrestv: described deltas

This contains code for tracking shares.
==Class Tracker==
Number of dictionaries that store the shares in various ways to allow fast access.
# shares (hash->share) Since share contains parent share allows you to link to previous shares all the way to the tail.
# reverse_shares (delta.tail->set of share_hashes) Allows you to link share to the next share that came after it all the way to the head.
# deltas (share_hash -> delta, ref)
# reverse_deltas (ref -> set of share_hashes)
# delta_refs (ref -> delta)
# reverse_delta_refs ( delta.tail -> ref)

Deltas are used for quickly answering queries by caching data between two points in the sharechain. Each share has a delta that goes between it and its highest parent and contains information such as how much work was done and how many shares are in between. If the highest parent has its parent added, the delta will keep referring to the old highest parent until it is next needed, and then it will be updated.
===Method add===
Adds a share to the tracker

P2Pool code documentation

2012-06-24T05:07:42Z

Forrestv: added file descriptions

'''Ignore this page for the minute.''' Is just a scratch pad for documenting the p2pool code.
Feel free to add or correct errors if you are familiar with code.

Will tidy up once initial pass done.

{| border=1
|+ '''Files'''
|-
!Files Name
!Description
|-
|p2pool/main.py
|Main startup and initialisation code
|-
|p2pool/data.py
|P2Pool data structures
|-
|p2pool/networks.py
|Definitions of P2Pool networks (eg. Bitcoin, Bitcoin-testnet, Litecoin, ...)
|-
|p2pool/p2p.py
|P2Pool P2P protocol implementation
|-
|p2pool/web.py
|P2Pool web interface
|-
|p2pool/bitcoin/
|Code related to Bitcoin and its clones. Contains nothing specific to P2Pool
|-
|p2pool/util/pack.py
|Handling of over the wire data structures
|-
|p2pool/util/variable.py
|Code to allow monitoring of when variables change and triggering events
|-
|p2pool/util/...
|<needs expansion>
|}

==p2pool/main.py==
Makes extensive use of twisted.defer. This allows it to "yield" to allow long running network code to complete.
Read up on Python Generators and this before progressing!

Contains main startup code.

===Function run()===
This is the initially executed function.
# Parses arguments
# Reads user/password from bitcoin config file
# Sets up log file
# Sets up logger that reports errors to http://u.forre.st/p2pool_error.cgi (If you are concerned this is a privacy issue add --no-bugreport to command line.)
Finally it adds the main function to the Twister Reactor and start the reactor. (i.e. runs the function main!).

===Function main()===
This does all the startup tasks.
# Tests connection to bitcoind.
# Prints hash of latest block to show bitcoind is up to date.
# Tests connection to p2pool network.
# Gets address to use for payout either from file or bitcoind.
# Validates address and checks local bitcoind owns it.
# Create a "tracker" and loads know shares from files in data/bitcoin/sharesX where X is a number.
# poll_bitcoind then gets work from bitcoind (i.e. block header to hash). Does this by calling getwork function explained below.
# The work_poller() function then polls bitcoind every 15 seconds for new work.
# Check for work from peers. This is new code to try to reduce stales. It gets new block headers from peers if they arrive before they arrive from bitcoind.
# Set up merged work for merged mining.
# Sets up combined work.
# Sets up Longpoll to trigger when current_work changes (transitions).
# Creates Node class that handles connections to other p2pool nodes (see p2p.py also).
# Read p2pool node address from addrs file else use bootstrap addresses.
# Create node object and start it connecting/sending/receiving data.
# Setup loop to save shares to disk every 60 seconds.
# Create tunnel through routers using upnp if enabled.
# Start listening for workers using WorkerBridge Class (e.g. cgminers).
# Create web_root and start web server. This is the monitoring web pages. (see web.py)
# Start IRC connection for announcing blocks.
# Start Status process that output to screen data every 3 seconds.

====Function main/submit_block====
This is a critical function that watches for tracker.verified shares being added. If they meet the difficulty requirements it then submits the block to bitcoind using BOTH the p2p connection and the JSONRPC connection.

The _ function that calls it also send the share that contains the block solution out over the p2pool network to propagate the solution asap and so reduce orphans.

====Class main/WorkerBridge ====
This is the main communication between p2pool process and the workers (mining processes running cgminer or similar).
=====get_user_details=====
This allows clients to connect. Also parses out if this client wants a higher than normal pseudoshare difficulty.
=====get_work=====
This is the main method.
Creates a new share to solve from current data.
Create a "BlockAttempt" which is a bitcoin header for the miner to find a nonce for.
returns the BlockAttempt and a got_response function.

got_response is called when miner finds a solution. It checks that the solution is valid. If below block target we found a block. If below share target we found a share.

'''More debugging in here would be useful to find the "10%" issue'''

===Function getWork()===
This connects to the bitcoind process using the jsonrpc proxy. It calls the getmemorypool function (see [[API_reference_(JSON-RPC)|Bitcoin json-rpc API document]] and [[Original_Bitcoin_client/API_Calls_list|getmemorypool document]]) This returns all the data needed to create a new block (except the nounce obviously!).

getwork then unpacks this into a dictionary containing the header info, the transactions
, the merkel branch/root and the coinbase flags. This is everything that a miner needs to calculate a valid nonce/block.

===Class Node===
This also covers code in p2pool/p2p.py.
It is dependant on p2pool/util/p2protocol.py which is the Twisted.protocol class that handles low level network communication and passes on messages to the handle_xxx methods of the Client and Server factories and Node class.
This class is the main class that handles all the p2pool connections and message handling. It is the core of the p2p network for p2pool.

Is initialised with best_share_hash variable so it can update/monitor it, port, store of peer addresses.

Initially it starts up the client factory that connects to other nodes and a server factory that allows incoming connections.

Then it checks it has enough node addresses, if not asks random peers to send it 8 more addresses.

====Method Node.handle_shares====
Passes new shares onto tracker.
Update peer_heads
Calls compute_work if a new share.

==p2pool/data.py==
Contains the main data structures used in p2pool.
These are:
===hash_link_type===
Serialized SHA256 engine state, used to prove that a coinbase transaction contains some data near the end without sending the entire transaction.
{| border=1
|+ '''hash_link_type'''
|-
!Field
!Type
!Description
|-
|state
|String(32)
|?
|-
|extra_data
|String(0)
|Comments say this is a hack
|-
|length
|VarInt
|?
|}
===small_block_header===
Bitcoin block header, excluding the merkle root. Included in shares, where the merkle root is computed implicitly from the coinbase transaction and the merkle branch.
{| border=1
|+ '''small_block_header'''
|-
!Field
!Type
!Description
|-
|version
|VarInt
|?
|-
|previous_block
|None or Int(256)
|?
|-
|timestamp
|Int(32)
|?
|-
|bits
|FloatingInteger(32)
|?
|-
|nonce
|Int(32)
|?
|}

===share_data_type===
Information contained within a share that is only relevant to P2Pool and that the client has control over (i.e. its value isn't fixed by the protocol rules).
{| border=1
|+ '''share_data_type'''
|-
!Field
!Type
!Description
|-
|previous_share_hash
|None or int(256)
|?
|-
|coinbase
|VarString
|?
|-
|nonce
|Int(32)
|?
|-
|pubkey_hash
|Int(160)
|?
|-
|subsidy
|Int(64)
|?
|-
|donation
|Int(16)
|?
|-
|stale_info
|String(32)
|Enum (orpan, dao, unk253, unk252...???
|-
|desired_version
|VarInt
|?
|}

===share_info_type===
Information contained within a share that is only relevant to P2Pool
{| border=1
|+ '''share_info_type'''
|-
!Field
!Type
!Description
|-
|share_data
|share_data_type (see above)
|?
|-
|far_share_hash
|none or int(256)
|?
|-
|max_bits
|Float Int
|?
|-
|bits
|Float Int
|?
|-
|timestamp
|Int(32)
|?
|}

===share_common_type===
Data common to both of the following two types of shares.
{| border=1
|+ '''share_common_type'''
|-
!Field
!Type
!Description
|-
|min_header
|small_block_header_type
|?
|-
|share_info
|share_info_type
|?
|-
|ref_merkle_link
|ComposedType(branch:List(Int), index:VarInt)
|?
|-
|hash_link
|hash_link_type
|?
|}

===share1a_type===
This is a share that isn't a block solution.
{| border=1
|+ '''share1a_type'''
|-
!Field
!Type
!Description
|-
|common
|share_common_type
|?
|-
|merkle_link
|ComposedType(branch:List(Int), index:VarInt)
|?
|}

===share1b_type===
This is a share that is a block solution.
{| border=1
|+ '''share1b_type'''
|-
!Field
!Type
!Description
|-
|common
|share_common_type
|?
|-
|other_txs
|List(bitcoin_data.tx_type)
|?
|}
===ref_type===
Internal data structure, hashed to determine the "reference hash" at the end of generation transaction.
{| border=1
|+ '''ref_type'''
|-
!Field
!Type
!Description
|-
|identifier
|str(4)
|?
|-
|share_info
|share_info_type
|?
|}

==p2pool/util/pack.py==
I think this handles all the binary data types used in the bitcoin protocol to send data over the network wire.
These are nasty as very low level and many big endian/little endian complications.
The p2pool network protocol uses these also.
Do not think you need to really understand this unless making changes at this low level.

==p2pool/__init__.py==
At bottom has DEBUG flag. Change to true to get more output. (running p2pool with --debug does this)
Other than that just returns version number from git if it can.

P2Pool code documentation

2012-06-24T05:04:02Z

Forrestv: explained some data structures

'''Ignore this page for the minute.''' Is just a scratch pad for documenting the p2pool code.
Feel free to add or correct errors if you are familiar with code.

Will tidy up once initial pass done.

{| border=1
|+ '''Files'''
|-
!Files Name
!Description
|-
|p2pool/main.py
|Main Startup and initialisation code
|-
|p2pool/data.py
|P2Pool main data structures
|-
|p2pool/util/pack.py
|Handling of over the wire data structures
|-
|p2pool/util/variable.py
|Code to allow monitoring of when variables change and triggering events
|}

==p2pool/main.py==
Makes extensive use of twisted.defer. This allows it to "yield" to allow long running network code to complete.
Read up on Python Generators and this before progressing!

Contains main startup code.

===Function run()===
This is the initially executed function.
# Parses arguments
# Reads user/password from bitcoin config file
# Sets up log file
# Sets up logger that reports errors to http://u.forre.st/p2pool_error.cgi (If you are concerned this is a privacy issue add --no-bugreport to command line.)
Finally it adds the main function to the Twister Reactor and start the reactor. (i.e. runs the function main!).

===Function main()===
This does all the startup tasks.
# Tests connection to bitcoind.
# Prints hash of latest block to show bitcoind is up to date.
# Tests connection to p2pool network.
# Gets address to use for payout either from file or bitcoind.
# Validates address and checks local bitcoind owns it.
# Create a "tracker" and loads know shares from files in data/bitcoin/sharesX where X is a number.
# poll_bitcoind then gets work from bitcoind (i.e. block header to hash). Does this by calling getwork function explained below.
# The work_poller() function then polls bitcoind every 15 seconds for new work.
# Check for work from peers. This is new code to try to reduce stales. It gets new block headers from peers if they arrive before they arrive from bitcoind.
# Set up merged work for merged mining.
# Sets up combined work.
# Sets up Longpoll to trigger when current_work changes (transitions).
# Creates Node class that handles connections to other p2pool nodes (see p2p.py also).
# Read p2pool node address from addrs file else use bootstrap addresses.
# Create node object and start it connecting/sending/receiving data.
# Setup loop to save shares to disk every 60 seconds.
# Create tunnel through routers using upnp if enabled.
# Start listening for workers using WorkerBridge Class (e.g. cgminers).
# Create web_root and start web server. This is the monitoring web pages. (see web.py)
# Start IRC connection for announcing blocks.
# Start Status process that output to screen data every 3 seconds.

====Function main/submit_block====
This is a critical function that watches for tracker.verified shares being added. If they meet the difficulty requirements it then submits the block to bitcoind using BOTH the p2p connection and the JSONRPC connection.

The _ function that calls it also send the share that contains the block solution out over the p2pool network to propagate the solution asap and so reduce orphans.

====Class main/WorkerBridge ====
This is the main communication between p2pool process and the workers (mining processes running cgminer or similar).
=====get_user_details=====
This allows clients to connect. Also parses out if this client wants a higher than normal pseudoshare difficulty.
=====get_work=====
This is the main method.
Creates a new share to solve from current data.
Create a "BlockAttempt" which is a bitcoin header for the miner to find a nonce for.
returns the BlockAttempt and a got_response function.

got_response is called when miner finds a solution. It checks that the solution is valid. If below block target we found a block. If below share target we found a share.

'''More debugging in here would be useful to find the "10%" issue'''

===Function getWork()===
This connects to the bitcoind process using the jsonrpc proxy. It calls the getmemorypool function (see [[API_reference_(JSON-RPC)|Bitcoin json-rpc API document]] and [[Original_Bitcoin_client/API_Calls_list|getmemorypool document]]) This returns all the data needed to create a new block (except the nounce obviously!).

getwork then unpacks this into a dictionary containing the header info, the transactions
, the merkel branch/root and the coinbase flags. This is everything that a miner needs to calculate a valid nonce/block.

===Class Node===
This also covers code in p2pool/p2p.py.
It is dependant on p2pool/util/p2protocol.py which is the Twisted.protocol class that handles low level network communication and passes on messages to the handle_xxx methods of the Client and Server factories and Node class.
This class is the main class that handles all the p2pool connections and message handling. It is the core of the p2p network for p2pool.

Is initialised with best_share_hash variable so it can update/monitor it, port, store of peer addresses.

Initially it starts up the client factory that connects to other nodes and a server factory that allows incoming connections.

Then it checks it has enough node addresses, if not asks random peers to send it 8 more addresses.

====Method Node.handle_shares====
Passes new shares onto tracker.
Update peer_heads
Calls compute_work if a new share.

==p2pool/data.py==
Contains the main data structures used in p2pool.
These are:
===hash_link_type===
Serialized SHA256 engine state, used to prove that a coinbase transaction contains some data near the end without sending the entire transaction.
{| border=1
|+ '''hash_link_type'''
|-
!Field
!Type
!Description
|-
|state
|String(32)
|?
|-
|extra_data
|String(0)
|Comments say this is a hack
|-
|length
|VarInt
|?
|}
===small_block_header===
Bitcoin block header, excluding the merkle root. Included in shares, where the merkle root is computed implicitly from the coinbase transaction and the merkle branch.
{| border=1
|+ '''small_block_header'''
|-
!Field
!Type
!Description
|-
|version
|VarInt
|?
|-
|previous_block
|None or Int(256)
|?
|-
|timestamp
|Int(32)
|?
|-
|bits
|FloatingInteger(32)
|?
|-
|nonce
|Int(32)
|?
|}

===share_data_type===
Information contained within a share that is only relevant to P2Pool and that the client has control over (i.e. its value isn't fixed by the protocol rules).
{| border=1
|+ '''share_data_type'''
|-
!Field
!Type
!Description
|-
|previous_share_hash
|None or int(256)
|?
|-
|coinbase
|VarString
|?
|-
|nonce
|Int(32)
|?
|-
|pubkey_hash
|Int(160)
|?
|-
|subsidy
|Int(64)
|?
|-
|donation
|Int(16)
|?
|-
|stale_info
|String(32)
|Enum (orpan, dao, unk253, unk252...???
|-
|desired_version
|VarInt
|?
|}

===share_info_type===
Information contained within a share that is only relevant to P2Pool
{| border=1
|+ '''share_info_type'''
|-
!Field
!Type
!Description
|-
|share_data
|share_data_type (see above)
|?
|-
|far_share_hash
|none or int(256)
|?
|-
|max_bits
|Float Int
|?
|-
|bits
|Float Int
|?
|-
|timestamp
|Int(32)
|?
|}

===share_common_type===
Data common to both of the following two types of shares.
{| border=1
|+ '''share_common_type'''
|-
!Field
!Type
!Description
|-
|min_header
|small_block_header_type
|?
|-
|share_info
|share_info_type
|?
|-
|ref_merkle_link
|ComposedType(branch:List(Int), index:VarInt)
|?
|-
|hash_link
|hash_link_type
|?
|}

===share1a_type===
This is a share that isn't a block solution.
{| border=1
|+ '''share1a_type'''
|-
!Field
!Type
!Description
|-
|common
|share_common_type
|?
|-
|merkle_link
|ComposedType(branch:List(Int), index:VarInt)
|?
|}

===share1b_type===
This is a share that is a block solution.
{| border=1
|+ '''share1b_type'''
|-
!Field
!Type
!Description
|-
|common
|share_common_type
|?
|-
|other_txs
|List(bitcoin_data.tx_type)
|?
|}
===ref_type===
Internal data structure, hashed to determine the "reference hash" at the end of generation transaction.
{| border=1
|+ '''ref_type'''
|-
!Field
!Type
!Description
|-
|identifier
|str(4)
|?
|-
|share_info
|share_info_type
|?
|}

==p2pool/util/pack.py==
I think this handles all the binary data types used in the bitcoin protocol to send data over the network wire.
These are nasty as very low level and many big endian/little endian complications.
The p2pool network protocol uses these also.
Do not think you need to really understand this unless making changes at this low level.

==p2pool/__init__.py==
At bottom has DEBUG flag. Change to true to get more output. (running p2pool with --debug does this)
Other than that just returns version number from git if it can.

P2Pool code documentation

2012-06-19T05:33:48Z

Forrestv: added some comments

'''Ignore this page for the minute.''' Is just a scratch pad for documenting the p2pool code.
Will tidy up once initial pass done.

{| border=1
|+ '''Files'''
|-
!Files Name
!Description
|-
|p2pool/main.py
|Main Startup and initialisation code
|-
|p2pool/data.py
|P2Pool main data structures
|-
|p2pool/util/pack.py
|Handling of over the wire data structures
|}

==p2pool/main.py==
Makes extensive use of twisted.defer. This allows it to "yield" to allow long running network code to complete.
Read up on Python Generators and this before progressing!

Contains main startup code.

Tests connection to bitcoind.
Prints hash of latest block to show bitcoind is up to date.

Tests connection to p2pool network.

Gets address to use for payout either from file or bitcoind.
Validates address and checks local bitcoind owns it.

==p2pool/data.py==
Contains the main data structures used in p2pool.
These are:
===hash_link_type===
Serialized SHA256 engine state, used to prove that a coinbase transaction contains some data near the end without sending the entire transaction.
{| border=1
|+ '''hash_link_type'''
|-
!Field
!Type
!Description
|-
|state
|String(32)
|?
|-
|extra_data
|String(0)
|Comments say this is a hack
|-
|length
|VarInt
|?
|}
===small_block_header===
Bitcoin block header, excluding the merkle root. Included in shares, where the merkle root is computed implicitly from the coinbase transaction and the merkle branch.
{| border=1
|+ '''small_block_header'''
|-
!Field
!Type
!Description
|-
|version
|VarInt
|?
|-
|previous_block
|None or Int(256)
|?
|-
|timestamp
|Int(32)
|?
|-
|bits
|FloatingInteger(32)
|?
|-
|nonce
|Int(32)
|?
|}

===share_data_type===
Information contained within a share that is only relevant to P2Pool and that the client has control over (i.e. its value isn't fixed by the protocol rules).
{| border=1
|+ '''share_data_type'''
|-
!Field
!Type
!Description
|-
|previous_share_hash
|None or int(256)
|?
|-
|coinbase
|VarString
|?
|-
|nonce
|Int(32)
|?
|-
|pubkey_hash
|Int(160)
|?
|-
|subsidy
|Int(64)
|?
|-
|donation
|Int(16)
|?
|-
|stale_info
|String(32)
|Enum (orpan, dao, unk253, unk252...???
|-
|desired_version
|VarInt
|?
|}

===share_info_type===
Information contained within a share that is only relevant to P2Pool
{| border=1
|+ '''share_info_type'''
|-
!Field
!Type
!Description
|-
|share_data
|share_data_type (see above)
|?
|-
|far_share_hash
|none or int(256)
|?
|-
|max_bits
|Float Int
|?
|-
|bits
|Float Int
|?
|-
|timestamp
|Int(32)
|?
|}

===x===
{| border=1
|+ '''x'''
|-
!Field
!Type
!Description
|-
|name
|String(32)
|?
|}
===x===
{| border=1
|+ '''x'''
|-
!Field
!Type
!Description
|-
|name
|String(32)
|?
|}
===x===
{| border=1
|+ '''x'''
|-
!Field
!Type
!Description
|-
|name
|String(32)
|?
|}

==p2pool/util/pack.py==
I think this handles all the binary data types used in the bitcoin protocol to send data over the network wire.
These are nasty as very low level and many big endian/little endian complications.
The p2pool network protocol uses these also.
Do not think you need to really understand this unless making changes at this low level.

==p2pool/__init__.py==
At bottom has DEBUG flag. Change to true to get more output. (running p2pool with --debug does this)
Other than that just returns version number for git if it can.

P2Pool

2012-06-18T14:15:02Z

Forrestv:

URGENT: All P2Pool miners must upgrade to P2Pool 3.1 as soon as possible! See [https://bitcointalk.org/index.php?topic=18313.0 the forum post]

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

<blockquote>P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 10 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target. Whenever a peer announces a new share found (new block in the P2Pool block chain), it is received by the other peers, and the other peers verify that this block contains payouts for all the previous miners who found a share (and announced it) that made it into the P2Pool share chain. This continues until some peer finds a block that has a difficulty that meets the Bitcoin network's difficulty target. This peer announces this block to the Bitcoin network and miners who have submitted shares for this block are paid in the generation transaction, proportionally to how many shares they have found in the last while. - Unknown author</blockquote>

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin and avoids the risk of hard to detect theft by pool operators.

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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization, some Bitcoin supporters donate to P2Pool miners, resulting in average returns above 100% of the expected reward.
However, it should be noted that there are other pools (such as [[BitPenny]] and [[Eligius]]) which can provide the same level of reduction of the power of the pool operator over the Bitcoin network, however, none can provide the guarantees against pool operator cheating that P2Pool can.

== 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, just as Bitcoin regulates it to generate one block every ten minutes.
This means that finding shares becomes more difficult (resulting in higher variance) the more people mine on P2Pool, though large miners have the option to raise their difficulty, and so reduce the impact of their mining on P2Pool's minimum difficulty.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640 (= 24 hours of shares), whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is 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 ===

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: edit bitcoin.conf to include:
rpcuser=USER
rpcpassword=LONG_RANDOM_SECRET_VALUE
server=1
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** 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
** Source: python run_p2pool.py
* Run a miner daemon with long polling connecting to 127.0.0.1 (or the IP of the host running p2pool if it isn't on the same computer as the miner) on port 9332 with any username and password
** cgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher (but not 3.x)
* python-argparse
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does cgminer report so many longpoll events when mining on p2pool? - P4Man" 
'''A:''' "Once every ~10 seconds is normal. That is how often p2pool shares are generated (as opposed to ~10 min for bitcoin blocks) - cabin"

'''Q:''' "Do the 'orphan' and 'dead' shares in P2Pool's status display hurt me?" 
'''A:''' They shouldn't - It's normal for some fraction of everyone's shares to end up orphaned or dead. Because payouts are calculated by counting how many shares you have relative to others, everyone with normal configurations is equally "hurt" by this. However, if you have a large proportion of stales, your payout will be hurt. You can see how well you're doing by looking at P2Pool's "Efficiency" (ex: ''Efficiency: ~110.6% (40-111%)''). If 100% doesn't lie within the [http://en.wikipedia.org/wiki/Confidence_interval confidence interval] at the end, something is probably wrong (with 95% confidence).

'''Q:''' "What do I do if my efficiency is low?" 
'''A:''' Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. If you have a lot of dead shares or the "Local dead on arrival" number is higher than a few percent, that means that something is wrong with your miner. Check to make sure that it is one of the working versions in the ''Miners'' section on this page. Lower the intensity or raise the FPS of your miner. If you have a lot of orphan shares, something is wrong with P2Pool's P2P connection. Decrease the load on your internet connection or enable QoS (Quality of Service) on your router.

'''Q:''' What is PPLNS? 
'''A:''' Pay-Per-Last-N-Shares is a payout method that is completely resistant to pool hoppers.

'''Q:''' Why am I not getting very many shares?! 
'''A:''' The P2Pool difficulty is hundreds of times higher than on other pools. It can take time to get a share. P2Pool displays an estimate of how long you have to wait in the console output.

'''Q:''' Why does my miner say it has found a lot of shares but p2pool say I have only found a few?! 
'''A:''' The real P2Pool difficulty is hundreds of times higher than on normal pools, but p2pool essentially lies to your miner and tells it to work on relatively easy shares so that it submits shares every few seconds instead of every few hours. P2Pool then ignores any submitted shares that don't match the real share difficulty. By doing this, P2Pool can more accurately report your local hash rate and you can see if you are having problems with too many stale shares quickly

'''Q:''' Why am I getting so many rejects? 
'''A:''' You're using an incompatible miner. See the miners section here, increase your FPS on the miner, decrease the intensity, upgrade your miner, or try a different miner.

'''Q:''' What stops the pool operator or the block finder from stealing a block? 
'''A:''' A block solution is only worth anything because its hash matches Bitcoin's target. Altering anything within the block will change its hash and make it worthless. If you are concerned about the pool operator stealing a block, you should try to inspect the source code of each new version.

'''Q:''' Why does it say "Generated?" I want to spend my coins now! 
'''A:''' P2Pool includes payouts in generation transactions, which must mature (taking 120 blocks or 20 hours) before they can be spent. The reason for this is that a block could be orphaned, which would make its payout invalid and could reverse transactions.

'''Q:''' Do I get paid transaction fees? 
'''A:''' Yes. They are split among P2Pool miners.

'''Q:''' What are these payments I'm getting that aren't generated? 
'''A:''' These are subsidies that people who support the idea of P2Pool send to miners.

'''Q:''' Cool Subsidies sound like an awesome idea! How do I send some BTC to these awesome miners? 
'''A:''' See end of this page.

'''Q:''' Do I really need the WHOLE blockchain? 
'''A:''' Yes. Your node needs to be able to independently make decisions about what transactions to mine.

'''Q:''' How do merged mining payments work? 
'''A:''' Merged mining is handled entirely by namecoind, so you're solo mining and payouts will go into namecoind's wallet.

=== 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 intensity (8 for cgminer?) helps a lot with reducing stales.

* cgminer works perfectly without any extra options. However, using multiple pools might cause problems, because long polling is only done for one pool.
* ufasoft works perfectly.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seamless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.
* You can make P2Pool use a configuration file by running run_p2pool.py @FILENAME, with FILENAME being the path to a file containing the command-line arguments (newlines are ignored) Example:
<pre>
--net litecoin
-n 1.2.3.4
</pre>
* Setting the username of your miner connecting to P2Pool to a Bitcoin address will make it mine to that address instead of the one requested from bitcoind or set by -a
* Appending "/1000" to a miner's username will increase the difficulty of producing a P2Pool share to at most 1000. This is useful to large miners because doing this can make it easier for small miners while minimally impacting the large miners themselves. See [https://bitcointalk.org/index.php?topic=18313.msg816322#msg816322 recommended values].
** Appending "+1" (for example) after that will make P2Pool always give your miners work with a difficulty of 1

=== Web interface ===

Lots of data and useful tools are available at http://127.0.0.1:9332/something:
* /static/ - Lots of information from shares to graphs to payouts.
* /rate
* /users
* /fee
* /current_payouts
* /patron_sendmany - Gives sendmany outputs for fair donations to P2Pool
* /global_stats
* /local_stats
* /peer_addresses
* /payout_addr
* /recent_blocks
* /uptime
* /web/log - Some different stats collected over the last day

=== Included README ===
<pre>Requirements:
Generic:
Bitcoin >=0.6.0rc4 or Bitcoin >=0.5.4 (for BIP16 support) or Litecoin
Python
Twisted
python-argparse (for Python <=2.6)

Linux:
sudo apt-get install python-zope.interface python-twisted python-twisted-web
sudo apt-get install python-argparse # if on Python 2.6 or older

Windows:
Install Python 2.7: http://www.python.org/getit/
Install Twisted: http://twistedmatrix.com/trac/wiki/Downloads
Install Zope.Interface: http://pypi.python.org/pypi/zope.interface/3.8.0
Unzip the files into C:\Python27\Lib\site-packages

Running P2Pool:
To use P2Pool, you must be running your own local bitcoind. For standard
configurations, using P2Pool should be as simple as:

python run_p2pool.py

Then run your miner program, connecting to 127.0.0.1 on port 9332 with any
username and password.

If you are behind a NAT, you should enable TCP port forwarding on your
router. Forward port 9333 to the host running P2Pool.

Run "python run_p2pool.py --help" for additional options.

Notes for Litecoin:
Requirements:
In order to run P2Pool with the Litecoin network, you would need to build and install the
ltc_scrypt module that includes the scrypt proof of work code that Litecoin uses for hashes.

Linux:
cd litecoin_scrypt
sudo python setup.py install

Windows:
Install MinGW: http://www.mingw.org/wiki/Getting_Started
Install Python 2.7: http://www.python.org/getit/

cd litecoin_scrypt
C:\Python27\python.exe setup.py build --compile=mingw32 install

If you run into an error with unrecognized command line option '-mno-cygwin', see this:
http://stackoverflow.com/questions/6034390/compiling-with-cython-and-mingw-produces-gcc-error-unrecognized-command-line-o

Running P2Pool:
Run P2Pool with the "--net litecoin" option.
Run your miner program, connecting to 127.0.0.1 on port 9327.
Forward port 9338 to the host running P2Pool.

Litecoin's use of ports 9332 and 9332 conflicts with P2Pool running on
the Bitcoin network. To avoid problems, add these lines to litecoin.conf
and restart litecoind:
rpcport=10332
port=10333
</pre>

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin,litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--give-author DONATION_PERCENTAGE] [--iocp]
[--irc-announce] [--no-bugreport] [--p2pool-port PORT]
[-n ADDR[:PORT]] [--disable-upnp] [--max-conns CONNS]
[-w PORT or ADDR:PORT] [-f FEE_PERCENTAGE]
[--bitcoind-address BITCOIND_ADDRESS]
[--bitcoind-rpc-port BITCOIND_RPC_PORT]
[--bitcoind-p2p-port BITCOIND_P2P_PORT]
[BITCOIND_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version 0.11.1-8-ged9359d)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin,litecoin}
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>)
--datadir DATADIR store data in this directory (default: <directory
run_p2pool.py is in>/data)
--logfile LOGFILE log to this file (default: data/<NET>/log)
--merged MERGED_URLS call getauxblock on this url to get work for merged
mining (example:
http://ncuser:ncpass@127.0.0.1:10332/)
--give-author DONATION_PERCENTAGE
donate this percentage of work towards the development
of p2pool (default: 0.5)
--iocp use Windows IOCP API in order to avoid errors due to
large number of sockets being open
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--no-bugreport disable submitting caught exceptions to the author
--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)
-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
--max-conns CONNS maximum incoming connections (default: 40)

worker interface:
-w PORT or ADDR:PORT, --worker-port PORT or ADDR:PORT
listen on PORT on interface with ADDR for RPC
connections from miners (default: all interfaces,
bitcoin:9332, litecoin:9327)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The pool began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:

For example, a bash script to donate 10 btc is:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany/10)"
</pre>

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.

Note that the amount you donate will be allocated to recent miners in proportion to the amount of work they've done in the last 24 hours or so, but all the miner whose shares of the donated amount are less than 0.01 BTC will have their shares combined into a single amount which is awarded to one of them at random, with the chance of winning this 'lottery' weighted by the miner's recent amount of work done. You can change this 0.01 BTC threshold like this, for example, which says to pay 10 BTC, but to share it amongst more miners that the default, cutting off at 0.001 BTC instead of at 0.01 BTC.
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany/10/0.001)"
</pre>

If you decide to donate you should announce it on the forums so that your donations provide the most incentive possible.

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]
* [[P2Pool code documentation]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support
* [http://p2pool.info/ p2pool.info] stats page
* [http://nodes.p2pmine.com nodes.p2pmine.com] Public list of P2Pool BTC/LTC nodes.

==References==
<references />

[[Category:Pool Operators]]

BIP 0022

2012-05-12T04:10:12Z

Forrestv:

{{bip}}

<pre>
BIP: 22
Title: getmemorypool
Author: Luke Dashjr <luke+bip22@dashjr.org>
Status: Draft
Type: Standards Track
Created: 28-02-2012
</pre>

==Abstract==

This BIP describes a new JSON-RPC method for "smart" Bitcoin miners and proxies.
Instead of sending a simple block header for hashing, the entire block structure is sent, and left to the miner to (optionally) customize and assemble.

==Specification==

===JSON-RPC Method: getmemorypool===

A new JSON-RPC method is defined, called "getmemorypool".
It accepts two arguments, both optional.
If the first argument is provided, and a String, the call is interpreted as a block [[#Block Submission|submission]] or [[#Block Proposal|proposal]];
otherwise, this call is interpreted as a request for a new block template from the server.

===Block Template Request===

getmemorypool [{parameters...}]

If called with a single Object argument, getmemorypool interprets that Object as a set of parameters to build a block template from:
{| class="wikitable"
! Key !! Type !! Description
|-
| capabilities || Array of Strings || SHOULD contain a list of the following, to indicate client-side support: [[#Long Polling|"longpoll"]], "coinbasetxn", "coinbasevalue", [[#Block Proposal|"proposal"]], [[#Logical Services|"serverlist"]], "workid", and any of the [[#Mutations|mutations]]
|-
| longpoll || Boolean || if provided and true, indicates this is a [[#Long Polling|long poll request]]
|-
| longpollid || String || "longpollid" of job to monitor for expiration; required and valid only for [[#Long Polling|long poll requests]]
|-
| nonces || Number || size of nonce range the miner needs; if not provided, the server SHOULD assume the client requires 232
|-
| sigoplimit || Number || number of sigops to include in template, at most; if negative, offset from the block maximum
|-
| sizelimit || Number || number of bytes to use for the entire block, at most; if negative, offset from the block maximum
|-
| tx || String || format of response "transactions" key elements ("hex" per default)
|}

getmemorypool MUST return a JSON Object containing the following keys:
{| class="wikitable"
! Key !! Required !! Type !! Description
|-
| bits || {{Yes}} || String || the compressed difficulty in hexadecimal
|-
| curtime || {{Yes}} || Number || the current time as seen by the server (recommended for block time)
|-
| height || {{Yes|Should}} || Number || the height of the block we are looking for
|-
| longpollid || {{Yes|Should}} || String || unique identifier for [[#Long Polling|long poll request]]; MUST be omitted if the server does not support long polling
|-
| previousblockhash || {{Yes}} || String || the hash of the previous block, in big-endian hexadecimal
|-
| sigoplimit || {{Yes|Should}} || Number || number of sigops allowed in blocks
|-
| sizelimit || {{Yes|Should}} || Number || number of bytes allowed in blocks
|-
| transactions ("hash") || {{Yes|Should}} || Array of Strings || hashes/ids of Bitcoin transactions (excluding coinbase), in little-endian hexadecimal
|-
| transactions ("hex") || {{Yes|Should}} || Array of Strings || data for Bitcoin transactions (excluding coinbase) encoded in hexadecimal (byte-for-byte)
|-
| transactions ("obj") || {{Yes|Should}} || Array of Objects || Objects containing [[#Transactions Object Format|information for Bitcoin transactions]] (excluding coinbase)
|-
| version || {{Yes}} || Number || always 1 (at least for bitcoin)
|-
| coinbasetxn || {{Patch|this or ↓}} || See "transactions" || coinbase transaction, in the same format as "transactions" key
|-
| coinbasevalue || {{Patch|this or ↑}} || Number || total funds available for the coinbase (in Satoshis)
|-
| capabilities || {{No}} || Array of Strings || MAY contain "proposal" to indicate support for [[#Block Proposal|block proposal]], and SHOULD contain [[#Long Polling|"longpoll"]] to indicate support for that
|-
| coinbaseaux || {{No}} || Object || data that SHOULD or MUST (depending on mutable flags) be included in the coinbase's scriptSig content. Only the values (hexadecimal byte-for-byte) in this Object should be included, not the keys.
|-
| expires || {{No}} || Number || how many seconds (beginning from when the server sent the response) this work is valid for, at most
|-
| fulltarget || {{No}} || String || the number which full results should be less than, in big-endian hexadecimal (see [[#Mutations|"share/*" mutations]])
|-
| longpolluri || {{No}} || String || if provided, an alternate URI to use for [[#Long Polling|longpoll requests]]
|-
| maxtime || {{No}} || Number || the maximum time allowed
|-
| maxtimeoff || {{No}} || Number || the maximum time allowed (as a moving offset from "curtime" - every second, the actual maxtime is incremented by 1; for example, "maxtimeoff":0 means "time" may be incremented by 1 every second)
|-
| mintime || {{No}} || Number || the minimum time allowed
|-
| mintimeoff || {{No}} || Number || the minimum time allowed (as a moving offset from "curtime")
|-
| mutable || {{No}} || Array of Strings || different manipulations that the server explicitly allows to be made (see [[#Mutations|Mutations]])
|-
| noncerange || {{No}} || String || two 32-bit integers, concatenated in big-endian hexadecimal, which represent the valid ranges of nonces the miner may scan
|-
| serverlist || {{No}} || Array of Objects || list of servers in this [[#Logical Services|single logical service]]
|-
| submitold || {{No}} || Boolean || only relevant for [[#Long Polling|long poll]] responses; indicates if work received prior to this response remains potentially valid (default) and should have its shares submitted; if false, the miner may wish to discard its share queue
|-
| target || {{No}} || String || the number which valid results must be less than, in big-endian hexadecimal
|-
| txrequired || {{No}} || Number || this many of the first transactions provided must be present in the final block, even if the "transactions/remove" mutation is allowed
|-
| workid || {{No}} || String or Number || if provided, this value must be returned with results (see [[#JSON-RPC Method: submitblock|"submitblock"]])
|}

==== Transactions Object Format ====

When the "tx" option is provided as "obj", the Objects listed in the response's "transactions" key may contain these keys:

{| class="wikitable"
! Key !! Required !! Type !! Description
|-
| data || {{Yes}} || String || transaction data encoded in hexadecimal (byte-for-byte)
|-
| depends || {{No}} || Array of Numbers || other transactions (by index in "transactions" list) that must be present in the final block if this one is
|-
| fee || {{No}} || Number || difference in value between transaction inputs and outputs (in Satoshis); for coinbase transactions, this is a negative Number of the total collected block fees (ie, not including the block subsidy)
|-
| hash || {{No}} || String || hash/id encoded in little-endian hexadecimal
|-
| required || {{No}} || Boolean || if provided and true, this transaction must be in the final block, even if the "transactions/remove" mutation is allowed
|-
| sigops || {{No}} || Number || total number of SigOps, as counted for purposes of block limits
|-
| sigopsreal || {{No}} || Number || total number of SigOps, as counted by current standard rules
|}

====Mutations====

Any of these may be listed in the "mutable" key to signify modifications the miner is allowed to make:

{| class="wikitable"
! Value !! Significance
|-
| coinbase/append
| append the provided coinbase scriptSig
|-
| coinbase
| provide their own coinbase; if one is provided, it may be replaced or modified (implied if "coinbasetxn" omitted)
|-
| generation
| add or remove outputs from the coinbase/generation transaction (implied if "coinbasetxn" omitted)
|-
| share/coinbase
| if the block hash is less than "target", but not less than "fulltarget", only return the block header and coinbase transaction, but only if the other transactions are unmodified from those proposed in the getmemorypool job
|-
| share/merkle
| if the block hash is less than "target", but not less than "fulltarget", only return the block header, coinbase transaction, and merkle tree connecting that transaction to the root (in the form of repeated right-side SHA256 hashes) in "submitblock"
|-
| share/truncate
| if the block hash is less than "target", but not less than "fulltarget", only return the block header in "submitblock"
|-
| time/increment
| change the time header to a value after "time" (implied if "maxtime" or "maxtimeoff" are provided)
|-
| time/decrement
| change the time header to a value before "time" (implied if "mintime" is provided)
|-
| time
| modify the time header of the block
|-
| transactions/add
| add other valid transactions to the block
|-
| transactions/remove
| remove transactions provided by the server
|-
| transactions
| add or remove transactions (both of the above; implied if "transactions" omitted from result)
|-
| prevblock
| use the work with other previous-blocks; this implicitly allows removing transactions that are no longer valid, unless they are part of the "txrequired" count; it also implies adjusting "height" as necessary
|}

Note that miners are NOT required to implement any of these mutations.

===== Format of Data for Merkle-Only Shares =====

The format used for submitting shares with the "share/merkle" mutation shall be the 80-byte block header, followed by the coinbase transaction, and then finally the little-endian SHA256 hashes of each link in the merkle chain connecting it to the merkle root.

==== Long Polling ====
If the server supports long polling, it MUST include the "longpollid" key
It MAY supply the "longpolluri" key with a relative or absolute URI, which MAY specify a completely different resource than the original connection, including port number.
If "longpolluri" is provided by the server, clients MUST only attempt to use that URI for longpoll requests.

Clients MAY start a longpoll request with a standard JSON-RPC request (in the case of HTTP transport, POST with data) and same authorization, setting the "longpoll" parameter in the request to true.
The client MUST also include the "longpollid" key provided by the server in the parameters.

This request SHOULD NOT be processed nor answered by the server until it wishes to replace the current block data as identified by the "longpollid".
Clients SHOULD make this request with a very long request timeout and MUST accept servers sending a partial response in advance (such as HTTP headers with "chunked" Transfer-Encoding), and only delaying the completion of the final JSON response until processing.

Upon receiving a completed response:
* Only if "submitold" is provided and false, the client MAY discard the results of past operations and MUST begin working on the new work immediately.
* The client SHOULD begin working on the new work received as soon as possible, if not immediately.
* The client SHOULD make a new request to the same long polling URI.

If a client receives an incomplete or invalid response, it SHOULD retry the request with an exponential backoff.
Clients MAY implement this backoff with limitations (such as maximum backoff time) or any algorithm as deemed suitable.
It is, however, forbidden to simply retry immediately with no delay after more than one failure.
In the case of a "Forbidden" response (for example, HTTP 403), a client SHOULD NOT attempt to retry without user intervention.

====Logical Services====

If the "serverlist" parameter is provided, clients MAY choose to intelligently treat the server as part of a larger single logical service.

Each host Object in the Array is comprised of the following fields:
{| class="wikitable"
! Key !! Required !! Type !! Description
|-
| uri || {{Yes}} || String || URI of the individual server; if authentication information is omitted, the same authentication used for this request MUST be assumed
|-
| avoid || {{No}} || Number || number of seconds to avoid using this server
|-
| priority || {{No}} || Number || an integer priority of this host (default: 0)
|-
| sticky || {{No}} || Number || number of seconds to stick to this server when used
|-
| update || {{No}} || Boolean || whether this server may update the serverlist (default: true)
|-
| weight || {{No}} || Number || a relative weight for hosts with the same priority (default: 1)
|}

When choosing which actual server to get the next job from, URIs MUST be tried in order of their "priority" key, lowest Number first.
Where the priority of URIs is the same, they should be chosen from in random order, weighed by their "weight" key.

Updates to the Logical Service server list may only be made by the original server, or servers listed with the "update" key missing or true.
Clients MAY choose to advertise serverlist capability to servers with a false "update" key, but if so, MUST treat the server list provided as a subset of the current one, only considered in the context of this server.
At least one server with "update" privilege MUST be attempted at least once daily.

If the "sticky" key is provided, then when that server is used, it should be used consistently for at least that many seconds, if possible.

A permanent change in server URI MAY be indicated with a simple "serverlist" parameter:
"serverlist":[{"uri": "http://newserver"}]

A temporary delegation to another server for 5 minutes MAY be indicated likewise:
"serverlist":[{"uri": "", avoid: 300}, {"uri": "http://newserver", "update": false}]

===Block Proposal===

getmemorypool "hex-encoded block data..." {mode: "proposal", parameters...}

At any point before a job expires, a miner MAY propose a block to the server for general validation.
This is accomplished by calling getmemorypool with the hex-encoded block data as the first argument (as in a [[#Block Submission|submission]]), and an Object as the second argument with the "mode" key set to "proposal".

The block data MUST be validated and checked against the server's usual acceptance rules (excluding the check for a valid proof-of-work).
If it is found to be in violation of any of these rules, the server MUST return a String giving the reason for the rejection (see [[#Block Submission|Block Submission]] for example reasons).
If it is acceptable as-is, the server MAY return a true Boolean.
Otherwise, the server may return a new block template (with or without changes); in this case, any missing keys are assumed to default to those in the proposed block or, if not applicable, the original block template it was based on.

It is RECOMMENDED that servers which merely need to track the proposed block for later share/* submissions, return a simple Object of the form:
{"workid":"new workid"}

Clients SHOULD assume their proposed block will remain valid if the only changes they make are to the portion of the coinbase scriptSig they themselves provided (if any) and the time header.
Servers SHOULD NOT break this assumption without good cause.

===Block Submission===

getmemorypool "hex-encoded block data..." [{...}]

When getmemorypool is called with a String as its first argument, it is interpreted as hex-encoded data for a potential block; this may be truncated or merkle-ified depending on the "share/truncate" or "share/merkle" mutations, respectively.
The second argument, if provided, is an Object of parameters for the submission.
If this includes the "mode" key set to "proposal", the [[#Block Proposal|block proposal]] process should be followed instead.
The only other defined key for this Object is the "workid" provided by the server:
if a "workid" was specified in the template, it must be submitted with the share/block.

If the parameters argument is specified, this method MUST return either null (when a share is accepted), a String describing briefly the reason the share was rejected, or an Object of these with a key for each merged-mining chain the share was submitted to.

If the parameters argument is omitted, this method SHOULD return either true (if the share is accepted) or false (if rejected).
Clients MUST NOT depend on this boolean response, and servers MAY choose not to implement this paragraph.

Possible reasons a share may be rejected include, but are not limited to:
{| class="wikitable"
! Reason !! Description
|-
| bad-cb-flag || the server detected a feature-signifying flag that it does not allow
|-
| bad-cb-length || the coinbase was too long (bitcoin limit is 100 bytes)
|-
| bad-cb-prefix || the server only allows appending to the coinbase, but it was modified beyond that
|-
| bad-diffbits || "bits" were changed
|-
| bad-prevblk || the previous-block is not the one the server intends to build on
|-
| bad-txnmrklroot || the block header's merkle root did not match the transaction merkle tree
|-
| bad-txns || the server didn't like something about the transactions in the block
|-
| bad-version || the version was wrong
|-
| duplicate || the server already processed this block data
|-
| high-hash || the block header did not hash to a value lower than the specified target
|-
| rejected || a generic rejection without details
|-
| stale-prevblk || the previous-block is no longer the one the server intends to build on
|-
| stale-work || the work this block was based on is no longer accepted
|-
| time-invalid || the time was not acceptable
|-
| time-too-new || the time was too far in the future
|-
| time-too-old || the time was too far in the past
|-
| unknown-user || the user submitting the block was not recognized
|-
| unknown-work || the template or workid could not be identified
|}

=== Known Bugs ===
This BIP should not be promoted from Draft status until these are addressed:
* ''(feel free to add issues here)''

==Motivation==

There is reasonable concerns about mining currently being too centralized on pools, and the amount of control these pools hold.
By exposing the details of the block proposals to the miners, they are enabled to audit and possibly modify the block before hashing it.

==Reference Implementation==

* [https://gitorious.org/bitcoin/eloipool Eloipool]
* [http://luke.dashjr.org/programs/bitcoin/w/bitcoind/luke-jr.git/blobdiff/722d9387be4b267b689d7b7d78daeb7157bd12d8..gmp_bip:/src/bitcoinrpc.cpp bitcoind]

[[Category:BIP|D]]

BIP 0022

2012-05-12T03:57:38Z

Forrestv:

{{bip}}

<pre>
BIP: 22
Title: getmemorypool
Author: Luke Dashjr <luke+bip22@dashjr.org>
Status: Draft
Type: Standards Track
Created: 28-02-2012
</pre>

==Abstract==

This BIP describes a new JSON-RPC method for "smart" Bitcoin miners and proxies.
Instead of sending a simple block header for hashing, the entire block structure is sent, and left to the miner to (optionally) customize and assemble.

==Specification==

===JSON-RPC Method: getmemorypool===

A new JSON-RPC method is defined, called "getmemorypool".
It accepts two arguments, both optional.
If the first argument is provided, and a String, the call is interpreted as a block [[#Block Submission|submission]] or [[#Block Proposal|proposal]];
otherwise, this call is interpreted as a request for a new block template from the server.

===Block Template Request===

getmemorypool [{parameters...}]

If called with a single Object argument, getmemorypool interprets that Object as a set of parameters to build a block template from:
{| class="wikitable"
! Key !! Type !! Description
|-
| capabilities || Array of Strings || SHOULD contain a list of the following, to indicate client-side support: [[#Long Polling|"longpoll"]], "coinbasetxn", "coinbasevalue", [[#Block Proposal|"proposal"]], [[#Logical Services|"serverlist"]], "workid", and any of the [[#Mutations|mutations]]
|-
| longpoll || Boolean || if provided and true, indicates this is a [[#Long Polling|long poll request]]
|-
| longpollid || String || "longpollid" of job to monitor for expiration; required and valid only for [[#Long Polling|long poll requests]]
|-
| nonces || Number || size of nonce range the miner needs; if not provided, the server SHOULD assume the client requires 232
|-
| sigoplimit || Number || number of sigops to include in template, at most; if negative, offset from the block maximum
|-
| sizelimit || Number || number of bytes to use for the entire block, at most; if negative, offset from the block maximum
|-
| tx || String || format of response "transactions" key elements ("hex" per default)
|}

getmemorypool MUST return a JSON Object containing the following keys:
{| class="wikitable"
! Key !! Required !! Type !! Description
|-
| bits || {{Yes}} || String || the compressed difficulty in hexadecimal
|-
| curtime || {{Yes}} || Number || the current time as seen by the server (recommended for block time)
|-
| height || {{Yes|Should}} || Number || the height of the block we are looking for
|-
| longpollid || {{Yes|Should}} || String || unique identifier for [[#Long Polling|long poll request]]; MUST be omitted if the server does not support long polling
|-
| previousblockhash || {{Yes}} || String || the hash of the previous block, in big-endian hexadecimal
|-
| sigoplimit || {{Yes|Should}} || Number || number of sigops allowed in blocks
|-
| sizelimit || {{Yes|Should}} || Number || number of bytes allowed in blocks
|-
| transactions ("hash") || {{Yes|Should}} || Array of Strings || hashes/ids of Bitcoin transactions (excluding coinbase), in little-endian hexadecimal
|-
| transactions ("hex") || {{Yes|Should}} || Array of Strings || data for Bitcoin transactions (excluding coinbase) encoded in hexadecimal (byte-for-byte)
|-
| transactions ("obj") || {{Yes|Should}} || Array of Objects || Objects containing [[#Transactions Object Format|information for Bitcoin transactions]] (excluding coinbase)
|-
| version || {{Yes}} || Number || always 1 (at least for bitcoin)
|-
| coinbasetxn || {{Patch|this or ↓}} || See "transactions" || coinbase transaction, in the same format as "transactions" key
|-
| coinbasevalue || {{Patch|this or ↑}} || Number || total funds available for the coinbase (in Satoshis)
|-
| capabilities || {{No}} || Array of Strings || MAY contain "proposal" to indicate support for [[#Block Proposal|block proposal]], and SHOULD contain [[#Long Polling|"longpoll"]] to indicate support for that
|-
| coinbaseaux || {{No}} || Object || data that SHOULD or MUST (depending on mutable flags) be included in the coinbase's scriptSig content. Only the values (hexadecimal byte-for-byte) in this Object should be included, not the keys.
|-
| expires || {{No}} || Number || how many seconds (beginning from when the server sent the response) this work is valid for, at most
|-
| fulltarget || {{No}} || String || the number which full results should be less than, in big-endian hexadecimal (see [[#Mutations|"share/*" mutations]])
|-
| longpolluri || {{No}} || String || if provided, an alternate URI to use for [[#Long Polling|longpoll requests]]
|-
| maxtime || {{No}} || Number || the maximum time allowed
|-
| maxtimeoff || {{No}} || Number || the maximum time allowed (as a moving offset from "curtime" - every second, the actual maxtime is incremented by 1; for example, "maxtimeoff":0 means "time" may be incremented by 1 every second)
|-
| mintime || {{No}} || Number || the minimum time allowed
|-
| mintimeoff || {{No}} || Number || the minimum time allowed (as a moving offset from "curtime")
|-
| mutable || {{No}} || Array of Strings || different manipulations that the server explicitly allows to be made (see [[#Mutations|Mutations]])
|-
| noncerange || {{No}} || String || two 32-bit integers, concatenated in big-endian hexadecimal, which represent the valid ranges of nonces the miner may scan
|-
| serverlist || {{No}} || Array of Objects || list of servers in this [[#Logical Services|single logical service]]
|-
| submitold || {{No}} || Boolean || only relevant for [[#Long Polling|long poll]] responses; indicates if work received prior to this response remains potentially valid (default) and should have its shares submitted; if false, the miner may wish to discard its share queue
|-
| target || {{No}} || String || the number which valid results must be less than, in big-endian hexadecimal
|-
| txrequired || {{No}} || Number || this many of the first transactions provided must be present in the final block, even if the "transactions/remove" mutation is allowed
|-
| workid || {{No}} || String or Number || if provided, this value must be returned with results (see [[#JSON-RPC Method: submitblock|"submitblock"]])
|}

==== Transactions Object Format ====

When the "tx" option is provided as "obj", the Objects listed in the response's "transactions" key may contain these keys:

{| class="wikitable"
! Key !! Required !! Type !! Description
|-
| data || {{Yes}} || String || transaction data encoded in hexadecimal (byte-for-byte)
|-
| depends || {{No}} || Array of Numbers || other transactions (by index in "transactions" list) that must be present in the final block if this one is
|-
| fee || {{No}} || Number || difference in value between transaction inputs and outputs (in Satoshis); for coinbase transactions, this is a negative Number of the total collected block fees (ie, not including the block subsidy)
|-
| hash || {{No}} || String || hash/id encoded in little-endian hexadecimal
|-
| required || {{No}} || Boolean || if provided and true, this transaction must be in the final block, even if the "transactions/remove" mutation is allowed
|-
| sigops || {{No}} || Number || total number of SigOps, as counted for purposes of block limits
|-
| sigopsreal || {{No}} || Number || total number of SigOps, as counted by current standard rules
|}

====Mutations====

Any of these may be listed in the "mutable" key to signify modifications the miner is allowed to make:

{| class="wikitable"
! Value !! Significance
|-
| coinbase/append
| append the provided coinbase scriptSig
|-
| coinbase
| provide their own coinbase; if one is provided, it may be replaced or modified (implied if "coinbasetxn" omitted)
|-
| generation
| add or remove outputs from the coinbase/generation transaction (implied if "coinbasetxn" omitted)
|-
| share/coinbase
| if the block hash is less than "target", but not less than "fulltarget", only return the block header and coinbase transaction, but only if the other transactions are unmodified from those proposed in the getmemorypool job
|-
| share/merkle
| if the block hash is less than "target", but not less than "fulltarget", only return the block header, coinbase transaction, and merkle tree connecting that transaction to the root (in the form of repeated right-side SHA256 hashes) in "submitblock"
|-
| share/truncate
| if the block hash is less than "target", but not less than "fulltarget", only return the block header in "submitblock"
|-
| time/increment
| change the time header to a value after "time" (implied if "maxtime" or "maxtimeoff" are provided)
|-
| time/decrement
| change the time header to a value before "time" (implied if "mintime" is provided)
|-
| time
| modify the time header of the block
|-
| transactions/add
| add other valid transactions to the block
|-
| transactions/remove
| remove transactions provided by the server
|-
| transactions
| add or remove transactions (both of the above; implied if "transactions" omitted from result)
|-
| prevblock
| use the work with other previous-blocks; this implicitly allows removing transactions that are no longer valid, unless they are part of the "txrequired" count; it also implies adjusting "height" as necessary
|}

Note that miners are NOT required to implement any of these mutations.

===== Format of Data for Merkle-Only Shares =====

The format used for submitting shares with the "share/merkle" mutation shall be the 80-byte block header, followed by the coinbase transaction, and then finally the little-endian SHA256 hashes of each link in the merkle chain connecting it to the merkle root.

==== Long Polling ====
If the server supports long polling, it MUST include the "longpollid" key
It MAY supply the "longpolluri" key with a relative or absolute URI, which MAY specify a completely different resource than the original connection, including port number.
If "longpolluri" is provided by the server, clients MUST only attempt to use that URI for longpoll requests.

Clients MAY start a longpoll request with a standard JSON-RPC request (in the case of HTTP transport, POST with data) and same authorization, setting the "longpoll" parameter in the request to true.
The client MUST also include the "longpollid" key provided by the server in the parameters.

This request SHOULD NOT be processed nor answered by the server until it wishes to replace the current block data as identified by the "longpollid".
Clients SHOULD make this request with a very long request timeout and MUST accept servers sending a partial response in advance (such as HTTP headers with "chunked" Transfer-Encoding), and only delaying the completion of the final JSON response until processing.

Upon receiving a completed response:
* Only if "submitold" is provided and false, the client MAY discard the results of past operations and MUST begin working on the new work immediately.
* The client SHOULD begin working on the new work received as soon as possible, if not immediately.
* The client SHOULD make a new request to the same long polling URI.

If a client receives an incomplete or invalid response, it SHOULD retry the request with an exponential backoff.
Clients MAY implement this backoff with limitations (such as maximum backoff time) or any algorithm as deemed suitable.
It is, however, forbidden to simply retry immediately with no delay after more than one failure.
In the case of a "Forbidden" response (for example, HTTP 403), a client SHOULD NOT attempt to retry without user intervention.

====Logical Services====

If the "serverlist" parameter is provided, clients MAY choose to intelligently treat the server as part of a larger single logical service.

Each host Object in the Array is comprised of the following fields:
{| class="wikitable"
! Key !! Required !! Type !! Description
|-
| uri || {{Yes}} || String || URI of the individual server; if authentication information is omitted, the same authentication used for this request MUST be assumed
|-
| avoid || {{No}} || Number || number of seconds to avoid using this server
|-
| priority || {{No}} || Number || an integer priority of this host (default: 0)
|-
| sticky || {{No}} || Number || number of seconds to stick to this server when used
|-
| update || {{No}} || Boolean || whether this server may update the serverlist (default: true)
|-
| weight || {{No}} || Number || a relative weight for hosts with the same priority (default: 1)
|}

When choosing which actual server to get the next job from, URIs MUST be tried in order of their "priority" key, lowest Number first.
Where the priority of URIs is the same, they should be chosen from in random order, weighed by their "weight" key.

Updates to the Logical Service server list may only be made by the original server, or servers listed with the "update" key missing or true.
Clients MAY choose to advertise serverlist capability to servers with a false "update" key, but if so, MUST treat the server list provided as a subset of the current one, only considered in the context of this server.
At least one server with "update" privilege MUST be attempted at least once daily.

If the "sticky" key is provided, then when that server is used, it should be used consistently for at least that many seconds, if possible.

A permanent change in server URI MAY be indicated with a simple "serverlist" parameter:
"serverlist":[{"uri": "http://newserver"}]

A temporary delegation to another server for 5 minutes MAY be indicated likewise:
"serverlist":[{"uri": "", avoid: 300}, {"uri": "http://newserver", "update": false}]

===Block Proposal===

getmemorypool "hex-encoded block data..." {mode: proposal, parameters...}

At any point before a job expires, a miner MAY propose a block to the server for general validation.
This is accomplished by calling getmemorypool with the hex-encoded block data as the first argument (as in a [[#Block Submission|submission]]), and an Object as the second argument with the "mode" key set to "proposal".

The block data MUST be validated and checked against the server's usual acceptance rules (excluding the check for a valid proof-of-work).
If it is found to be in violation of any of these rules, the server MUST return a String giving the reason for the rejection (see [[#Block Submission|Block Submission]] for example reasons).
If it is acceptable as-is, the server MAY return a true Boolean.
Otherwise, the server may return a new block template (with or without changes); in this case, any missing keys are assumed to default to those in the proposed block or, if not applicable, the original block template it was based on.

It is RECOMMENDED that servers which merely need to track the proposed block for later share/* submissions, return a simple Object of the form:
{"workid":"new workid"}

Clients SHOULD assume their proposed block will remain valid if the only changes they make are to the portion of the coinbase scriptSig they themselves provided (if any) and the time header.
Servers SHOULD NOT break this assumption without good cause.

===Block Submission===

getmemorypool "hex-encoded block data..." [{...}]

When getmemorypool is called with a String as its first argument, it is interpreted as hex-encoded data for a potential block; this may be truncated or merkle-ified depending on the "share/truncate" or "share/merkle" mutations, respectively.
The second argument, if provided, is an Object of parameters for the submission.
If this includes the "mode" key set to "proposal", the [[#Block Proposal|block proposal]] process should be followed instead.
The only other defined key for this Object is the "workid" provided by the server:
if a "workid" was specified in the template, it must be submitted with the share/block.

If the parameters argument is specified, this method MUST return either null (when a share is accepted), a String describing briefly the reason the share was rejected, or an Object of these with a key for each merged-mining chain the share was submitted to.

If the parameters argument is omitted, this method SHOULD return either true (if the share is accepted) or false (if rejected).
Clients MUST NOT depend on this boolean response, and servers MAY choose not to implement this paragraph.

Possible reasons a share may be rejected include, but are not limited to:
{| class="wikitable"
! Reason !! Description
|-
| bad-cb-flag || the server detected a feature-signifying flag that it does not allow
|-
| bad-cb-length || the coinbase was too long (bitcoin limit is 100 bytes)
|-
| bad-cb-prefix || the server only allows appending to the coinbase, but it was modified beyond that
|-
| bad-diffbits || "bits" were changed
|-
| bad-prevblk || the previous-block is not the one the server intends to build on
|-
| bad-txnmrklroot || the block header's merkle root did not match the transaction merkle tree
|-
| bad-txns || the server didn't like something about the transactions in the block
|-
| bad-version || the version was wrong
|-
| duplicate || the server already processed this block data
|-
| high-hash || the block header did not hash to a value lower than the specified target
|-
| rejected || a generic rejection without details
|-
| stale-prevblk || the previous-block is no longer the one the server intends to build on
|-
| stale-work || the work this block was based on is no longer accepted
|-
| time-invalid || the time was not acceptable
|-
| time-too-new || the time was too far in the future
|-
| time-too-old || the time was too far in the past
|-
| unknown-user || the user submitting the block was not recognized
|-
| unknown-work || the template or workid could not be identified
|}

=== Known Bugs ===
This BIP should not be promoted from Draft status until these are addressed:
* ''(feel free to add issues here)''

==Motivation==

There is reasonable concerns about mining currently being too centralized on pools, and the amount of control these pools hold.
By exposing the details of the block proposals to the miners, they are enabled to audit and possibly modify the block before hashing it.

==Reference Implementation==

* [https://gitorious.org/bitcoin/eloipool Eloipool]
* [http://luke.dashjr.org/programs/bitcoin/w/bitcoind/luke-jr.git/blobdiff/722d9387be4b267b689d7b7d78daeb7157bd12d8..gmp_bip:/src/bitcoinrpc.cpp bitcoind]

[[Category:BIP|D]]

BIP 0022

2012-05-12T03:46:20Z

Forrestv: clarified some things

{{bip}}

<pre>
BIP: 22
Title: getmemorypool
Author: Luke Dashjr <luke+bip22@dashjr.org>
Status: Draft
Type: Standards Track
Created: 28-02-2012
</pre>

==Abstract==

This BIP describes a new JSON-RPC method for "smart" Bitcoin miners and proxies.
Instead of sending a simple block header for hashing, the entire block structure is sent, and left to the miner to (optionally) customize and assemble.

==Specification==

===JSON-RPC Method: getmemorypool===

A new JSON-RPC method is defined, called "getmemorypool".
It accepts two arguments, both optional.
If the first argument is provided, and a String, the call is interpreted as a block [[#Block Submission|submission]] or [[#Block Proposal|proposal]];
otherwise, this call is interpreted as a request for a new block template from the server.

===Block Template Request===

getmemorypool [{parameters...}]

If called with a single Object argument, getmemorypool interprets that Object as a set of parameters to build a block template from:
{| class="wikitable"
! Key !! Type !! Description
|-
| capabilities || Array of Strings || SHOULD contain a list of the following, to indicate client-side support: [[#Long Polling|"longpoll"]], "coinbasetxn", "coinbasevalue", [[#Block Proposal|"proposal"]], [[#Logical Services|"serverlist"]], "workid", and any of the [[#Mutations|mutations]]
|-
| longpoll || Boolean || if provided and true, indicates this is a [[#Long Polling|long poll request]]
|-
| longpollid || String || "longpollid" of job to monitor for expiration; required and valid only for [[#Long Polling|long poll requests]]
|-
| nonces || Number || size of nonce range the miner needs; if not provided, the server SHOULD assume the client requires 232
|-
| sigoplimit || Number || number of sigops to include in template, at most; if negative, offset from the block maximum
|-
| sizelimit || Number || number of bytes to use for the entire block, at most; if negative, offset from the block maximum
|-
| tx || String || format of response "transactions" key elements ("hex" per default)
|}

getmemorypool MUST return a JSON Object containing the following keys:
{| class="wikitable"
! Key !! Required !! Type !! Description
|-
| bits || {{Yes}} || String || the compressed difficulty in hexadecimal
|-
| curtime || {{Yes}} || Number || the current time as seen by the server (recommended for block time)
|-
| height || {{Yes|Should}} || Number || the height of the block we are looking for
|-
| longpollid || {{Yes|Should}} || String || unique identifier for [[#Long Polling|long poll request]]; MUST be omitted if the server does not support long polling
|-
| previousblockhash || {{Yes}} || String || the hash of the previous block, in big-endian hexadecimal
|-
| sigoplimit || {{Yes|Should}} || Number || number of sigops allowed in blocks
|-
| sizelimit || {{Yes|Should}} || Number || number of bytes allowed in blocks
|-
| transactions ("hash") || {{Yes|Should}} || Array of Strings || hashes/ids of Bitcoin transactions (excluding coinbase), in little-endian hexadecimal
|-
| transactions ("hex") || {{Yes|Should}} || Array of Strings || data for Bitcoin transactions (excluding coinbase) encoded in hexadecimal (byte-for-byte)
|-
| transactions ("obj") || {{Yes|Should}} || Array of Objects || Objects containing [[#Transactions Object Format|information for Bitcoin transactions]] (excluding coinbase)
|-
| version || {{Yes}} || Number || always 1 (at least for bitcoin)
|-
| coinbasetxn || {{Patch|or ↓}} || See "transactions" || coinbase transaction, in the same format as "transactions" key
|-
| coinbasevalue || {{Patch|or ↑}} || Number || total funds available for the coinbase (in Satoshis)
|-
| capabilities || {{No}} || Array of Strings || MAY contain "proposal" to indicate support for [[#Block Proposal|block proposal]], and SHOULD contain [[#Long Polling|"longpoll"]] to indicate support for that
|-
| coinbaseaux || {{No}} || Object || data that SHOULD or MUST (depending on mutable flags) be included in the coinbase's scriptSig content. Only the values (hexadecimal byte-for-byte) in this Object should be included, not the keys.
|-
| expires || {{No}} || Number || how many seconds (beginning from when the server sent the response) this work is valid for, at most
|-
| fulltarget || {{No}} || String || the number which full results should be less than, in big-endian hexadecimal (see [[#Mutations|"share/*" mutations]])
|-
| longpolluri || {{No}} || String || if provided, an alternate URI to use for [[#Long Polling|longpoll requests]]
|-
| maxtime || {{No}} || Number || the maximum time allowed
|-
| maxtimeoff || {{No}} || Number || the maximum time allowed (as a moving offset from "curtime" - every second, the actual maxtime is incremented by 1; for example, "maxtimeoff":0 means "time" may be incremented by 1 every second)
|-
| mintime || {{No}} || Number || the minimum time allowed
|-
| mintimeoff || {{No}} || Number || the minimum time allowed (as a moving offset from "curtime")
|-
| mutable || {{No}} || Array of Strings || different manipulations that the server explicitly allows to be made (see [[#Mutations|Mutations]])
|-
| noncerange || {{No}} || String || two 32-bit integers, concatenated in big-endian hexadecimal, which represent the valid ranges of nonces the miner may scan
|-
| serverlist || {{No}} || Array of Objects || list of servers in this [[#Logical Services|single logical service]]
|-
| submitold || {{No}} || Boolean || only relevant for [[#Long Polling|long poll]] responses; indicates if work received prior to this response remains potentially valid (default) and should have its shares submitted; if false, the miner may wish to discard its share queue
|-
| target || {{No}} || String || the number which valid results must be less than, in big-endian hexadecimal
|-
| txrequired || {{No}} || Number || this many of the first transactions provided must be present in the final block, even if the "transactions/remove" mutation is allowed
|-
| workid || {{No}} || String or Number || if provided, this value must be returned with results (see [[#JSON-RPC Method: submitblock|"submitblock"]])
|}

==== Transactions Object Format ====

When the "tx" option is provided as "obj", the Objects listed in the response's "transactions" key may contain these keys:

{| class="wikitable"
! Key !! Required !! Type !! Description
|-
| data || {{Yes}} || String || transaction data encoded in hexadecimal (byte-for-byte)
|-
| depends || {{No}} || Array of Numbers || other transactions (by index in "transactions" list) that must be present in the final block if this one is
|-
| fee || {{No}} || Number || difference in value between transaction inputs and outputs (in Satoshis); for coinbase transactions, this is a negative Number of the total collected block fees (ie, not including the block subsidy)
|-
| hash || {{No}} || String || hash/id encoded in little-endian hexadecimal
|-
| required || {{No}} || Boolean || if provided and true, this transaction must be in the final block, even if the "transactions/remove" mutation is allowed
|-
| sigops || {{No}} || Number || total number of SigOps, as counted for purposes of block limits
|-
| sigopsreal || {{No}} || Number || total number of SigOps, as counted by current standard rules
|}

====Mutations====

Any of these may be listed in the "mutable" key to signify modifications the miner is allowed to make:

{| class="wikitable"
! Value !! Significance
|-
| coinbase/append
| append the provided coinbase scriptSig
|-
| coinbase
| provide their own coinbase; if one is provided, it may be replaced or modified (implied if "coinbasetxn" omitted)
|-
| generation
| add or remove outputs from the coinbase/generation transaction (implied if "coinbasetxn" omitted)
|-
| share/coinbase
| if the block hash is less than "target", but not less than "fulltarget", only return the block header and coinbase transaction, but only if the other transactions are unmodified from those proposed in the getmemorypool job
|-
| share/merkle
| if the block hash is less than "target", but not less than "fulltarget", only return the block header, coinbase transaction, and merkle tree connecting that transaction to the root (in the form of repeated right-side SHA256 hashes) in "submitblock"
|-
| share/truncate
| if the block hash is less than "target", but not less than "fulltarget", only return the block header in "submitblock"
|-
| time/increment
| change the time header to a value after "time" (implied if "maxtime" or "maxtimeoff" are provided)
|-
| time/decrement
| change the time header to a value before "time" (implied if "mintime" is provided)
|-
| time
| modify the time header of the block
|-
| transactions/add
| add other valid transactions to the block
|-
| transactions/remove
| remove transactions provided by the server
|-
| transactions
| add or remove transactions (both of the above; implied if "transactions" omitted from result)
|-
| prevblock
| use the work with other previous-blocks; this implicitly allows removing transactions that are no longer valid, unless they are part of the "txrequired" count; it also implies adjusting "height" as necessary
|}

Note that miners are NOT required to implement any of these mutations.

===== Format of Data for Merkle-Only Shares =====

The format used for submitting shares with the "share/merkle" mutation shall be the 80-byte block header, followed by the coinbase transaction, and then finally the little-endian SHA256 hashes of each link in the merkle chain connecting it to the merkle root.

==== Long Polling ====
If the server supports long polling, it MUST include the "longpollid" key
It MAY supply the "longpolluri" key with a relative or absolute URI, which MAY specify a completely different resource than the original connection, including port number.
If "longpolluri" is provided by the server, clients MUST only attempt to use that URI for longpoll requests.

Clients MAY start a longpoll request with a standard JSON-RPC request (in the case of HTTP transport, POST with data) and same authorization, setting the "longpoll" parameter in the request to true.
The client MUST also include the "longpollid" key provided by the server in the parameters.

This request SHOULD NOT be processed nor answered by the server until it wishes to replace the current block data as identified by the "longpollid".
Clients SHOULD make this request with a very long request timeout and MUST accept servers sending a partial response in advance (such as HTTP headers with "chunked" Transfer-Encoding), and only delaying the completion of the final JSON response until processing.

Upon receiving a completed response:
* Only if "submitold" is provided and false, the client MAY discard the results of past operations and MUST begin working on the new work immediately.
* The client SHOULD begin working on the new work received as soon as possible, if not immediately.
* The client SHOULD make a new request to the same long polling URI.

If a client receives an incomplete or invalid response, it SHOULD retry the request with an exponential backoff.
Clients MAY implement this backoff with limitations (such as maximum backoff time) or any algorithm as deemed suitable.
It is, however, forbidden to simply retry immediately with no delay after more than one failure.
In the case of a "Forbidden" response (for example, HTTP 403), a client SHOULD NOT attempt to retry without user intervention.

====Logical Services====

If the "serverlist" parameter is provided, clients MAY choose to intelligently treat the server as part of a larger single logical service.

Each host Object in the Array is comprised of the following fields:
{| class="wikitable"
! Key !! Required !! Type !! Description
|-
| uri || {{Yes}} || String || URI of the individual server; if authentication information is omitted, the same authentication used for this request MUST be assumed
|-
| avoid || {{No}} || Number || number of seconds to avoid using this server
|-
| priority || {{No}} || Number || an integer priority of this host (default: 0)
|-
| sticky || {{No}} || Number || number of seconds to stick to this server when used
|-
| update || {{No}} || Boolean || whether this server may update the serverlist (default: true)
|-
| weight || {{No}} || Number || a relative weight for hosts with the same priority (default: 1)
|}

When choosing which actual server to get the next job from, URIs MUST be tried in order of their "priority" key, lowest Number first.
Where the priority of URIs is the same, they should be chosen from in random order, weighed by their "weight" key.

Updates to the Logical Service server list may only be made by the original server, or servers listed with the "update" key missing or true.
Clients MAY choose to advertise serverlist capability to servers with a false "update" key, but if so, MUST treat the server list provided as a subset of the current one, only considered in the context of this server.
At least one server with "update" privilege MUST be attempted at least once daily.

If the "sticky" key is provided, then when that server is used, it should be used consistently for at least that many seconds, if possible.

A permanent change in server URI MAY be indicated with a simple "serverlist" parameter:
"serverlist":[{"uri": "http://newserver"}]

A temporary delegation to another server for 5 minutes MAY be indicated likewise:
"serverlist":[{"uri": "", avoid: 300}, {"uri": "http://newserver", "update": false}]

===Block Proposal===

getmemorypool "hex-encoded block data..." {mode: proposal, parameters...}

At any point before a job expires, a miner MAY propose a block to the server for general validation.
This is accomplished by calling getmemorypool with the hex-encoded block data as the first argument (as in a [[#Block Submission|submission]]), and an Object as the second argument with the "mode" key set to "proposal".

The block data MUST be validated and checked against the server's usual acceptance rules (excluding the check for a valid proof-of-work).
If it is found to be in violation of any of these rules, the server MUST return a String giving the reason for the rejection (see [[#Block Submission|Block Submission]] for example reasons).
If it is acceptable as-is, the server MAY return a true Boolean.
Otherwise, the server may return a new block template (with or without changes); in this case, any missing keys are assumed to default to those in the proposed block or, if not applicable, the original block template it was based on.

It is RECOMMENDED that servers which merely need to track the proposed block for later share/* submissions, return a simple Object of the form:
{"workid":"new workid"}

Clients SHOULD assume their proposed block will remain valid if the only changes they make are to the portion of the coinbase scriptSig they themselves provided (if any) and the time header.
Servers SHOULD NOT break this assumption without good cause.

===Block Submission===

getmemorypool "hex-encoded block data..." [{...}]

When getmemorypool is called with a String as its first argument, it is interpreted as hex-encoded data for a potential block; this may be truncated or merkle-ified depending on the "share/truncate" or "share/merkle" mutations, respectively.
The second argument, if provided, is an Object of parameters for the submission.
If this includes the "mode" key set to "proposal", the [[#Block Proposal|block proposal]] process should be followed instead.
The only other defined key for this Object is the "workid" provided by the server:
if a "workid" was specified in the template, it must be submitted with the share/block.

If the parameters argument is specified, this method MUST return either null (when a share is accepted), a String describing briefly the reason the share was rejected, or an Object of these with a key for each merged-mining chain the share was submitted to.

If the parameters argument is omitted, this method SHOULD return either true (if the share is accepted) or false (if rejected).
Clients MUST NOT depend on this boolean response, and servers MAY choose not to implement this paragraph.

Possible reasons a share may be rejected include, but are not limited to:
{| class="wikitable"
! Reason !! Description
|-
| bad-cb-flag || the server detected a feature-signifying flag that it does not allow
|-
| bad-cb-length || the coinbase was too long (bitcoin limit is 100 bytes)
|-
| bad-cb-prefix || the server only allows appending to the coinbase, but it was modified beyond that
|-
| bad-diffbits || "bits" were changed
|-
| bad-prevblk || the previous-block is not the one the server intends to build on
|-
| bad-txnmrklroot || the block header's merkle root did not match the transaction merkle tree
|-
| bad-txns || the server didn't like something about the transactions in the block
|-
| bad-version || the version was wrong
|-
| duplicate || the server already processed this block data
|-
| high-hash || the block header did not hash to a value lower than the specified target
|-
| rejected || a generic rejection without details
|-
| stale-prevblk || the previous-block is no longer the one the server intends to build on
|-
| stale-work || the work this block was based on is no longer accepted
|-
| time-invalid || the time was not acceptable
|-
| time-too-new || the time was too far in the future
|-
| time-too-old || the time was too far in the past
|-
| unknown-user || the user submitting the block was not recognized
|-
| unknown-work || the template or workid could not be identified
|}

=== Known Bugs ===
This BIP should not be promoted from Draft status until these are addressed:
* ''(feel free to add issues here)''

==Motivation==

There is reasonable concerns about mining currently being too centralized on pools, and the amount of control these pools hold.
By exposing the details of the block proposals to the miners, they are enabled to audit and possibly modify the block before hashing it.

==Reference Implementation==

* [https://gitorious.org/bitcoin/eloipool Eloipool]
* [http://luke.dashjr.org/programs/bitcoin/w/bitcoind/luke-jr.git/blobdiff/722d9387be4b267b689d7b7d78daeb7157bd12d8..gmp_bip:/src/bitcoinrpc.cpp bitcoind]

[[Category:BIP|D]]

P2Pool

2012-05-07T18:27:31Z

Forrestv: updated README and --help text

URGENT: All P2Pool miners must upgrade to P2Pool 0.11.0 as soon as possible! See [https://bitcointalk.org/index.php?topic=18313.0 the forum post]

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

<blockquote>P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 10 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target. Whenever a peer announces a new share found (new block in the P2Pool block chain), it is received by the other peers, and the other peers verify that this block contains payouts for all the previous miners who found a share (and announced it) that made it into the P2Pool share chain. This continues until some peer finds a block that has a difficulty that meets the Bitcoin network's difficulty target. This peer announces this block to the Bitcoin network and miners who have submitted shares for this block are paid in the generation transaction, proportionally to how many shares they have found in the last while. - Unknown author</blockquote>

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin and avoids the risk of hard to detect theft by pool operators.

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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization, some Bitcoin supporters donate to P2Pool miners, resulting in average returns above 100% of the expected reward.
However, it should be noted that there are other pools (such as [[BitPenny]] and [[Eligius]]) which can provide the same level of reduction of the power of the pool operator over the Bitcoin network, however, none can provide the guarantees against pool operator cheating that P2Pool can.

== 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, just as Bitcoin regulates it to generate one block every ten minutes.
This means that finding shares becomes more difficult (resulting in higher variance) the more people mine on P2Pool, though large miners have the option to raise their difficulty, and so reduce the impact of their mining on P2Pool's minimum difficulty.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640 (= 24 hours of shares), whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is 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 ===

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: edit bitcoin.conf to include:
rpcuser=USER
rpcpassword=LONG_RANDOM_SECRET_VALUE
server=1
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** 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
** Source: python run_p2pool.py
* Run a miner daemon with long polling connecting to 127.0.0.1 (or the IP of the host running p2pool if it isn't on the same computer as the miner) on port 9332 with any username and password
** cgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher (but not 3.x)
* python-argparse
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does cgminer report so many longpoll events when mining on p2pool? - P4Man" 
'''A:''' "Once every ~10 seconds is normal. That is how often p2pool shares are generated (as opposed to ~10 min for bitcoin blocks) - cabin"

'''Q:''' "Do the 'orphan' and 'dead' shares in P2Pool's status display hurt me?" 
'''A:''' They shouldn't - It's normal for some fraction of everyone's shares to end up orphaned or dead. Because payouts are calculated by counting how many shares you have relative to others, everyone with normal configurations is equally "hurt" by this. However, if you have a large proportion of stales, your payout will be hurt. You can see how well you're doing by looking at P2Pool's "Efficiency" (ex: ''Efficiency: ~110.6% (40-111%)''). If 100% doesn't lie within the [http://en.wikipedia.org/wiki/Confidence_interval confidence interval] at the end, something is probably wrong (with 95% confidence).

'''Q:''' "What do I do if my efficiency is low?" 
'''A:''' Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. If you have a lot of dead shares or the "Local dead on arrival" number is higher than a few percent, that means that something is wrong with your miner. Check to make sure that it is one of the working versions in the ''Miners'' section on this page. Lower the intensity or raise the FPS of your miner. If you have a lot of orphan shares, something is wrong with P2Pool's P2P connection. Decrease the load on your internet connection or enable QoS (Quality of Service) on your router.

'''Q:''' What is PPLNS? 
'''A:''' Pay-Per-Last-N-Shares is a payout method that is completely resistant to pool hoppers.

'''Q:''' Why am I not getting very many shares?! 
'''A:''' The P2Pool difficulty is hundreds of times higher than on other pools. It can take time to get a share. P2Pool displays an estimate of how long you have to wait in the console output.

'''Q:''' Why does my miner say it has found a lot of shares but p2pool say I have only found a few?! 
'''A:''' The real P2Pool difficulty is hundreds of times higher than on normal pools, but p2pool essentially lies to your miner and tells it to work on relatively easy shares so that it submits shares every few seconds instead of every few hours. P2Pool then ignores any submitted shares that don't match the real share difficulty. By doing this, P2Pool can more accurately report your local hash rate and you can see if you are having problems with too many stale shares quickly

'''Q:''' Why am I getting so many rejects? 
'''A:''' You're using an incompatible miner. See the miners section here, increase your FPS on the miner, decrease the intensity, upgrade your miner, or try a different miner.

'''Q:''' What stops the pool operator or the block finder from stealing a block? 
'''A:''' A block solution is only worth anything because its hash matches Bitcoin's target. Altering anything within the block will change its hash and make it worthless. If you are concerned about the pool operator stealing a block, you should try to inspect the source code of each new version.

'''Q:''' Why does it say "Generated?" I want to spend my coins now! 
'''A:''' P2Pool includes payouts in generation transactions, which must mature (taking 120 blocks or 20 hours) before they can be spent. The reason for this is that a block could be orphaned, which would make its payout invalid and could reverse transactions.

'''Q:''' Do I get paid transaction fees? 
'''A:''' Yes. They are split among P2Pool miners.

'''Q:''' What are these payments I'm getting that aren't generated? 
'''A:''' These are subsidies that people who support the idea of P2Pool send to miners.

'''Q:''' Cool Subsidies sound like an awesome idea! How do I send some BTC to these awesome miners? 
'''A:''' See end of this page.

'''Q:''' Do I really need the WHOLE blockchain? 
'''A:''' Yes. Your node needs to be able to independently make decisions about what transactions to mine.

'''Q:''' How do merged mining payments work? 
'''A:''' Merged mining is handled entirely by namecoind, so you're solo mining and payouts will go into namecoind's wallet.

=== 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 intensity (8 for cgminer?) helps a lot with reducing stales.

* cgminer works perfectly without any extra options. However, using multiple pools might cause problems, because long polling is only done for one pool.
* ufasoft works perfectly.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seamless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.
* You can make P2Pool use a configuration file by running run_p2pool.py @FILENAME, with FILENAME being the path to a file containing the command-line arguments (newlines are ignored) Example:
<pre>
--net litecoin
-n 1.2.3.4
</pre>
* Setting the username of your miner connecting to P2Pool to a Bitcoin address will make it mine to that address instead of the one requested from bitcoind or set by -a
* Appending "/1000" to a miner's username will increase the difficulty of producing a P2Pool share to at most 1000. This is useful to large miners because doing this can make it easier for small miners while minimally impacting the large miners themselves. See [https://bitcointalk.org/index.php?topic=18313.msg816322#msg816322 recommended values].
** Appending "+1" (for example) after that will make P2Pool always give your miners work with a difficulty of 1

=== Web interface ===

Lots of data and useful tools are available at http://127.0.0.1:9332/something:
* /static/ - Lots of information from shares to graphs to payouts.
* /rate
* /users
* /fee
* /current_payouts
* /patron_sendmany - Gives sendmany outputs for fair donations to P2Pool
* /global_stats
* /local_stats
* /peer_addresses
* /payout_addr
* /recent_blocks
* /uptime
* /web/log - Some different stats collected over the last day

=== Included README ===
<pre>Requirements:
Generic:
Bitcoin >=0.6.0rc4 or Bitcoin >=0.5.4 (for BIP16 support) or Litecoin
Python
Twisted
python-argparse (for Python <=2.6)

Linux:
sudo apt-get install python-zope.interface python-twisted python-twisted-web
sudo apt-get install python-argparse # if on Python 2.6 or older

Windows:
Install Python 2.7: http://www.python.org/getit/
Install Twisted: http://twistedmatrix.com/trac/wiki/Downloads
Install Zope.Interface: http://pypi.python.org/pypi/zope.interface/3.8.0
Unzip the files into C:\Python27\Lib\site-packages

Running P2Pool:
To use P2Pool, you must be running your own local bitcoind. For standard
configurations, using P2Pool should be as simple as:

python run_p2pool.py

Then run your miner program, connecting to 127.0.0.1 on port 9332 with any
username and password.

If you are behind a NAT, you should enable TCP port forwarding on your
router. Forward port 9333 to the host running P2Pool.

Run "python run_p2pool.py --help" for additional options.

Notes for Litecoin:
Requirements:
In order to run P2Pool with the Litecoin network, you would need to build and install the
ltc_scrypt module that includes the scrypt proof of work code that Litecoin uses for hashes.

Linux:
cd litecoin_scrypt
sudo python setup.py install

Windows:
Install MinGW: http://www.mingw.org/wiki/Getting_Started
Install Python 2.7: http://www.python.org/getit/

cd litecoin_scrypt
C:\Python27\python.exe setup.py build --compile=mingw32 install

If you run into an error with unrecognized command line option '-mno-cygwin', see this:
http://stackoverflow.com/questions/6034390/compiling-with-cython-and-mingw-produces-gcc-error-unrecognized-command-line-o

Running P2Pool:
Run P2Pool with the "--net litecoin" option.
Run your miner program, connecting to 127.0.0.1 on port 9327.
Forward port 9338 to the host running P2Pool.

Litecoin's use of ports 9332 and 9332 conflicts with P2Pool running on
the Bitcoin network. To avoid problems, add these lines to litecoin.conf
and restart litecoind:
rpcport=10332
port=10333
</pre>

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin,litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--give-author DONATION_PERCENTAGE] [--iocp]
[--irc-announce] [--no-bugreport] [--p2pool-port PORT]
[-n ADDR[:PORT]] [--disable-upnp] [--max-conns CONNS]
[-w PORT or ADDR:PORT] [-f FEE_PERCENTAGE]
[--bitcoind-address BITCOIND_ADDRESS]
[--bitcoind-rpc-port BITCOIND_RPC_PORT]
[--bitcoind-p2p-port BITCOIND_P2P_PORT]
[BITCOIND_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version 0.11.1-8-ged9359d)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin,litecoin}
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>)
--datadir DATADIR store data in this directory (default: <directory
run_p2pool.py is in>/data)
--logfile LOGFILE log to this file (default: data/<NET>/log)
--merged MERGED_URLS call getauxblock on this url to get work for merged
mining (example:
http://ncuser:ncpass@127.0.0.1:10332/)
--give-author DONATION_PERCENTAGE
donate this percentage of work towards the development
of p2pool (default: 0.5)
--iocp use Windows IOCP API in order to avoid errors due to
large number of sockets being open
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--no-bugreport disable submitting caught exceptions to the author
--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)
-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
--max-conns CONNS maximum incoming connections (default: 40)

worker interface:
-w PORT or ADDR:PORT, --worker-port PORT or ADDR:PORT
listen on PORT on interface with ADDR for RPC
connections from miners (default: all interfaces,
bitcoin:9332, litecoin:9327)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The pool began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:

For example, a bash script to donate 10 btc is:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany/10)"
</pre>

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.

Note that the amount you donate will be allocated to recent miners in proportion to the amount of work they've done in the last 24 hours or so, but all the miner whose shares of the donated amount are less than 0.01 BTC will have their shares combined into a single amount which is awarded to one of them at random, with the chance of winning this 'lottery' weighted by the miner's recent amount of work done. You can change this 0.01 BTC threshold like this, for example, which says to pay 10 BTC, but to share it amongst more miners that the default, cutting off at 0.001 BTC instead of at 0.01 BTC.
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany/10/0.001)"
</pre>

If you decide to donate you should announce it on the forums so that your donations provide the most incentive possible.

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support
* [http://p2pool.info/ p2pool.info] stats page
* [http://nodes.p2pmine.com nodes.p2pmine.com] Public list of P2Pool BTC/LTC nodes.

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2012-05-05T23:52:32Z

Forrestv: documented pseudoshare difficulty option

URGENT: All P2Pool miners must upgrade to P2Pool 0.11.0 as soon as possible! See [https://bitcointalk.org/index.php?topic=18313.0 the forum post]

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

<blockquote>P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 10 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target. Whenever a peer announces a new share found (new block in the P2Pool block chain), it is received by the other peers, and the other peers verify that this block contains payouts for all the previous miners who found a share (and announced it) that made it into the P2Pool share chain. This continues until some peer finds a block that has a difficulty that meets the Bitcoin network's difficulty target. This peer announces this block to the Bitcoin network and miners who have submitted shares for this block are paid in the generation transaction, proportionally to how many shares they have found in the last while. - Unknown author</blockquote>

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin and avoids the risk of hard to detect theft by pool operators.

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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization, some Bitcoin supporters donate to P2Pool miners, resulting in average returns above 100% of the expected reward.
However, it should be noted that there are other pools (such as [[BitPenny]] and [[Eligius]]) which can provide the same level of reduction of the power of the pool operator over the Bitcoin network, however, none can provide the guarantees against pool operator cheating that P2Pool can.

== 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, just as Bitcoin regulates it to generate one block every ten minutes.
This means that finding shares becomes more difficult (resulting in higher variance) the more people mine on P2Pool, though large miners have the option to raise their difficulty, and so reduce the impact of their mining on P2Pool's minimum difficulty.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640 (= 24 hours of shares), whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is 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 ===

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: edit bitcoin.conf to include:
rpcuser=USER
rpcpassword=LONG_RANDOM_SECRET_VALUE
server=1
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** 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
** Source: python run_p2pool.py
* Run a miner daemon with long polling connecting to 127.0.0.1 (or the IP of the host running p2pool if it isn't on the same computer as the miner) on port 9332 with any username and password
** cgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher (but not 3.x)
* python-argparse
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does cgminer report so many longpoll events when mining on p2pool? - P4Man" 
'''A:''' "Once every ~10 seconds is normal. That is how often p2pool shares are generated (as opposed to ~10 min for bitcoin blocks) - cabin"

'''Q:''' "Do the 'orphan' and 'dead' shares in P2Pool's status display hurt me?" 
'''A:''' They shouldn't - It's normal for some fraction of everyone's shares to end up orphaned or dead. Because payouts are calculated by counting how many shares you have relative to others, everyone with normal configurations is equally "hurt" by this. However, if you have a large proportion of stales, your payout will be hurt. You can see how well you're doing by looking at P2Pool's "Efficiency" (ex: ''Efficiency: ~110.6% (40-111%)''). If 100% doesn't lie within the [http://en.wikipedia.org/wiki/Confidence_interval confidence interval] at the end, something is probably wrong (with 95% confidence).

'''Q:''' "What do I do if my efficiency is low?" 
'''A:''' Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. If you have a lot of dead shares or the "Local dead on arrival" number is higher than a few percent, that means that something is wrong with your miner. Check to make sure that it is one of the working versions in the ''Miners'' section on this page. Lower the intensity or raise the FPS of your miner. If you have a lot of orphan shares, something is wrong with P2Pool's P2P connection. Decrease the load on your internet connection or enable QoS (Quality of Service) on your router.

'''Q:''' What is PPLNS? 
'''A:''' Pay-Per-Last-N-Shares is a payout method that is completely resistant to pool hoppers.

'''Q:''' Why am I not getting very many shares?! 
'''A:''' The P2Pool difficulty is hundreds of times higher than on other pools. It can take time to get a share. P2Pool displays an estimate of how long you have to wait in the console output.

'''Q:''' Why does my miner say it has found a lot of shares but p2pool say I have only found a few?! 
'''A:''' The real P2Pool difficulty is hundreds of times higher than on normal pools, but p2pool essentially lies to your miner and tells it to work on relatively easy shares so that it submits shares every few seconds instead of every few hours. P2Pool then ignores any submitted shares that don't match the real share difficulty. By doing this, P2Pool can more accurately report your local hash rate and you can see if you are having problems with too many stale shares quickly

'''Q:''' Why am I getting so many rejects? 
'''A:''' You're using an incompatible miner. See the miners section here, increase your FPS on the miner, decrease the intensity, upgrade your miner, or try a different miner.

'''Q:''' What stops the pool operator or the block finder from stealing a block? 
'''A:''' A block solution is only worth anything because its hash matches Bitcoin's target. Altering anything within the block will change its hash and make it worthless. If you are concerned about the pool operator stealing a block, you should try to inspect the source code of each new version.

'''Q:''' Why does it say "Generated?" I want to spend my coins now! 
'''A:''' P2Pool includes payouts in generation transactions, which must mature (taking 120 blocks or 20 hours) before they can be spent. The reason for this is that a block could be orphaned, which would make its payout invalid and could reverse transactions.

'''Q:''' Do I get paid transaction fees? 
'''A:''' Yes. They are split among P2Pool miners.

'''Q:''' What are these payments I'm getting that aren't generated? 
'''A:''' These are subsidies that people who support the idea of P2Pool send to miners.

'''Q:''' Cool Subsidies sound like an awesome idea! How do I send some BTC to these awesome miners? 
'''A:''' See end of this page.

'''Q:''' Do I really need the WHOLE blockchain? 
'''A:''' Yes. Your node needs to be able to independently make decisions about what transactions to mine.

'''Q:''' How do merged mining payments work? 
'''A:''' Merged mining is handled entirely by namecoind, so you're solo mining and payouts will go into namecoind's wallet.

=== 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 intensity (8 for cgminer?) helps a lot with reducing stales.

* cgminer works perfectly without any extra options. However, using multiple pools might cause problems, because long polling is only done for one pool.
* ufasoft works perfectly.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seamless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.
* You can make P2Pool use a configuration file by running run_p2pool.py @FILENAME, with FILENAME being the path to a file containing the command-line arguments (newlines are ignored) Example:
<pre>
--net litecoin
-n 1.2.3.4
</pre>
* Setting the username of your miner connecting to P2Pool to a Bitcoin address will make it mine to that address instead of the one requested from bitcoind or set by -a
* Appending "/1000" to a miner's username will increase the difficulty of producing a P2Pool share to at most 1000. This is useful to large miners because doing this can make it easier for small miners while minimally impacting the large miners themselves. See [https://bitcointalk.org/index.php?topic=18313.msg816322#msg816322 recommended values].
** Appending "+1" (for example) after that will make P2Pool always give your miners work with a difficulty of 1

=== Web interface ===

Lots of data and useful tools are available at http://127.0.0.1:9332/something:
* /static/ - Lots of information from shares to graphs to payouts.
* /rate
* /users
* /fee
* /current_payouts
* /patron_sendmany - Gives sendmany outputs for fair donations to P2Pool
* /global_stats
* /local_stats
* /peer_addresses
* /payout_addr
* /recent_blocks
* /uptime
* /web/log - Some different stats collected over the last day

=== Included README ===
<pre>
Requirements:
Generic:
Bitcoin >=0.5.0 or Litecoin
Python
Twisted
python-argparse (for Python <=2.6)

Linux:
sudo apt-get install python-zope.interface python-twisted python-twisted-web
sudo apt-get install python-argparse # if on Python 2.6 or older

Windows:
Install Python 2.7: http://www.python.org/getit/
Install Twisted: http://twistedmatrix.com/trac/wiki/Downloads
Install Zope.Interface: http://pypi.python.org/pypi/zope.interface/3.8.0
Unzip the files into C:\Python27\Lib\site-packages

Running P2Pool:
To use P2Pool, you must be running your own local bitcoind. For standard
configurations, using P2Pool should be as simple as:

python run_p2pool.py

Then run your miner program, connecting to 127.0.0.1 on port 9332 with any
username and password.

If you are behind a NAT, you should enable TCP port forwarding on your
router. Forward port 9333 to the host running P2Pool.

Run "python run_p2pool.py --help" for additional options.

Notes for Litecoin:
Requirements:
In order to run P2Pool with the Litecoin network, you would need to build and install the
ltc_scrypt module that includes the scrypt proof of work code that Litecoin uses for hashes.

Linux:
cd litecoin_scrypt
sudo python setup.py install

Windows:
Install MinGW: http://www.mingw.org/wiki/Getting_Started
Install Python 2.7: http://www.python.org/getit/

cd litecoin_scrypt
C:\Python27\python.exe setup.py build --compile=mingw32 install

If you run into an error with unrecognized command line option '-mno-cygwin', see this:
http://stackoverflow.com/questions/6034390/compiling-with-cython-and-mingw-produces-gcc-error-unrecognized-command-line-o

Running P2Pool:
Run P2Pool with the "--net litecoin" option.
Run your miner program, connecting to 127.0.0.1 on port 9327.
Forward port 9338 to the host running P2Pool.

Litecoin's use of ports 9332 and 9332 conflicts with P2Pool running on
the Bitcoin network. To avoid problems, add these lines to litecoin.conf
and restart litecoind:
rpcport=10332
port=10333
</pre>

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin, litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--merged-url MERGED_URL]
[--merged-userpass MERGED_USERPASS]
[--give-author DONATION_PERCENTAGE] [--irc-announce]
[--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_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version 28a1948)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin, litecoin}
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>)
--datadir DATADIR store data in this directory (default: <directory
run_p2pool.py is in>/data)
--logfile LOGFILE log to this file (default: data/<NET>/log)
--merged MERGED_URLS call getauxblock on this url to get work for merged
mining (example:
http://ncuser:ncpass@127.0.0.1:10332/)
--merged-url MERGED_URL
DEPRECATED, use --merged
--merged-userpass MERGED_USERPASS
DEPRECATED, use --merged
--give-author DONATION_PERCENTAGE
donate this percentage of work to author of p2pool
(default: 0.5)
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--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)
-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)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The pool began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:

For example, a bash script to donate 10 btc is:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany/10)"
</pre>

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.

Note that the amount you donate will be allocated to recent miners in proportion to the amount of work they've done in the last 24 hours or so, but all the miner whose shares of the donated amount are less than 0.01 BTC will have their shares combined into a single amount which is awarded to one of them at random, with the chance of winning this 'lottery' weighted by the miner's recent amount of work done. You can change this 0.01 BTC threshold like this, for example, which says to pay 10 BTC, but to share it amongst more miners that the default, cutting off at 0.001 BTC instead of at 0.01 BTC.
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany/10/0.001)"
</pre>

If you decide to donate you should announce it on the forums so that your donations provide the most incentive possible.

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support
* [http://p2pool.info/ p2pool.info] stats page
* [http://nodes.p2pmine.com nodes.p2pmine.com] Public list of P2Pool BTC/LTC nodes.

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2012-05-03T05:11:34Z

Forrestv: updated warning to 0.11.0

URGENT: All P2Pool miners must upgrade to P2Pool 0.11.0 as soon as possible! See [https://bitcointalk.org/index.php?topic=18313.0 the forum post]

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

<blockquote>P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 10 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target. Whenever a peer announces a new share found (new block in the P2Pool block chain), it is received by the other peers, and the other peers verify that this block contains payouts for all the previous miners who found a share (and announced it) that made it into the P2Pool share chain. This continues until some peer finds a block that has a difficulty that meets the Bitcoin network's difficulty target. This peer announces this block to the Bitcoin network and miners who have submitted shares for this block are paid in the generation transaction, proportionally to how many shares they have found in the last while. - Unknown author</blockquote>

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin and avoids the risk of hard to detect theft by pool operators.

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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization, some Bitcoin supporters donate to P2Pool miners, resulting in average returns above 100% of the expected reward.
However, it should be noted that there are other pools (such as [[BitPenny]] and [[Eligius]]) which can provide the same level of reduction of the power of the pool operator over the Bitcoin network, however, none can provide the guarantees against pool operator cheating that P2Pool can.

== 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, just as Bitcoin regulates it to generate one block every ten minutes.
This means that finding shares becomes more difficult (resulting in higher variance) the more people mine on P2Pool, though large miners have the option to raise their difficulty, and so reduce the impact of their mining on P2Pool's minimum difficulty.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640 (= 24 hours of shares), whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is 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 ===

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: edit bitcoin.conf to include:
rpcuser=USER
rpcpassword=LONG_RANDOM_SECRET_VALUE
server=1
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** 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
** Source: python run_p2pool.py
* Run a miner daemon with long polling connecting to 127.0.0.1 (or the IP of the host running p2pool if it isn't on the same computer as the miner) on port 9332 with any username and password
** cgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher (but not 3.x)
* python-argparse
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does cgminer report so many longpoll events when mining on p2pool? - P4Man" 
'''A:''' "Once every ~10 seconds is normal. That is how often p2pool shares are generated (as opposed to ~10 min for bitcoin blocks) - cabin"

'''Q:''' "Do the 'orphan' and 'dead' shares in P2Pool's status display hurt me?" 
'''A:''' They shouldn't - It's normal for some fraction of everyone's shares to end up orphaned or dead. Because payouts are calculated by counting how many shares you have relative to others, everyone with normal configurations is equally "hurt" by this. However, if you have a large proportion of stales, your payout will be hurt. You can see how well you're doing by looking at P2Pool's "Efficiency" (ex: ''Efficiency: ~110.6% (40-111%)''). If 100% doesn't lie within the [http://en.wikipedia.org/wiki/Confidence_interval confidence interval] at the end, something is probably wrong (with 95% confidence).

'''Q:''' "What do I do if my efficiency is low?" 
'''A:''' Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. If you have a lot of dead shares or the "Local dead on arrival" number is higher than a few percent, that means that something is wrong with your miner. Check to make sure that it is one of the working versions in the ''Miners'' section on this page. Lower the intensity or raise the FPS of your miner. If you have a lot of orphan shares, something is wrong with P2Pool's P2P connection. Decrease the load on your internet connection or enable QoS (Quality of Service) on your router.

'''Q:''' What is PPLNS? 
'''A:''' Pay-Per-Last-N-Shares is a payout method that is completely resistant to pool hoppers.

'''Q:''' Why am I not getting very many shares?! 
'''A:''' The P2Pool difficulty is hundreds of times higher than on other pools. It can take time to get a share. P2Pool displays an estimate of how long you have to wait in the console output.

'''Q:''' Why does my miner say it has found a lot of shares but p2pool say I have only found a few?! 
'''A:''' The real P2Pool difficulty is hundreds of times higher than on normal pools, but p2pool essentially lies to your miner and tells it to work on relatively easy shares so that it submits shares every few seconds instead of every few hours. P2Pool then ignores any submitted shares that don't match the real share difficulty. By doing this, P2Pool can more accurately report your local hash rate and you can see if you are having problems with too many stale shares quickly

'''Q:''' Why am I getting so many rejects? 
'''A:''' You're using an incompatible miner. See the miners section here, increase your FPS on the miner, decrease the intensity, upgrade your miner, or try a different miner.

'''Q:''' What stops the pool operator or the block finder from stealing a block? 
'''A:''' A block solution is only worth anything because its hash matches Bitcoin's target. Altering anything within the block will change its hash and make it worthless. If you are concerned about the pool operator stealing a block, you should try to inspect the source code of each new version.

'''Q:''' Why does it say "Generated?" I want to spend my coins now! 
'''A:''' P2Pool includes payouts in generation transactions, which must mature (taking 120 blocks or 20 hours) before they can be spent. The reason for this is that a block could be orphaned, which would make its payout invalid and could reverse transactions.

'''Q:''' Do I get paid transaction fees? 
'''A:''' Yes. They are split among P2Pool miners.

'''Q:''' What are these payments I'm getting that aren't generated? 
'''A:''' These are subsidies that people who support the idea of P2Pool send to miners.

'''Q:''' Cool Subsidies sound like an awesome idea! How do I send some BTC to these awesome miners? 
'''A:''' See end of this page.

'''Q:''' Do I really need the WHOLE blockchain? 
'''A:''' Yes. Your node needs to be able to independently make decisions about what transactions to mine.

'''Q:''' How do merged mining payments work? 
'''A:''' Merged mining is handled entirely by namecoind, so you're solo mining and payouts will go into namecoind's wallet.

=== 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 intensity (8 for cgminer?) helps a lot with reducing stales.

* cgminer works perfectly without any extra options. However, using multiple pools might cause problems, because long polling is only done for one pool.
* ufasoft works perfectly.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seamless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.
* You can make P2Pool use a configuration file by running run_p2pool.py @FILENAME, with FILENAME being the path to a file containing the command-line arguments (newlines are ignored) Example:
<pre>
--net litecoin
-n 1.2.3.4
</pre>
* Setting the username of your miner connecting to P2Pool to a Bitcoin address will make it mine to that address instead of the one requested from bitcoind or set by -a
* Appending "/1000" to a miner's username will increase the difficulty of producing a P2Pool share to at most 1000. This is useful to large miners because doing this can make it easier for small miners while minimally impacting the large miners themselves. See [https://bitcointalk.org/index.php?topic=18313.msg816322#msg816322 recommended values].

=== Web interface ===

Lots of data and useful tools are available at http://127.0.0.1:9332/something:
* /static/ - Lots of information from shares to graphs to payouts.
* /rate
* /users
* /fee
* /current_payouts
* /patron_sendmany - Gives sendmany outputs for fair donations to P2Pool
* /global_stats
* /local_stats
* /peer_addresses
* /payout_addr
* /recent_blocks
* /uptime
* /web/log - Some different stats collected over the last day

=== Included README ===
<pre>
Requirements:
Generic:
Bitcoin >=0.5.0 or Litecoin
Python
Twisted
python-argparse (for Python <=2.6)

Linux:
sudo apt-get install python-zope.interface python-twisted python-twisted-web
sudo apt-get install python-argparse # if on Python 2.6 or older

Windows:
Install Python 2.7: http://www.python.org/getit/
Install Twisted: http://twistedmatrix.com/trac/wiki/Downloads
Install Zope.Interface: http://pypi.python.org/pypi/zope.interface/3.8.0
Unzip the files into C:\Python27\Lib\site-packages

Running P2Pool:
To use P2Pool, you must be running your own local bitcoind. For standard
configurations, using P2Pool should be as simple as:

python run_p2pool.py

Then run your miner program, connecting to 127.0.0.1 on port 9332 with any
username and password.

If you are behind a NAT, you should enable TCP port forwarding on your
router. Forward port 9333 to the host running P2Pool.

Run "python run_p2pool.py --help" for additional options.

Notes for Litecoin:
Requirements:
In order to run P2Pool with the Litecoin network, you would need to build and install the
ltc_scrypt module that includes the scrypt proof of work code that Litecoin uses for hashes.

Linux:
cd litecoin_scrypt
sudo python setup.py install

Windows:
Install MinGW: http://www.mingw.org/wiki/Getting_Started
Install Python 2.7: http://www.python.org/getit/

cd litecoin_scrypt
C:\Python27\python.exe setup.py build --compile=mingw32 install

If you run into an error with unrecognized command line option '-mno-cygwin', see this:
http://stackoverflow.com/questions/6034390/compiling-with-cython-and-mingw-produces-gcc-error-unrecognized-command-line-o

Running P2Pool:
Run P2Pool with the "--net litecoin" option.
Run your miner program, connecting to 127.0.0.1 on port 9327.
Forward port 9338 to the host running P2Pool.

Litecoin's use of ports 9332 and 9332 conflicts with P2Pool running on
the Bitcoin network. To avoid problems, add these lines to litecoin.conf
and restart litecoind:
rpcport=10332
port=10333
</pre>

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin, litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--merged-url MERGED_URL]
[--merged-userpass MERGED_USERPASS]
[--give-author DONATION_PERCENTAGE] [--irc-announce]
[--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_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version 28a1948)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin, litecoin}
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>)
--datadir DATADIR store data in this directory (default: <directory
run_p2pool.py is in>/data)
--logfile LOGFILE log to this file (default: data/<NET>/log)
--merged MERGED_URLS call getauxblock on this url to get work for merged
mining (example:
http://ncuser:ncpass@127.0.0.1:10332/)
--merged-url MERGED_URL
DEPRECATED, use --merged
--merged-userpass MERGED_USERPASS
DEPRECATED, use --merged
--give-author DONATION_PERCENTAGE
donate this percentage of work to author of p2pool
(default: 0.5)
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--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)
-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)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The pool began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:

For example, a bash script to donate 10 btc is:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany/10)"
</pre>

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.

Note that the amount you donate will be allocated to recent miners in proportion to the amount of work they've done in the last 24 hours or so, but all the miner whose shares of the donated amount are less than 0.01 BTC will have their shares combined into a single amount which is awarded to one of them at random, with the chance of winning this 'lottery' weighted by the miner's recent amount of work done. You can change this 0.01 BTC threshold like this, for example, which says to pay 10 BTC, but to share it amongst more miners that the default, cutting off at 0.001 BTC instead of at 0.01 BTC.
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany/10/0.001)"
</pre>

If you decide to donate you should announce it on the forums so that your donations provide the most incentive possible.

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support
* [http://p2pool.info/ p2pool.info] stats page
* [http://nodes.p2pmine.com nodes.p2pmine.com] Public list of P2Pool BTC/LTC nodes.

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2012-05-02T05:29:47Z

Forrestv: clarified "other pools" note :)

URGENT: All P2Pool miners must upgrade to P2Pool 0.10.3 before April 1st! See [https://bitcointalk.org/index.php?topic=18313.0 the forum post]

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

<blockquote>P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 10 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target. Whenever a peer announces a new share found (new block in the P2Pool block chain), it is received by the other peers, and the other peers verify that this block contains payouts for all the previous miners who found a share (and announced it) that made it into the P2Pool share chain. This continues until some peer finds a block that has a difficulty that meets the Bitcoin network's difficulty target. This peer announces this block to the Bitcoin network and miners who have submitted shares for this block are paid in the generation transaction, proportionally to how many shares they have found in the last while. - Unknown author</blockquote>

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin and avoids the risk of hard to detect theft by pool operators.

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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization, some Bitcoin supporters donate to P2Pool miners, resulting in average returns above 100% of the expected reward.
However, it should be noted that there are other pools (such as [[BitPenny]] and [[Eligius]]) which can provide the same level of reduction of the power of the pool operator over the Bitcoin network, however, none can provide the guarantees against pool operator cheating that P2Pool can.

== 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, just as Bitcoin regulates it to generate one block every ten minutes.
This means that finding shares becomes more difficult (resulting in higher variance) the more people mine on P2Pool, though large miners have the option to raise their difficulty, and so reduce the impact of their mining on P2Pool's minimum difficulty.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640 (= 24 hours of shares), whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is 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 ===

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: edit bitcoin.conf to include:
rpcuser=USER
rpcpassword=LONG_RANDOM_SECRET_VALUE
server=1
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** 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
** Source: python run_p2pool.py
* Run a miner daemon with long polling connecting to 127.0.0.1 (or the IP of the host running p2pool if it isn't on the same computer as the miner) on port 9332 with any username and password
** cgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher (but not 3.x)
* python-argparse
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does cgminer report so many longpoll events when mining on p2pool? - P4Man" 
'''A:''' "Once every ~10 seconds is normal. That is how often p2pool shares are generated (as opposed to ~10 min for bitcoin blocks) - cabin"

'''Q:''' "Do the 'orphan' and 'dead' shares in P2Pool's status display hurt me?" 
'''A:''' They shouldn't - It's normal for some fraction of everyone's shares to end up orphaned or dead. Because payouts are calculated by counting how many shares you have relative to others, everyone with normal configurations is equally "hurt" by this. However, if you have a large proportion of stales, your payout will be hurt. You can see how well you're doing by looking at P2Pool's "Efficiency" (ex: ''Efficiency: ~110.6% (40-111%)''). If 100% doesn't lie within the [http://en.wikipedia.org/wiki/Confidence_interval confidence interval] at the end, something is probably wrong (with 95% confidence).

'''Q:''' "What do I do if my efficiency is low?" 
'''A:''' Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. If you have a lot of dead shares or the "Local dead on arrival" number is higher than a few percent, that means that something is wrong with your miner. Check to make sure that it is one of the working versions in the ''Miners'' section on this page. Lower the intensity or raise the FPS of your miner. If you have a lot of orphan shares, something is wrong with P2Pool's P2P connection. Decrease the load on your internet connection or enable QoS (Quality of Service) on your router.

'''Q:''' What is PPLNS? 
'''A:''' Pay-Per-Last-N-Shares is a payout method that is completely resistant to pool hoppers.

'''Q:''' Why am I not getting very many shares?! 
'''A:''' The P2Pool difficulty is hundreds of times higher than on other pools. It can take time to get a share. P2Pool displays an estimate of how long you have to wait in the console output.

'''Q:''' Why does my miner say it has found a lot of shares but p2pool say I have only found a few?! 
'''A:''' The real P2Pool difficulty is hundreds of times higher than on normal pools, but p2pool essentially lies to your miner and tells it to work on relatively easy shares so that it submits shares every few seconds instead of every few hours. P2Pool then ignores any submitted shares that don't match the real share difficulty. By doing this, P2Pool can more accurately report your local hash rate and you can see if you are having problems with too many stale shares quickly

'''Q:''' Why am I getting so many rejects? 
'''A:''' You're using an incompatible miner. See the miners section here, increase your FPS on the miner, decrease the intensity, upgrade your miner, or try a different miner.

'''Q:''' What stops the pool operator or the block finder from stealing a block? 
'''A:''' A block solution is only worth anything because its hash matches Bitcoin's target. Altering anything within the block will change its hash and make it worthless. If you are concerned about the pool operator stealing a block, you should try to inspect the source code of each new version.

'''Q:''' Why does it say "Generated?" I want to spend my coins now! 
'''A:''' P2Pool includes payouts in generation transactions, which must mature (taking 120 blocks or 20 hours) before they can be spent. The reason for this is that a block could be orphaned, which would make its payout invalid and could reverse transactions.

'''Q:''' Do I get paid transaction fees? 
'''A:''' Yes. They are split among P2Pool miners.

'''Q:''' What are these payments I'm getting that aren't generated? 
'''A:''' These are subsidies that people who support the idea of P2Pool send to miners.

'''Q:''' Cool Subsidies sound like an awesome idea! How do I send some BTC to these awesome miners? 
'''A:''' See end of this page.

'''Q:''' Do I really need the WHOLE blockchain? 
'''A:''' Yes. Your node needs to be able to independently make decisions about what transactions to mine.

'''Q:''' How do merged mining payments work? 
'''A:''' Merged mining is handled entirely by namecoind, so you're solo mining and payouts will go into namecoind's wallet.

=== 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 intensity (8 for cgminer?) helps a lot with reducing stales.

* cgminer works perfectly without any extra options. However, using multiple pools might cause problems, because long polling is only done for one pool.
* ufasoft works perfectly.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seamless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.
* You can make P2Pool use a configuration file by running run_p2pool.py @FILENAME, with FILENAME being the path to a file containing the command-line arguments (newlines are ignored) Example:
<pre>
--net litecoin
-n 1.2.3.4
</pre>
* Setting the username of your miner connecting to P2Pool to a Bitcoin address will make it mine to that address instead of the one requested from bitcoind or set by -a
* Appending "/1000" to a miner's username will increase the difficulty of producing a P2Pool share to at most 1000. This is useful to large miners because doing this can make it easier for small miners while minimally impacting the large miners themselves. See [https://bitcointalk.org/index.php?topic=18313.msg816322#msg816322 recommended values].

=== Web interface ===

Lots of data and useful tools are available at http://127.0.0.1:9332/something:
* /static/ - Lots of information from shares to graphs to payouts.
* /rate
* /users
* /fee
* /current_payouts
* /patron_sendmany - Gives sendmany outputs for fair donations to P2Pool
* /global_stats
* /local_stats
* /peer_addresses
* /payout_addr
* /recent_blocks
* /uptime
* /web/log - Some different stats collected over the last day

=== Included README ===
<pre>
Requirements:
Generic:
Bitcoin >=0.5.0 or Litecoin
Python
Twisted
python-argparse (for Python <=2.6)

Linux:
sudo apt-get install python-zope.interface python-twisted python-twisted-web
sudo apt-get install python-argparse # if on Python 2.6 or older

Windows:
Install Python 2.7: http://www.python.org/getit/
Install Twisted: http://twistedmatrix.com/trac/wiki/Downloads
Install Zope.Interface: http://pypi.python.org/pypi/zope.interface/3.8.0
Unzip the files into C:\Python27\Lib\site-packages

Running P2Pool:
To use P2Pool, you must be running your own local bitcoind. For standard
configurations, using P2Pool should be as simple as:

python run_p2pool.py

Then run your miner program, connecting to 127.0.0.1 on port 9332 with any
username and password.

If you are behind a NAT, you should enable TCP port forwarding on your
router. Forward port 9333 to the host running P2Pool.

Run "python run_p2pool.py --help" for additional options.

Notes for Litecoin:
Requirements:
In order to run P2Pool with the Litecoin network, you would need to build and install the
ltc_scrypt module that includes the scrypt proof of work code that Litecoin uses for hashes.

Linux:
cd litecoin_scrypt
sudo python setup.py install

Windows:
Install MinGW: http://www.mingw.org/wiki/Getting_Started
Install Python 2.7: http://www.python.org/getit/

cd litecoin_scrypt
C:\Python27\python.exe setup.py build --compile=mingw32 install

If you run into an error with unrecognized command line option '-mno-cygwin', see this:
http://stackoverflow.com/questions/6034390/compiling-with-cython-and-mingw-produces-gcc-error-unrecognized-command-line-o

Running P2Pool:
Run P2Pool with the "--net litecoin" option.
Run your miner program, connecting to 127.0.0.1 on port 9327.
Forward port 9338 to the host running P2Pool.

Litecoin's use of ports 9332 and 9332 conflicts with P2Pool running on
the Bitcoin network. To avoid problems, add these lines to litecoin.conf
and restart litecoind:
rpcport=10332
port=10333
</pre>

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin, litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--merged-url MERGED_URL]
[--merged-userpass MERGED_USERPASS]
[--give-author DONATION_PERCENTAGE] [--irc-announce]
[--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_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version 28a1948)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin, litecoin}
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>)
--datadir DATADIR store data in this directory (default: <directory
run_p2pool.py is in>/data)
--logfile LOGFILE log to this file (default: data/<NET>/log)
--merged MERGED_URLS call getauxblock on this url to get work for merged
mining (example:
http://ncuser:ncpass@127.0.0.1:10332/)
--merged-url MERGED_URL
DEPRECATED, use --merged
--merged-userpass MERGED_USERPASS
DEPRECATED, use --merged
--give-author DONATION_PERCENTAGE
donate this percentage of work to author of p2pool
(default: 0.5)
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--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)
-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)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The pool began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:

For example, a bash script to donate 10 btc is:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany/10)"
</pre>

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.

Note that the amount you donate will be allocated to recent miners in proportion to the amount of work they've done in the last 24 hours or so, but all the miner whose shares of the donated amount are less than 0.01 BTC will have their shares combined into a single amount which is awarded to one of them at random, with the chance of winning this 'lottery' weighted by the miner's recent amount of work done. You can change this 0.01 BTC threshold like this, for example, which says to pay 10 BTC, but to share it amongst more miners that the default, cutting off at 0.001 BTC instead of at 0.01 BTC.
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany/10/0.001)"
</pre>

If you decide to donate you should announce it on the forums so that your donations provide the most incentive possible.

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support
* [http://p2pool.info/ p2pool.info] stats page
* [http://nodes.p2pmine.com nodes.p2pmine.com] Public list of P2Pool BTC/LTC nodes.

==References==
<references />

[[Category:Pool Operators]]

Alternative chain

2012-04-14T02:19:23Z

Forrestv: added note to "Generalized proof of work"

An '''alternative chain''' is a system using the block chain algorithm to achieve distributed consensus on a particular topic. Alternative chains may share miners with a '''parent''' network such as Bitcoin's; this is called '''merged mining'''. Alternative chains have been suggested as ways to implement DNS, SSL certificate authorities, timestamping, file storage and voting systems.

== Objective ==

Bitcoin uses the [[block chain]] algorithm to achieve distributed consensus on who owns what coins. Block chains were invented specifically for the Bitcoin project but they can be applied anywhere a distributed consensus needs to be established in the presence of malicious or untrustworthy actors.

Whilst it's possible to abuse the Bitcoin financial block chain for other purposes, it's better to set up an alternative network and chain which share the same miners. There are several reasons to do this.

* The block chain is a large, complex data structure shared between many people. Verifying its integrity requires many slow (and thus expensive) operations like ECDSA verifications and disk seeks. Everyone who takes part in Bitcoin today runs a node and thus maintains the whole thing. Whilst in future end-users will probably use more efficient but slightly less secure modes (SPV), merchants and miners will probably always pay the full costs for the upkeep of this shared data structure. All these people today are united by a common interest in a new form of payments. They may or may not also be interested in other schemes. So one reason to keep the Bitcoin chain for finance is it's unfair to externalize the costs of unrelated schemes onto people who are interested only in payments - the canonical example being merchants. Increasing the cost of accepting Bitcoins for goods and services hurts everyone who uses the system by reducing the number of merchants or increasing their costs.

* Another reason is that it's just bad engineering to cram every possible distributed quorum into the design constraints of Bitcoin. The transaction format Bitcoin uses is flexible but ultimately designed for finance. You cannot leave out the "value" field. It's always there, even if it'd make no sense for your particular application. Building non-financial applications on top of a financial system results in bizarre protocols and code that are difficult to understand, leading to maintainability problems.

* One final reason is that [[Satoshi Nakamoto|Satoshi]] was opposed to putting non-Bitcoin related data into the main chain. As creator of the system, his opinion should carry a lot of weight with anyone serious about extending it.

=== Designing a new network ===

To create a new network that uses Nakamoto block chains, you need to start by defining what a transaction in your new network means. Bitcoin transactions split and combine value using scripts, but yours don't have to do that. They could be anything. Here's an example of a simple DNS style "transaction" described using [http://code.google.com/p/protobuf/ Google protocol buffers] syntax.

message NameTx {
required string name = 1;
repeated bytes ip_addresses = 2;
required bytes pubkey = 3;
enum ClaimType {
NEW_NAME,
TRANSFER
}
required ClaimType type = 4;

// Only used if type == TRANSFER. The new owner of the name and signature proving current ownership.
optional bytes dest_pubkey = 5;
optional bytes signature = 6;
}

This is very different to a Bitcoin style transaction. There's no concept of inputs, outputs, addresses, values or scripts. It's got what you need for a very simple DNS style scheme (that lacks abuse controls etc) and nothing more. There's also no concept of a "coinbase" transaction.

The block definition is also up to you. It does not have to be formatted in the same way as Satoshi chose, but you need most of the same conceptual parts. You also need to store something else, some data from Bitcoin. Here's a minimal example of what's needed:

message MyBlock {
required bytes prev_block_hash = 1;
required uint32 difficulty = 2;
required uint32 time = 3;

repeated MyTx transactions = 4;
}

message SuperBlock {
required MyBlock my_data = 1;
required BitcoinData bitcoin_data = 2;
}

It's important to observe what we don't have as well as what we do. We don't have the following fields from Satoshis format:

# version: protobufs handles the versioning of binary data formats for us
# merkle root: you can choose to arrange your transactions into a merkle root if you like, so you can use the same disk space reclamation trick Satoshi did. But it's strictly optional. If you want to simplify things down you can skip it.
# nonce

== Sharing work ==

The bitcoin_data field is how you share work with miners today (assuming they opt in by installing your software alongside their bitcoin node). It's defined like this:

message BitcoinData {
// A Bitcoin format block header. Because it's in Satoshis custom format we represent this as a byte array.
required bytes header = 1;

// The first transaction from the block.
required bytes coinbase_tx = 2;

// The merkle branch linking the coinbase transaction to the header.
required bytes coinbase_merkle_branch = 3;

// The coinbase scriptSig contains bits of data in order. Which one is our hash?
required int coinbase_tx_index = 4;
}

All you need to share work is the above four things.

A [[wikipedia:Merkle tree|merkle tree]] is a data structure in which each node in the tree is a hash. The leaf nodes are hashes of the things you want to include in the tree. The interior nodes are hashes of the concatenations of the child nodes. A merkle branch is a part of a merkle tree which allows you to cryptographically prove that something you're given was in the tree, without needing everything that was in the tree. They are calculated by the CBlock::GetMerkleBranch() function in the Bitcoin code.

We store a merkle branch here for efficiency. It means no matter how large the current Bitcoin block is, your alternative network only needs to handle a small amount of data. You could just store the entire Bitcoin block - that would be simpler but inefficient.

The merkle branch links the coinbase transaction to the block header, so you can prove it was in that block. The coinbase TX is a regular Bitcoin coinbase (that makes new coins and claims fees), except the scriptSig on its input contains an extra entry that todays scriptSigs don't. That extra entry is a hash of your block structure. The coinbase scriptSig today is formatted like this:

void IncrementExtraNonce(CBlock* pblock, CBlockIndex* pindexPrev, unsigned int& nExtraNonce, int64& nPrevTime)
{
.....
pblock->vtx[0].vin[0].scriptSig = CScript() << pblock->nBits << CBigNum(nExtraNonce);
.....
}

Just the difficulty bits and the "extra nonce". But it's actually allowed to contain anything, as long as it's not too big. So in your new blocks it'd be:

<MyBlock hash> <nBits> <nExtraNonce>

To get the MyBlock hash into Bitcoin requires a presently unimplemented RPC command, "setextrahashes". It'd update a global list and the IncrementExtraNonce function would include the extra hashes when the scriptSig is built. This is a very simple change to Bitcoin.

In the scriptSig above the coinbase_tx_index would be zero. It's possible to work on an arbitrary number of alternative chains simultaneously:

<MyBlock hash> <SomeOtherChainBlock hash> <nBits> <nExtraNonce>

in which case the BitcoinData message for SomeOtherChain would be 1 rather than zero.

A more complex change is the other new RPC. Because you have your own chain, it has its own difficulty. Most likely it'll be different to Bitcoins own. So you need a way to tell Bitcoin "when you find a block that matches an extradifficulty, please let me know". To mine on multiple difficulties at once, the node vends work (via getwork) matching the easiest difficulty. When a miner reports finding a solution the difficulty is checked to see which chains it is sufficiently difficult for.

Important note: Your chain has its own difficulty and as such the block creation rate is independent of how much mining takes place.

== Independent node software ==

Your new network has its own codebase. It can be written in whatever language you like, use whatever P2P protocol you like, store its data however you like and so on.

When a node on your network receives a message informing it about a new transaction, it verifies that transaction follows the rules of your network. To use our simple DNS example it would verify that if you're claiming a new name, it doesn't already exist and if you're transferring a name that the signatures are correct.

If the transaction is valid, it's added to your current MyBlock message. That message is serialized to binary (protobufs does this for you), hashed and then your node makes an RPC to Bitcoin telling it what the current extra hash is. When Bitcoin finds a Bitcoin-format block of the right difficulty for your network, it informs your software and passes the block header, coinbase transaction and merkle branch to it. Your node combines them together into a BitcoinData message, which is then glued together with your alternative chains block. This "superblock" is then broadcast via your independent P2P network.

When a node on your new network receives a superblock it does the following things:

# Verifies the MyBlock contents are correct, ie, that the transactions follow the rules.
# Verifies that the MyBlock prev hash makes it fit somewhere in the chain and that the difficulty is correct.
# Hashes the MyBlock structure and then verifies that this hash appears in the BitcoinData coinbase scriptSig, in the right place.
# Extracts the merkle root of the Bitcoin format block from the header and then verifies that the coinbase tx provided did, in fact, exist in that block (using the branch, root, tx and header together).
# Verifies that the hash of the Bitcoin format block header is below the difficulty found in the MyBlock structure.

You've now verified that a sufficiently hard proof of work was done over the contents of the MyBlock structure, so your node can relay the newly found block (or if you don't use a P2P network make it available on your server, etc).

On the other side when Bitcoin finds a block that is correct for the Bitcoin network and chain, it broadcasts it and obviously the hash of your MyBlock is included. Fortunately this is only an additional 33 bytes overhead so nobody cares about it - the pollution of the financial chain is both trivial and constant. Note that regular Bitcoin nodes just ignore this extra hash, it doesn't mean anything to them.

== Handling your new block chain ==

You have to handle re-organizations. This is a standard part of the block chain algorithm. When a re-org occurs you have to verify that the state of your world still makes sense. For example in the new chain maybe somebody else now owns a resource you thought you owned. It's up to you how to inform your users of these events and what app specific logic is appropriate here.

You can choose your own parameters for the new chain. As an example, Satoshi chose to target one new block every ten minutes as a tradeoff between latency and wasted work. You could choose something much larger (hours, days) or much faster if you're willing to tolerate more splits due to blocks being found simultaneously. Bitcoin retargets the difficulty roughly every two weeks. You could choose some other length of time.

To store the block chain, Satoshi chose to use Berkeley DB as a way to index from transactions to the blocks they appeared in (amongst other things). You could use any database you liked.

== Paying for resources on alternative chains with Bitcoins ==

A commonly cited reason for putting DNS related data into the financial chain is the desire to pay for names with Bitcoins. You can do this with an independent chain too, because you make the rules and can link the two chains together as you see fit.

To start, decide on the purpose of your payments and who will receive the coins - if anyone. In the case of a DNS system, there are two reasons you might want to pay for names:

# To prevent abuse by people claiming all interesting names via a dictionary attack.
# To incentivise people to run your software and mine on your alternative chain.

In the first case really nobody should receive the payment. The money is being put up as a collateral and has no other use, so as long as it's sitting around unspent that is good enough. In the second case the payment should go to the miner working on the DNS chain.

To implement this we extend our hypothetical DNS transaction message like this:

message NameTx {
required string name = 1;
repeated bytes ip_addresses = 2;
required bytes pubkey = 3;
enum ClaimType {
NEW_NAME,
TRANSFER
}
required ClaimType type = 4;

// Only used if type == TRANSFER. The new owner of the name and signature proving current ownership.
optional bytes dest_pubkey = 5;
optional bytes signature = 6;

// Only used if type == NEW_NAME.
optional bytes collateral_signature = 7;
optional string miner_address = 8;
optional uint64 miner_fee = 9;
}

The collateral_signature field contains an ECDSA signature generated from a public key that holds some Bitcoins. The miner address is blank when the name purchaser creates the transaction and is filled out after a miner receives it, but before they begin working on it.

To buy a name that costs 10 BTC with a miner fee of 2 BTC, a user presses the "buy name" button in their DNS software. It talks to their local Bitcoin node via RPC and does the following:

# Creates a new Bitcoin address (key).
# Sends 10 BTC to the new address (a send-to-self transaction).
# Extracts the key from Bitcoin, meaning it's no longer available to spend in your wallet.
# Stores the key in a local DNS data file ("wallet") somewhere.
# Sets the miner_fee field to the pre-agreed value of 2 BTC.
# Takes the public key part and uses it to sign a version of the NameTx that lacks collateral_signature (a signature can't sign itself) and miner_address.
# The signature is placed in collateral_signature field.
# The transaction is sent to a miner who charges 2 BTC.

When the miner receives the transaction, it verifies that the 10 BTC is not spent:

# The ECDSA public key recovery algorithm is run on the collateral_signature. It can yield several possible keys.
# The public keys recovered are used to verify the signature is correct. This step also figures out which of the possible keys is the right one.
# The correct public key is turned into a Bitcoin address (by hashing it)
# The DNS node software queries Bitcoin to discover whether that address has 10 BTC associated with it, or whether the balance of that address is lower. Note that todays software does not index the balance of every address in the system, but it can be added (the Block Explorer does this).
# If the address does indeed have 10 unspent Bitcoins then the collateral is present and it's OK to serve the name

The miner then creates a new Bitcoin address for themselves and sets miner_address to contain it, then includes it into the current block being worked on. After a block matching the DNS chains difficulty is found, it is broadcast. Other nodes do the following:

# For each transaction, repeat the verification steps to ensure the collateral is not spent.
# Check the balance of the miners own address.
# If the balance is not yet equal to miner_fee, the name is put into a "pending" state in which it is owned but not served in response to DNS queries.

The user observes the broadcast and sees that their name is now pending payment, so they send 2 BTC to the address they find in their transaction. As nodes notice the payment becoming confirmed they start responding to DNS queries for that name (ie, the ownership process is complete).

When the user gets tired of owning the name, he can simply re-import the collateral key into his wallet and spend the coins. The DNS network will soon observe that the coins are spent and make the name available for purchasing by somebody else.

== Incentivising non-resource based chains ==

It's possible to incentivise mining on an alt-chain even if that chain does not have any concept of ownership, ie, if the act of finding a block itself is what is being paid for. An example of this is a timestamping chain in which presence in a block alone is sufficient to satisfy the user.

To implement this, set up a new chain as normal. Blocks in this new chain arrange transactions into a merkle tree in the same manner as Bitcoin does. A client that wants something incorporated into a block connects directly to some miners and submits their transaction. The miners add their address to the transaction as normal. Once a miner finds a block, it immediately sends the block to connected clients whose transactions made it in, but does not broadcast the new block to other miners. The clients respond with a valid Bitcoin transaction which pays for block inclusion. Once all clients have paid up the transaction is broadcast.

If a client has disconnected or does not pay quickly enough, their transaction can be replaced inside the block with its hash. In this way the blocks validity is preserved because the merkle tree is still valid. The newly found alt-block is broadcast, minus the transaction of the delinquent customer. As long as clients are still connected the payment process for all found transactions can be completed quickly: it would only take a few seconds to gather the payments and broadcast those on the Bitcoin network, minimizing the chance of a race that would require you to trust the miner to reinclude your transactions in the next block despite having already been paid.

== Mining on the alt-chain but not Bitcoin ==

So far we've considered a scheme in which all alt-chain miners simultaneously mine on Bitcoin. It's possible some people may wish to mine on your chain but not Bitcoin, perhaps because the cost of keeping up with the Bitcoin transaction rate has become too high for them to bother.

To mine without an attached Bitcoin node, your software can simply implement the same getwork protocol Bitcoin itself does. When a mining tool requests work your program would generate a correctly formatted but ultimately bogus Bitcoin block. The contents of this block don't need to be correct because it will never be broadcast on the Bitcoin network, for example, the prevBlockHash field can be all zeros. It exists purely for backwards compatibility. Whilst the block needs a valid merkle root and a coinbase transaction, no other transactions are required and the only part of the coinbase tx that matters is the part holding the hash.

== Scaling up ==

In the simple scheme each alt-chain being worked on needs 33 bytes in the Bitcoin coinbase transaction (1 for the length and 32 for the hash). Note that if there are two independent miners working on two different alt-chains, you still only need 1 hash in the coinbase scriptSig because the hash isn't meaningful to anyone else on the Bitcoin network. If miners only want to work a handful of chains this overhead is trivially dwarfed by the rest of the data in a Bitcoin block.

But if a miner wishes to work on hundreds, thousands or millions of alternative chains the size of the coinbase scriptSig would balloon and become unworkable. To solve this, the hash stored in the scriptSig can be the root of yet another merkle tree, this time a tree over the hashes of all blocks being worked on. The BitcoinData message is extended like this:

message MyBlock {
required bytes prev_block_hash = 1;
required uint32 difficulty = 2;
required uint32 time = 3;

repeated MyTx transactions = 4;
}

message SuperBlock {
required MyBlock my_data = 1;
required BitcoinData bitcoin_data = 2;
}

message BitcoinData {
// A Bitcoin format block header. Because it's in Satoshis custom format we represent this as a byte array.
required bytes header = 1;

// The first transaction from the block.
required bytes coinbase_tx = 2;

// The merkle branch linking the coinbase transaction to the header.
required bytes coinbase_merkle_branch = 3;

// The merkle branch linking MyBlock to the merkle root in the coinbase_tx.
required bytes altblock_merkle_branch = 4;
}

The verification step becomes a bit more complex:

# Verify the header is of sufficient difficulty for the alt-chain
# Verify coinbase_tx was a part of that block by checking the coinbase_merkle_branch is linked to the merkle root in the header.
# Extract the root of the second merkle tree from the coinbase_tx (call it 2MR).
# Hash the alt-chain block (my_data), verify that altblock_merkle_branch links the my_data hash to 2MR.

You have now proven that the MyBlock instance was worked on, along with perhaps thousands of other chains you don't have to know anything about.

This is an advanced technique which is probably not worth implementing unless the additional scalability is required. It can be introduced in a backwards compatible manner for new chains without impacting older networks.

=== Protecting against double proof ===

The merkle tree approach to scalability comes with a caveat. If naïvely implemented, a miner could cheat the proof-of-work system by putting more than one alt-chain block header into one Bitcoin block. This "cheating" would not cause a problem if the alt-chain blocks all had the same previous-block hash: one or another would win the race, as happens when competing blocks enter the network. The problem would arise if a linked series of alt-chain blocks all existed in one Bitcoin block's auxiliary merkle trees. The miner could work on them all at once, getting more from his hashes than difficulty warrants.

Namecoin's [http://dot-bit.org/forum/viewtopic.php?f=5&t=269&start=11 solution] is to constrain the paths by which alt-chain blocks may be embedded in Bitcoin blocks. This works, but it complicates the picture for miners and chain designers in a future with many alternative chains.

A better solution for new chains is to forbid multiple blocks from having the same proof of work hash - the hash measured against the difficulty target would need to be unique over all blocks. This means you can't embed a series of blocks into the same merkle tree and win them all simultaneously as the network would accept only one.

== Generalized proof of work ==

Hashes embedded in transactions and headers, merkle branches, and [[Nonce|nonces]] all contribute to the goal of [[Proof of work|proving work]] on a block header. One can express all as sequences of these basic operations:

* prepend a byte string to the current data
* append a byte string to the current data
* hash the current data

For maximum flexibility, a work-sharing chain's block acceptance algorithm might accept proof in the form of a script using just these operations. The script would receive as input an alternative chain block header, and the hash of its output would have to satisfy the chain's difficulty.

This design would even support plain Bitcoin proof of work, where the "header" consists of all [[Protocol Specification#block|Bitcoin block header fields]] except the nonce, and the proof-of-work script simply appends the nonce. Thus, one can think of the work-sharing rules as an extension of the original Bitcoin rules.

Note that any naive implementation of this idea would let people create proofs-of-work by including data in a Bitcoin transaction, which would be accepted into a block.

==External Links==

* [https://bitcointalk.org/index.php?topic=6197.0 BitDNS in the words of Satoshi]
* [http://dot-bit.org/Merged_Mining Merged Mining] in Namecoin
* [http://dot-bit.org/forum/viewtopic.php?f=5&t=269 Namecoin forum discussion]
* [https://bitcointalk.org/index.php?topic=46927.msg572981#msg572981 Forum thread about double proof]

----

See also [[Intrinsic worth brainstorming]].

[[Category:Technical]]

P2Pool

2012-03-29T17:37:33Z

Forrestv: added notice about april 1st

URGENT: All P2Pool miners must upgrade to P2Pool 0.10.3 before April 1st! See [https://bitcointalk.org/index.php?topic=18313.0 the forum post]

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

<blockquote>P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 10 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target. Whenever a peer announces a new share found (new block in the P2Pool block chain), it is received by the other peers, and the other peers verify that this block contains payouts for all the previous miners who found a share (and announced it) that made it into the P2Pool share chain. This continues until some peer finds a block that has a difficulty that meets the Bitcoin network's difficulty target. This peer announces this block to the Bitcoin network and miners who have submitted shares for this block are paid in the generation transaction, proportionally to how many shares they have found in the last while. - Unknown author</blockquote>

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin and avoids the risk of hard to detect theft by pool operators.

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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization, some Bitcoin supporters donate to P2Pool miners, resulting in average returns above 100% of the expected reward.
However, it should be noted that there are other pools (such as [[BitPenny]] and [[Eligius]]) which can provide the same level of reduction of the power of the pool operator over the Bitcoin network.

== 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, just as Bitcoin regulates it to generate one block every ten minutes.
This means that finding shares becomes more difficult (resulting in higher variance) the more people mine on P2Pool, though large miners have the option to raise their difficulty, and so reduce the impact of their mining on P2Pool's minimum difficulty.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640 (= 24 hours of shares), whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is 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 ===

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: edit bitcoin.conf to include:
rpcuser=USER
rpcpassword=LONG_RANDOM_SECRET_VALUE
server=1
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** 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
** Source: python run_p2pool.py
* Run a miner daemon with long polling connecting to 127.0.0.1 (or the IP of the host running p2pool if it isn't on the same computer as the miner) on port 9332 with any username and password
** cgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher (but not 3.x)
* python-argparse
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does cgminer report so many longpoll events when mining on p2pool? - P4Man" 
'''A:''' "Once every ~10 seconds is normal. That is how often p2pool shares are generated (as opposed to ~10 min for bitcoin blocks) - cabin"

'''Q:''' "Do the 'orphan' and 'dead' shares in P2Pool's status display hurt me?" 
'''A:''' They shouldn't - It's normal for some fraction of everyone's shares to end up orphaned or dead. Because payouts are calculated by counting how many shares you have relative to others, everyone with normal configurations is equally "hurt" by this. However, if you have a large proportion of stales, your payout will be hurt. You can see how well you're doing by looking at P2Pool's "Efficiency" (ex: ''Efficiency: ~110.6% (40-111%)''). If 100% doesn't lie within the [http://en.wikipedia.org/wiki/Confidence_interval confidence interval] at the end, something is probably wrong (with 95% confidence).

'''Q:''' "What do I do if my efficiency is low?" 
'''A:''' Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. If you have a lot of dead shares or the "Local dead on arrival" number is higher than a few percent, that means that something is wrong with your miner. Check to make sure that it is one of the working versions in the ''Miners'' section on this page. Lower the intensity or raise the FPS of your miner. If you have a lot of orphan shares, something is wrong with P2Pool's P2P connection. Decrease the load on your internet connection or enable QoS (Quality of Service) on your router.

'''Q:''' What is PPLNS? 
'''A:''' Pay-Per-Last-N-Shares is a payout method that is completely resistant to pool hoppers.

'''Q:''' Why am I not getting very many shares?! 
'''A:''' The P2Pool difficulty is hundreds of times higher than on other pools. It can take time to get a share. P2Pool displays an estimate of how long you have to wait in the console output.

'''Q:''' Why does my miner say it has found a lot of shares but p2pool say I have only found a few?! 
'''A:''' The real P2Pool difficulty is hundreds of times higher than on normal pools, but p2pool essentially lies to your miner and tells it to work on relatively easy shares so that it submits shares every few seconds instead of every few hours. P2Pool then ignores any submitted shares that don't match the real share difficulty. By doing this, P2Pool can more accurately report your local hash rate and you can see if you are having problems with too many stale shares quickly

'''Q:''' Why am I getting so many rejects? 
'''A:''' You're using an incompatible miner. See the miners section here, increase your FPS on the miner, decrease the intensity, upgrade your miner, or try a different miner.

'''Q:''' What stops the pool operator or the block finder from stealing a block? 
'''A:''' A block solution is only worth anything because its hash matches Bitcoin's target. Altering anything within the block will change its hash and make it worthless. If you are concerned about the pool operator stealing a block, you should try to inspect the source code of each new version.

'''Q:''' Why does it say "Generated?" I want to spend my coins now! 
'''A:''' P2Pool includes payouts in generation transactions, which must mature (taking 120 blocks or 20 hours) before they can be spent. The reason for this is that a block could be orphaned, which would make its payout invalid and could reverse transactions.

'''Q:''' Do I get paid transaction fees? 
'''A:''' Yes. They are split among P2Pool miners.

'''Q:''' What are these payments I'm getting that aren't generated? 
'''A:''' These are subsidies that people who support the idea of P2Pool send to miners.

'''Q:''' Cool Subsidies sound like an awesome idea! How do I send some BTC to these awesome miners? 
'''A:''' See end of this page.

'''Q:''' Do I really need the WHOLE blockchain? 
'''A:''' Yes. Your node needs to be able to independently make decisions about what transactions to mine.

'''Q:''' How do merged mining payments work? 
'''A:''' Merged mining is handled entirely by namecoind, so you're solo mining and payouts will go into namecoind's wallet.

=== 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 intensity (8 for cgminer?) helps a lot with reducing stales.

* cgminer works perfectly without any extra options. However, using multiple pools might cause problems, because long polling is only done for one pool.
* ufasoft works perfectly.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seamless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.
* You can make P2Pool use a configuration file by running run_p2pool.py @FILENAME, with FILENAME being the path to a file containing the command-line arguments (newlines are ignored) Example:
<pre>
--net litecoin
-n 1.2.3.4
</pre>
* Setting the username of your miner connecting to P2Pool to a Bitcoin address will make it mine to that address instead of the one requested from bitcoind or set by -a
* Appending "/1000" to a miner's username will increase the difficulty of producing a P2Pool share to at most 1000. This is useful to large miners because doing this can make it easier for small miners while minimally impacting the large miners themselves. See [https://bitcointalk.org/index.php?topic=18313.msg816322#msg816322 recommended values].

=== Web interface ===

Lots of data and useful tools are available at http://127.0.0.1:9332/something:
* /graphs - RRD graphs of past hash rates for pool and local miners. Look for "VIP password" in P2Pool's output when it starts and use that for your miners to get graphs for individual miners.
* /rate
* /users
* /fee
* /current_payouts
* /patron_sendmany - Gives sendmany outputs for fair donations to P2Pool
* /global_stats
* /local_stats
* /peer_addresses
* /payout_addr
* /recent_blocks
* /uptime
* /chain_img - Visualization of sharechain
* /web/log - Some different stats collected over the last day

=== Included README ===
<pre>
Requirements:
Generic:
Bitcoin >=0.5.0 or Litecoin
Python
Twisted
python-argparse (for Python <=2.6)

Linux:
sudo apt-get install python-zope.interface python-twisted python-twisted-web
sudo apt-get install python-argparse # if on Python 2.6 or older

Windows:
Install Python 2.7: http://www.python.org/getit/
Install Twisted: http://twistedmatrix.com/trac/wiki/Downloads
Install Zope.Interface: http://pypi.python.org/pypi/zope.interface/3.8.0
Unzip the files into C:\Python27\Lib\site-packages

Running P2Pool:
To use P2Pool, you must be running your own local bitcoind. For standard
configurations, using P2Pool should be as simple as:

python run_p2pool.py

Then run your miner program, connecting to 127.0.0.1 on port 9332 with any
username and password.

If you are behind a NAT, you should enable TCP port forwarding on your
router. Forward port 9333 to the host running P2Pool.

Run "python run_p2pool.py --help" for additional options.

Notes for Litecoin:
Requirements:
In order to run P2Pool with the Litecoin network, you would need to build and install the
ltc_scrypt module that includes the scrypt proof of work code that Litecoin uses for hashes.

Linux:
cd litecoin_scrypt
sudo python setup.py install

Windows:
Install MinGW: http://www.mingw.org/wiki/Getting_Started
Install Python 2.7: http://www.python.org/getit/

cd litecoin_scrypt
C:\Python27\python.exe setup.py build --compile=mingw32 install

If you run into an error with unrecognized command line option '-mno-cygwin', see this:
http://stackoverflow.com/questions/6034390/compiling-with-cython-and-mingw-produces-gcc-error-unrecognized-command-line-o

Running P2Pool:
Run P2Pool with the "--net litecoin" option.
Run your miner program, connecting to 127.0.0.1 on port 9327.
Forward port 9338 to the host running P2Pool.

Litecoin's use of ports 9332 and 9332 conflicts with P2Pool running on
the Bitcoin network. To avoid problems, add these lines to litecoin.conf
and restart litecoind:
rpcport=10332
port=10333
</pre>

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin, litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--merged-url MERGED_URL]
[--merged-userpass MERGED_USERPASS]
[--give-author DONATION_PERCENTAGE] [--irc-announce]
[--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_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version 28a1948)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin, litecoin}
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>)
--datadir DATADIR store data in this directory (default: <directory
run_p2pool.py is in>/data)
--logfile LOGFILE log to this file (default: data/<NET>/log)
--merged MERGED_URLS call getauxblock on this url to get work for merged
mining (example:
http://ncuser:ncpass@127.0.0.1:10332/)
--merged-url MERGED_URL
DEPRECATED, use --merged
--merged-userpass MERGED_USERPASS
DEPRECATED, use --merged
--give-author DONATION_PERCENTAGE
donate this percentage of work to author of p2pool
(default: 0.5)
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--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)
-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)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:

For example, a bash script to donate 10 btc is:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany/10)"
</pre>

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.

Note that the amount you donate will be allocated to recent miners in proportion to the amount of work they've done in the last 24 hours or so, but all the miner whose shares of the donated amount are less than 0.01 BTC will have their shares combined into a single amount which is awarded to one of them at random, with the chance of winning this 'lottery' weighted by the miner's recent amount of work done. You can change this 0.01 BTC threshold like this, for example, which says to pay 10 BTC, but to share it amongst more miners that the default, cutting off at 0.001 BTC instead of at 0.01 BTC.
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany/10/0.001)"
</pre>

If you decide to donate you should announce it on the forums so that your donations provide the most incentive possible.

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support
* [http://p2pool.info/ p2pool.info] stats page
* [http://nodes.p2pmine.com nodes.p2pmine.com] Public list of P2Pool BTC/LTC nodes.

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2012-03-24T22:36:03Z

Forrestv: several corrections

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

<blockquote>P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 10 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target. Whenever a peer announces a new share found (new block in the P2Pool block chain), it is received by the other peers, and the other peers verify that this block contains payouts for all the previous miners who found a share (and announced it) that made it into the P2Pool share chain. This continues until some peer finds a block that has a difficulty that meets the Bitcoin network's difficulty target. This peer announces this block to the Bitcoin network and miners who have submitted shares for this block are paid in the generation transaction, proportionally to how many shares they have found in the last while. - Unknown author</blockquote>

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin and avoids the risk of hard to detect theft by pool operators.

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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization, some Bitcoin supporters donate to P2Pool miners, resulting in average returns above 100% of the expected reward.
However, it should be noted that there are other pools (such as [[BitPenny]] and [[Eligius]]) which can provide the same level of reduction of the power of the pool operator over the Bitcoin network.

== 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, just as Bitcoin regulates it to generate one block every ten minutes.
This means that finding shares becomes more difficult (resulting in higher variance) the more people mine on P2Pool, though large miners have the option to raise their difficulty, and so reduce the impact of their mining on P2Pool's minimum difficulty.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640, whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is 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 ===

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: edit bitcoin.conf to include:
rpcuser=USER
rpcpassword=LONG_RANDOM_SECRET_VALUE
server=1
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** 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
** Source: python run_p2pool.py
* Run a miner daemon with long polling connecting to 127.0.0.1 (or the IP of the host running p2pool if it isn't on the same computer as the miner) on port 9332 with any username and password
** cgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher (but not 3.x)
* python-argparse
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does cgminer report so many longpoll events when mining on p2pool? - P4Man" 
'''A:''' "Once every ~10 seconds is normal. That is how often p2pool shares are generated (as opposed to ~10 min for bitcoin blocks) - cabin"

'''Q:''' "Do the 'orphan' and 'dead' shares in P2Pool's status display hurt me?" 
'''A:''' They shouldn't - It's normal for some fraction of everyone's shares to end up orphaned or dead. Because payouts are calculated by counting how many shares you have relative to others, everyone with normal configurations is equally "hurt" by this. However, if you have a large proportion of stales, your payout will be hurt. You can see how well you're doing by looking at P2Pool's "Efficiency" (ex: ''Efficiency: ~110.6% (40-111%)''). If 100% doesn't lie within the [http://en.wikipedia.org/wiki/Confidence_interval confidence interval] at the end, something is probably wrong (with 95% confidence).

'''Q:''' "What do I do if my efficiency is low?" 
'''A:''' Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. If you have a lot of dead shares or the "Local dead on arrival" number is higher than a few percent, that means that something is wrong with your miner. Check to make sure that it is one of the working versions in the ''Miners'' section on this page. Lower the intensity or raise the FPS of your miner. If you have a lot of orphan shares, something is wrong with P2Pool's P2P connection. Decrease the load on your internet connection or enable QoS (Quality of Service) on your router.

'''Q:''' What is PPLNS? 
'''A:''' Pay-Per-Last-N-Shares is a payout method that is completely resistant to pool hoppers.

'''Q:''' Why am I not getting very many shares?! 
'''A:''' The P2Pool difficulty is hundreds of times higher than on other pools. It can take time to get a share. P2Pool displays an estimate of how long you have to wait in the console output.

'''Q:''' Why does my miner say it has found a lot of shares but p2pool say I have only found a few?! 
'''A:''' The real P2Pool difficulty is hundreds of times higher than on normal pools, but p2pool essentially lies to your miner and tells it to work on relatively easy shares so that it submits shares every few seconds instead of every few hours. P2Pool then ignores any submitted shares that don't match the real share difficulty. By doing this, P2Pool can more accurately report your local hash rate and you can see if you are having problems with too many stale shares quickly

'''Q:''' Why am I getting so many rejects? 
'''A:''' You're using an incompatible miner. See the miners section here, increase your FPS on the miner, decrease the intensity, upgrade your miner, or try a different miner.

'''Q:''' What stops the pool operator or the block finder from stealing a block? 
'''A:''' A block solution is only worth anything because its hash matches Bitcoin's target. Altering anything within the block will change its hash and make it worthless. If you are concerned about the pool operator stealing a block, you should try to inspect the source code of each new version.

'''Q:''' Why does it say "Generated?" I want to spend my coins now! 
'''A:''' P2Pool includes payouts in generation transactions, which must mature (taking 120 blocks or 20 hours) before they can be spent. The reason for this is that a block could be orphaned, which would make its payout invalid and could reverse transactions.

'''Q:''' Do I get paid transaction fees? 
'''A:''' Yes. They are split among P2Pool miners.

'''Q:''' What are these payments I'm getting that aren't generated? 
'''A:''' These are subsidies that people who support the idea of P2Pool send to miners.

'''Q:''' Cool Subsidies sound like an awesome idea! How do I send some BTC to these awesome miners? 
'''A:''' See end of this page.

'''Q:''' Do I really need the WHOLE blockchain? 
'''A:''' Yes. Your node needs to be able to independently make decisions about what transactions to mine.

'''Q:''' How do merged mining payments work? 
'''A:''' Merged mining is handled entirely by namecoind, so you're solo mining and payouts will go into namecoind's wallet.

=== 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 intensity (8 for cgminer?) helps a lot with reducing stales.

* cgminer works perfectly without any extra options. However, using multiple pools might cause problems, because long polling is only done for one pool.
* ufasoft works perfectly.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seamless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.
* You can make P2Pool use a configuration file by running run_p2pool.py @FILENAME, with FILENAME being the path to a file containing the command-line arguments (newlines are ignored) Example:
<pre>
--net litecoin
-n 1.2.3.4
</pre>
* Setting the username of your miner connecting to P2Pool to a Bitcoin address will make it mine to that address instead of the one requested from bitcoind or set by -a
* Appending "/1000" to a miner's username will increase the difficulty of producing a P2Pool share to at most 1000. This is useful to large miners because doing this can make it easier for small miners while minimally impacting the large miners themselves. See [https://bitcointalk.org/index.php?topic=18313.msg816322#msg816322 recommended values].

=== Web interface ===

Lots of data and useful tools are available at http://127.0.0.1:9332/something:
* /graphs - RRD graphs of past hash rates for pool and local miners. Look for "VIP password" in P2Pool's output when it starts and use that for your miners to get graphs for individual miners.
* /rate
* /users
* /fee
* /current_payouts
* /patron_sendmany - Gives sendmany outputs for fair donations to P2Pool
* /global_stats
* /local_stats
* /peer_addresses
* /payout_addr
* /recent_blocks
* /uptime
* /chain_img - Visualization of sharechain
* /web/log - Some different stats collected over the last day

=== Included README ===
<pre>
Requirements:
Generic:
Bitcoin >=0.5.0 or Litecoin
Python
Twisted
python-argparse (for Python <=2.6)

Linux:
sudo apt-get install python-zope.interface python-twisted python-twisted-web
sudo apt-get install python-argparse # if on Python 2.6 or older

Windows:
Install Python 2.7: http://www.python.org/getit/
Install Twisted: http://twistedmatrix.com/trac/wiki/Downloads
Install Zope.Interface: http://pypi.python.org/pypi/zope.interface/3.8.0
Unzip the files into C:\Python27\Lib\site-packages

Running P2Pool:
To use P2Pool, you must be running your own local bitcoind. For standard
configurations, using P2Pool should be as simple as:

python run_p2pool.py

Then run your miner program, connecting to 127.0.0.1 on port 9332 with any
username and password.

If you are behind a NAT, you should enable TCP port forwarding on your
router. Forward port 9333 to the host running P2Pool.

Run "python run_p2pool.py --help" for additional options.

Notes for Litecoin:
Requirements:
In order to run P2Pool with the Litecoin network, you would need to build and install the
ltc_scrypt module that includes the scrypt proof of work code that Litecoin uses for hashes.

Linux:
cd litecoin_scrypt
sudo python setup.py install

Windows:
Install MinGW: http://www.mingw.org/wiki/Getting_Started
Install Python 2.7: http://www.python.org/getit/

cd litecoin_scrypt
C:\Python27\python.exe setup.py build --compile=mingw32 install

If you run into an error with unrecognized command line option '-mno-cygwin', see this:
http://stackoverflow.com/questions/6034390/compiling-with-cython-and-mingw-produces-gcc-error-unrecognized-command-line-o

Running P2Pool:
Run P2Pool with the "--net litecoin" option.
Run your miner program, connecting to 127.0.0.1 on port 9327.
Forward port 9338 to the host running P2Pool.

Litecoin's use of ports 9332 and 9332 conflicts with P2Pool running on
the Bitcoin network. To avoid problems, add these lines to litecoin.conf
and restart litecoind:
rpcport=10332
port=10333
</pre>

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin, litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--merged-url MERGED_URL]
[--merged-userpass MERGED_USERPASS]
[--give-author DONATION_PERCENTAGE] [--irc-announce]
[--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_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version 28a1948)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin, litecoin}
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>)
--datadir DATADIR store data in this directory (default: <directory
run_p2pool.py is in>/data)
--logfile LOGFILE log to this file (default: data/<NET>/log)
--merged MERGED_URLS call getauxblock on this url to get work for merged
mining (example:
http://ncuser:ncpass@127.0.0.1:10332/)
--merged-url MERGED_URL
DEPRECATED, use --merged
--merged-userpass MERGED_USERPASS
DEPRECATED, use --merged
--give-author DONATION_PERCENTAGE
donate this percentage of work to author of p2pool
(default: 0.5)
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--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)
-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)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:

For example, a bash script to donate 10 btc is:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany/10)"
</pre>

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.

Note that the amount you donate will be allocated to recent miners in proportion to the amount of work they've done in the last 24 hours or so, but all the miner whose shares of the donated amount are less than 0.01 BTC will have their shares combined into a single amount which is awarded to one of them at random, with the chance of winning this 'lottery' weighted by the miner's recent amount of work done. You can change this 0.01 BTC threshold like this, for example, which says to pay 10 BTC, but to share it amongst more miners that the default, cutting off at 0.001 BTC instead of at 0.01 BTC.
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany/10/0.001)"
</pre>

If you decide to donate you should announce it on the forums so that your donations provide the most incentive possible.

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support
* [http://p2pool.info/ p2pool.info] stats page
* [http://nodes.p2pmine.com nodes.p2pmine.com] Public list of P2Pool BTC/LTC nodes.

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2012-03-07T23:49:01Z

Forrestv: updated donation urls

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

<blockquote>P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 10 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target. Whenever a peer announces a new share found (new block in the P2Pool block chain), it is received by the other peers, and the other peers verify that this block contains payouts for all the previous miners who found a share (and announced it) that made it into the P2Pool share chain. This continues until some peer finds a block that has a difficulty that meets the Bitcoin network's difficulty target. This peer announces this block to the Bitcoin network and miners who have submitted shares for this block are paid in the generation transaction, proportionally to how many shares they have found in the last while. - Unknown author</blockquote>

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin, avoids the risk of hard to detect theft by pool operators, and 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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization some Bitcoin supporters donate to P2Pool miners, resulting in returns 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, just as Bitcoin regulates it to generate one block every ten minutes.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640, whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is 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 bitcoind.

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: put rpcuser=USER, rpcpassword=LONG_RANDOM_SECRET_VALUE, and server=1 in bitcoin.conf (on separate lines)
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** 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
** Source: python run_p2pool.py
* Run a miner daemon with long polling connecting to 127.0.0.1 (or the IP of the host running p2pool if it isn't on the same computer as the miner) on port 9332 with any username and password
** cgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher
* python-argparse for Python 2.6 and lower
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does cgminer report so many longpoll events when mining on p2pool? - P4Man" 
'''A:''' "Once every ~10 seconds is normal. That is how often p2pool shares are generated (as opposed to ~10 min for bitcoin blocks) - cabin"

'''Q:''' "Do the 'orphan' and 'dead' shares in P2Pool's status display hurt me?" 
'''A:''' They shouldn't - It's normal for some fraction of everyone's shares to end up orphaned or dead. Because payouts are calculated by counting how many shares you have relative to others, everyone with normal configurations is equally "hurt" by this. However, if you have a large proportion of stales, your payout will be hurt. You can see how well you're doing by looking at P2Pool's "Efficiency" (ex: ''Efficiency: ~110.6% (40-111%)''). If 100% doesn't lie within the [http://en.wikipedia.org/wiki/Confidence_interval confidence interval] at the end, something is probably wrong (with 95% confidence).

'''Q:''' "What do I do if my efficiency is low?" 
'''A:''' Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. If you have a lot of dead shares or the "Local dead on arrival" number is higher than a few percent, that means that something is wrong with your miner. Check to make sure that it is one of the working versions in the ''Miners'' section on this page. Lower the intensity or raise the FPS of your miner. If you have a lot of orphan shares, something is wrong with P2Pool's P2P connection. Decrease the load on your internet connection or enable QoS (Quality of Service) on your router.

'''Q:''' What is PPLNS? 
'''A:''' Pay-Per-Last-N-Shares is a payout method that is completely resistant to pool hoppers.

'''Q:''' Why am I not getting very many shares?! 
'''A:''' The P2Pool difficulty is hundreds of times higher than on normal pools. It can take time to get a share. P2Pool displays an estimate of how long you have to wait in the console output.

'''Q:''' Why does my miner say it has found a lot of shares but p2pool say I have only found a few?! 
'''A:''' The real P2Pool difficulty is hundreds of times higher than on normal pools, but p2pool essentially lies to your miner and tells it to work on relatively easy shares so that it submits shares every few seconds instead of every few hours. P2Pool then ignores any submitted shares that don't match the real share difficulty. By doing this, P2Pool can more accurately report your local hash rate and you can see if you are having problems with too many stale shares quickly

'''Q:''' Why am I getting so many rejects? 
'''A:''' You're using an incompatible miner. See the miners section here, increase your FPS on the miner, decrease the intensity, upgrade your miner, or try a different miner.

'''Q:''' What stops the pool operator or the block finder from stealing a block? 
'''A:''' A block solution is only worth anything because its hash matches Bitcoin's target. Altering anything within the block will change its hash and make it worthless.

'''Q:''' Why does it say "Generated?" I want to spend my coins now! 
'''A:''' P2Pool includes payouts in generation transactions, which must mature (taking 120 blocks or 20 hours) before they can be spent. The reason for this is that a block could be orphaned, which would make its payout invalid and could reverse transactions.

'''Q:''' Do I get paid transaction fees? 
'''A:''' Yes. They are split among P2Pool miners.

'''Q:''' What are these payments I'm getting that aren't generated? 
'''A:''' These are subsidies that people who support the idea of P2Pool send to miners.

'''Q:''' Cool Subsidies sound like an awesome idea! How do I send some BTC to these awesome miners? 
'''A:''' See end of this page.

'''Q:''' Do I really need the WHOLE blockchain? 
'''A:''' Yes. Your node needs to be able to independently make decisions about what transactions to mine.

'''Q:''' How do merged mining payments work? 
'''A:''' Merged mining is handled entirely by namecoind, so you're solo mining and payouts will go into namecoind's wallet.

=== 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 intensity (8 for cgminer?) helps a lot with reducing stales.

* cgminer works perfectly without any extra options. However, using multiple pools might cause problems, because long polling is only done for one pool.
* ufasoft works perfectly.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seemless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.
* You can make P2Pool use a configuration file by running run_p2pool.py @FILENAME, with FILENAME being the path to a file containing the command-line arguments (newlines are ignored) Example:
<pre>
--net litecoin
-n 1.2.3.4
</pre>
* Setting the username of your miner connecting to P2Pool to a Bitcoin address will make it mine to that address instead of the one requested from bitcoind or set by -a

=== Web interface ===

Lots of data and useful tools are available at http://127.0.0.1:9332/something:
* /graphs - RRD graphs of past hash rates for pool and local miners. Look for "VIP password" in P2Pool's output when it starts and use that for your miners to get graphs for individual miners.
* /rate
* /users
* /fee
* /current_payouts
* /patron_sendmany - Gives sendmany outputs for fair donations to P2Pool
* /global_stats
* /local_stats
* /peer_addresses
* /payout_addr
* /recent_blocks
* /uptime
* /chain_img - Visualization of sharechain
* /web/log - Some different stats collected over the last day

=== Included README ===
<pre>
Requirements:
Generic:
Bitcoin >=0.5.0 or Litecoin
Python
Twisted
python-argparse (for Python <=2.6)

Linux:
sudo apt-get install python-zope.interface python-twisted python-twisted-web
sudo apt-get install python-argparse # if on Python 2.6 or older

Windows:
Install Python 2.7: http://www.python.org/getit/
Install Twisted: http://twistedmatrix.com/trac/wiki/Downloads
Install Zope.Interface: http://pypi.python.org/pypi/zope.interface/3.8.0
Unzip the files into C:\Python27\Lib\site-packages

Running P2Pool:
To use P2Pool, you must be running your own local bitcoind. For standard
configurations, using P2Pool should be as simple as:

python run_p2pool.py

Then run your miner program, connecting to 127.0.0.1 on port 9332 with any
username and password.

If you are behind a NAT, you should enable TCP port forwarding on your
router. Forward port 9333 to the host running P2Pool.

Run "python run_p2pool.py --help" for additional options.

Notes for Litecoin:
Requirements:
In order to run P2Pool with the Litecoin network, you would need to build and install the
ltc_scrypt module that includes the scrypt proof of work code that Litecoin uses for hashes.

Linux:
cd litecoin_scrypt
sudo python setup.py install

Windows:
Install MinGW: http://www.mingw.org/wiki/Getting_Started
Install Python 2.7: http://www.python.org/getit/

cd litecoin_scrypt
C:\Python27\python.exe setup.py build --compile=mingw32 install

If you run into an error with unrecognized command line option '-mno-cygwin', see this:
http://stackoverflow.com/questions/6034390/compiling-with-cython-and-mingw-produces-gcc-error-unrecognized-command-line-o

Running P2Pool:
Run P2Pool with the "--net litecoin" option.
Run your miner program, connecting to 127.0.0.1 on port 9327.
Forward port 9338 to the host running P2Pool.

Litecoin's use of ports 9332 and 9332 conflicts with P2Pool running on
the Bitcoin network. To avoid problems, add these lines to litecoin.conf
and restart litecoind:
rpcport=10332
port=10333
</pre>

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin, litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--merged-url MERGED_URL]
[--merged-userpass MERGED_USERPASS]
[--give-author DONATION_PERCENTAGE] [--irc-announce]
[--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_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version 28a1948)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin, litecoin}
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>)
--datadir DATADIR store data in this directory (default: <directory
run_p2pool.py is in>/data)
--logfile LOGFILE log to this file (default: data/<NET>/log)
--merged MERGED_URLS call getauxblock on this url to get work for merged
mining (example:
http://ncuser:ncpass@127.0.0.1:10332/)
--merged-url MERGED_URL
DEPRECATED, use --merged
--merged-userpass MERGED_USERPASS
DEPRECATED, use --merged
--give-author DONATION_PERCENTAGE
donate this percentage of work to author of p2pool
(default: 0.5)
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--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)
-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)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:

For example, a bash script to donate 10 btc is:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany/10)"
</pre>

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.

Note that the amount you donate will be allocated to recent miners in proportion to the amount of work they've done in the last 24 hours or so, but all the miner whose shares of the donated amount are less than 0.01 BTC will have their shares combined into a single amount which is awarded to one of them at random, with the chance of winning this 'lottery' weighted by the miner's recent amount of work done. You can change this 0.01 BTC threshold like this, for example, which says to pay 10 BTC, but to share it amongst more miners that the default, cutting off at 0.001 BTC instead of at 0.01 BTC.
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany/10/0.001)"
</pre>

If you decide to donate you should announce it on the forums so that your donations provide the most incentive possible.

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support
* [http://p2pool.info/ p2pool.info] stats page

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2012-03-07T21:57:00Z

Forrestv:

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

<blockquote>P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 10 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target. Whenever a peer announces a new share found (new block in the P2Pool block chain), it is received by the other peers, and the other peers verify that this block contains payouts for all the previous miners who found a share (and announced it) that made it into the P2Pool share chain. This continues until some peer finds a block that has a difficulty that meets the Bitcoin network's difficulty target. This peer announces this block to the Bitcoin network and miners who have submitted shares for this block are paid in the generation transaction, proportionally to how many shares they have found in the last while. - Unknown author</blockquote>

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin, avoids the risk of hard to detect theft by pool operators, and 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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization some Bitcoin supporters donate to P2Pool miners, resulting in returns 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, just as Bitcoin regulates it to generate one block every ten minutes.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640, whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is 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 bitcoind.

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: put rpcuser=USER, rpcpassword=LONG_RANDOM_SECRET_VALUE, and server=1 in bitcoin.conf (on separate lines)
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** 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
** Source: python run_p2pool.py
* Run a miner daemon with long polling connecting to 127.0.0.1 (or the IP of the host running p2pool if it isn't on the same computer as the miner) on port 9332 with any username and password
** cgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher
* python-argparse for Python 2.6 and lower
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does cgminer report so many longpoll events when mining on p2pool? - P4Man" 
'''A:''' "Once every ~10 seconds is normal. That is how often p2pool shares are generated (as opposed to ~10 min for bitcoin blocks) - cabin"

'''Q:''' "Do the 'orphan' and 'dead' shares in P2Pool's status display hurt me?" 
'''A:''' They shouldn't - It's normal for some fraction of everyone's shares to end up orphaned or dead. Because payouts are calculated by counting how many shares you have relative to others, everyone with normal configurations is equally "hurt" by this. However, if you have a large proportion of stales, your payout will be hurt. You can see how well you're doing by looking at P2Pool's "Efficiency" (ex: ''Efficiency: ~110.6% (40-111%)''). If 100% doesn't lie within the [http://en.wikipedia.org/wiki/Confidence_interval confidence interval] at the end, something is probably wrong (with 95% confidence).

'''Q:''' "What do I do if my efficiency is low?" 
'''A:''' Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. If you have a lot of dead shares or the "Local dead on arrival" number is higher than a few percent, that means that something is wrong with your miner. Check to make sure that it is one of the working versions in the ''Miners'' section on this page. Lower the intensity or raise the FPS of your miner. If you have a lot of orphan shares, something is wrong with P2Pool's P2P connection. Decrease the load on your internet connection or enable QoS (Quality of Service) on your router.

'''Q:''' What is PPLNS? 
'''A:''' Pay-Per-Last-N-Shares is a payout method that is completely resistant to pool hoppers.

'''Q:''' Why am I not getting very many shares?! 
'''A:''' The P2Pool difficulty is hundreds of times higher than on normal pools. It can take time to get a share. P2Pool displays an estimate of how long you have to wait in the console output.

'''Q:''' Why does my miner say it has found a lot of shares but p2pool say I have only found a few?! 
'''A:''' The real P2Pool difficulty is hundreds of times higher than on normal pools, but p2pool essentially lies to your miner and tells it to work on relatively easy shares so that it submits shares every few seconds instead of every few hours. P2Pool then ignores any submitted shares that don't match the real share difficulty. By doing this, P2Pool can more accurately report your local hash rate and you can see if you are having problems with too many stale shares quickly

'''Q:''' Why am I getting so many rejects? 
'''A:''' You're using an incompatible miner. See the miners section here, increase your FPS on the miner, decrease the intensity, upgrade your miner, or try a different miner.

'''Q:''' What stops the pool operator or the block finder from stealing a block? 
'''A:''' A block solution is only worth anything because its hash matches Bitcoin's target. Altering anything within the block will change its hash and make it worthless.

'''Q:''' Why does it say "Generated?" I want to spend my coins now! 
'''A:''' P2Pool includes payouts in generation transactions, which must mature (taking 120 blocks or 20 hours) before they can be spent. The reason for this is that a block could be orphaned, which would make its payout invalid and could reverse transactions.

'''Q:''' Do I get paid transaction fees? 
'''A:''' Yes. They are split among P2Pool miners.

'''Q:''' What are these payments I'm getting that aren't generated? 
'''A:''' These are subsidies that people who support the idea of P2Pool send to miners.

'''Q:''' Cool Subsidies sound like an awesome idea! How do I send some BTC to these awesome miners? 
'''A:''' See end of this page.

'''Q:''' Do I really need the WHOLE blockchain? 
'''A:''' Yes. Your node needs to be able to independently make decisions about what transactions to mine.

'''Q:''' How do merged mining payments work? 
'''A:''' Merged mining is handled entirely by namecoind, so you're solo mining and payouts will go into namecoind's wallet.

=== 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 intensity (8 for cgminer?) helps a lot with reducing stales.

* cgminer works perfectly without any extra options. However, using multiple pools might cause problems, because long polling is only done for one pool.
* ufasoft works perfectly.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seemless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.
* You can make P2Pool use a configuration file by running run_p2pool.py @FILENAME, with FILENAME being the path to a file containing the command-line arguments (newlines are ignored) Example:
<pre>
--net litecoin
-n 1.2.3.4
</pre>
* Setting the username of your miner connecting to P2Pool to a Bitcoin address will make it mine to that address instead of the one requested from bitcoind or set by -a

=== Web interface ===

Lots of data and useful tools are available at http://127.0.0.1:9332/something:
* /graphs - RRD graphs of past hash rates for pool and local miners. Look for "VIP password" in P2Pool's output when it starts and use that for your miners to get graphs for individual miners.
* /rate
* /users
* /fee
* /current_payouts
* /patron_sendmany - Gives sendmany outputs for fair donations to P2Pool
* /global_stats
* /local_stats
* /peer_addresses
* /payout_addr
* /recent_blocks
* /uptime
* /chain_img - Visualization of sharechain
* /web/log - Some different stats collected over the last day

=== Included README ===
<pre>
Requirements:
Generic:
Bitcoin >=0.5.0 or Litecoin
Python
Twisted
python-argparse (for Python <=2.6)

Linux:
sudo apt-get install python-zope.interface python-twisted python-twisted-web
sudo apt-get install python-argparse # if on Python 2.6 or older

Windows:
Install Python 2.7: http://www.python.org/getit/
Install Twisted: http://twistedmatrix.com/trac/wiki/Downloads
Install Zope.Interface: http://pypi.python.org/pypi/zope.interface/3.8.0
Unzip the files into C:\Python27\Lib\site-packages

Running P2Pool:
To use P2Pool, you must be running your own local bitcoind. For standard
configurations, using P2Pool should be as simple as:

python run_p2pool.py

Then run your miner program, connecting to 127.0.0.1 on port 9332 with any
username and password.

If you are behind a NAT, you should enable TCP port forwarding on your
router. Forward port 9333 to the host running P2Pool.

Run "python run_p2pool.py --help" for additional options.

Notes for Litecoin:
Requirements:
In order to run P2Pool with the Litecoin network, you would need to build and install the
ltc_scrypt module that includes the scrypt proof of work code that Litecoin uses for hashes.

Linux:
cd litecoin_scrypt
sudo python setup.py install

Windows:
Install MinGW: http://www.mingw.org/wiki/Getting_Started
Install Python 2.7: http://www.python.org/getit/

cd litecoin_scrypt
C:\Python27\python.exe setup.py build --compile=mingw32 install

If you run into an error with unrecognized command line option '-mno-cygwin', see this:
http://stackoverflow.com/questions/6034390/compiling-with-cython-and-mingw-produces-gcc-error-unrecognized-command-line-o

Running P2Pool:
Run P2Pool with the "--net litecoin" option.
Run your miner program, connecting to 127.0.0.1 on port 9327.
Forward port 9338 to the host running P2Pool.

Litecoin's use of ports 9332 and 9332 conflicts with P2Pool running on
the Bitcoin network. To avoid problems, add these lines to litecoin.conf
and restart litecoind:
rpcport=10332
port=10333
</pre>

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin, litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--merged-url MERGED_URL]
[--merged-userpass MERGED_USERPASS]
[--give-author DONATION_PERCENTAGE] [--irc-announce]
[--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_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version 28a1948)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin, litecoin}
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>)
--datadir DATADIR store data in this directory (default: <directory
run_p2pool.py is in>/data)
--logfile LOGFILE log to this file (default: data/<NET>/log)
--merged MERGED_URLS call getauxblock on this url to get work for merged
mining (example:
http://ncuser:ncpass@127.0.0.1:10332/)
--merged-url MERGED_URL
DEPRECATED, use --merged
--merged-userpass MERGED_USERPASS
DEPRECATED, use --merged
--give-author DONATION_PERCENTAGE
donate this percentage of work to author of p2pool
(default: 0.5)
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--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)
-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)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:

For example, a bash script to donate 10 btc is:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany?total=10)"
</pre>

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.

Note that the amount you donate will be allocated to recent miners in proportion to the amount of work they've done in the last 24 hours or so, but all the miner whose shares of the donated amount are less than 0.01 BTC will have their shares combined into a single amount which is awarded to one of them at random, with the chance of winning this 'lottery' weighted by the miner's recent amount of work done. You can change this 0.01 BTC threshold like this, for example, which says to pay 10 BTC, but to share it amongst more miners that the default, cutting off at 0.001 BTC instead of at 0.01 BTC.
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany?total=10/0.001)"
</pre>

If you decide to donate you should announce it on the forums so that your donations provide the most incentive possible.

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support
* [http://p2pool.info/ p2pool.info] stats page

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2012-03-06T03:02:16Z

Forrestv: copied readme into

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

<blockquote>P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 10 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target. Whenever a peer announces a new share found (new block in the P2Pool block chain), it is received by the other peers, and the other peers verify that this block contains payouts for all the previous miners who found a share (and announced it) that made it into the P2Pool share chain. This continues until some peer finds a block that has a difficulty that meets the Bitcoin network's difficulty target. This peer announces this block to the Bitcoin network and miners who have submitted shares for this block are paid in the generation transaction, proportionally to how many shares they have found in the last while. - Unknown author</blockquote>

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin, avoids the risk of hard to detect theft by pool operators, and 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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization some Bitcoin supporters donate to P2Pool miners, resulting in returns 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, just as Bitcoin regulates it to generate one block every ten minutes.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640, whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is 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 bitcoind.

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: put rpcuser=USER, rpcpassword=LONG_RANDOM_SECRET_VALUE, and server=1 in bitcoin.conf (on separate lines)
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** 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
** Source: python run_p2pool.py
* Run a miner daemon with long polling connecting to 127.0.0.1 (or the IP of the host running p2pool if it isn't on the same computer as the miner) on port 9332 with any username and password
** cgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher
* python-argparse for Python 2.6 and lower
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does cgminer report so many longpoll events when mining on p2pool? - P4Man" 
'''A:''' "Once every ~10 seconds is normal. That is how often p2pool shares are generated (as opposed to ~10 min for bitcoin blocks) - cabin"

'''Q:''' "Do the 'orphan' and 'dead' shares in P2Pool's status display hurt me?" 
'''A:''' They shouldn't - It's normal for some fraction of everyone's shares to end up orphaned or dead. Because payouts are calculated by counting how many shares you have relative to others, everyone with normal configurations is equally "hurt" by this. However, if you have a large proportion of stales, your payout will be hurt. You can see how well you're doing by looking at P2Pool's "Efficiency" (ex: ''Efficiency: ~110.6% (40-111%)''). If 100% doesn't lie within the [http://en.wikipedia.org/wiki/Confidence_interval confidence interval] at the end, something is probably wrong (with 95% confidence).

'''Q:''' "What do I do if my efficiency is low?" 
'''A:''' If you have a lot of dead shares or the "Local dead on arrival" number is higher than a few percent, that means that something is wrong with your miner. Check to make sure that it is one of the working versions in the ''Miners'' section on this page. Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. Lower the intensity or raise the FPS of your miner. If you have a lot of orphan shares, something is wrong with P2Pool's P2P connection. Don't overload your internet connection or enable QoS (Quality of Service) on your router.

'''Q:''' What is PPLNS? 
'''A:''' Pay-Per-Last-N-Shares is a payout method that is completely resistant to pool hoppers.

'''Q:''' Why am I not getting very many shares?! 
'''A:''' The P2Pool difficulty is hundreds of times higher than on normal pools. It can take time to get a share. P2Pool displays an estimate of how long you have to wait in the console output.

'''Q:''' Why does my miner say it has found a lot of shares but p2pool say I have only found a few?! 
'''A:''' The real P2Pool difficulty is hundreds of times higher than on normal pools, but p2pool essentially lies to your miner and tells it to work on relatively easy shares so that it submits shares every few seconds instead of every few hours. P2Pool then ignores any submitted shares that don't match the real share difficulty. By doing this, P2Pool can more accurately report your local hash rate and you can see if you are having problems with too many stale shares quickly

'''Q:''' Why am I getting so many rejects? 
'''A:''' You're using an incompatible miner. See the miners section here, increase your FPS on the miner, decrease the intensity, upgrade your miner, or try a different miner.

'''Q:''' What stops the pool operator or the block finder from stealing a block? 
'''A:''' A block solution is only worth anything because its hash matches Bitcoin's target. Altering anything within the block will change its hash and make it worthless.

'''Q:''' Why does it say "Generated?" I want to spend my coins now! 
'''A:''' P2Pool includes payouts in generation transactions, which must mature (taking 120 blocks or 20 hours) before they can be spent. The reason for this is that a block could be orphaned, which would make its payout invalid and could reverse transactions.

'''Q:''' Do I get paid transaction fees? 
'''A:''' Yes. They are split among P2Pool miners.

'''Q:''' What are these payments I'm getting that aren't generated? 
'''A:''' These are subsidies that people who support the idea of P2Pool send to miners.

'''Q:''' Cool Subsidies sound like an awesome idea! How do I send some BTC to these awesome miners? 
'''A:''' See end of this page.

'''Q:''' Do I really need the WHOLE blockchain? 
'''A:''' Yes. Your node needs to be able to independently make decisions about what transactions to mine.

'''Q:''' How do merged mining payments work? 
'''A:''' Merged mining is handled entirely by namecoind, so you're solo mining and payouts will go into namecoind's wallet.

=== 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 intensity (8 for cgminer?) helps a lot with reducing stales.

* cgminer works perfectly without any extra options. However, using multiple pools might cause problems, because long polling is only done for one pool.
* ufasoft works perfectly.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seemless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.
* You can make P2Pool use a configuration file by running run_p2pool.py @FILENAME, with FILENAME being the path to a file containing the command-line arguments (newlines are ignored) Example:
<pre>
--net litecoin
-n 1.2.3.4
</pre>
* Setting the username of your miner connecting to P2Pool to a Bitcoin address will make it mine to that address instead of the one requested from bitcoind or set by -a

=== Web interface ===

Lots of data and useful tools are available at http://127.0.0.1:9332/something:
* /graphs - RRD graphs of past hash rates for pool and local miners. Look for "VIP password" in P2Pool's output when it starts and use that for your miners to get graphs for individual miners.
* /rate
* /users
* /fee
* /current_payouts
* /patron_sendmany - Gives sendmany outputs for fair donations to P2Pool
* /global_stats
* /local_stats
* /peer_addresses
* /payout_addr
* /recent_blocks
* /uptime
* /chain_img - Visualization of sharechain
* /web/log - Some different stats collected over the last day

=== Included README ===
<pre>
Requirements:
Generic:
Bitcoin >=0.5.0 or Litecoin
Python
Twisted
python-argparse (for Python <=2.6)

Linux:
sudo apt-get install python-zope.interface python-twisted python-twisted-web
sudo apt-get install python-argparse # if on Python 2.6 or older

Windows:
Install Python 2.7: http://www.python.org/getit/
Install Twisted: http://twistedmatrix.com/trac/wiki/Downloads
Install Zope.Interface: http://pypi.python.org/pypi/zope.interface/3.8.0
Unzip the files into C:\Python27\Lib\site-packages

Running P2Pool:
To use P2Pool, you must be running your own local bitcoind. For standard
configurations, using P2Pool should be as simple as:

python run_p2pool.py

Then run your miner program, connecting to 127.0.0.1 on port 9332 with any
username and password.

If you are behind a NAT, you should enable TCP port forwarding on your
router. Forward port 9333 to the host running P2Pool.

Run "python run_p2pool.py --help" for additional options.

Notes for Litecoin:
Requirements:
In order to run P2Pool with the Litecoin network, you would need to build and install the
ltc_scrypt module that includes the scrypt proof of work code that Litecoin uses for hashes.

Linux:
cd litecoin_scrypt
sudo python setup.py install

Windows:
Install MinGW: http://www.mingw.org/wiki/Getting_Started
Install Python 2.7: http://www.python.org/getit/

cd litecoin_scrypt
C:\Python27\python.exe setup.py build --compile=mingw32 install

If you run into an error with unrecognized command line option '-mno-cygwin', see this:
http://stackoverflow.com/questions/6034390/compiling-with-cython-and-mingw-produces-gcc-error-unrecognized-command-line-o

Running P2Pool:
Run P2Pool with the "--net litecoin" option.
Run your miner program, connecting to 127.0.0.1 on port 9327.
Forward port 9338 to the host running P2Pool.

Litecoin's use of ports 9332 and 9332 conflicts with P2Pool running on
the Bitcoin network. To avoid problems, add these lines to litecoin.conf
and restart litecoind:
rpcport=10332
port=10333
</pre>

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin, litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--merged-url MERGED_URL]
[--merged-userpass MERGED_USERPASS]
[--give-author DONATION_PERCENTAGE] [--irc-announce]
[--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_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version 28a1948)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin, litecoin}
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>)
--datadir DATADIR store data in this directory (default: <directory
run_p2pool.py is in>/data)
--logfile LOGFILE log to this file (default: data/<NET>/log)
--merged MERGED_URLS call getauxblock on this url to get work for merged
mining (example:
http://ncuser:ncpass@127.0.0.1:10332/)
--merged-url MERGED_URL
DEPRECATED, use --merged
--merged-userpass MERGED_USERPASS
DEPRECATED, use --merged
--give-author DONATION_PERCENTAGE
donate this percentage of work to author of p2pool
(default: 0.5)
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--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)
-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)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:

For example, a bash script to donate 10 btc is:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany?total=10)"
</pre>

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.

Note that the amount you donate will be allocated to recent miners in proportion to the amount of work they've done in the last 24 hours or so, but all the miner whose shares of the donated amount are less than 0.01 BTC will have their shares combined into a single amount which is awarded to one of them at random, with the chance of winning this 'lottery' weighted by the miner's recent amount of work done. You can change this 0.01 BTC threshold like this, for example, which says to pay 10 BTC, but to share it amongst more miners that the default, cutting off at 0.001 BTC instead of at 0.01 BTC.
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany?total=10/0.001)"
</pre>

If you decide to donate you should announce it on the forums so that your donations provide the most incentive possible.

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support
* [http://p2pool.info/ p2pool.info] stats page

==References==
<references />

[[Category:Pool Operators]]

BIP 0022

2012-03-03T17:14:47Z

Forrestv: reason share was accepted -> reason share was rejected

<pre>
BIP: TBD
Title: getmemorypool
Author: Luke Dashjr <luke+bipgmp@dashjr.org>
Status: Draft
Type: Standards Track
Created: 28-02-2012
</pre>

==Abstract==

This BIP describes a new JSON-RPC method for "smart" Bitcoin miners and proxies.
Instead of sending a simple block header for hashing, the entire block structure is sent, and left to the miner to (optionally) customize and assemble.

==Specification==

===JSON-RPC Method: getmemorypool===

A new JSON-RPC method is defined, called "getmemorypool".
It takes no arguments.
If arguments are provided, it may wrap the "submitblock" JSON-RPC method (described later), cast to a Boolean return value (true = share accepted).

getmemorypool MUST return a JSON Object containing at least the following keys, all of which relate to the block header:
{| class="wikitable"
! Key !! Required !! Type !! Description
|-
| bits || {{Yes}} || String || the big-endian compressed difficulty in hexadecimal
|-
| previousblockhash || {{Yes}} || String || the hash of the previous block, in little endian converted to hexadecimal
|-
| time || {{Yes}} || Number || the recommended time
|-
| transactions || {{Yes|Should}} || Array of Strings || Bitcoin transactions encoded in hexadecimal (byte-for-byte), not including coinbase
|-
| version || {{Yes}} || Number || always 1 (at least for bitcoin)
|-
| coinbasetxn || {{Patch|or ↓}} || String || hexadecimal byte-for-byte coinbase transaction
|-
| coinbasevalue || {{Patch|or ↑}} || Number || total funds available for the coinbase
|-
| coinbaseaux || {{No}} || Object || data that SHOULD or MUST (depending on mutable flags) be included in the coinbase's scriptSig content. Only the values (hexadecimal byte-for-byte) in this Object should be included, not the keys.
|-
| curtime || {{No}} || Number || TODO?
|-
| expires || {{No}} || Number || how many seconds (beginning from when the server sent the response) this work is valid for, at most
|-
| fulltarget || {{No}} || String || the number which full results should be less than, in little-endian hexadecimal (see [[#Mutations|"share/*" mutations]])
|-
| longpoll || {{No}} || String || URI for [[#Long Polling|long polling]]
|-
| maxtime || {{No}} || Number || the maximum time allowed
|-
| maxtimeoff || {{No}} || Number || the maximum time allowed (as a moving offset from 'time' - every second, the actual maxtime is incremented by 1; for example, "maxtimeoff":0 means "time" may be incremented by 1 every second)
|-
| mintime || {{No}} || Number || the minimum time allowed
|-
| mutable || {{No}} || Array of Strings || different manipulations that the server explicitly allows to be made (see [[#Mutations|Mutations]])
|-
| noncerange || {{No}} || String || two 32-bit integers, concatenated in big-endian hexadecimal, which represent the valid ranges of nonces the miner may scan
|-
| submitold || {{No}} || Boolean || only relevant for [[#Long Polling|long poll]] responses; indicates if work received prior to this response remains potentially valid (default) and should have its shares submitted; if false, the miner may wish to discard its share queue
|-
| target || {{No}} || String || the number which valid results must be less than, in little-endian hexadecimal
|-
| txrequired || {{No}} || Number || this many of the first transactions provided must be present in the final block, even if the "transactions/remove" mutation is allowed
|-
| workid || {{No}} || String or Number || if provided, this value must be returned with results (see [[#JSON-RPC Method: submitblock|"submitblock"]])
|}

====Mutations====

Any of these may be listed in the "mutable" key to signify modifications the miner is allowed to make:

{| class="wikitable"
! Value !! Significance
|-
| coinbase/append
| append the provided coinbase scriptSig
|-
| coinbase
| provide their own coinbase; if one is provided, it may be replaced or modified (implied if "coinbasetxn" omitted)
|-
| generation
| add or remove outputs from the coinbase/generation transaction (implied if "coinbasetxn" omitted)
|-
| share/merkle
| if the block hash is less than "target", but not less than "fulltarget", only return the block header, coinbase transaction, and merkle tree connecting that transaction to the root (in the form of repeated right-side SHA256 hashes) in "submitblock"
|-
| share/truncate
| if the block hash is less than "target", but not less than "fulltarget", only return the block header in "submitblock"
|-
| time/increment
| change the time header to a value after "time" (implied if "maxtime" or "maxtimeoff" are provided)
|-
| time/decrement
| change the time header to a value before "time" (implied if "mintime" is provided)
|-
| time
| modify the time header of the block
|-
| transactions/add
| add other valid transactions to the block
|-
| transactions/remove
| remove transactions provided by the server
|-
| transactions
| add or remove transactions (both of the above; default if "transactions" omitted)
|-
| prevblock
| use the work with other previous-blocks; this implicitly allows removing transactions that are no longer valid, unless they are part of the "transactionsrequired" count
|}

Note that miners are NOT required to implement any of these mutations.

==== Long Polling ====
If the server supports long polling, it SHOULD include the "longpoll" key with a relative or absolute URI.
The absolute URI MAY specify a different port than the original connection.
Miners MAY start a request to this long polling URI with a standard JSON-RPC request (POST with data) and same basic authorization.
This request SHOULD NOT be processed nor answered by the server until it wishes to replace the current block data.
Clients SHOULD make this request with a very long request timeout and MUST accept the server sending response headers with "chunked" Transfer-Encoding delaying the completion of the final JSON response.

Upon receiving a completed response:
* Only if "submitold" is provided and false, the client MAY discard the results of past operations and MUST begin working on the new work immediately.
* The client SHOULD begin working on the new work received as soon as possible, if not immediately.
* The client SHOULD make a new request to the same long polling URI.

If a client receives an incomplete or invalid response, it SHOULD retry the request with an exponential backoff.
Clients MAY implement this backoff with limitations (such as maximum backoff time) or any algorithm as deemed suitable.
It is however forbidden to simply retry immediately with no delay after more than one failure.
In the case of a "Forbidden" response (for example, HTTP 403), a client SHOULD NOT attempt to retry without user intervention.

===JSON-RPC Method: submitblock===
A new JSON-RPC method is defined, called "submitblock".
It takes one to two arguments.
The first argument is the block data; this may be truncated or merkle-ified depending on the "share/truncate" or "share/merkle" mutations, respectively.
The second argument, if provided, is an Object.
The only defined key of this Object is the "workid" provided by the server:
if a "workid" was specified, it must be submitted with the share/block.

This method MUST return either null (when a share is accepted), a String describing briefly the reason the share was rejected, or an Object of these with a key for each merged-mining chain the share was submitted to.

Possible reasons a share may be rejected include, but are not limited to:
{| class="wikitable"
! Reason !! Description
|-
| bad-cb-flag || the server detected a feature-signifying flag that it does not allow
|-
| bad-cb-length || the coinbase was too long (bitcoin limit is 100 bytes)
|-
| bad-cb-prefix || the server only allows appending to the coinbase, but it was modified beyond that
|-
| bad-diffbits || "bits" were changed
|-
| bad-prevblk || the previous-block is not the one the server intends to build on
|-
| bad-txnmrklroot || the block header's merkle root did not match the transaction merkle tree
|-
| bad-txns || the server didn't like something about the transactions in the block
|-
| bad-version || the version was wrong
|-
| duplicate || the server already processed this block data
|-
| high-hash || the block header did not hash to a value lower than the specified target
|-
| rejected || a generic rejection without details
|-
| stale-prevblk || the previous-block is no longer the one the server intends to build on
|-
| stale-work || the work this block was based on is no longer accepted
|-
| time-invalid || the time was not acceptable
|-
| time-too-new || the time was too far in the future
|-
| time-too-old || the time was too far in the past
|-
| unknown-user || the user submitting the block was not recognized
|-
| unknown-work || the template or workid could not be identified
|}

==Motivation==

There is reasonable concerns about mining currently being too centralized on pools, and the amount of control these pools hold.
By exposing the details of the block proposals to the miners, they are enabled to audit and possibly modify the block before hashing it.

There is also a very minor load reduction on the pool server, since it does not need to calculate SHA256 for the block's merkle tree.

==Reference Implementation==

* [https://gitorious.org/bitcoin/eloipool Eloipool]
* [http://luke.dashjr.org/programs/bitcoin/w/bitcoind/luke-jr.git/blobdiff/722d9387be4b267b689d7b7d78daeb7157bd12d8..gmp_bip:/src/bitcoinrpc.cpp bitcoind]

[[Category:BIP|D]]

P2Pool

2012-02-19T20:57:21Z

Forrestv: added line breaks

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

<blockquote>P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 10 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target. Whenever a peer announces a new share found (new block in the P2Pool block chain), it is received by the other peers, and the other peers verify that this block contains payouts for all the previous miners who found a share (and announced it) that made it into the P2Pool share chain. This continues until some peer finds a block that has a difficulty that meets the Bitcoin network's difficulty target. This peer announces this block to the Bitcoin network and miners who have submitted shares for this block are paid in the generation transaction, proportionally to how many shares they have found in the last while. - Unknown author</blockquote>

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin, avoids the risk of hard to detect theft by pool operators, and 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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization some Bitcoin supporters donate to P2Pool miners, resulting in returns 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, just as Bitcoin regulates it to generate one block every ten minutes.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640, whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is 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 bitcoind.

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: put rpcuser=USER, rpcpassword=LONG_RANDOM_SECRET_VALUE, and server=1 in bitcoin.conf (on separate lines)
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** 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
** Source: python run_p2pool.py
* Run a miner daemon with long polling connecting to 127.0.0.1 (or the IP of the host running p2pool if it isn't on the same computer as the miner) on port 9332 with any username and password
** cgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher
* python-argparse for Python 2.6 and lower
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does cgminer report so many longpoll events when mining on p2pool? - P4Man" 
'''A:''' "Once every ~10 seconds is normal. That is how often p2pool shares are generated (as opposed to ~10 min for bitcoin blocks) - cabin"

'''Q:''' "Do the 'orphan' and 'dead' shares in P2Pool's status display hurt me?" 
'''A:''' They shouldn't - It's normal for some fraction of everyone's shares to end up orphaned or dead. Because payouts are calculated by counting how many shares you have relative to others, everyone with normal configurations is equally "hurt" by this. However, if you have a large proportion of stales, your payout will be hurt. You can see how well you're doing by looking at P2Pool's "Efficiency" (ex: ''Efficiency: ~110.6% (40-111%)''). If 100% doesn't lie within the [http://en.wikipedia.org/wiki/Confidence_interval confidence interval] at the end, something is probably wrong (with 95% confidence).

'''Q:''' "What do I do if my efficiency is low?" 
'''A:''' If you have a lot of dead shares or the "Local dead on arrival" number is higher than a few percent, that means that something is wrong with your miner. Check to make sure that it is one of the working versions in the ''Miners'' section on this page. Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. Lower the intensity or raise the FPS of your miner. If you have a lot of orphan shares, something is wrong with P2Pool's P2P connection. Don't overload your internet connection or enable QoS (Quality of Service) on your router.

'''Q:''' What is PPLNS? 
'''A:''' Pay-Per-Last-N-Shares is a payout method that is completely resistant to pool hoppers.

'''Q:''' Why am I not getting any shares with my NVIDIA after waiting a whole 5 minutes?! 
'''A:''' The P2Pool difficulty is hundreds of times higher than on normal pools. It can take time to get a share. P2Pool displays an estimate of how long you have to wait in the console output.

'''Q:''' Why am I getting so many rejects? 
'''A:''' You're using an incompatible miner. See the miners section here, increase your FPS on the miner, decrease the intensity, upgrade your miner, or try a different miner.

'''Q:''' What stops the pool operator or the block finder from stealing a block? 
'''A:''' A block solution is only worth anything because its hash matches Bitcoin's target. Altering anything within the block will change its hash and make it worthless.

'''Q:''' Why does it say "Generated?" I want to spend my coins now! 
'''A:''' P2Pool includes payouts in generation transactions, which must mature (taking 120 blocks or 20 hours) before they can be spent. The reason for this is that a block could be orphaned, which would make its payout invalid and could reverse transactions.

'''Q:''' Do I get paid transaction fees? 
'''A:''' Yes. They are split among P2Pool miners.

'''Q:''' What are these payments I'm getting that aren't generated? 
'''A:''' These are subsidies that people who support the idea of P2Pool send to miners.

'''Q:''' Cool Subsidies sound like an awesome idea! How do I send some BTC to these awesome miners? 
'''A:''' See end of this page.

'''Q:''' Do I really need the WHOLE blockchain? 
'''A:''' Yes. Your node needs to be able to independently make decisions about what transactions to mine.

'''Q:''' How do merged mining payments work? 
'''A:''' Merged mining is handled entirely by namecoind, so you're solo mining and payouts will go into namecoind's wallet.

=== 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 intensity (8 for cgminer?) helps a lot with reducing stales.

* cgminer works perfectly without any extra options. However, using multiple pools might cause problems, because long polling is only done for one pool.
* ufasoft works perfectly.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seemless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.
* You can make P2Pool use a configuration file by running run_p2pool.py @FILENAME, with FILENAME being the path to a file containing the command-line arguments (newlines are ignored) Example:
<pre>
--net litecoin
-n 1.2.3.4
</pre>
* Setting the username of your miner connecting to P2Pool to a Bitcoin address will make it mine to that address instead of the one requested from bitcoind or set by -a

=== Web interface ===

Lots of data and useful tools are available at http://127.0.0.1:9332/something:
* /graphs - RRD graphs of past hash rates for pool and local miners. Look for "VIP password" in P2Pool's output when it starts and use that for your miners to get graphs for individual miners.
* /rate
* /users
* /fee
* /current_payouts
* /patron_sendmany - Gives sendmany outputs for fair donations to P2Pool
* /global_stats
* /local_stats
* /peer_addresses
* /payout_addr
* /recent_blocks
* /uptime
* /chain_img - Visualization of sharechain
* /web/log - Some different stats collected over the last day

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin, litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--merged-url MERGED_URL]
[--merged-userpass MERGED_USERPASS]
[--give-author DONATION_PERCENTAGE] [--irc-announce]
[--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_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version 28a1948)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin, litecoin}
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>)
--datadir DATADIR store data in this directory (default: <directory
run_p2pool.py is in>/data)
--logfile LOGFILE log to this file (default: data/<NET>/log)
--merged MERGED_URLS call getauxblock on this url to get work for merged
mining (example:
http://ncuser:ncpass@127.0.0.1:10332/)
--merged-url MERGED_URL
DEPRECATED, use --merged
--merged-userpass MERGED_USERPASS
DEPRECATED, use --merged
--give-author DONATION_PERCENTAGE
donate this percentage of work to author of p2pool
(default: 0.5)
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--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)
-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)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:

For example, a bash script to donate 10 btc is:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany?total=10)"
</pre>

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.

Note that the amount you donate will be allocated to recent miners in proportion to the amount of work they've done in the last 24 hours or so, but all the miner whose shares of the donated amount are less than 0.01 BTC will have their shares combined into a single amount which is awarded to one of them at random, with the chance of winning this 'lottery' weighted by the miner's recent amount of work done. You can change this 0.01 BTC threshold like this, for example, which says to pay 10 BTC, but to share it amongst more miners that the default, cutting off at 0.001 BTC instead of at 0.01 BTC.
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany?total=10/0.001)"
</pre>

If you decide to donate you should announce it on the forums so that your donations provide the most incentive possible.

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support
* [http://btcstats.net/p2pool/ P2Pool Stats Page]

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2012-02-19T20:56:27Z

Forrestv: added to faq

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

<blockquote>P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 10 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target. Whenever a peer announces a new share found (new block in the P2Pool block chain), it is received by the other peers, and the other peers verify that this block contains payouts for all the previous miners who found a share (and announced it) that made it into the P2Pool share chain. This continues until some peer finds a block that has a difficulty that meets the Bitcoin network's difficulty target. This peer announces this block to the Bitcoin network and miners who have submitted shares for this block are paid in the generation transaction, proportionally to how many shares they have found in the last while. - Unknown author</blockquote>

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin, avoids the risk of hard to detect theft by pool operators, and 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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization some Bitcoin supporters donate to P2Pool miners, resulting in returns 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, just as Bitcoin regulates it to generate one block every ten minutes.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640, whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is 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 bitcoind.

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: put rpcuser=USER, rpcpassword=LONG_RANDOM_SECRET_VALUE, and server=1 in bitcoin.conf (on separate lines)
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** 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
** Source: python run_p2pool.py
* Run a miner daemon with long polling connecting to 127.0.0.1 (or the IP of the host running p2pool if it isn't on the same computer as the miner) on port 9332 with any username and password
** cgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher
* python-argparse for Python 2.6 and lower
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does cgminer report so many longpoll events when mining on p2pool? - P4Man" 
'''A:''' "Once every ~10 seconds is normal. That is how often p2pool shares are generated (as opposed to ~10 min for bitcoin blocks) - cabin"

'''Q:''' "Do the 'orphan' and 'dead' shares in P2Pool's status display hurt me?" 
'''A:''' They shouldn't - It's normal for some fraction of everyone's shares to end up orphaned or dead. Because payouts are calculated by counting how many shares you have relative to others, everyone with normal configurations is equally "hurt" by this. However, if you have a large proportion of stales, your payout will be hurt. You can see how well you're doing by looking at P2Pool's "Efficiency" (ex: ''Efficiency: ~110.6% (40-111%)''). If 100% doesn't lie within the [http://en.wikipedia.org/wiki/Confidence_interval confidence interval] at the end, something is probably wrong (with 95% confidence).

'''Q:''' "What do I do if my efficiency is low?" 
'''A:''' If you have a lot of dead shares or the "Local dead on arrival" number is higher than a few percent, that means that something is wrong with your miner. Check to make sure that it is one of the working versions in the ''Miners'' section on this page. Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. Lower the intensity or raise the FPS of your miner. If you have a lot of orphan shares, something is wrong with P2Pool's P2P connection. Don't overload your internet connection or enable QoS (Quality of Service) on your router.

'''Q:''' What is PPLNS?
'''A:''' Pay-Per-Last-N-Shares is a payout method that is completely resistant to pool hoppers.

'''Q:''' Why am I not getting any shares with my NVIDIA after waiting a whole 5 minutes?!
'''A:''' The P2Pool difficulty is hundreds of times higher than on normal pools. It can take time to get a share. P2Pool displays an estimate of how long you have to wait in the console output.

'''Q:''' Why am I getting so many rejects?
'''A:''' You're using an incompatible miner. See the miners section here, increase your FPS on the miner, decrease the intensity, upgrade your miner, or try a different miner.

'''Q:''' What stops the pool operator or the block finder from stealing a block?
'''A:''' A block solution is only worth anything because its hash matches Bitcoin's target. Altering anything within the block will change its hash and make it worthless.

'''Q:''' Why does it say "Generated?" I want to spend my coins now!
'''A:''' P2Pool includes payouts in generation transactions, which must mature (taking 120 blocks or 20 hours) before they can be spent. The reason for this is that a block could be orphaned, which would make its payout invalid and could reverse transactions.

'''Q:''' Do I get paid transaction fees?
'''A:''' Yes.

'''Q:''' What are these payments I'm getting that aren't generated?
'''A:''' These are subsidies that people who support the idea of P2Pool send to miners.

'''Q:''' Cool Subsidies sound like an awesome idea! How do I send some BTC to these awesome miners?
'''A:''' See end of this page.

'''Q:''' Do I really need the WHOLE blockchain?
'''A:''' Yes. Your node needs to be able to independently make decisions about what transactions to mine.

'''Q:''' How do merged mining payments work?
'''A:''' Merged mining is handled entirely by namecoind, so you're solo mining and payouts will go into namecoind's wallet.

=== 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 intensity (8 for cgminer?) helps a lot with reducing stales.

* cgminer works perfectly without any extra options. However, using multiple pools might cause problems, because long polling is only done for one pool.
* ufasoft works perfectly.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seemless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.
* You can make P2Pool use a configuration file by running run_p2pool.py @FILENAME, with FILENAME being the path to a file containing the command-line arguments (newlines are ignored) Example:
<pre>
--net litecoin
-n 1.2.3.4
</pre>
* Setting the username of your miner connecting to P2Pool to a Bitcoin address will make it mine to that address instead of the one requested from bitcoind or set by -a

=== Web interface ===

Lots of data and useful tools are available at http://127.0.0.1:9332/something:
* /graphs - RRD graphs of past hash rates for pool and local miners. Look for "VIP password" in P2Pool's output when it starts and use that for your miners to get graphs for individual miners.
* /rate
* /users
* /fee
* /current_payouts
* /patron_sendmany - Gives sendmany outputs for fair donations to P2Pool
* /global_stats
* /local_stats
* /peer_addresses
* /payout_addr
* /recent_blocks
* /uptime
* /chain_img - Visualization of sharechain
* /web/log - Some different stats collected over the last day

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin, litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--merged-url MERGED_URL]
[--merged-userpass MERGED_USERPASS]
[--give-author DONATION_PERCENTAGE] [--irc-announce]
[--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_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version 28a1948)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin, litecoin}
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>)
--datadir DATADIR store data in this directory (default: <directory
run_p2pool.py is in>/data)
--logfile LOGFILE log to this file (default: data/<NET>/log)
--merged MERGED_URLS call getauxblock on this url to get work for merged
mining (example:
http://ncuser:ncpass@127.0.0.1:10332/)
--merged-url MERGED_URL
DEPRECATED, use --merged
--merged-userpass MERGED_USERPASS
DEPRECATED, use --merged
--give-author DONATION_PERCENTAGE
donate this percentage of work to author of p2pool
(default: 0.5)
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--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)
-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)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:

For example, a bash script to donate 10 btc is:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany?total=10)"
</pre>

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.

Note that the amount you donate will be allocated to recent miners in proportion to the amount of work they've done in the last 24 hours or so, but all the miner whose shares of the donated amount are less than 0.01 BTC will have their shares combined into a single amount which is awarded to one of them at random, with the chance of winning this 'lottery' weighted by the miner's recent amount of work done. You can change this 0.01 BTC threshold like this, for example, which says to pay 10 BTC, but to share it amongst more miners that the default, cutting off at 0.001 BTC instead of at 0.01 BTC.
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany?total=10/0.001)"
</pre>

If you decide to donate you should announce it on the forums so that your donations provide the most incentive possible.

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support
* [http://btcstats.net/p2pool/ P2Pool Stats Page]

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2012-02-17T23:57:19Z

Forrestv: typo

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

<blockquote>P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 10 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target. Whenever a peer announces a new share found (new block in the P2Pool block chain), it is received by the other peers, and the other peers verify that this block contains payouts for all the previous miners who found a share (and announced it) that made it into the P2Pool share chain. This continues until some peer finds a block that has a difficulty that meets the Bitcoin network's difficulty target. This peer announces this block to the Bitcoin network and miners who have submitted shares for this block are paid in the generation transaction, proportionally to how many shares they have found in the last while. - Unknown author</blockquote>

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin, avoids the risk of hard to detect theft by pool operators, and 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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization some Bitcoin supporters donate to P2Pool miners, resulting in returns 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, just as Bitcoin regulates it to generate one block every ten minutes.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640, whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is 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 bitcoind.

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: put rpcuser=USER, rpcpassword=LONG_RANDOM_SECRET_VALUE, and server=1 in bitcoin.conf (on separate lines)
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** 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
** Source: python run_p2pool.py
* Run a miner daemon with long polling connecting to 127.0.0.1 (or the IP of the host running p2pool if it isn't on the same computer as the miner) on port 9332 with any username and password
** cgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher
* python-argparse for Python 2.6 and lower
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does cgminer report so many longpoll events when mining on p2pool? - P4Man" 
'''A:''' "Once every ~10 seconds is normal. That is how often p2pool shares are generated (as opposed to ~10 min for bitcoin blocks) - cabin"

'''Q:''' "Do the 'orphan' and 'dead' shares in P2Pool's status display hurt me?" 
'''A:''' They shouldn't - It's normal for some fraction of everyone's shares to end up orphaned or dead. Because payouts are calculated by counting how many shares you have relative to others, everyone with normal configurations is equally "hurt" by this. However, if you have a large proportion of stales, your payout will be hurt. You can see how well you're doing by looking at P2Pool's "Efficiency" (ex: ''Efficiency: ~110.6% (40-111%)''). If 100% doesn't lie within the [http://en.wikipedia.org/wiki/Confidence_interval confidence interval] at the end, something is probably wrong (with 95% confidence).

'''Q:''' "What do I do if my efficiency is low?" 
'''A:''' If you have a lot of dead shares or the "Local dead on arrival" number is higher than a few percent, that means that something is wrong with your miner. Check to make sure that it is one of the working versions in the ''Miners'' section on this page. Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. Lower the intensity or raise the FPS of your miner. If you have a lot of orphan shares, something is wrong with P2Pool's P2P connection. Don't overload your internet connection or enable QoS (Quality of Service) on your router.

=== 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 intensity (8 for cgminer?) helps a lot with reducing stales.

* cgminer works perfectly without any extra options. However, using multiple pools might cause problems, because long polling is only done for one pool.
* ufasoft works perfectly.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seemless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.
* You can make P2Pool use a configuration file by running run_p2pool.py @FILENAME, with FILENAME being the path to a file containing the command-line arguments (newlines are ignored) Example:
<pre>
--net litecoin
-n 1.2.3.4
</pre>
* Setting the username of your miner connecting to P2Pool to a Bitcoin address will make it mine to that address instead of the one requested from bitcoind or set by -a

=== Web interface ===

Lots of data and useful tools are available at http://127.0.0.1:9332/something:
* /graphs - RRD graphs of past hash rates for pool and local miners. Look for "VIP password" in P2Pool's output when it starts and use that for your miners to get graphs for individual miners.
* /rate
* /users
* /fee
* /current_payouts
* /patron_sendmany - Gives sendmany outputs for fair donations to P2Pool
* /global_stats
* /local_stats
* /peer_addresses
* /payout_addr
* /recent_blocks
* /uptime
* /chain_img - Visualization of sharechain
* /web/log - Some different stats collected over the last day

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin, litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--merged-url MERGED_URL]
[--merged-userpass MERGED_USERPASS]
[--give-author DONATION_PERCENTAGE] [--irc-announce]
[--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_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version 28a1948)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin, litecoin}
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>)
--datadir DATADIR store data in this directory (default: <directory
run_p2pool.py is in>/data)
--logfile LOGFILE log to this file (default: data/<NET>/log)
--merged MERGED_URLS call getauxblock on this url to get work for merged
mining (example:
http://ncuser:ncpass@127.0.0.1:10332/)
--merged-url MERGED_URL
DEPRECATED, use --merged
--merged-userpass MERGED_USERPASS
DEPRECATED, use --merged
--give-author DONATION_PERCENTAGE
donate this percentage of work to author of p2pool
(default: 0.5)
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--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)
-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)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:

For example, a bash script to donate 10 btc is:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany?total=10)"
</pre>

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.

Note that the amount you donate will be allocated to recent miners in proportion to the amount of work they've done in the last 24 hours or so, but all the miner whose shares of the donated amount are less than 0.01 BTC will have their shares combined into a single amount which is awarded to one of them at random, with the chance of winning this 'lottery' weighted by the miner's recent amount of work done. You can change this 0.01 BTC threshold like this, for example, which says to pay 10 BTC, but to share it amongst more miners that the default, cutting off at 0.001 BTC instead of at 0.01 BTC.
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany?total=10/0.001)"
</pre>

If you decide to donate you should announce it on the forums so that your donations provide the most incentive possible.

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support
* [http://btcstats.net/p2pool/ P2Pool Stats Page]

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2012-02-12T16:25:24Z

Forrestv: added web interface docs

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

<blockquote>P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 10 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target. Whenever a peer announces a new share found (new block in the P2Pool block chain), it is received by the other peers, and the other peers verify that this block contains payouts for all the previous miners who found a share (and announced it) that made it into the P2Pool share chain. This continues until some peer finds a block that has a difficulty that meets the Bitcoin network's difficulty target. This peer announces this block to the Bitcoin network and miners who have submitted shares for this block are paid in the generation transaction, proportionally to how many shares they have found in the last while. - Unknown author</blockquote>

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin, avoids the risk of hard to detect theft by pool operators, and 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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization some Bitcoin supporters donate to P2Pool miners, resulting in returns 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, just as Bitcoin regulates it to generate one block every ten minutes.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640, whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is 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 bitcoind.

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: put rpcuser=USER, rpcpassword=LONG_RANDOM_SECRET_VALUE, and server=1 in bitcoin.conf (on separate lines)
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** 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
** Source: python run_p2pool.py
* Run a miner daemon with long polling connecting to 127.0.0.1 (or the IP of the host running p2pool if it isn't on the same computer as the miner) on port 9332 with any username and password
** cgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher
* python-argparse for Python 2.6 and lower
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does cgminer report so many longpoll events when mining on p2pool? - P4Man" 
'''A:''' "Once every ~10 seconds is normal. That is how often p2pool shares are generated (as opposed to ~10 min for bitcoin blocks) - cabin"

'''Q:''' "Do the 'orphan' and 'dead' shares in P2Pool's status display hurt me?" 
'''A:''' They shouldn't - It's normal for some fraction of everyone's shares to end up orphaned or dead. Because payouts are calculated by counting how many shares you have relative to others, everyone with normal configurations is equally "hurt" by this. However, if you have a large proportion of stales, your payout will be hurt. You can see how well you're doing by looking at P2Pool's "Efficiency" (ex: ''Efficiency: ~110.6% (40-111%)''). If 100% doesn't lie within the [http://en.wikipedia.org/wiki/Confidence_interval confidence interval] at the end, something is probably wrong (with 5% confidence).

'''Q:''' "What do I do if my efficiency is low?" 
'''A:''' If you have a lot of dead shares or the "Local dead on arrival" number is higher than a few percent, that means that something is wrong with your miner. Check to make sure that it is one of the working versions in the ''Miners'' section on this page. Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. Lower the intensity or raise the FPS of your miner. If you have a lot of orphan shares, something is wrong with P2Pool's P2P connection. Don't overload your internet connection or enable QoS (Quality of Service) on your router.

=== 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 intensity (8 for cgminer?) helps a lot with reducing stales.

* cgminer works perfectly without any extra options. However, using multiple pools might cause problems, because long polling is only done for one pool.
* ufasoft works perfectly.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seemless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.
* You can make P2Pool use a configuration file by running run_p2pool.py @FILENAME, with FILENAME being the path to a file containing the command-line arguments (newlines are ignored) Example:
<pre>
--net litecoin
-n 1.2.3.4
</pre>
* Setting the username of your miner connecting to P2Pool to a Bitcoin address will make it mine to that address instead of the one requested from bitcoind or set by -a

=== Web interface ===

Lots of data and useful tools are available at http://127.0.0.1:9332/something:
* /graphs - RRD graphs of past hash rates for pool and local miners. Look for "VIP password" in P2Pool's output when it starts and use that for your miners to get graphs for individual miners.
* /rate
* /users
* /fee
* /current_payouts
* /patron_sendmany - Gives sendmany outputs for fair donations to P2Pool
* /global_stats
* /local_stats
* /peer_addresses
* /payout_addr
* /recent_blocks
* /uptime
* /chain_img - Visualization of sharechain
* /web/log - Some different stats collected over the last day

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin, litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--merged-url MERGED_URL]
[--merged-userpass MERGED_USERPASS]
[--give-author DONATION_PERCENTAGE] [--irc-announce]
[--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_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version 28a1948)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin, litecoin}
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>)
--datadir DATADIR store data in this directory (default: <directory
run_p2pool.py is in>/data)
--logfile LOGFILE log to this file (default: data/<NET>/log)
--merged MERGED_URLS call getauxblock on this url to get work for merged
mining (example:
http://ncuser:ncpass@127.0.0.1:10332/)
--merged-url MERGED_URL
DEPRECATED, use --merged
--merged-userpass MERGED_USERPASS
DEPRECATED, use --merged
--give-author DONATION_PERCENTAGE
donate this percentage of work to author of p2pool
(default: 0.5)
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--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)
-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)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany?total=1)"
</pre>

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==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2012-02-11T23:41:37Z

Forrestv: added bitcoin address as miner username info

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

<blockquote>P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 10 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target. Whenever a peer announces a new share found (new block in the P2Pool block chain), it is received by the other peers, and the other peers verify that this block contains payouts for all the previous miners who found a share (and announced it) that made it into the P2Pool share chain. This continues until some peer finds a block that has a difficulty that meets the Bitcoin network's difficulty target. This peer announces this block to the Bitcoin network and miners who have submitted shares for this block are paid in the generation transaction, proportionally to how many shares they have found in the last while. - Unknown author</blockquote>

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin, avoids the risk of hard to detect theft by pool operators, and 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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization some Bitcoin supporters donate to P2Pool miners, resulting in returns 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, just as Bitcoin regulates it to generate one block every ten minutes.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640, whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is 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 bitcoind.

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: put rpcuser=USER, rpcpassword=LONG_RANDOM_SECRET_VALUE, and server=1 in bitcoin.conf (on separate lines)
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** 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
** Source: python run_p2pool.py
* Run a miner daemon with long polling connecting to 127.0.0.1 (or the IP of the host running p2pool if it isn't on the same computer as the miner) on port 9332 with any username and password
** cgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher
* python-argparse for Python 2.6 and lower
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does cgminer report so many longpoll events when mining on p2pool? - P4Man" 
'''A:''' "Once every ~10 seconds is normal. That is how often p2pool shares are generated (as opposed to ~10 min for bitcoin blocks) - cabin"

'''Q:''' "Do the 'orphan' and 'dead' shares in P2Pool's status display hurt me?" 
'''A:''' They shouldn't - It's normal for some fraction of everyone's shares to end up orphaned or dead. Because payouts are calculated by counting how many shares you have relative to others, everyone with normal configurations is equally "hurt" by this. However, if you have a large proportion of stales, your payout will be hurt. You can see how well you're doing by looking at P2Pool's "Efficiency" (ex: ''Efficiency: ~110.6% (40-111%)''). If 100% doesn't lie within the [http://en.wikipedia.org/wiki/Confidence_interval confidence interval] at the end, something is probably wrong (with 5% confidence).

'''Q:''' "What do I do if my efficiency is low?" 
'''A:''' If you have a lot of dead shares or the "Local dead on arrival" number is higher than a few percent, that means that something is wrong with your miner. Check to make sure that it is one of the working versions in the ''Miners'' section on this page. Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. Lower the intensity or raise the FPS of your miner. If you have a lot of orphan shares, something is wrong with P2Pool's P2P connection. Don't overload your internet connection or enable QoS (Quality of Service) on your router.

=== 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 intensity (8 for cgminer?) helps a lot with reducing stales.

* cgminer works perfectly without any extra options. However, using multiple pools might cause problems, because long polling is only done for one pool.
* ufasoft works perfectly.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seemless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.
* You can make P2Pool use a configuration file by running run_p2pool.py @FILENAME, with FILENAME being the path to a file containing the command-line arguments (newlines are ignored) Example:
<pre>
--net litecoin
-n 1.2.3.4
</pre>
* Setting the username of your miner connecting to P2Pool to a Bitcoin address will make it mine to that address instead of the one requested from bitcoind or set by -a

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin, litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--merged-url MERGED_URL]
[--merged-userpass MERGED_USERPASS]
[--give-author DONATION_PERCENTAGE] [--irc-announce]
[--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_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version 28a1948)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin, litecoin}
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>)
--datadir DATADIR store data in this directory (default: <directory
run_p2pool.py is in>/data)
--logfile LOGFILE log to this file (default: data/<NET>/log)
--merged MERGED_URLS call getauxblock on this url to get work for merged
mining (example:
http://ncuser:ncpass@127.0.0.1:10332/)
--merged-url MERGED_URL
DEPRECATED, use --merged
--merged-userpass MERGED_USERPASS
DEPRECATED, use --merged
--give-author DONATION_PERCENTAGE
donate this percentage of work to author of p2pool
(default: 0.5)
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--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)
-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)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany?total=1)"
</pre>

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==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2012-02-09T21:50:38Z

Forrestv: updated help text

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

<blockquote>P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 10 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target. Whenever a peer announces a new share found (new block in the P2Pool block chain), it is received by the other peers, and the other peers verify that this block contains payouts for all the previous miners who found a share (and announced it) that made it into the P2Pool share chain. This continues until some peer finds a block that has a difficulty that meets the Bitcoin network's difficulty target. This peer announces this block to the Bitcoin network and miners who have submitted shares for this block are paid in the generation transaction, proportionally to how many shares they have found in the last while. - Unknown author</blockquote>

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin, avoids the risk of hard to detect theft by pool operators, and 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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization some Bitcoin supporters donate to P2Pool miners, resulting in returns 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, just as Bitcoin regulates it to generate one block every ten minutes.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640, whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is 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 bitcoind.

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: put rpcuser=USER, rpcpassword=LONG_RANDOM_SECRET_VALUE, and server=1 in bitcoin.conf (on separate lines)
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** 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
** Source: python run_p2pool.py
* Run a miner daemon with long polling connecting to 127.0.0.1 (or the IP of the host running p2pool if it isn't on the same computer as the miner) on port 9332 with any username and password
** cgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher
* python-argparse for Python 2.6 and lower
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does cgminer report so many longpoll events when mining on p2pool? - P4Man" 
'''A:''' "Once every ~10 seconds is normal. That is how often p2pool shares are generated (as opposed to ~10 min for bitcoin blocks) - cabin"

'''Q:''' "Do the 'orphan' and 'dead' shares in P2Pool's status display hurt me?" 
'''A:''' They shouldn't - It's normal for some fraction of everyone's shares to end up orphaned or dead. Because payouts are calculated by counting how many shares you have relative to others, everyone with normal configurations is equally "hurt" by this. However, if you have a large proportion of stales, your payout will be hurt. You can see how well you're doing by looking at P2Pool's "Efficiency" (ex: ''Efficiency: ~110.6% (40-111%)''). If 100% doesn't lie within the [http://en.wikipedia.org/wiki/Confidence_interval confidence interval] at the end, something is probably wrong (with 5% confidence).

'''Q:''' "What do I do if my efficiency is low?" 
'''A:''' If you have a lot of dead shares or the "Local dead on arrival" number is higher than a few percent, that means that something is wrong with your miner. Check to make sure that it is one of the working versions in the ''Miners'' section on this page. Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. Lower the intensity or raise the FPS of your miner. If you have a lot of orphan shares, something is wrong with P2Pool's P2P connection. Don't overload your internet connection or enable QoS (Quality of Service) on your router.

=== 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 intensity (8 for cgminer?) helps a lot with reducing stales.

* cgminer works perfectly without any extra options. However, using multiple pools might cause problems, because long polling is only done for one pool.
* ufasoft works perfectly.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seemless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.
* You can make P2Pool use a configuration file by running run_p2pool.py @FILENAME, with FILENAME being the path to a file containing the command-line arguments (newlines are ignored) Example:
<pre>
--net litecoin
-n 1.2.3.4
</pre>

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin, litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--merged-url MERGED_URL]
[--merged-userpass MERGED_USERPASS]
[--give-author DONATION_PERCENTAGE] [--irc-announce]
[--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_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version 28a1948)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin, litecoin}
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>)
--datadir DATADIR store data in this directory (default: <directory
run_p2pool.py is in>/data)
--logfile LOGFILE log to this file (default: data/<NET>/log)
--merged MERGED_URLS call getauxblock on this url to get work for merged
mining (example:
http://ncuser:ncpass@127.0.0.1:10332/)
--merged-url MERGED_URL
DEPRECATED, use --merged
--merged-userpass MERGED_USERPASS
DEPRECATED, use --merged
--give-author DONATION_PERCENTAGE
donate this percentage of work to author of p2pool
(default: 0.5)
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--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)
-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)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany?total=1)"
</pre>

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==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2012-02-09T21:49:50Z

Forrestv: added configuration file usage

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

<blockquote>P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 10 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target. Whenever a peer announces a new share found (new block in the P2Pool block chain), it is received by the other peers, and the other peers verify that this block contains payouts for all the previous miners who found a share (and announced it) that made it into the P2Pool share chain. This continues until some peer finds a block that has a difficulty that meets the Bitcoin network's difficulty target. This peer announces this block to the Bitcoin network and miners who have submitted shares for this block are paid in the generation transaction, proportionally to how many shares they have found in the last while. - Unknown author</blockquote>

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin, avoids the risk of hard to detect theft by pool operators, and 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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization some Bitcoin supporters donate to P2Pool miners, resulting in returns 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, just as Bitcoin regulates it to generate one block every ten minutes.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640, whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is 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 bitcoind.

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: put rpcuser=USER, rpcpassword=LONG_RANDOM_SECRET_VALUE, and server=1 in bitcoin.conf (on separate lines)
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** 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
** Source: python run_p2pool.py
* Run a miner daemon with long polling connecting to 127.0.0.1 (or the IP of the host running p2pool if it isn't on the same computer as the miner) on port 9332 with any username and password
** cgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher
* python-argparse for Python 2.6 and lower
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does cgminer report so many longpoll events when mining on p2pool? - P4Man" 
'''A:''' "Once every ~10 seconds is normal. That is how often p2pool shares are generated (as opposed to ~10 min for bitcoin blocks) - cabin"

'''Q:''' "Do the 'orphan' and 'dead' shares in P2Pool's status display hurt me?" 
'''A:''' They shouldn't - It's normal for some fraction of everyone's shares to end up orphaned or dead. Because payouts are calculated by counting how many shares you have relative to others, everyone with normal configurations is equally "hurt" by this. However, if you have a large proportion of stales, your payout will be hurt. You can see how well you're doing by looking at P2Pool's "Efficiency" (ex: ''Efficiency: ~110.6% (40-111%)''). If 100% doesn't lie within the [http://en.wikipedia.org/wiki/Confidence_interval confidence interval] at the end, something is probably wrong (with 5% confidence).

'''Q:''' "What do I do if my efficiency is low?" 
'''A:''' If you have a lot of dead shares or the "Local dead on arrival" number is higher than a few percent, that means that something is wrong with your miner. Check to make sure that it is one of the working versions in the ''Miners'' section on this page. Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. Lower the intensity or raise the FPS of your miner. If you have a lot of orphan shares, something is wrong with P2Pool's P2P connection. Don't overload your internet connection or enable QoS (Quality of Service) on your router.

=== 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 intensity (8 for cgminer?) helps a lot with reducing stales.

* cgminer works perfectly without any extra options. However, using multiple pools might cause problems, because long polling is only done for one pool.
* ufasoft works perfectly.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seemless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.
* You can make P2Pool use a configuration file by running run_p2pool.py @FILENAME, with FILENAME being the path to a file containing the command-line arguments (newlines are ignored) Example:
<pre>
--net litecoin
-n 1.2.3.4
</pre>

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin, litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--logfile LOGFILE]
[--merged-url MERGED_URL]
[--merged-userpass MERGED_USERPASS]
[--give-author DONATION_PERCENTAGE] [--irc-announce]
[--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_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version a7d3ae4)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin, litecoin}
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)
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--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)
-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)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany?total=1)"
</pre>

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==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2012-02-08T22:19:42Z

Forrestv: added FAQ

P2Pool

2012-02-06T17:25:22Z

Forrestv: added description

P2Pool

2012-02-04T17:06:38Z

Forrestv: updated instructions

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin, avoids the risk of hard to detect theft by pool operators, and 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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization some Bitcoin supporters donate to P2Pool miners, resulting in returns 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, just as Bitcoin regulates it to generate one block every ten minutes.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640, whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is 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 bitcoind.

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: put rpcuser=USER, rpcpassword=LONG_RANDOM_SECRET_VALUE, and server=1 in bitcoin.conf (on separate lines)
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** 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
** Source: python run_p2pool.py
* 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/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher
* 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 intensity (8 for cgminer?) helps a lot with reducing stales.

* cgminer works perfectly without any extra options. However, using multiple pools might cause problems, because long polling is only done for one pool.
* ufasoft works perfectly.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seemless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin, litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--logfile LOGFILE]
[--merged-url MERGED_URL]
[--merged-userpass MERGED_USERPASS]
[--give-author DONATION_PERCENTAGE] [--irc-announce]
[--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_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version a7d3ae4)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin, litecoin}
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)
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--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)
-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)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany?total=1)"
</pre>

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==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2012-02-04T05:01:31Z

Forrestv: changed default donation from 10BTC to 1BTC.. don't want people complaining if they copy/paste it as is accidentally

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin, avoids the risk of hard to detect theft by pool operators, and 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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization some Bitcoin supporters donate to P2Pool miners, resulting in returns 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, just as Bitcoin regulates it to generate one block every ten minutes.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640, whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is 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 bitcoind.

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: put rpcuser=USER, rpcpassword=LONG_RANDOM_SECRET_VALUE, and server=1 in bitcoin.conf (on separate lines)
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** 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 LONG_RANDOM_SECRET_VALUE
** Source: python run_p2pool.py USER LONG_RANDOM_SECRET_VALUE
* 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
* 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 intensity (8 for cgminer?) helps a lot with reducing stales.

* cgminer works perfectly without any extra options. However, using multiple pools might cause problems, because long polling is only done for one pool.
* ufasoft works perfectly.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seemless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin, litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--logfile LOGFILE]
[--merged-url MERGED_URL]
[--merged-userpass MERGED_USERPASS]
[--give-author DONATION_PERCENTAGE] [--irc-announce]
[--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_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version a7d3ae4)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin, litecoin}
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)
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--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)
-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)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany?total=1)"
</pre>

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==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2012-02-04T05:00:04Z

Forrestv: undid potentially malicious donation address change by Drag

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin, avoids the risk of hard to detect theft by pool operators, and 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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization some Bitcoin supporters donate to P2Pool miners, resulting in returns 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, just as Bitcoin regulates it to generate one block every ten minutes.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640, whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is 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 bitcoind.

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: put rpcuser=USER, rpcpassword=LONG_RANDOM_SECRET_VALUE, and server=1 in bitcoin.conf (on separate lines)
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** 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 LONG_RANDOM_SECRET_VALUE
** Source: python run_p2pool.py USER LONG_RANDOM_SECRET_VALUE
* 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
* 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 intensity (8 for cgminer?) helps a lot with reducing stales.

* cgminer works perfectly without any extra options. However, using multiple pools might cause problems, because long polling is only done for one pool.
* ufasoft works perfectly.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seemless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin, litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--logfile LOGFILE]
[--merged-url MERGED_URL]
[--merged-userpass MERGED_USERPASS]
[--give-author DONATION_PERCENTAGE] [--irc-announce]
[--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_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version a7d3ae4)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin, litecoin}
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)
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--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)
-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)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany?total=10.0)"
</pre>

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==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2012-02-02T21:35:53Z

Forrestv: added "useful features" section - needs more expansion

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin, avoids the risk of hard to detect theft by pool operators, and 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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization some Bitcoin supporters donate to P2Pool miners, resulting in returns 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, just as Bitcoin regulates it to generate one block every ten minutes.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640, whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is 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 bitcoind.

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: put rpcuser=USER, rpcpassword=LONG_RANDOM_SECRET_VALUE, and server=1 in bitcoin.conf (on separate lines)
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it.
** 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 LONG_RANDOM_SECRET_VALUE
** Source: python run_p2pool.py USER LONG_RANDOM_SECRET_VALUE
* 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
* 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 intensity (8 for cgminer?) helps a lot with reducing stales.

* cgminer works perfectly without any extra options. However, using multiple pools might cause problems, because long polling is only done for one pool.
* ufasoft works perfectly.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seemless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin, litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--logfile LOGFILE]
[--merged-url MERGED_URL]
[--merged-userpass MERGED_USERPASS]
[--give-author DONATION_PERCENTAGE] [--irc-announce]
[--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_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version a7d3ae4)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin, litecoin}
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)
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--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)
-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)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 forum profile].

==Donating to P2Pool miners==
In order to encourage people to mine to P2Pool you can donate to the following bitcoin address:

16TgDchkexj3nVoN8akinrNDiMqpqPQdwc

If you decide to donate you should announce it on the forums so that your donations provide the most incentive possible.

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2012-01-31T17:33:54Z

Forrestv: updated --help text

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin, avoids the risk of hard to detect theft by pool operators, and 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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization some Bitcoin supporters donate to P2Pool miners, resulting in returns 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, just as Bitcoin regulates it to generate one block every ten minutes.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640, whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is 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 bitcoind.

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: put rpcuser=USER, rpcpassword=LONG_RANDOM_SECRET_VALUE, and server=1 in bitcoin.conf (on separate lines)
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it.
** 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 LONG_RANDOM_SECRET_VALUE
** Source: python run_p2pool.py USER LONG_RANDOM_SECRET_VALUE
* 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
* 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 intensity (8 for cgminer?) helps a lot with reducing stales.

* cgminer works perfectly without any extra options. However, using multiple pools might cause problems, because long polling is only done for one pool.
* ufasoft works perfectly.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin, litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--logfile LOGFILE]
[--merged-url MERGED_URL]
[--merged-userpass MERGED_USERPASS]
[--give-author DONATION_PERCENTAGE] [--irc-announce]
[--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_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version a7d3ae4)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin, litecoin}
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)
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--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)
-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)
-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 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 forum profile].

==Donating to P2Pool miners==
In order to encourage people to mine to P2Pool you can donate to the following bitcoin address:

16TgDchkexj3nVoN8akinrNDiMqpqPQdwc

If you decide to donate you should announce it on the forums so that your donations provide the most incentive possible.

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2012-01-28T19:45:13Z

Forrestv: updated miners

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin, avoids the risk of hard to detect theft by pool operators, and 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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization some Bitcoin supporters donate to P2Pool miners, resulting in returns 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, just as Bitcoin regulates it to generate one block every ten minutes.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640, whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is 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 bitcoind.

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 [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: put rpcuser=USER, rpcpassword=LONG_RANDOM_SECRET_VALUE, and server=1 in bitcoin.conf (on separate lines)
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it.
** 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 LONG_RANDOM_SECRET_VALUE
** Source: python run_p2pool.py USER LONG_RANDOM_SECRET_VALUE
* 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
* 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 intensity (8 for cgminer?) helps a lot with reducing stales.

* cgminer works perfectly without any extra options. However, using multiple pools might cause problems, because long polling is only done for one pool.
* ufasoft works perfectly.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

=== Option Reference ===
<pre>
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
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 forum profile].

==Donating to P2Pool miners==
In order to encourage people to mine to P2Pool you can donate to the following bitcoin address:

16TgDchkexj3nVoN8akinrNDiMqpqPQdwc

If you decide to donate you should announce it on the forums so that your donations provide the most incentive possible.

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2012-01-23T13:04:57Z

Forrestv: updates

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin, avoids the risk of hard to detect theft by pool operators, and 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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization some Bitcoin supporters donate to P2Pool miners, resulting in returns 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, just as Bitcoin regulates it to generate one block every ten minutes.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640, whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is 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 bitcoind.

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.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind 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
* 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 > 17000 shares) helps a lot with reducing stales.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

==== Works as-is ====

===== cgminer =====
Works very well as is.

===== ufasoft =====
Works as is.

===== DiabloMiner =====
Works fine after commit 3b731b9b54.

==== Needs patch to reduce stales ====

===== Poclbm =====
Waits a full second between long polls.

GitHub fork: https://github.com/forrestv/poclbm
Pull request: https://github.com/m0mchil/poclbm/pull/41
<pre>git clone git://github.com/forrestv/poclbm.git
cd poclbm
git checkout fast_long_polling</pre>

Windows binary: http://u.forre.st/u/wodukkea/p2pool-poclbm_win32_5590e7c.zip

===== Phoenix =====
(Works fine after commit 8263f65!)

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 ===
<pre>
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
</pre>

== 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'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany?total=10.0)"
</pre>

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==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2012-01-23T13:02:34Z

Forrestv: some cleanup

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin, avoids the risk of hard to detect theft by pool operators, and 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 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, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization some Bitcoin supporters donate to P2Pool miners, resulting in returns 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, just as Bitcoin regulates it to generate one block every ten minutes.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 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 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 8640, whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is 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 bitcoind.

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.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind 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
* 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 > 17000 shares) helps a lot with reducing stales.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

==== Works as-is ====

===== cgminer =====
Works very well as is.

===== ufasoft =====
Works as is.

===== DiabloMiner =====
Works fine after commit 3b731b9b54.

==== Needs patch to reduce stales ====

===== Poclbm =====
Waits a full second between long polls.

GitHub fork: https://github.com/forrestv/poclbm
Pull request: https://github.com/m0mchil/poclbm/pull/41
<pre>git clone git://github.com/forrestv/poclbm.git
cd poclbm
git checkout fast_long_polling</pre>

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 ===
<pre>
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
</pre>

== 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<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany?total=10.0)"
</pre>

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==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2012-01-17T01:49:19Z

Forrestv: removed sqlite mention

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|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 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 returns 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 8640 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 8640, 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 bitcoind.

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.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind 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
* 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 > 17000 shares) helps a lot with reducing stales.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

==== Works as-is ====

===== cgminer =====
Works very well as is.

===== ufasoft =====
Works as is.

===== DiabloMiner =====
Works fine after commit 3b731b9b54.

==== Needs patch to reduce stales ====

===== Poclbm =====
Waits a full second between long polls.

GitHub fork: https://github.com/forrestv/poclbm
Pull request: https://github.com/m0mchil/poclbm/pull/41
<pre>git clone git://github.com/forrestv/poclbm.git
cd poclbm
git checkout fast_long_polling</pre>

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 ===
<pre>
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
</pre>

== 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<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany?total=10.0)"
</pre>

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==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2012-01-16T23:44:11Z

Forrestv: updated share counts

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|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 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 returns 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 8640 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 8640, 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 bitcoind.

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.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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 bitcoind 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 > 17000 shares) helps a lot with reducing stales.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

==== Works as-is ====

===== cgminer =====
Works very well as is.

===== ufasoft =====
Works as is.

===== DiabloMiner =====
Works fine after commit 3b731b9b54.

==== Needs patch to reduce stales ====

===== Poclbm =====
Waits a full second between long polls.

GitHub fork: https://github.com/forrestv/poclbm
Pull request: https://github.com/m0mchil/poclbm/pull/41
<pre>git clone git://github.com/forrestv/poclbm.git
cd poclbm
git checkout fast_long_polling</pre>

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 ===
<pre>
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
</pre>

== 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<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany?total=10.0)"
</pre>

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==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2012-01-16T03:48:10Z

Forrestv: moved section

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|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 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 returns 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 bitcoind.

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.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

==== Works as-is ====

===== cgminer =====
Works very well as is.

===== ufasoft =====
Works as is.

===== DiabloMiner =====
Works fine after commit 3b731b9b54.

==== Needs patch to reduce stales ====

===== Poclbm =====
Waits a full second between long polls.

GitHub fork: https://github.com/forrestv/poclbm
Pull request: https://github.com/m0mchil/poclbm/pull/41
<pre>git clone git://github.com/forrestv/poclbm.git
cd poclbm
git checkout fast_long_polling</pre>

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 ===
<pre>
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
</pre>

== 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<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany?total=10.0)"
</pre>

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==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2012-01-16T03:47:53Z

Forrestv: updated diablominer section

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|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 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 returns 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 bitcoind.

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.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

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

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

==== Works as-is ====

===== cgminer =====
Works very well as is.

===== ufasoft =====
Works as is.

==== Needs patch to reduce stales ====

===== DiabloMiner =====
Works fine after commit 3b731b9b54.

===== Poclbm =====
Waits a full second between long polls.

GitHub fork: https://github.com/forrestv/poclbm
Pull request: https://github.com/m0mchil/poclbm/pull/41
<pre>git clone git://github.com/forrestv/poclbm.git
cd poclbm
git checkout fast_long_polling</pre>

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 ===
<pre>
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
</pre>

== 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<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 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:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany?total=10.0)"
</pre>

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==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support

==References==
<references />

[[Category:Pool Operators]]