Counting stale shares in p2pool.
This document is a result of a discussion on IRC between rkjnsn, br0k3n, and blodyx.
Written by rkjnsn (1rkjnsnjXfDkjnQkY6ngAajRo5fh97G9L)
Purpose:
Including all shares into the block chain that were generated based on the current bitcoin block.
Rational:
Currently, there is a relatively hight percentage (~8%) of stale shares generated by p2pool miners. This increases the variance that miners experience in income when using p2pool.
Also, batch mining devices, such as the BFL Single, perform a large number of hashes at a time, returning the results all at once. Users of these devices are severely penalized on p2pool for two reasons. First, because they take a few seconds to run through the batch, there is a high probability that the discovered shares will be stale before they are returned. Second, even when the results are returned in time, only the first share can be counted even though several may be found. This results in users of these devices receiving significantly less credit than they deserve, keeping them away from p2pool. Even if such devices can be modified such that results are returned immediately and operations can be interrupted, the various latencies involved would still lead to reduced efficiency.
Proposed Approach:
Instead of orphaning shares, merge them back into the tree. This would be accomplished by generating a share that is based on two or more previous shares.
Share 2
/ \
Share 1 Share 4
\ /
Share 3
Share 2--Share 3----
/ \
Share 1 Share 5
\ /
-------------Share 4
The last share contains the appropriate payouts to the generators involved with both branches.
Problem:
While merging as above is in the collective interest of the pool, both to decrease variance and to allow the use of hardware miners, it is detrimental to the user actually performing the merge (Tragedy of the Commons). By merging the two branches rather than orphaning one of them, the user increases the number of shares in the pool belonging to other users, leading to a slight decrease in his/her own payout. In order for this approach to be successful, some incentive must be offered for merging.
Possible Solution 1:
One possible solution is to offer the user performing the merge an award. This award could either come from the the pool (like the finders fee) or from the shares of the branches being merged. The latter option would also serve to discourage purposeful splitting of the chain (e.g., in hopes of then collecting the merge fee). The exact award needed for adequate incentive would still need to be analyzed.
Possible Solution 2:
Another possible solution is to reject shares that don't merge when they could. Earning a new share is more beneficial for a user than excluding another user's share, so rejecting non-merging shares would make merging the more profitable. Unfortunately, rejecting all transactions that could have merged would also reject legitimate shares whose calculation was begun before one of the conflicting shares was known. It may be possible to take a propagation delay into account, only considering a share well known after it has been on the p2pool network for a given length of time.
