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 to be well known after it has been on
the p2pool network for a given length of time.
