P2Pool code documentation

This is the initially executed function.

1. Parses arguments
2. Reads user/password from bitcoin config file
3. Sets up log file
4. 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!).

This does all the startup tasks.

1. Tests connection to bitcoind.
2. Prints hash of latest block to show bitcoind is up to date.
3. Tests connection to p2pool network.
4. Gets address to use for payout either from file or bitcoind.
5. Validates address and checks local bitcoind owns it.
6. Create a "tracker" and loads know shares from files in data/bitcoin/sharesX where X is a number.
7. poll_bitcoind then gets work from bitcoind (i.e. block header to hash). Does this by calling getwork function explained below.
8. The work_poller() function then polls bitcoind every 15 seconds for new work.
9. 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.
10. Set up merged work for merged mining.
11. Sets up combined work.
12. Sets up Longpoll to trigger when current_work changes (transitions).
13. Creates Node class that handles connections to other p2pool nodes (see p2p.py also).
14. Read p2pool node address from addrs file else use bootstrap addresses.
15. Create node object and start it connecting/sending/receiving data.
16. Setup loop to save shares to disk every 60 seconds.
17. Create tunnel through routers using upnp if enabled.
18. Start listening for workers using WorkerBridge Class (e.g. cgminers).
19. Create web_root and start web server. This is the monitoring web pages. (see web.py)
20. Start IRC connection for announcing blocks.
21. Start Status process that output to screen data every 3 seconds.

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.

This is the main communication between p2pool process and the workers (mining processes running cgminer or similar).

This allows clients to connect. Also parses out if this client wants a higher than normal pseudoshare difficulty.

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

This connects to the bitcoind process using the jsonrpc proxy. It calls the getmemorypool function (see Bitcoin json-rpc API document and 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.

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.

Passes new shares onto tracker. Update peer_heads Calls compute_work if a new share.

Serialized SHA256 engine state, used to prove that a coinbase transaction contains some data near the end without sending the entire transaction.

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.

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

Information contained within a share that is only relevant to P2Pool

Data common to both of the following two types of shares.

This is a share that isn't a block solution.

This is a share that is a block solution.

Internal data structure, hashed to determine the "reference hash" at the end of generation transaction.

Class used to store shares.

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

1. The donation sent to the developers.
2. 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.