Thread

Zero-JS Hypermedia Browser

Relays: 5
Replies: 8
Generated: 07:47:51
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
2025-09-16 02:51:12 from 1 relay(s) 3 replies ↓
Login to reply

Replies (8)

Sounds great, thought I'm too excited to see the real details and use case. I am biased now by the project I'm in the process of building right now: A proxy pool customized for mining with BitAxes in pooled-mode (not solo), with convenient daily payouts, Nostr-integrated. I'm making a proxy pool by running a datum-gateway -- miners connect here. I've modified datum-gateway to perform username translation and save to work information. All miners mine under one account in Ocean, that gets reward payments, and distributes payments to the individual miners. In a form that makes it easy to use the payout for zapping on Nostr. Miner ID will be the Nostr pubkey. In effect this turns a BitAxe producing a tiny amount of sats regularly usable for zapping. I will make my patched datum-gateway public if the project proves to be useful (the modifications are kept minimal). An open implementation might be useful, though I will probably just use the patched datum-gateway. It would've been nicer from their part if they also publish a (versioned) protocol spec.
2025-09-16 10:24:11 from 1 relay(s) ↑ Parent 1 replies ↓ Reply
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.
2025-09-17 01:04:36 from 1 relay(s) ↑ Parent 1 replies ↓ Reply
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.
2025-09-17 18:23:28 from 1 relay(s) ↑ Parent Reply