Historical Share Determination

The pool will use the best confirmed deadlines of each miner from the last 360 blocks to estimate the plot size of the miners (minerPlotSize) as well as the total pool size (poolPlotSize) to determine the historicalShare of the miners:
historicalShare = minerPlotSize / poolPlotSize
Blocks with block time of less than TMin are not used for the estimation to improve accuracy. The formulas used to determine the estimated plot sizes are given below. Some important properties of this estimation are:
  • The pool will only estimate the miners plot size if it confirmed DLs from the miner in more than 1 blocks. Until then, the miners estimated plot size will be set to 0.

  • For newly joined miners it will take a run-up period of 360 blocks until the estimate will reflect the miners actual plot size

  • Under good conditions, the estimate will fluctuate around the miner's actual plot size after the run-up period. (if not, see below)

  • The estimate only uses the miner's best DL of each round. To decrease the pool workload, miners should decrease their targetDL to a reasonable value. (see below)

  • The estimate cannot be tricked into systematically overestimating the miners plot size by withholding bad DLs. In fact, it will give reasonable estimations even if the miners targetDL is set to a value at which some rounds go without any submits.
The estimated plot sizes can be viewed in the "Miners" overview tab.

Choosing a Reasonable targetDL

If you haven't bothered optimizing your targetDL yet, the following formula (with yourPlotSize in TeraBytes) might give you a good value to start with:
targetDL = 720 * netDifficulty / yourPlotSize
For netDifficulty you can use the latest mean network difficulty (~212107.052). With this targetDL you should submit a DL in ~95% of rounds on average.

How the Estimated Plot Size Is Determined

Say the miner got nConf best confirmed deadlines in the last nAvg rounds (only the blocks with block time less than TMin are used for the estimate). To turn every best DL into a value that has a clear relation with the miners plot size, the DLs are divided by the Difficulty of the round they were confirmed in.
target_i = Deadline_i / Difficulty_i
Those characteristic values target_i are summed up to get the totalTarget. With this the estimated effective plot size (EEPS) is calculated:
EEPS = alpha * 240 * (nConf-1) / totalTarget
The constant 240 is the mean block time (in seconds) that the burst network aims to achieve. The parameter alpha is a bias that always assumes that the miner withheld the (nAvg-nConf) of his worst target values if the miner did not submit DLs in every of the last nAvg rounds. This ensures that miners cannot trick the pool into systematically overestimating the miners plot size. alpha is calculated as:
alpha = 1 - (nAvg-nConf) / nConf * Ln[ nAvg / (nAvg-nConf) ]

Reward Distribution

If a block was won the poolFee will be subtracted from the blockReward:
poolShareInBurst = blockReward (1 - 0)
The winner will receive:
poolShareInBurst * 0.5
From the remaining bursts all miners (including the winner) will receive burst proportional to their historicalShare on the block:
poolShareInBurst * (1-0.5) * historicalShare
The pending amount for each miner includes the tx fee!
Miners that were not active for 5000 blocks will be removed from the database together with their pending burst.

My Estimated Plot Size Is Lower Than My Actual Plot Size. Why?

Under good conditions, the estimated plot size should on average (at least almost) reproduce the miners actual plot size. But fluctuations in the miners luck can still cause the estimate to be lower than the actual plot size for days. If you think the pool systematically (not just randomly) underestimates your plot size, one of the following can be the case:
  • Your plot files overlap, which lowers your effective plot size.
  • Your plot read speed is slow, so you can't finish reading your plots to submit your best DL in many of the shorter rounds. In this case you might want to optimize your plot files or optimize your mining hardware for better read speeds.
  • The Pool's confirmation time is very long, so some of your best DLs are not confirmed before the round ends. Miners should optimize their targetDL (see above) to reduce the pools work load, so everyone can get their best DLs confirmed as fast as possible. If the pool is very occupied miners can also get better estimates with lower targetDLs.
  • If the fault is on the pools side (bad confirmation times), the estimated plot sizes will be lowered for all miners equally, so the historical share will still be fair. You should get your fair share at all times as long as you optimize your mining rig.

Dynamic Payout

Miners can send unencrypted messages to the pool account to change their payment thresholds/intervals. The fees for a message - if there are any - are subtracted from your pending shares when the message arrives the pool. If your pending do not saturate those fees the message will be ignored by the pool.

You can use one of the following messages:

now
  • forces a payout if you have a positive balance
  • after that pool defaults are set
  • Fee: 100000000 Planck
daily
  • forces a daily payout if you have a positive balance at the time, when the payment is made
  • Fee: 0 Planck
weekly
  • forces a weekly payout if you have a positive balance at the time, when the payment is made
  • Fee: 0 Planck
12345 or similar (unsigned integer) in Planck (not Burst!)
  • you can set any integer value you like to eg. 12345
  • payment is done after you pass this threshold including txFee with your pendings
  • any existing recurring payment settings will be removed
  • Fee: 100000000 Planck
0
  • reset to pool's defaults
  • any existing recurring payment settings will be removed
  • no fees

A Planck equals 0.00000001 Burst. One Burst is 100000000 Planck.
The fees will be subtracted from your pending directly as soon as the message arrives the pool. Make sure to have enough Burst in your Pendings - otherwhise the message will be ignored by the pool. Invalid messages will be ignored.