hmm.. FPPS doesn’t really make sense for a DATUM pool. The pool operator doesn’t control the block template (miners do), so fee attribution is fuzzy and the variance/treasury risk sits on the pool. FPPS works today mostly because legacy pools own the template (and often a private mempool). With DATUM, per-block PPLNS fits better: pay on confirmed coinbase using a last-B-blocks (or N-difficulty) window.
Building such a pool is more grunt work, totally doable. Turning this PoC into a realistic PPLNS/(or similar) DATUM pool is mostly plumbing and ops — not research. This was the whole point about my post. If pool owners are motivated for decentralized mining where miners control template then DATUM is just ready to go.
DB-wise: keep it boring. Postgres for users/rounds/credits/payouts. If you want raw share lineage, add Timescale for a shares hypertable; otherwise store per-height aggregates only.
Login to reply
Replies (1)
Thanks!
My only interest in FPPS is that it seemed easier to implement than PPLNS and especially TIDES, with its payouts to miners directly from the coinbase tx.
But now I've realized you could send all the rewards from the coinbase tx to a pool operator's address and still implement PPLNS payouts.