The pool has been updated to 1.4.0 and the wallets was updated to BRS 2.2.5. We are updating the pool, because we have a feeling that PoC3 is not too far off in the future. The old Web UI was not compatible with the update, will be working on getting that look back soon.

All Burst have been forced to payout if you had over 0.2 Burst in the old pool. Block Payout Delay has been moved from 10 blocks to just 2 blocks and Minimum Payout is now 50 Burst.

Server Upgrade!

The datacenter that the pool is hosted in has been upgrading their equipment. So in return they upgraded us.
Server Specs
New Server Old Server
CPU: 8 Cores @ 2.20 GHz, Turbo 3.10 GHz 6 Cores @ 2.10 GHz, Turbo 3.00 GHz
RAM: 30GB DDR4 @ 2133MHz 24GB DDR4 @ 1866MHz
Storage: 800 GB NVMe 600 GB SSD
DDoS Protection: Datacenter upto 50 Gbps + Cloudflare Datacenter upto 1 Gbps + Cloudflare
Internet: 600/600 Mbps Unmetered 100/100 Mbps Unmetered
Disk Backups: 2 0
Still hosted in Germany but has moved locations

If you need any help don't hesitate to contact on us Discord, will try to help. Might be a bit busy working on the pool.

Miners that need to check reward recipient!
Account Name Recipient set to
DAD8-7644-VGH8-2UB2N TomWar PoCC Pool: 0-100

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 2 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 (~245907.4939). 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:

  • forces a payout if you have a positive balance
  • after that pool defaults are set
  • Fee: 100000000 Planck
  • forces a daily payout if you have a positive balance at the time, when the payment is made
  • Fee: 100000000 Planck
  • 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
  • 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.