Correr tu propia infraestructura Bitcoin no solo es útil: es una declaración radical de soberanía digital. En esta sección aprenderás a correr tu propio nodo de Bitcoin e indexarlo con Esplora, utilizando docker-compose y asegurándote de que todo corra sobre almacenamiento sólido y fiable.

🔧 ¿Qué componentes incluye?

La infraestructura que implementaremos consta de:

• 🟠 Nodo de Bitcoin Core

⚙️ Requisitos para correr tu nodo de Bitcoin

Para levantar la infraestructura completa de Bitcoin Core junto con el indexador Esplora, necesitas lo siguiente:

📦 Almacenamiento recomendado

• 🟢 Bitcoin Core (cadena principal): 500 GB

• 🔵 Esplora (Electrs + backend): ~300 GB

• ⚠️ Total sugerido: 1 TB SSD (formateado en EXT4 si usas Linux)

🛠 Requisitos previos

• Tener Docker y Docker Compose instalados

• Acceso a una máquina Linux (puede ser física o una VM)

• Conexión estable a Internet (se descargará toda la blockchain de Bitcoin)

🏗️ Levantar la Infraestructura

1. 🌞 Clona el repositorio del Explorador Sigiloso

y corre el nodo Bitcoin, asegurándote de que Docker esté corriendo.

$ git clone https://github.com/josemariasosa/explorador-sigiloso.git
$ cd explorador-sigiloso

2. Revisar el archivo Docker Compose

Var una revisada al archivo docker-compose.yml, y asegurarse que el volumen sea el correcto, en donde hemos de almacenar el nodo de Bitcoin.

  bitcoin:
    image: bitcoin/bitcoin:latest
    container_name: bitcoin-mainnet
    restart: unless-stopped
    ports:
      - "8332:8332"  # RPC
      - "8333:8333"  # P2P
    volumes:
      - /media/honey/bitcoin_data/bitcoin-node:/home/bitcoin/.bitcoin

3. Revisar el archivo bitcoin de Configuración

El archivo bitcoin.conf deberá estar presente en el directorio del volumen.

$ sudo ls /media/honey/bitcoin_data/bitcoin-node

banlist.json  blocks      default            mempool.dat
bitcoin.conf  chainstate  fee_estimates.dat  peers.dat
bitcoind.pid  debug.log   indexes            settings.json

Y su contenido luce así.

$ sudo cat /media/honey/bitcoin_data/bitcoin-node/bitcoin.conf

# General options
txindex=1
rpcuser=bitcoin
rpcpassword=bitcoin123
rpcbind=0.0.0.0
rpcallowip=0.0.0.0/0
printtoconsole=1

# Load the default wallet at startup
wallet=default

4. 💳 Confirmar la Wallet con bitcoin-cli

Para que un nodo de bitcoin pueda ser consultado, incluso si no está completamente sincronizado, necesita tener cargada una wallet. En el archivo bitcoin.conf, añadimos una wallet default, o predeterminada.

Para asegurarse de que la wallet está cargada, es posible ejecutar comandos directamente al nodo mente el bitcoin-cli.

# Listar wallets disponibles
$ docker exec -it bitcoin-mainnet bitcoin-cli \
    -rpcuser=bitcoin \
    -rpcpassword=bitcoin123 \
    listwallets

[
  "default"
]

# Info adicional de la wallet
$ docker exec -it bitcoin-mainnet bitcoin-cli \
    -rpcuser=bitcoin \
    -rpcpassword=bitcoin123 \
    getwalletinfo

{
  "walletname": "default",
  "walletversion": 169900,
  "format": "sqlite",
  "balance": 0.00000000,
  ...
}

Si no añadimos el archivo bitcoin.conf entonces podemos crear la wallet directamente desde la terminal.

# Crear la wallet si no existe
$ docker exec -it bitcoin-mainnet bitcoin-cli \
    -rpcuser=bitcoin \
    -rpcpassword=bitcoin123 \
    createwallet default

5. Listos para correr el nodo de Bitcoin

Si es la primera vez que se corre, el nodo comenzará a sincronizarse desde cero, este proceso es muy tardado, y se verá en la terminal el avance, mediante los logs de Docker.

$ docker compose up -d bitcoin
$ docker logs -f bitcoin-mainnet

# Para detener el nodo, SIEMPRE utilizar el comando
$ docker compose down

6. ☎️ Llamar a nuestro nodo local

Verifica que tu nodo funciona:

# Obtener detalles de la cadena
$ docker exec -it bitcoin-mainnet bitcoin-cli \
    -rpcuser=bitcoin \
    -rpcpassword=bitcoin123 \
    getblockchaininfo

{
  "chain": "main",
  "blocks": 613236,
  "headers": 893552,
  "bestblockhash": "000000000000000000030bdf3d6c86419b1a42319efa530147d2e793f6592bcc",
  ...
}

Para obtener el último bloque, e información adicional sobre el mismo, entonces llamar:

# Obtener el último bloque
$ docker exec -it bitcoin-mainnet bitcoin-cli \
    -rpcuser=bitcoin \
    -rpcpassword=bitcoin123 \
    getbestblockhash

0000000000000000000b70857493d5c8ab06fbe7a00ba3b45812b45c94df4adf

# Obtener detalles del bloque
$ docker exec -it bitcoin-mainnet bitcoin-cli \
    -rpcuser=bitcoin \
    -rpcpassword=bitcoin123 \
    getblock 0000000000000000000b70857493d5c8ab06fbe7a00ba3b45812b45c94df4adf 2
    
{
  "hash": "0000000000000000000b70857493d5c8ab06fbe7a00ba3b45812b45c94df4adf",
  "confirmations": 16,
  "height": 613255,
  "version": 536870912,
  "versionHex": "20000000",
  "merkleroot": "16c916e623811beb5892d21a1cada8c1bdc64b97d6e08d78016d08352b3e7631",
  "time": 1579257023,
  "mediantime": 1579250177,
  "nonce": 295860742,
  ...
}

🌳 Filosofía del Nodo Sigiloso

En Nodo Sigiloso, correr un nodo no es un hobby: es una convicción. Creemos que ser parte de la red es el siguiente paso lógico para un bitcoiner que ya no solo quiere "hodlear", sino participar en la infraestructura misma.

Este documento es bitácora, manual, guía de supervivencia. Ayúdanos a poblar el bosque de nodos soberanos. Correr tu propio nodo no te da solo control: te da conocimiento, privacidad, y dignidad digital.

Bienvenid@ a la documentación oficial de Nodo Sigiloso, tu compañero discreto para operar infraestructura blockchain y construir exploradores multicadena.

Tanto si eres operador de nodos, desarrollador curioso o simplemente quieres consultar datos de blockchains sin depender de terceros… este proyecto es para ti.

🚀 ¿Qué es Nodo Sigiloso?

Nodo Sigiloso es una iniciativa abierta para ayudarte a desplegar y mantener nodos blockchain de forma segura, económica y soberana.

Ofrecemos:

• 🧱 Guías para montar tu propia infraestructura: nodos de Bitcoin, Ethereum (L2s) y NEAR, con indexadores opcionales.

• 🔍 Una API llamada Explorador para consultar datos blockchain en tiempo real, ya sea desde tus propios nodos o desde nuestros endpoints públicos.

Nuestra misión: hacer que operar nodos sea algo accesible, elegante y enfocado en la privacidad — para los builders, por los builders.

📚 Estructura de la documentación

La documentación está dividida en dos secciones principales:

1. 🛠 Corre tu propia infraestructura

Pasos para instalar y operar nodos completos o indexadores de:

• Bitcoin — Nodo completo o podado

• Ethereum / L2s — Incluye indexadores personalizados y proveedores RPC

• NEAR Protocol — Con configuración para validadores

Cada guía incluye recomendaciones de hardware, configuración con Docker, sincronización y monitoreo.

2. 🔎 Explorador Sigiloso API

La explorador_sigiloso_api es un backend multi-cadena que te permite:

Ver actividad por dirección BTC

Consultar deltas de bloques (entradas, salidas, recompensas)

Acceder a estadísticas on-chain personalizadas

Ideal para crear dashboards, alertas, bots o alimentar tus propias apps — todo esto usando tus propios nodos o los nuestros.

🧭 Primeros pasos

🧪 Esta documentación está en desarrollo activo — se irá actualizando semanalmente mientras mejoramos el explorador, la API y los manuales de despliegue.

¿Quieres contribuir o dejar tu estrella? Visita el repo: 👉 github.com/josemariasosa/explorador-sigiloso

¿Cuándo se lanza Pectra en Ethereum?

Pectra (la fusión de Prague + Electra) es la próxima gran actualización de Ethereum. Según los desarrolladores de Ethereum, la fecha estimada para Pectra en mainnet es en el tercer o cuarto trimestre de 2025, aunque no hay una fecha oficial confirmada aún.

✨ ¿Qué cambia con Pectra para los validadores?

Uno de los cambios más esperados es:

🔐 Las credenciales de retiro tipo 0x02

• Las credenciales de tipo 0x01 envían automáticamente las recompensas al withdrawal address en L1 (por ejemplo, una dirección 0x... de Ethereum).

• Las credenciales de tipo 0x02 permiten que el validador retire y vuelva a depositar más ETH, más allá del límite original de 32 ETH.

Esto significa que, una vez que Pectra esté en vivo, si tu validador usa credenciales 0x02, podrás:

• Seguir acumulando recompensas en el balance efectivo de tu validador

• Aumentar el stake más allá de los 32 ETH iniciales

🛡️ Pectra y el Futuro de los Validadores en Ethereum

Pectra es el nombre clave de una actualización que unifica los desarrollos de Prague (en capa de ejecución) y Electra (en capa de consenso). Está planeada para activarse en mainnet durante la segunda mitad de 2025.

Uno de los cambios más importantes es la introducción de las credenciales de retiro 0x02.

✨ Estas credenciales permiten que un validador incremente su stake más allá de los 32 ETH originales, algo que antes no era posible.

¿Qué tipo de credencial tengo?

• Si tu credencial de retiro es 0x01: tus recompensas se retiran automáticamente a tu dirección L1.

• Si tu credencial de retiro es 0x02: podrás incrementar tu stake una vez que la actualización de Pectra esté activa.

¿Qué necesito hacer?

Si ya estás operando un nodo validador con credenciales 0x01, no podrás migrar a 0x02. Para aprovechar esta funcionalidad, deberás generar una nueva clave de retiro tipo 0x02 y realizar un nuevo depósito de validación.

GitBook has a powerful block-based editor that allows you to seamlessly create, update, and enhance your content.

Writing content

GitBook offers a range of block types for you to add to your content inline — from simple text and tables, to code blocks and more. These elements will make your pages more useful to readers, and offer extra information and context.

Either start typing below, or press / to see a list of the blocks you can insert into your page.

Add a new block

GitBook allows you to add images and media easily to your docs. Simply drag a file into the editor, or use the file manager in the upper right corner to upload multiple images at once.

In addition to the default Markdown you can write, GitBook has a number of out-of-the-box interactive blocks you can use. You can find interactive blocks by pressing / from within the editor.

Tabs

const handleFetchEvent = async (request, context) => {
    return new Response({message: "Hello World"});
};

Expandable sections

Drawings

Embedded content

GitBook supports many different types of content, and is backed by Markdown — meaning you can copy and paste any existing Markdown files directly into the editor!

Feel free to test it out and copy the Markdown below by hovering over the code block in the upper right, and pasting into a new line underneath.

# Heading

This is some paragraph text, with a [link](https://docs.gitbook.com) to our docs. 

## Heading 2
- Point 1
- Point 2
- Point 3

GitBook integrations allow you to connect your GitBook spaces to some of your favorite platforms and services. You can install integrations into your GitBook page from the Integrations menu in the top left.

Types of integrations

You can sync GitBook pages with an OpenAPI or Swagger file or a URL to include auto-generated API methods in your documentation.

OpenAPI block

🔑 Entropía y la creación de llaves

Primero que nada, hay que entender que una nueva llave pública —una nueva dirección— introduce entropía a todo el sistema. Es un nuevo nodo en el universo. La red responde generando nuevas conexiones, reorganizando sus caminos internos, reajustando rutas, como un bosque que se abre paso entre raíces antiguas.

Pero, generar aleatoriedad real es difícil.

Lo que usamos, incluso en los sistemas más avanzados, son generadores de números pseudoaleatorios. Esto significa que toman datos del entorno —del ruido del ventilador, del timing entre pulsaciones, de las estrellas, si se pudiera— y los combinan para formar una secuencia lo suficientemente caótica, aunque en esencia, calculada.

El momento clave sucede cuando un usuario trae consigo una semilla. Una cadena de 12, 18 o 24 palabras. Solo él conoce su origen. Solo él tiene el derecho y la responsabilidad de protegerla. Esta semilla es su llave al reino, su identidad secreta en la red.

🔮 La Ceremonia de Entropía para L2

En 2022, antes del nacimiento de muchas L2 (cadenas de segunda capa sobre Ethereum), se llevó a cabo una ceremonia pública para generar la llave inicial de su universo.

Esta ceremonia, conocida como el Trusted Setup, consistió en una colaboración de miles de participantes alrededor del mundo. Cada uno contribuyó con un fragmento de entropía —ya sea moviendo su mouse, grabando ruidos, o incluso leyendo poesía al azar— para construir una única clave maestra.

El principio era simple: si al menos uno de los participantes no mentía, la clave sería segura.

Esto sentó las bases criptográficas para zk-rollups y otras soluciones L2 que ahora validan millones de transacciones.

Ethereum necesita ejecutar dos tipos de clientes, o programas, que interactúan entre sí para hacer funcionar las aplicaciones descentralizadas (dApps). Cada uno de estos clientes tiene responsabilidades complementarias: uno se encarga del consenso, y el otro de la ejecución.

Para que un nuevo bloque se agregue a la cadena, una mayoría de nodos debe llegar a un consenso. En este momento, la cadena cuenta con 22,442,491 bloques, todos acordados bajo las reglas comunes a las que se adhieren los participantes de la red.

🌞 Cliente de consenso

Uno de los clientes de consenso que utilizo es Grandine, un cliente de código abierto. Cada validador, para ser incluido dentro del conjunto activo, debe hacer staking de, al menos, 32 ETH en la Beacon Chain. Porque con la nueva actualización de Pectra, los nodos podrán manejar una cantidad mayor.

Si solo se desea usar el nodo como proveedor de datos (RPC node) sin participar en el staking, también es posible: simplemente se corre el nodo y se espera a que se sincronice con la red.

Otro cliente de consenso muy popular, escrito en Rust, es Lighthouse 🏮, que tiene una mayor cuota de mercado. Yo corro ambos: Grandine y Lighthouse, para experimentar y comparar su comportamiento.

⚙️ Cliente de ejecución

Hasta ahora hemos hablado únicamente del consenso —la parte “oscura” y silenciosa del proceso. Pero también está la capa de ejecución, a menudo identificada como Ethereum Mainnet (Chain ID: 1). Aquí es donde realmente viven y se ejecutan los contratos inteligentes y las aplicaciones descentralizadas que usamos todos los días.

Para correr estas aplicaciones, se necesita un cliente de ejecución, que interactúe con la cadena y ejecute el código de los contratos.

La capa de ejecución es donde ocurren las interacciones visibles de Ethereum: contratos inteligentes, tokens, aplicaciones DeFi, NFTs, DAOs y más. Para que todo esto funcione, se necesita un cliente de ejecución que reciba transacciones, las valide y ejecute el código de los contratos según las reglas del protocolo.

El más utilizado históricamente es Geth (Go-Ethereum), desarrollado en Go por la Fundación Ethereum. Es el cliente más maduro y compatible, y ha sido durante años el estándar de facto para desarrolladores y operadores de nodos.

Sin embargo, en tiempos más recientes ha ganado mucha tracción Reth, un cliente de ejecución escrito en Rust, desarrollado por el equipo de Paradigm. Reth ha sido diseñado desde cero con un enfoque en seguridad, modularidad y rendimiento, aprovechando todo el poder y las garantías del lenguaje Rust.

Además de Geth y Reth, existen otros clientes de ejecución como:

• Erigon, enfocado en archivado y eficiencia en almacenamiento.

• Besu, ideal para entornos empresariales y compatibles con redes privadas.

• Nethermind, escrito en C# y muy usado en algunos entornos de investigación.

Cada cliente tiene sus particularidades, pero todos cumplen el mismo propósito: ejecutar la Ethereum Virtual Machine (EVM) y mantener el estado de la red.

Después de correr nodos en Bitcoin y Ethereum, operar en NEAR es notablemente más simple, gracias a las herramientas que el ecosistema ha desarrollado.

🚀 Herramienta utilizada: Xnode

Con Xnode, levantamos nuestro validador remoto de forma rápida, segura y confiable. Desde la terminal, la máquina comienza a trabajar: produce firmas, endosa bloques y mantiene el pulso de la red.

📊 Estado actual del nodo

Reporte reciente:

.------------------------------------.
|              | Expected | Produced |
|--------------|----------|----------|
| Blocks       |        0 |        0 |
| Chunks       |        0 |        0 |
| Endorsements |    28994 |    27386 |
'------------------------------------'

Aunque aún no producimos bloques ni chunks, estamos realizando endosos de manera activa, contribuyendo al consenso con constancia.

💠 Delegar con propósito

Este nodo forma parte de la red de Meta Pool, y ha sido desplegado desde América del Norte con la intención de fortalecer la descentralización y aportar transparencia.

Puedes delegar en:

🔹 nodosigiloso.pool.near

Delegar es respaldar una infraestructura abierta, mantenida con cuidado y documentada con claridad.

Lo primero es recordar, cómo fue que se crearon las llaves de aquella cartera. Fue mediante una billetera externa, o tirando dados 🎲.

La ardilla resurge: Origen y recuperación de tu semilla

Antes de restaurar una cartera, recuerda cómo se generaron tus claves:

• Wallet externo o hardware: la aplicación proporcionó tu frase mnemónica BIP39.

• Método manual: entropía generada con dados 🎲.

Consulta con tu proveedor de wallet el procedimiento exacto de backup y restore que emplea.

1. Estándares de semilla: BIP39 vs SLIP39

BIP39 (mnemónico clásico)

• Frase de 12–24 palabras de un vocabulario de 2 048 términos.

• Cada palabra codifica 11 bits; ENT + CS bits → semilla de 512 bits.

SLIP39 (Shamir Seed Sharing)

1. Elige un umbral t y un total de n fragmentos (shares).

2. Convierte la semilla maestra en la constante de un polinomio de grado t – 1 sobre un campo finito.

3. Evalúa el polinomio en n puntos distintos → n fragmen­tos.

4. Cualquier conjunto de t fragments permite interpolar el polinomio y reconstruir la semilla; con menos de t no hay información.

Ideal para repartir confianza sin exponer todo el secreto.

2. Derivación de claves: BIP44

Tras generar la semilla (BIP39 o SLIP39), aplica la ruta jerárquica BIP44:

m/44'/<moneda>'/<cuenta>'/0/0

• <moneda>: 0 (Bitcoin), 60 (Ethereum), 397 (NEAR)

• <cuenta>: índice de cuenta (normalmente 0)

Esto deriva tu clave maestra extendida (xprv/xpub) y de ahí salen todas tus direcciones.

3. Cuatro pasos para restaurar tu monedero

Cuando el reloj corre y cada bit vale, sigue estos pasos:

1. Entorno seguro

   • Dispositivo limpio y actualizado.

   • Red confiable (evita Wi‑Fi públicas).

   • Mnemónico BIP39 o fragmentos SLIP39 alineados.

2. Elegir la wallet

   • Multicadena: Exodus, Atomic, Trust Wallet.

   • Especializada:

     • BTC → Electrum

     • ETH → MetaMask / MyEtherWallet

     • NEAR → NEAR Wallet / near-cli

   • Debe soportar “Restore from seed” o “Shamir shares”.

3. Importar y derivar

   • Selecciona “Importar cuenta” o “Restore from seed”.

   • Ingresa tu frase o tus t fragmentos Shamir.

   • Si pide passphrase BIP39, déjala vacía salvo que la usaras.

   • Confirma la ruta BIP44 por defecto.

4. Verificar y reforzar

   • Espera sincronización y escaneo de direcciones.

   • Comprueba saldos en BTC, ETH y NEAR.

   • Refuerza seguridad: contraseña fuerte, respaldo físico y 2FA/PIN.

Con estos pasos, tu “ardilla” recupera la semilla y protege tu bosque de fondos.

Busca a tu proveedor de wallet y pregúntale sobre el procedimiento en particular para reestablecer una cartera.

El estandar de las palabras mnemónicas en Bitcoin proviene del bip39, sin embargo en la actuallidad ya existen otras alternativas como el SLIP39, el cual utiliza un procedimiento conocido como shamir seed sharing.

A question for you mister machine, Can you explain how the shamir thing works, and sort everything again, including the 4 steps. The steps are good, but I would like to give a broad explanation that how thinks work, my fellow mexican engineers are amazing, so lets dive on the importants. Then after the seed is generated either bip39 or slip39, then after the same bip44 runs right, it is a question?

1. Preparar un entorno seguro

• Elige un dispositivo limpio y actualizado.

• Conéctate a una red fiable (evita Wi-Fi públicas).

• Ten a mano tu frase de 12–24 palabras, correcta y en orden.

2. Seleccionar la wallet adecuada

• Multicadena: Exodus, Atomic Wallet, o Trust Wallet.

• Especializada:

  • Bitcoin: Electrum (BIP39/BIP44).

  • Ethereum: MetaMask o MyEtherWallet.

  • NEAR: NEAR Wallet (web) o near-cli.

• Comprueba que la wallet permita restaurar por “Seed phrase” o “Recovery phrase”.

3. Importar la frase y configurar derivación

• Abre la opción “Importar cuenta” / “Restore from seed”.

• Introduce tu frase mnemónica palabra por palabra.

• Si se solicita passphrase adicional (BIP39), déjala en blanco salvo que la usaras.

• Selecciona la ruta de derivación por defecto (BIP44):

  Copy

  m/44'/<moneda>'/<cuenta>'/0/0

  • Bitcoin → <moneda> = 0

  • Ethereum → <moneda> = 60

  • NEAR → <moneda> = 397

4. Verificar saldos y reforzar seguridad

• Espera a que la wallet sincronice y escanee direcciones.

• Confirma que tus fondos aparecen en cada red (BTC, ETH, NEAR).

• Refuerza la protección:

  • Establece contraseña fuerte.

  • Guarda la frase en un soporte físico seguro.

  • Habilita 2FA o PIN si la wallet lo permite.

Tengo mi servidor pequeno, y para permitirle correr multiples trabajos al mismo tiempo. O lo que viene siendo lo mismo, dejar corriendo algo. Se utiliza el comando de Linux screen.

Instalar el comando screen

$ sudo apt install screen

Abrir una nueva ventana y dejarla correr

$ screen -ls

$ screen -S machine-gun

# On the Keyboard cmd + A + D to detach screen

$ screen -r machine-gune # to jump into screen

Al correr múltiples clientes de Ethereum en una misma máquina, es importante evitar conflictos de puertos. Aquí documento cómo instalé y configuré Reth y Grandine, y cómo fui debuggeando para usar puertos alternativos correctamente.

✅ Instalación de Reth

# Clonamos el repositorio oficial
git clone https://github.com/paradigmxyz/reth
cd reth/

# Instalamos el binario principal
cargo install --locked --path bin/reth --bin reth

🚀 Ejecución con puertos por defecto

# Puerto por defecto
reth node

# Cambiar solo el puerto de discovery
reth node --discovery.port 30304

# Cambiar ambos puertos
reth node --discovery.port 30304 --port 30304

# También el puerto del authrpc
reth node --discovery.port 30304 --port 30304 --authrpc.port 8552

⚠️ En todos los casos, el nodo arrancaba sin errores aparentes, pero no sincronizaba bloques. Aparentemente, los puertos no estaban abiertos por el firewall del sistema.

🔩 Instalación de dependencias del sistema

sudo apt-get install ca-certificates libssl-dev clang cmake unzip protobuf-compiler libz-dev

Esto es necesario para compilar correctamente proyectos en Rust como Reth o Grandine.

🧱 Compilación de Grandine

git clone https://github.com/grandinetech/grandine
cd grandine/

# Inicializar los submódulos necesarios
git submodule update --init dedicated_executor eth2_libp2p

# Compilar con el perfil compacto y redes por defecto
cargo build --profile compact --features default-networks

🔥 Configuración de puertos con UFW

Para permitir la conexión y sincronización de nodos, hay que abrir los puertos específicos utilizados:

# Activar el firewall si aún no está activado
sudo ufw enable

# Permitir puertos de red alternativos para Reth
sudo ufw allow 30304/tcp   # P2P TCP
sudo ufw allow 30304/udp   # Discovery UDP
sudo ufw allow 8552/tcp    # AuthRPC

# Ver estado del firewall
sudo ufw status verbose

💡 Si estás ejecutando otros clientes como Lighthouse o Grandine, también deberás permitir sus puertos correspondientes.

📝 Notas

• El firewall (UFW) puede estar bloqueando el tráfico por defecto, incluso si el nodo corre sin errores.

• Probar conectividad con telnet, nc o revisar logs puede ser útil.

• Siempre que se cambien puertos, verificar que no haya conflicto con otros servicios en el sistema.

¿Quién dijo miedo? Aquí seguimos debuggeando sin parar 🛠️⚡

sudo ufw status

🔗 Network Configuration

The standard UFW - Uncomplicated firewall can be used to control network access to your node and protect against unwelcome intruders.

Configure UFW Defaults

By default, deny all incoming traffic and allow outgoing traffic.

6  sudo ufw default deny incoming
7  sudo ufw default allow outgoing

Configure SSH Port 22
8  sudo ufw allow from 177.177.1.0/24 to any port 22 proto tcp comment 'Allow SSH from local network'

Execution
9  sudo ufw allow 30303 comment 'Allow execution client port'

Consensus

10 sudo ufw allow 9000 comment 'Allow consensus client port' 11 sudo ufw enable 12 sudo ufw status numbered 13 history

177.177.1.0 <- local network.

ludo ufw allow from 177.177.1.0/24 to any port 22 proto tcp comment 'Allow SSH from local network'

El usuario es una abstraccion

✨ About the Name: /api/user/

Yes. It's fancy, mnemonic, and future-proof. I’d maybe document:

• /api/user/<address> — raw BTC or ETH address

• /api/user/<pubkey> — raw BTC compressed pubkey (33 bytes, hex)

• /api/user/<ens> — will resolve via ethers.js or web3.js (optional in v1)

🧠 Design Overview: /api/user/<ANY_IDENTIFIER>

✅ Supported Inputs:

You can design this endpoint to accept multiple identity types:

• Bitcoin address (bc1..., 1..., 3...)

• Ethereum address (0x...)

• Public keys (for BTC, only once revealed via spend)

• ENS name (sigiloso.eth)

• Other identifiers (in future: NEAR, Solana, etc.)

A good first move: normalize the identifier and redirect internally to the corresponding type resolver (BTC address → BTC profile view).

Al instalar Ubuntu 24.04 en mi servidor recién ensamblado, me encontré con que el disco principal (/) estaba completamente lleno al 100%. Esto me sorprendió, ya que había instalado dos discos internos con amplio espacio de almacenamiento.

Al revisar, noté que la instalación por defecto crea una partición encriptada que utiliza LVM (Logical Volume Management). LVM es una forma de virtualizar el almacenamiento, permitiendo manejar volúmenes lógicos sobre dispositivos físicos reales. Esto significa que podemos redimensionar estos volúmenes según nuestras necesidades, mientras exista espacio disponible en el grupo de volúmenes (VG).

1. 📈 Incrementar el tamaño del volumen de bloque

Primero, verifica el estado actual del disco:

$ df -h

Busca una línea similar a:

/dev/mapper/ubuntu--vg-ubuntu--lv   100G   100G   0  100% /

2. 🔎 Revisar el espacio disponible en el grupo de volúmenes (VG)

Para ver cuánto espacio libre queda en tu grupo de volúmenes (en este caso, ubuntu-vg):

$ vgdisplay

Busca la línea Free PE / Size, que indica el espacio libre que puedes asignar.

3. 📦 Verificar detalles del volumen lógico (LV)

Confirma que estás apuntando al volumen correcto:

$ lvdisplay

4. ➕ Extender el volumen lógico (LV)

Una vez identificado el nombre correcto del volumen lógico (por defecto ubuntu-lv), extiéndelo utilizando todo el espacio libre disponible en el grupo:

$ sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

Verifica nuevamente:

$ lvdisplay

5. 🛠️ Redimensionar el sistema de archivos (filesystem)

Finalmente, expande el sistema de archivos para que aproveche el nuevo espacio:

$ sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv

Verifica que el cambio se haya aplicado correctamente:

$ df -h

Deberías ver ahora una partición mucho más grande asignada a /.

✅ Resultado final esperado

Después de completar estos pasos, tendrás tu volumen lógico y sistema de archivos ampliado, utilizando todo el espacio disponible en tus discos físicos.

“Una ardilla sola sobrevive. Un bosque de ardillas prospera.”

🧭 Introducción

En esta publicación te cuento cómo, con un poco de Rust, algo de imaginación, y muchas ganas de entender la infraestructura descentralizada, construí una red de nodos multichain que se comunican entre sí, se monitorean, y comparten seguros en una Safe multisig. Lo llamo: el bosque de nodos P2P.

Este sistema está inspirado en la naturaleza: cada nodo es una ardilla que vive en su árbol (su ciudad, su servidor), pero juntas forman un ecosistema capaz de resistir caídas, coordinarse y tomar decisiones en grupo.

🐿️ Arquitectura general

El bosque se compone de varios elementos, cada uno con una responsabilidad clara:

Todos los servicios están escritos en Rust y pueden correr en contenedores separados o en conjunto dentro de un nodo único.

🌐 El protocolo del bosque: libp2p + gossip

Cada nodo en el bosque corre una instancia de hivemind, que usa libp2p y el protocolo de gossipsub para compartir mensajes del tipo:

jsonCopyEdit{
  "node_id": "squirrel_mexico_city",
  "eth_block": 21023311,
  "btc_block": 847521,
  "timestamp": "2025-06-06T18:00:00Z"
}

Estos mensajes permiten que cada nodo sepa el estado de los demás, identifique si alguno está caído, y tome decisiones como:

• "¿Debemos asumir su tarea?"

• "¿Repartimos el seguro del multisig?"

• "¿Quién lidera la próxima tarea?"

🏦 El fondo común: Gnosis Safe Multisig

Todos los nodos comparten una cuenta multisig que actúa como fondo de seguro colectivo. Esta Safe puede:

• Reembolsar a nodos que toman tareas extras cuando otro cae

• Financiar el despliegue de contratos

• Firmar transacciones importantes desde un módulo seguro

Cada acción importante pasa por una firma colectiva. Esto protege al sistema de acciones maliciosas o accidentales.

📦 Modularidad: Un workspace de Rust

Todos los componentes están organizados en un solo workspace de Cargo:

CopyEditexplorador_sigiloso/
├── node/
├── daemon/
├── hivemind/
├── signer/
├── api/
├── ui/
├── common/

Esto permite mantener cada módulo separado pero con tipos compartidos (NodeStatus, SignedGossip, ChainInfo, etc.), facilitando el testing, despliegue y escalabilidad.

🔁 Resiliencia: Qué pasa cuando un nodo cae

Supongamos que el nodo de Yucatán pierde conectividad.

1. Los nodos de CDMX y Chicago notan su ausencia vía gossip.

2. Se redistribuyen tareas automáticamente (por ahora manual, luego vía reglas).

3. El multisig puede compensar al nodo que asume trabajo extra.

4. El explorador_sigiloso_ui muestra en tiempo real el estado del bosque.

El sistema no se detiene. Se adapta.

📊 ¿Qué viene después?

• Gobernanza de membresía: ¿quién puede unirse al bosque?

• Validadores cross-chain coordinados

• Módulos de reputación para cada ardilla

• Escalado a más regiones y servidores

🌲 Reflexión final

Construir un sistema resiliente y descentralizado es un reto técnico, pero también una declaración filosófica: no queremos depender de un solo punto de control. Queremos que el bosque prospere, incluso si algunos árboles caen.

Si tú también quieres montar tu nodo ardilla, contribuir al código o simplemente observar el bosque, bienvenido.

🛰️ ¡La red está viva!

1. Listar los discos disponibles

Para localizar el disco, físico o virtual, en el que se va a trabajar, se puede utilizar el comando lsblk.

$ lsblk

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0 931.5G  0 disk /media/honey/bitcoin_data
mmcblk0     179:0    0  59.6G  0 disk
|-mmcblk0p1 179:1    0   512M  0 part /boot/firmware
`-mmcblk0p2 179:2    0  59.1G  0 part /

En Mac, se puede utilizar diskutil list.

$ diskutil list

/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.3 GB   disk0
   1:             Apple_APFS_ISC Container disk1         524.3 MB   disk0s1
   2:                 Apple_APFS Container disk3         494.4 GB   disk0s2
   3:        Apple_APFS_Recovery Container disk2         5.4 GB     disk0s3

/dev/disk3 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +494.4 GB   disk3
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            11.2 GB    disk3s1
   2:              APFS Snapshot com.apple.os.update-... 11.2 GB    disk3s1s1
   3:                APFS Volume Preboot                 7.2 GB     disk3s2
   4:                APFS Volume Recovery                1.0 GB     disk3s3
   5:                APFS Volume Data                    404.8 GB   disk3s5
   6:                APFS Volume VM                      5.4 GB     disk3s6

2. Espacio disponible y utilizado

Antes de comenzar, asegúrate de que tienes un SSD montado con suficiente espacio libre. Esto es crítico para correr un nodo Bitcoin confiable.

# Verifica el espacio disponible
$ df -h /media/honey/bitcoin_data/

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda        916G  360G  510G  42% /media/honey/bitcoin_data

3. Montaje y desmontaje del SSD

# Montar
$ sudo mkdir -p /mnt/bitcoin-data
$ sudo mount /dev/sda /mnt/bitcoin-data

# Desmontar
$ sudo umount /mnt/bitcoin-data

Con Mac,

$ diskutil unmount /Volumes/bitcoin_data

🧠 No desconectes el SSD sin desmontarlo. Recuerda que tu nodo es un monje zen: necesita cerrar con paz.

Aqui comienza...

      +----------------------+
      |  12–24 palabras      |
      |  (frase mnemónica)   |          BIP 39 
      +----------------------+
                |
                v
      +----------------------+
      |       Semilla        |
      |  (512 bits típico)   |
      +----------------------+
                |
                v
      +----------------------+
      |  Cadena (master key) |
      |  y datos de cadena   |
      +----------------------+
                |
                v
      +----------------------+
      |      Encoding        |
      | • Hexadecimal        |
      | • Base58Check        |
      | • Bech32             |
      +----------------------+

Una vision alternativa.

aca sigue Las mnemónicas provienen de BIP39: • BIP39 define cómo convertir una lista de 12–24 palabras en una semilla de alta entropía. • Cada palabra se serializa a una cadena de 11 bits (0–2047). • Se concatenan ENT (128–256 bits) + CS (checksum) bits para formar el total de bits.

 +----------------------+
 |      BIP39           |
 +----------------------+
           |
           v
 +----------------------+
 | 12–24 palabras       |
 | (frase mnemónica)    |
 +----------------------+
           |
           v
 +----------------------+
 |  Bits (ENT + CS)     |
 +----------------------+
           |
           v
 +----------------------+
 |     Semilla (512b)   |
 +----------------------+
           |
           v
 +----------------------+
 | Cadena maestra (xprv)|
 | y datos de cadena    |
 +----------------------+
           |
           v
 +-------------------------------------------+
 | Ruta de derivación (BIP44)                |
 | m / propósito' / tipo_moneda' / cuenta'   |
 |     / cambio / índice_dirección           |
 +-------------------------------------------+
 Ejemplo: m/44'/0'/0'/0/0

BIP44 define la estructura de rutas:

1. propósito: 44' (hardened)

2. tipo_moneda: 0' para Bitcoin, 60' para Ethereum…

3. cuenta: índice de cuenta (normalmente 0')

4. cambio: 0 para externo, 1 para interno

5. índice_dirección: 0, 1, 2, …

Con esto, cada nodo puede derivar claves privadas y públicas de forma determinista y jerárquica.

Esta vez, joven, señor, señorita, les venimos ofreciendo esto que es el paso a paso pues. Que agarro y que le digo, para correr la versión, la imagen de bitcoin en docker, más actualizada.

🛑 Step 1: Stop the node

This stops the container but preserves data (assuming you're using a persistent volume):

docker stop bitcoin-mainnet

🔼 Step 2: Pull the latest Bitcoin Core image

This downloads the latest bitcoin/bitcoin image (even if tagged as latest, Docker won't auto-update unless you pull it):

docker pull bitcoin/bitcoin:latest

🧼 Step 3: Remove the old container

The container is just a wrapper — this won’t delete your blockchain data if you're using a volume (double-check your docker-compose.yml to confirm this):

docker rm bitcoin-mainnet

🚀 Step 4: Restart the node with the new image

If you use docker-compose.yml, simply run:

docker-compose up -d

Or if you’re using docker run, re-run it with your original settings and volume mounts, something like:

bashCopyEditdocker run -d \
  --name=bitcoin-mainnet \
  -p 8332:8332 \
  -p 8333:8333 \
  -v /your/host/bitcoin-data:/bitcoin/.bitcoin \
  --restart unless-stopped \
  bitcoin/bitcoin:latest \
  bitcoind -printtoconsole -server

✅ Step 5: Confirm it’s running and synced

Check logs:

bashCopyEditdocker logs -f bitcoin-mainnet

Or get block height:

bashCopyEditdocker exec bitcoin-mainnet bitcoin-cli getblockcount

⚙️ Estado actual

Tu nodo lleva 3 semanas corriendo, pero solo ha alcanzado el 85% del progreso de sincronización. Eso no está bien. Deberías estar más cerca del 100% en ese tiempo, especialmente si tu hardware no es muy viejo y tu red es estable.

bashCopyEditprogress=0.847138

🧭 Diagnóstico inicial

🚫 ¿Problemas de red?

❌ Poco probable. Si otros nodos (como tus de Ethereum) sincronizan bien en la misma red, entonces no es tu conexión.

💾 ¿Problemas de disco?

✅ Estás usando un disco externo montado en /media/user/bitcoin_data:

bashCopyEdit/dev/sda        916G  680G  190G  79%

Parece un SSD de casi 1 TB. No hay errores de espacio, y el uso del 79% es aceptable.

PERO: Si es un SSD viejo o sin TRIM activo, puede ser muy lento en operaciones de escritura aleatoria, lo que afecta directamente el rendimiento de Bitcoin Core.

🔍 ¿Qué puedo revisar?

1. Verifica el rendimiento del disco

Ejecuta esto para ver si es lento:

bashCopyEditsudo hdparm -Tt /dev/sda

Si da resultados por debajo de 100 MB/s (lectura), probablemente necesitas cambiar de disco o moverlo a un NVMe interno.

2. Verifica cuántos peers tienes

bashCopyEditbitcoin-cli getnetworkinfo | grep connections

Si tienes menos de 8-10 conexiones, tu nodo se sincroniza lento.

Solución: abre más puertos o usa nodos públicos como bootstrap (por ejemplo: addnode en bitcoin.conf).

3. Activa más caché de disco

Edita tu bitcoin.conf y añade:

iniCopyEditdbcache=2048
maxmempool=300

Y reinicia tu nodo. Esto puede mejorar muchísimo la velocidad de validación de bloques.

🌱 ¿Y si ya no quiero esperar?

✍️ Reflexión final

Correr un nodo no es solo prender una caja, es un acto de soberanía tecnológica. Si se tarda... no desesperes, optimiza, aprende y sigue corriendo 🧸

🐿️ Una arquitectura sigilosa para custodiar el invierno

"Cada semilla contiene un bosque. Pero también, si cae en malas patas, puede quemarse entero." - 🐈‍⬛

En el mundo de los nodos, el frío no avisa. Por eso, como buena exploradora, planeamos con tiempo y ordenamos nuestras semillas (nuestras llaves). Para lograrlo, existe una serie de estándares llamados BIPs (Bitcoin Improvement Proposals) que nos permiten organizar de forma determinista —y segura— todas las llaves que derivan de una sola semilla.

Sí, una sola semilla puede dar lugar a miles de direcciones, y si sabes cómo caminar por los caminos correctos (HD paths), entonces puedes tener control, trazabilidad, y sobre todo, seguridad.

🛤️ ¿Qué es un camino HD?

Un camino HD (Hierarchical Deterministic Path) es simplemente una ruta que le dice al monedero cómo llegar a una dirección a partir de una semilla.

Ejemplo visual:

nginxCopyEditm / propósito' / tipo_moneda' / cuenta' / cambio / índice

Por ejemplo, el camino m/44'/60'/0'/0/0 indica la primera dirección de Ethereum, siguiendo el estándar BIP44.

🧱 Diseño recomendado para empresas sigilosas

En Nodo Sigiloso recomendamos el siguiente esquema. Fácil de recordar, pero bien separado por función:

🔸 Para Bitcoin (BIP84 – direcciones tipo bc1...)

🟣 Para Ethereum (BIP44 – MetaMask, Ledger, etc.)

🧠 Filosofía ardillesca: la semilla es sagrada

Todas estas direcciones derivan de una sola llave semilla (seed phrase). Esta semilla es la raíz de poder 🎋.

🧊 Consejos para ardillas precavidas

• 🧯 Nunca compartas tu semilla.

• 🔑 Usa hardware wallets y divide funciones (una para operar, otra para custodiar).

• 🧩 Para mayor seguridad, divídela en fragmentos (Shamir Secret Sharing).

• 🏔️ Guarda la semilla física en lugares separados y seguros.

• 🐚 Las cuentas derivadas no tienen que tener conexión entre ellas, lo cual reduce riesgo si se compromete una rama.

¿Te gustaría que lo complemente con una imagen visual del árbol HD con las ramas operativas y tesorería? 🌳