Nostr Web Client

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?

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.

50

50bdea8d... 3mo ago 💬 8

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

50

50bdea8d... 3mo ago

🧱 Selfish Mining Revisited — Deep Dive into Two Key Papers

Reclaiming Miner Sovereignty: Why Decentralized Block Construction is Crucial for Bitcoin's Future

#bitcoin #mining

👇

https://primal.net/e/naddr1qvzqqqr4gupzq59aa2xs9z3t8jxr6jt9c7zpg9xa59agm2akp8vv62784cqjstrfqquj6um9d3nxjumg94kkjmnfdenj6un9we5hx6t5v4jz6ttyv4jhqttyd9mx2ttfde6x7tt5wahj66m90ykhqctsv4e8xtgdvppt0

Replying to

Bitcoin Mechanic

No, it's a silly meme. Pruning OP_RETURN means dumping all archival data along with it.

This is one of the most annoying misrepresentations about this. OP_RETURNs just don't exist in the UTXO set so people present them as harmless.

50

50bdea8d... 3mo ago

Mechanic you should do a video on this.

Many people think prunable means they can remove from their node. The pruning is only for utxo validation but once in block it stays there forever. This means if you run full node you will have it.

Already everyday so much junk is put in the OP_RETURN (even with <80bytes).

I run a spam check (I have a simple ML classification model )

It detects

| 🧬 Malware indicators : `MZ`, binary blobs, shellcode, etc.

| 🧱 Overly large payloads : Likely trying to store malware

| 🧾 Structured address spam: Recognizable crypto address formats

| 🧟 Botnet / C2 : Random hex data, possible signal packets

| 🧨 Garbage entropy :Nonsense strings, high entropy content

50

50bdea8d... 3mo ago

🚨 Bitcoin blocks are silently accumulating embedded data — not all of it benign.

I built a model that scans OP_RETURNs for suspicious payloads like malware, phishing links, and binary blobs. It works — and that’s the scary part.

📌 Here's why it matters:

- Today, AV/EDR systems don’t scan `.bitcoin/blocks`

- Tomorrow, they will — and when they do, infected chains could get flagged

- Nodes on cloud infrastructure (AWS, GCP) may face bans or throttling

- Centralized miners can bypass mempool policy, embedding malicious data

🧠 This is about more than spam. It's about Bitcoin's long-term health and legitimacy.

We need:

- Sensible datacarrier/mempool policies

- Transparency in block contents

- Decentralized, policy-respecting mining

Bitcoin is permissionless. Let’s not let it become indefensible.

#Bitcoin #OP_RETURN #Malware #AVDetection #Mempool #Mining #ChainSecurity #Nostr

Replying to

Super Testnet

Why Ocean says its miners make more money

The short answer is: lower fees. Mining pools don’t distribute *all* of their revenue to their miners because the admins keep some revenue for themselves as fees. Ocean charges *lower* fees than all other pools, so they give *more* revenue to their miners than all other pools. But there’s a somewhat complex reason why Ocean can afford to do that. So I’m about to give the long answer.

But before I do that, here’s some background: Ocean Mining is a controversial mining pool in bitcoin for several reasons. One reason is the loud opposition to “arbitrary data” voiced by some of its administrators. Most mining pools in bitcoin have a welcoming attitude toward almost any transaction that pays competitive mining fees, regardless of what data it embeds on the blockchain. But Ocean’s administrators loudly oppose transactions that embed pictures, audio, and other non-financial data on the blockchain, and they propose a default mining template to their miners that excludes many such transactions, even though the pool collects less money from transaction fees as a result.

This stance causes some bitcoiners to wonder how Ocean remains competitive with other mining pools. Aren’t they making less revenue than other pools? That must be the consequence of rejecting a whole class of fee-paying transactions by default, right? And shouldn’t that lead their miners to make less money than they can make at other pools, and abandon Ocean as a result?

Ocean’s loud answer is: “Nope, on the contrary, our miners make more money than the miners at other pools make.” And this is not because Ocean *earns more* than other pools (in fact, as might be expected with their stance, the pool earns slightly less); it is because Ocean *distributes more* of their revenue to their miners.

Think of it this way: suppose there are two pools, Ocean and Desert. Both have 100 miners who all contribute equal amounts of hashrate. But while Ocean earns $500,000 per block, Desert earns $501,000, because it welcomes transactions containing lots of arbitrary data. In that scenario, you might expect Ocean’s miners to collect $5,000 in revenue apiece while Desert’s miners should get $5,010. But admin fees change this: if Desert charges 2% in admin fees, and Ocean charges only 1%, then Desert’s miners will only make $4,909.80 per block while Ocean’s will make $4,950. So a pool can earn slightly *less* money in total but still distribute *more* money to its miners simply by charging lower admin fees.

So that explains part of how Ocean remains competitive, but there’s another factor I’d like to cover: how can Ocean afford to charge lower admin fees than its competitors?

The answer involves something called “variance.” Mining bitcoin is partially random; which pool mines a given block is not exactly predictable, but a general rule is, the pools with more hashrate mine blocks more often. But sometimes a pool gets unlucky, and doesn’t mine very many blocks for a while, and when that happens, its payouts are smaller than expected. This creates a layer of unpredictability – aka variance – that mining pools don’t like: many miners would *like* a guarantee that they will receive a particular amount each month, but variance makes this difficult.

The solution adopted by most mining pools is to use a portion of their admin fees to create a kind of “luck fund.” When the pool is unlucky, and doesn’t make enough money to pay their miners what they usually pay, they get the difference from this fund, and replenish it when their luck returns.

Ocean simply does not have this luck fund, so they just don’t charge the portion of their admin fees that they *would* otherwise deposit into that fund. When you mine with Ocean, your payouts only come from what they earned in recent blocks, and none of it comes from the luck fund, which does not exist. This means you make more money than other pools so long as the pool’s luck is average or higher than normal (because they charge lower admin fees), but less money when their luck is poor (because they mined fewer blocks than expected, and have no luck fund to make up the difference).

In summary, Ocean claims its miners make more money than miners in other pools because Ocean charges lower admin fees, and thus they can distribute *more* money to their miners, even though the pool makes slightly *less* money *in total* than other pools. They can charge lower admin fees because they do not have a luck fund, and this means the amounts they payout vary more than other pools do, but with a significant skew to the upside. I hope that helps!

50

50bdea8d... 3mo ago 💬 1

There are more nuances.. basically FPPS is not very transparent.

many pools may not even share transaction fees.

I like Ocean mainly because that is what PoW is ..

1) You get reward only if you pool mines a block

2) You can create your own block templates and if you are big miner you directly get paid by coinbase transaction and for a small miner like me I get a BOLT12 lightning payout

Replying to 50bdea8d...

🧪 Homomorphic Encryption over Nostr — Proof of Concept

Simulated a lightweight Nostr relay using WebSockets + a custom event kind 555 to send/aggregate homomorphically encrypted integers.

Paillier scheme, local clients, fully async, dumb relay.

Built it to explore encrypted coordination on top of Nostr.

+------------------+

| Initiator |

|------------------|

| Gen Paillier Key |

| Encrypt Value X |

| Send via Kind 555|

+--------+---------+

|

v

[ Local Relay ]

|

+-------------------+-------------------+

| | |

v v v

+--------------+ +--------------+ +--------------+

|--------------| |--------------| |--------------|

+------+--------+ +------+--------+ +------+--------+

| | |

+--------+---------+------------------+

|

v

+------------------+

| Initiator |

|------------------|

| Decrypt X+a |

| Decrypt X+b |

| Decrypt X+c |

+------------------+

50

50bdea8d... 3mo ago

50

50bdea8d... 3mo ago 💬 1

🧪 Homomorphic Encryption over Nostr — Proof of Concept

Simulated a lightweight Nostr relay using WebSockets + a custom event kind 555 to send/aggregate homomorphically encrypted integers.

Paillier scheme, local clients, fully async, dumb relay.

Built it to explore encrypted coordination on top of Nostr.

+------------------+

| Initiator |

|------------------|

| Gen Paillier Key |

| Encrypt Value X |

| Send via Kind 555|

+--------+---------+

|

v

[ Local Relay ]

|

+-------------------+-------------------+

| | |

v v v

+--------------+ +--------------+ +--------------+

|--------------| |--------------| |--------------|

+------+--------+ +------+--------+ +------+--------+

| | |

+--------+---------+------------------+

|

v

+------------------+

| Initiator |

|------------------|

| Decrypt X+a |

| Decrypt X+b |

| Decrypt X+c |

+------------------+

50

50bdea8d... 3mo ago

🛠️ Spin up Bitcoin Knots + DATUM Gateway in Docker Compose.

No more juggling configs — just docker-compose up and you're live with a proper Bitcoin node + Datum Gateway.

🔗 https://github.com/electricalgrade/btc_datum

Built this for myself, but figured someone else might want it.

Run infra, not drama.

#Bitcoin #Nostr #Docker

Replying to 50bdea8d...

Noise Protocol: A Minimal and Modular Cryptographic Tool

Been working with the Noise protocol recently — here’s a quick breakdown of what it does and how it works under the hood.

Noise is a small framework for building secure handshakes. It’s not a full protocol like TLS, more like a toolkit to define your own. It handles the initial key exchange, identity/auth, and gives you encrypted transport keys after the handshake. That’s it. No certificates, no extensions, no middleboxes.

Each handshake in Noise is built using a "pattern" — I’ve been using XX and NX. These define how the keys are exchanged:

* XX: both sides are anonymous, and exchange keys during handshake.

* NX: responder has a static pubkey, initiator is ephemeral (closer to client-server flows like SV2).

Behind the scenes, these patterns are just sequences of Diffie-Hellman operations between the parties' keys (ephemeral and static), and the handshake hash is updated after each message. Once complete, both sides split the final hash into two symmetric cipherstates, and that’s what’s used to encrypt transport messages.

All operations are constant-time. I’m using the `noise-c` library, which supports `Noise_XX_25519_ChaChaPoly_BLAKE2s` (or SHA256 if you tweak the suite string). Noise defines the handshake state machine, but the crypto primitives are pluggable.

The nice part is that everything’s deterministic and testable. Given the same inputs, the handshake always produces the same shared keys. It’s all pure key material — no ASN.1, no PEMs, no handshake extensions to worry about.

In the next post, I’ll show a tiny C implementation that wraps a Noise handshake (XX or NX), and exchanges Stratum V2 `SetupConnection` messages post-handshake. Useful for testing your own SV2 client/server implementations.

#noiseprotocol #cryptography #infosec #keyexchange #stratumv2 #miningprotocol #cprogramming #protocolengineering #decentralization #bitcoin #nostrdev #datumgateway #DLT #securecommunication #networkprotocols

50

50bdea8d... 4mo ago

🧪 Part 2: Minimal Stratum V2 Handshake (Noise XX/NX + SetupConnection)

Following up on the Noise Protocol intro — here's a small, self-contained C implementation that performs a Noise handshake (XX or NX) and exchanges Stratum V2 SetupConnection messages immediately after.

It’s built to test client/server handshake logic without needing full SV2 support or encryption on the transport layer (yet).

Just Noise + SetupConnection, using raw TCP with framed messages.

🔧 What’s included:

Minimal “pool server” (sv2_pool_server.c) that:

Accepts TCP connections

Completes a Noise handshake (XX by default, NX optional via --nx)

Decodes a SetupConnection message and responds with SetupConnection.Success

Matching client (noise_client.c) that:

Connects to the pool

Runs Noise handshake

Sends a valid SetupConnection payload

Handshake and transport logic is handled using noise-c — clean, constant-time, and easy to audit.

🔐 Handshake Patterns:

XX: Both parties are anonymous; ephemeral key exchange on both sides.

NX: Server has a static key; client is ephemeral (more realistic for mining pools).

These map directly to Noise patterns (Noise_XX_25519_ChaChaPoly_BLAKE2s) and can be swapped via --xx / --nx.

🧰 Framing and Messages:

Transport uses simple framing: uint16_be length prefix + payload.

After handshake, we send:

SetupConnection (client → server)

SetupConnection.Success (server → client)

These are built using SV2 helpers (sv2_common.[ch], sv2_wire.[ch]) to encode/decode the frames.

🔄 Example Usage:

Start the pool server:

./sv2_pool_server -l 0.0.0.0:3334 --prologue STRATUM/2 --sk

Start the client:

./noise_client -l 127.0.0.1:3334 --prologue STRATUM/2

Both ends should print confirmation of the handshake and the SetupConnection exchange.

🚫 What's intentionally missing (for now):

No full SV2 session yet (no channel open, no job distribution)

No post-handshake encryption of transport messages

No persistent session keys or reconnection logic

This is by design — the goal is to test handshakes + basic SV2 flows before introducing more complexity. Once the handshake layer is stable, you can drop in encrypted transport using sv2_noise_send_transport() and sv2_noise_recv_transport() provided in the demo.

💡 I’m using this for testing SV2 client implementations and validating message formats over raw TCP before wiring into a full miner or pool stack.

This is all part of adding SV2 mining protocol support to Datum gateway.

I already have a SV1 to SV2 translator. Now adding SV2 server features.

#noiseprotocol #stratumv2 #miningprotocol #bitcoinmining #handshake #cryptography #protocoltesting #cprogramming #securecommunications #nostrdev #decentralization #packetengineering #DLT

nostr:nevent1qvzqqqqqqypzq59aa2xs9z3t8jxr6jt9c7zpg9xa59agm2akp8vv62784cqjstrfqythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qythwumn8ghj7cnfw33k76twv4ezuum0vd5kzmp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qpqacaj5nwru0fw2ea0tsm8l5hf75scca43nf4s8e556lkn8nqm8hpqtwfrff

Replying to 50bdea8d...

Running Bitcoin Knots + Datum is as simple as

docker compose up

50

50bdea8d... 4mo ago

Here is the git hub to quickly get knots+datum running.

Tested this on Mac, arm64 and x86

#bitcoin

https://github.com/electricalgrade/btc_datum.git

nostr:nevent1qvzqqqqqqypzq59aa2xs9z3t8jxr6jt9c7zpg9xa59agm2akp8vv62784cqjstrfqythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qythwumn8ghj7cnfw33k76twv4ezuum0vd5kzmp0qyehwumn8ghj7cmfdukkzatrw35k7m3dvfkx7mny94cxcctwde5kueeww3e8jcmvda6kgenvv9ex2tnrdakj7qpqaq4up7z7l2zrft36x3yux0myrsghz36eymsy8adev2e5vqqqpapqn0c7vl

50

50bdea8d... 4mo ago 💬 1

Running Bitcoin Knots + Datum is as simple as

docker compose up

50

50bdea8d... 4mo ago

Built Bitcoin Knots (v28.1.knots20250305) from source in a clean Docker container 🚀

- Ubuntu 22.04 base

- Wallet disabled (--disable-wallet)

- Auto builds from official Knots repo

- Clean & reproducible setup

- bitcoind ready out-of-the-box

💡 Useful for devs, testers, node runners

#Bitcoin #BitcoinKnots #Docker #Nostr

Source & Dockerfile:

https://github.com/electricalgrade/bitcoin/tree/28.x-knots/docker