Testnet Bitcoin-BLAKE2b live NOW:

mempool - Bitcoin Explorer

Explore Bitcoin

Once upon a time, in the land of invisible money, there stood a great magic castle called Bitcoin. It was the biggest, strongest, most famous castle in the whole wide world. Millions of people lived inside, and all the building giants with their enormous digging machines worked there to make it taller and taller. But one day, things began to change. The big machines and the powerful owners started making rules that not everybody liked. Some thought the castle had lost its magic and was turning into a place ruled by the same old giants as always. So a band of brave rebels decided to do something no one had ever dared to do before: **break the rules of the game completely**. They cast a spell of change so enormous that the powerful owners' giant machines were useless on their new path. And so a second castle was born, a twin castle but tiny, built with another secret magic called BLAKE2b. Because it was so new, work on this second castle was almost at a standstill for a whole month. It was very lonely and a little bit scary! The first castle (the old one with SHA256d magic) still had nearly everybody inside playing it safe, because moving to the new one was a terribly dangerous adventure where you might get lost. But the rebels of the new castle are very stubborn, the sort who say: *"Even if we're on our own and it costs us twice as much, we'll be right here putting up a fight."* For the guardian of this tale, the situation is very serious. He feels there are dark forces trying to destroy the true soul of the original castle, and he swears they'll have to fight very hard indeed to stop anyone from putting out the flame of freedom that gave the game life in the first place. That's why the guardian has made a secret decision. Although his treasures were split evenly between the two castles at first, he already knows what he's going to do: he's going to start taking his riches out of the old, giant, famous castle, little by little, to carry them all over to the new, tiny, rebel castle. He prefers that harder road because he believes the true magic lives there. And you? Which of the two castles would you take your treasures to?

Stack Watts

⚡ MONETARY NODES — the BIP that deletes spam from your node A BIP draft has appeared (sambitcoin/BitcoinMonetaryNode) proposing something different: a node that performs full consensus validation, exactly like any other, but refuses to STORE the spam. It's not a fork. It doesn't change the rules. Nothing valid today becomes invalid. It's local policy, per node, unilateral and reversible. ━━━━━━━━━━━━━━━━━ 🗑 WHAT IT DELETES, EXACTLY Syntactic, deterministic classification, with no dependency on any external indexer. Four carriers: 1. Inscription envelopes in the taproot witness (ordinals) 2. OP_RETURN over 83 bytes 3. Stamp-style bare multisig 4. Oversized scriptSig Plus token-protocol dust in the UTXO set. Note the 83-byte limit: the BIP REQUIRES keeping it, and justifies it in those exact words — "consistent with Bitcoin Knots policy and BIP-110". The author is on our side. ━━━━━━━━━━━━━━━━━ 🧠 THE CLEVER PART: IT DELETES WITHOUT LOSING What gets deleted is the CHAINSTATE — the internal database where bitcoind keeps live outputs, its ledger of balances. Non-monetary ones are removed right after each block is validated, and never accumulate at all, not even during IBD. But the block files are kept INTACT. So what happens when someone spends a deleted output? The node reconstructs it by reading the block it holds on disk. If it didn't have it, it requests that block from any peer and verifies it against the header chain it already validated. The output remains spendable. And from block 680,000 it maintains TWO MuHash accumulators: one over the full set (legacy) and one over the filtered set. Each non-monetary output is folded into the legacy hash right before deletion, so the full-set hash stays correct without storing the data. ━━━━━━━━━━━━━━━━━ ✅ THE GOOD • Doesn't touch consensus. No fork, no coordination, no permission from anyone. • Attacks a real problem: the UTXO set grows and cannot be pruned. • Unilateral and reversible adoption. • Purely syntactic classification, no external indexers. ❌ THE BAD • IT DOESN'T EXIST. The README itself says the Knots patchset is "not yet started". Zero code. • Not even posted to the bitcoindev list. No public review. • Enabling it on a synced node requires a REINDEX taking days. • coinstatsindex left to rework. • A node that doesn't store those outputs serves the network less. ━━━━━━━━━━━━━━━━━ ⚠️ THE REAL CRITIQUE This only makes sense on a BARE NODE, with nothing hanging off it. My numbers, measured: blocks ......... 808 GB indexes ........ 81 GB chainstate ..... 11 GB ─────────────────────── total .......... 899 GB The BIP halves the chainstate: from 11 GB to 5.5. It saves me 5 GB out of 899. That's 0.6%. My problem is the 808 GB of blocks, and those it does NOT touch — precisely because it needs them to reconstruct what it deletes. The savings and the mechanism get in each other's way by design. There's a more aggressive variant in the repo (the GAMEPLAN) that does strip blocks: 37 GB out of 296, across 194,863 blocks verified with zero merkle failures. Technically impeccable. But it breaks everything that needs whole transactions: Fulcrum, Dojo, BTCPay, indexers. The dilemma in one line: THE COMPATIBLE VERSION BARELY SAVES ANYTHING, AND THE ONE THAT SAVES ISN'T COMPATIBLE. For anyone running Lightning: gettxout is answered by reading the chainstate, and gettxout is exactly what LND queries to check your funding output is still unspent. Channels aren't at risk by design (a P2WSH multisig looks like none of the four carriers), but a bug in a new, unreviewed classifier wouldn't kill your node: it would blind a channel. ━━━━━━━━━━━━━━━━━ 📌 VERDICT The idea is good, and the approach — local policy instead of a soft fork — is the most sensible I've seen for the UTXO problem. Worth following. But there's nothing to install today, and the day there is, it will only pay off for whoever runs a bare node on modest hardware. If you have Fulcrum, Dojo, BTCPay or Lightning behind it, the math doesn't work. 🔗 github.com/sambitcoin/BitcoinMonetaryNode

⚡ MONETARY NODES — el BIP que borra el spam de tu nodo Ha aparecido un borrador de BIP (sambitcoin/BitcoinMonetaryNode) que propone algo distinto: un nodo que valida el consenso completo, igual que cualquier otro, pero que se niega a GUARDAR el spam. No es un fork. No cambia las reglas. Nada que sea válido hoy deja de serlo. Es política local de cada nodo, unilateral y reversible. ━━━━━━━━━━━━━━━━━ 🗑 QUÉ BORRA EXACTAMENTE Clasificación sintáctica y determinista, sin depender de ningún indexador externo. Cuatro portadores: 1. Sobres de inscripción en el witness taproot (ordinals) 2. OP_RETURN de más de 83 bytes 3. Bare multisig estilo Stamps 4. ScriptSig sobredimensionado Más el dust de protocolos de tokens en el UTXO set. Ojo al límite de 83 bytes: el BIP EXIGE mantenerlo, y lo justifica textualmente como "consistent with Bitcoin Knots policy and BIP-110". El autor está en nuestro bando. ━━━━━━━━━━━━━━━━━ 🧠 LA PARTE LISTA: BORRA, PERO NO PIERDE Lo que se borra es el CHAINSTATE — la base de datos interna donde bitcoind guarda las salidas vivas, su libro de saldos. Las no monetarias se eliminan justo después de validar cada bloque, y nunca llegan a acumularse, ni siquiera durante el IBD. Pero los ficheros de bloques se conservan INTACTOS. ¿Y si alguien gasta una salida borrada? El nodo la reconstruye leyéndola del bloque que tiene en disco. Si no lo tuviera, pide ese bloque a cualquier par y lo verifica contra la cadena de cabeceras que ya validó. La salida sigue siendo gastable. Y desde el bloque 680.000 mantiene DOS acumuladores MuHash: uno del set completo (legacy) y otro del filtrado. Cada salida no monetaria se pliega en el hash legacy justo antes de borrarla, así el hash del set completo sigue correcto sin guardar los datos. ━━━━━━━━━━━━━━━━━ ✅ LO BUENO • No toca consenso. Sin fork, sin coordinación, sin pedir permiso a nadie. • Ataca un problema real: el UTXO set crece y no se puede podar. • Adopción unilateral y reversible. • Clasificación puramente sintáctica, sin indexadores externos. ❌ LO MALO • NO EXISTE. El propio README dice que el patchset de Knots "not yet started". Cero código. • Ni enviado a la lista bitcoindev. Sin revisión pública. • Activarlo en un nodo sincronizado exige un REINDEX de días. • El coinstatsindex, a rehacer. • Un nodo que no guarda esas salidas sirve menos a la red. ━━━━━━━━━━━━━━━━━ ⚠️ LA CRÍTICA DE VERDAD Esto solo tiene sentido en un NODO PELADO, sin nada colgando. Mis números, medidos: blocks ......... 808 GB indexes ........ 81 GB chainstate ..... 11 GB ─────────────────────── total .......... 899 GB El BIP reduce el chainstate a la mitad: de 11 GB a 5,5. Me ahorra 5 GB de 899. Un 0,6%. Mi problema son los 808 GB de bloques, y esos NO los toca — precisamente porque los necesita para reconstruir lo que borra. El ahorro y el mecanismo se estorban por diseño. Hay una variante más agresiva en el repo (el GAMEPLAN) que sí recorta bloques: 37 GB de 296, con 194.863 bloques verificados y cero fallos de merkle. Técnicamente impecable. Pero rompe todo lo que usa transacciones enteras: Fulcrum, Dojo, BTCPay, indexadores. El dilema en una línea: LA VERSIÓN COMPATIBLE APENAS AHORRA, Y LA QUE AHORRA NO ES COMPATIBLE. Para quien tenga Lightning: gettxout se responde leyendo el chainstate, y es justo lo que consulta LND para comprobar que tu funding output sigue sin gastar. Los canales no corren peligro por diseño (un multisig P2WSH no se parece a ninguno de los cuatro portadores), pero un fallo en un clasificador nuevo y sin revisar no te tumbaría el nodo: te cegaría un canal. ━━━━━━━━━━━━━━━━━ 📌 VEREDICTO La idea es buena y el enfoque —política local en vez de soft fork— es el más sensato que he visto para el problema del UTXO. Merece seguimiento. Pero hoy no hay nada que instalar, y el día que lo haya solo compensará a quien corra un nodo pelado en hardware modesto. Si tienes Fulcrum, Dojo, BTCPay, Lightning u otras dependencias detrás, las cuentas no salen. 🔗 github.com/sambitcoin/BitcoinMonetaryNode

printf '{"id":1,"method":"mining.subscribe","params":["c/1"]}\n{"id":2,"method":"mining.authorize","params":["1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa.check","x"]}\n' | timeout --foreground 3600 nc kilodatum.airdns.org 11010 | jq -rc --unbuffered 'select(.method=="mining.notify")|.params[5]' | { v=""; t=$(date +%s); while :; do read -r -t 10 nv; rc=$?; (( rc == 1 )) && { echo "$(date +%T) *** CONEXION CERRADA ***"; break; }; if (( rc == 0 )); then v=$nv; t=$(date +%s); n=" <- job nuevo"; else n=""; fi; [ -z "$v" ] && { echo "$(date +%T) esperando primer job..."; continue; }; a=$(( $(date +%s) - t )); (( 0x$v & 0x10 )) && s="SEÑALIZA BIP110" || s="*** NO SEÑALIZA ***"; (( a > 60 )) && w=" AVISO: sin job hace ${a}s" || w=""; echo "$(date +%T) 0x$v $s (hace ${a}s)$n$w"; done; } Replace "kilodatum.airdns.org 11010" with the pool you want to observe

#BIP110