Skip to content

Instantly share code, notes, and snippets.

@checksum0
Last active December 11, 2023 03:00
Show Gist options
  • Save checksum0/101ca17b71c7b713df95c54ae9124934 to your computer and use it in GitHub Desktop.
Save checksum0/101ca17b71c7b713df95c54ae9124934 to your computer and use it in GitHub Desktop.
Pool OPEX estimates
Assuming the following:
- A sensible pool infrastructure at 10EH/s, not 1EH/s;
- A badly distributed hashrate with 50% hashrate in North America, 25% in South America, 15% in Europe, and the remainder
in APAC;
- A block refresh interval at 30s with a target submitted shraes for vardiff at 10s;
- A network average efficiency at 30J/TH with a 3500W PSU, making it a 116.6TH/s machine;
- A 19 output coinbase like ocean.xyz (just for fun).
10,000,000 TH/s (aka 10EH/s) / 116TH/s/machine = 85,764 machines
Ocean.xyz send me mining.notify message of 2400 characters, considering this is ASCII it is also 2.4KB. 2.4KB
* 85,764 machines = 206MB. You need to send that in AT MOST 0.5s, so you will need a 3.4gbps upload capacity across your
infrastructure to be able to do that. This is the primary driver to the operating expenses costs. A normal FPPS pool
requirement would be 2gbps. An ideal ocean.xyz coinbase with 100 outputs would require 10gbps.
Assuming you get 1gbps capable VM, assuming each VM cost you 80$/months (that's expensive), assuming since you are a small
pool you can operate with 5 locations (2 in USA, 1 in Brazil, 1 in Europe, 1 in APAC) and each location require at least 2 VM
for redundancy. Assuming you add a 150$/month VM per location for bitcoind. Assuming you add a 200$/month dedicated server in
a centralized location for centralized pool stuff (frontend, accounting, payout distribution, etc...)
The following outlined requirements would fulfill your upload bulk capacity requirements (assuming you aren't running the
idealized ocean.xyz setup). So it would cost you:
- 5 locations * 2 VM * 80$/month = 800$/month for stratum endpoint
- 5 locations * 1 VM (can always use other locations as backups) * 150$/month = 750$/month
- 1 location * 1 server * 200$/month = 200$/month
Total: 1750$/month
Assuming you ran 10EH/s during these two difficulty adjustement (the one that ended up and the one that's just starting)
for 1% fee (more realistic than 2% fee in current industry), the average difficulty of both period is 67.64T.
P: Payouts (in BTC)
H: Hashrate (in hashes/sec)
t: Time period (one standard month here (aka 365/12 days))
D: Difficulty (unitless)
P = (1x10^19 * 60secs * 60mins * 24hours * (365/12)days * (6.25 BTC * 118% (fees))) / (2^32 * 67.64T)
P = 667.15 BTC
Pool revenue = 667.15 BTC * 1% = 6.6715
Pool revenue = 293,000$
As you can see, IT IS NOT OPEX THAT IS A LIMITING FACTOR IN A POOL OPERATIONS.
The most limiting factors are two-fold:
- Human ressources costs (devs, devops, managers, executives, sales people, support people)
- The very large BTC reserve you must hold, or the very large insurance policy you must hold to avoid bankruptcy.
Meni Rosenfeld defines the required reserve to be held as so:
R: Reserve
B: Block reward
Delta (the greek letter): Probability of bankruptcy
f: fee rate
Assuming 0.01% chance of bankruptcy
R = B ln 1/delta / (2f)
R = (6.25BTC * 1.18) * ln 1/0.0001) / (2 * 0.01)
R = 3396 BTC
This formula in effect runs a full Markov chain for a pool operating at a 6.25BTC block reward, 18% block fees, and 1%
pool fees, and find the lowest value to which the Markov chain drops to.
Holding 3396 BTC in reserve is what make running a FPPS pool so hard.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment