What kind of database do you think would appropriate to store and efficiently access this kind of information?
Also do you think it would be too difficult to evolve this PoC into a realistic FPPS DATUM pool?
Got a minimal DATUM “pool” talking to datum_gateway (interop demo)
TL;DR: datum_gateway being open source is enough to build your own pool. EGPOOL is a minimal proof — not production.
Datum_gateway is open source and the protocol is right there in the code. My take: if you can read the protocol, you can build your own pool.
Before arguing, I wanted to try it. So I hacked together a tiny Python prototype called EGPOOL. It speaks the DATUM protocol and can handshake, push CONFIG, and round-trip shares with the gateway — no Ocean pool code involved.
What I proved (all from the public datum gateway code):
• Framing: 4-byte XOR’d header + payload
• Handshake:
- proto=1 HELLO: sealed to pool LT X25519, signed by client LT Ed25519
- proto=2 RESP: sealed to client SESSION X25519, signed by pool LT Ed25519
• Channel (cmd=5):
- Box(serverSessSK, clientSessPK) w/ 24-byte nonce from nk + client session pk
- Nonces increment per message (LE 6×u32)
• CONFIG 0x99: signed by pool SESSION key, applied by gateway
• Share submit 0x27 ↔ response 0x8F: round-trip works
My test setup
EGPOOL pool server <-> DATUM GATEWAY -> Bitcoin node
I connected a bitaxe miner to DATUM Gateway.
I saw gateway handshake with pool server and accepting shares from miner.
Datum Gateway logs from my run:
Handshake response received.
DATUM Server MOTD: Welcome to Python DATUM Prime (prototype)
client configuration cmd received from DATUM server
DATUM Pool Coinbase Tag: "EGPOOL"
DATUM Pool Prime ID: a1b2c3d4
DATUM Pool Min Diff: 65536
Starting Stratum v1 server
---
quick disclaimer — this is a test rig, not a real pool
This is just an interop demo to show the protocol surface is enough.
A production pool still needs all the boring-but-critical stuff: reliable networking & reconnects, user/worker auth, proper vardiff and duplicate detection, real accept/reject plumbing, accounting backed by a DB, coinbaser v2 with real splits, the 0x50 validation path (stxids → by-id → full set), signature discipline (LT vs session), rate limiting/DoS guards, key management/rotation, metrics/alerts, etc
Want to understand more about the protocol?
check my GitHub
https://github.com/electricalgrade/sv2/blob/main/doc/Datum_Protocol_Spec.md
#Bitcoin #Mining #DATUM
Discussion
Custodial FPPS pools are technically very easy in general.
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.
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.