Share Validation

Shares carry a claimed proof of work and are rewarded for it. Nodes validate every share added to the sharechain so that no proof of work is rewarded twice. Without this validation, a sending node could reuse one proof of work across several shares and earn several payouts for the same work. Nodes also validate each share’s transactions and timestamp, which makes transactions on the sharechain verifiable.

Validation covers the following concerns.

Proof of Work Meets Pool Difficulty

Payouts depend on the proof of work miners submit. The pool difficulty comes from the ASERT algorithm applied over a share’s ancestors. A share’s declared target must match the target computed using ASERT.

Sharechain headers carry all the information needed to validate the ASERT difficulty of a share received from a peer. A node can run this check only once all of a header’s ancestors are available, a quirk of ASERT. During initial sync, nodes therefore validate share proof of work serially, once all headers have arrived. During normal operation all ancestors are available, and a node waits for any that are missing.

Timestamp Limits

ASERT sets the difficulty from share times and heights. Miners therefore cannot manipulate share timestamps to lower the difficulty of their shares.

P2Poolv2 puts a tight bound on the median time past (MTP) over 11 blocks: a share’s timestamp must be greater than the MTP and no more than 120s ahead of the local clock.

No two shares can use the same bitcoin proof of work to earn more than one reward. P2Poolv2 uses share commitments to prevent this; see Share Commitments for how a share commits to a bitcoin header. A bitcoin header with proof of work can be embedded only in the share header it commits to, so each share has a unique proof of work that no other share can claim.

Uncles Follow the Rules

Uncle shares earn rewards, so uncles follow the same validation rules as all shares. Additional rules limit how deep an uncle can sit below its nephew. Nephews are given a bonus for including uncles, and uncles are reward is discounted for not being on the main chain.

Each shareblock can have three uncles, and each uncle must be at most three shareblocks below the nephew that refers to it. A shareblock can be included as an uncle only if it is not already an uncle to another shareblock on the sharechain.

Bitcoin Payouts Follow the PPLNS Window

Every bitcoin coinbase follows the PPLNS window on the sharechain. Bitcoin headers in shares commit to coinbase transaction outputs that pay miners according to the sharechain’s PPLNS reward distribution.

P2Poolv2 uses a PPLNS window of the last 120,960 shareblocks, the number of 10s intervals in two weeks. This period gives miners enough time to trade their shares for bitcoin, and smaller miners with tiny payouts need that trading to get paid. The Sell Shares for Payouts page describes how a share can be traded for bitcoin.

Nakamoto consensus provides eventual consistency and shares have to wait till they are replicated and they are considered confirmed. The coinbase in shareblocks are not spendable until 6048 blocks have been mined on top of it. This is similar in terms of time to bitcoins 100 block. Once a share is out of the PPLNS window, it is no longer rewarded for work in bitcoin blocks and therefore can not be spent/traded any more. See the PPLNS Share Accounting page for details.

All shareblock transactions, including the coinbase, are valid in terms of value spent, scripts, and spent outputs.

As in bitcoin, nodes check every shareblock transaction for double spends and for the amount spent, so that no one creates share value out of thin air.

Mine on the Current Bitcoin Chain

The bitcoin header builds on the current bitcoin chain, not on an miniorty hashrate fork of bitcoin.

Nodes verify that each shareblock header’s bitcoin header (see Sharechain) is reachable from the parent share’s bitcoin header. Each share that extends the sharechain therefore mines on the same bitcoin chain as its parent. If bitcoin forks attack the main chain, all nodes reject shares mined on those forks. The pool follows the bitcoin fork that the majority of its hashrate follows.

Bitcoin Blocks Are Not Validated

As Mine on the Current Bitcoin Chain describes, each share builds on the chain that the majority of the hashrate follows. P2Poolv2 does not validate bitcoin block contents; it verifies only that the header follows the correct bitcoin chain.

Nodes do verify the coinbase transaction from the bitcoin block body. Each shareblock header holds the bitcoin header, and the shareblock carries the merkle branches of the bitcoin block. With these, a node verifies that the share commitment and the bitcoin coinbase payout match its own PPLNS window.

Validating full bitcoin blocks would add latency, increasing the uncle rate and so reducing the number of mining nodes the pool can handle. The Block Withholding Attack section discusses this further.