Chemaclass - tutorial

Dentro de la Carpeta .claude

2026-04-17T00:00:00+00:00

Cada proyecto en el que trabajo tiene una carpeta .claude/ en la raíz. Commiteada en git, como el resto del código.

Esa carpeta convierte Claude Code de un asistente genérico en un compañero que conoce tu proyecto. Quien clone el repo hereda el mismo setup.

El agentic coding es tan bueno como el contexto que le das al agente. La carpeta .claude/ es donde vive ese contexto.

La carpeta .claude, de un vistazo #

.claude/
├── CLAUDE.md # onboarding del proyecto
├── settings.json # permisos, hooks, env
├── skills/ # procedimientos reutilizables (slash commands)
├── rules/ # convenciones por glob
├── hooks/ # scripts que reaccionan a eventos
└── agents/ # roles especializados

Seis capas, una carpeta. Contexto, seguridad, procedimientos, barandillas, automatización, especialistas.

Los cimientos #

CLAUDE.md: donde todo empieza #

Claude Code lee CLAUDE.md en cada arranque. El doc de onboarding.

En Phel, el mío cubre el pipeline del compilador (Lexer → Parser → Analyzer → Emitter), la estructura de módulos, convenciones y comandos clave.

Un ~/.claude/CLAUDE.md global aplica a todos tus proyectos. El archivo de proyecto dice cómo funciona este código. El global dice cómo trabajo yo.

Cada byte viaja en cada prompt. Mantenlo corto. Si pasa de una pantalla, mueve el detalle a rules/ o skills/.

Un buen CLAUDE.md es un buen doc de onboarding. Cuanto mejor sea, menos te repites.

settings.json: seguridad antes que potencia #

Antes de darle más poder al agente, bloquea lo que nunca debe hacer.

.claude/settings.json contiene tres cosas: permissions (allow/deny), hooks (comandos por evento) y env (variables). Un settings.local.json gitignoreado mantiene las configuraciones personales aparte.

{
 "permissions": {
 "allow": [
 "Bash(composer:*)",
 "Bash(./bin/phel:*)",
 "Bash(git:*)",
 "Bash(gh:*)"
 ],
 "deny": [
 "Bash(rm -rf:*)",
 "Bash(sudo:*)"
 ]
 }
}

Allow desbloquea el flujo. Deny marca la línea que el agente no puede cruzar, aunque se lo pidas con buena cara.

Los permisos son el suelo. Todo lo demás se construye sobre una base segura.

Procedimientos y barandillas #

Skills: procedimientos que puedes ejecutar #

Siguiente dolor tras onboarding: la repetición. Los skills lo resuelven.

Un skill es un archivo markdown en .claude/skills/, un procedimiento que invocas con una barra:

/gh-issue <número>: de issue a rama, plan TDD, PR.
/commit: fix, análisis, tests, commit convencional.
/refactor-check: SOLID, naming, olores de arquitectura.
/release [version]: changelog, PHAR, tag, release.

Prompt directo: “arregla el issue #42”. El agente improvisa. Distinto cada vez.
Rule: “usa conventional commits”. Da forma al resultado, no al procedimiento.
Skill: “/gh-issue 42”. El procedimiento es la instrucción.

Los skills convierten conocimiento tribal en pasos ejecutables por cualquiera.

Los skills capturan qué hacer. Las rules capturan qué no hacer.

Rules: las barandillas #

CLAUDE.md se lee en cada sesión. Las rules solo cuando aplican. Los archivos en .claude/rules/ apuntan a áreas del código con patrones glob: el agente carga solo lo que corresponde, manteniendo el contexto ligero.

Archivos de rules en Phel:

compiler.md: pipeline estricto de 4 fases, sin atajos.
php.md: PER 3.0, clases final, readonly, patrón Gacela.
phel.md: kebab-case, defn- privadas, :doc/:example obligatorios.
integration-tests.md: secciones --PHEL-- / --PHP-- en fixtures.

Las rules del compilador no se activan al editar código Phel. Las rules de Phel no se activan al editar infraestructura PHP.

Las rules no son sugerencias. Viajan con el código: un cambio de convención y su rule viajan en el mismo commit. Sin drift, sin wikis desactualizadas.

Automatización y delegación #

Hooks: automatización en los bordes #

Las rules dicen al agente qué hacer. Los hooks se aseguran de que ocurra aunque el agente olvide.

Comandos shell disparados por eventos de Claude Code (PreToolUse, PostToolUse, Stop), conectados vía settings.json. En Phel, PreToolUse bloquea ediciones a archivos críticos (build/release.sh, .github/*, composer.lock). PostToolUse auto-formatea PHP vía php-cs-fixer.

{
 "hooks": {
 "PreToolUse": [{
 "matcher": "Edit|Write",
 "hooks": [{ "type": "command", "command": ".claude/hooks/protect-files.sh" }]
 }],
 "PostToolUse": [{
 "matcher": "Edit|Write",
 "hooks": [{ "type": "command", "command": ".claude/hooks/format-php.sh" }]
 }]
 }
}

Las rules son lo que el agente debe saber. Los hooks son lo que el sistema impone de todas formas.

Agents: roles especializados #

Todo lo anterior da forma a un solo agente. Los agents añaden especialistas a los que el agente principal puede delegar, cada uno con sus propias herramientas, permisos y modelo. La pieza más avanzada. La recomiendo de última.

Algunos de Phel:

Explorer (Sonnet, solo lectura): archivos, mapeo de estructura.
Clean Code Reviewer: SOLID y naming en diffs.
TDD Coach: imposición red-green-refactor.
Domain Architect: límites de módulos, pipeline del compilador.
Debugger: errores del compilador en todas las fases.

Cada agente corre en su propia ventana de contexto: la sesión principal se mantiene limpia mientras el especialista profundiza. La ganancia no es solo coste, es foco. Un agente con solo read y grep no puede reescribir tu código por error.

El modelo correcto para el trabajo correcto. Rápido y barato para explorar. Profundo y cuidadoso para arquitectura.

Empieza pequeño, crece con la fricción #

No construyas todo esto el primer día.

El orden, guiado por fricción real:

Empieza con CLAUDE.md.
Bloquea permisos en settings.json.
La primera vez que te repitas, escribe un skill.
La primera vez que el agente rompa una convención, añade una rule.
La primera vez que algo malo casi se commitee, añade un hook.
La primera vez que un generalista no encaje, define un especialista.

Cada paso soluciona un problema que realmente tuviste. No uno que imaginaste.

El setup crece desde la fricción real, no desde el diseño anticipado.

Commitea la carpeta. Compártela. Cuando alguien se una, su sesión hereda todo.

Trata .claude/ como infraestructura. Versiónala. Revísala. Hazla evolucionar con el código.

Cómo Funciona Bitcoin

2025-12-22T00:00:00+00:00

Este post explica cómo funciona Bitcoin por dentro. Si buscas entender por qué importa, empieza con Fundamentos de Bitcoin.

Para los técnicamente curiosos.

La Blockchain #

El problema del doble gasto #

El dinero digital tiene un problema fundamental: ¿cómo evitas que alguien copie sus monedas y las gaste dos veces? Los sistemas tradicionales lo resuelven con una autoridad central (bancos, PayPal) que rastrea quién posee qué. El avance de Bitcoin fue resolver esto sin ningún intermediario.

La solución: un libro mayor compartido que todos pueden verificar pero nadie controla.

Cómo funciona #

Bitcoin usa una blockchain: una cadena de bloques donde cada bloque contiene transacciones y enlaza al bloque anterior a través de hashes criptográficos.

Una función hash toma cualquier entrada y produce una huella digital de tamaño fijo. Cambia un bit de la entrada y la salida cambia por completo. Esto hace evidente cualquier manipulación. Bitcoin usa SHA-256, que produce una salida de 256 bits.

Cada bloque contiene:

Una lista de transacciones
Un hash del encabezado del bloque anterior
Una solución proof-of-work (más abajo)

Antes de entrar en un bloque, las transacciones esperan en el mempool. Los mineros seleccionan de este pool, priorizando las que pagan más comisiones. Puedes verlo en tiempo real en mempool.space.

Cada nodo guarda una copia completa de la blockchain. No hay un solo servidor que hackear ni una base de datos central que corromper. Para cambiar el historial, tendrías que reescribir bloques en la mayoría de nodos del mundo.

Un bloque tiene dos partes: el encabezado (80 bytes) y el cuerpo (transacciones).

El encabezado contiene:

Versión: Versión del protocolo
Hash del bloque anterior: Enlaza a la cadena
Raíz Merkle: Hash de todas las transacciones en el bloque
Marca de tiempo: Cuándo se creó el bloque
Objetivo de dificultad: Qué tan difícil era el puzzle
Nonce: La solución que encontraron los mineros

Los árboles Merkle organizan las transacciones de forma eficiente. Cada transacción se hashea, luego los pares de hashes se combinan y hashean de nuevo, hasta llegar a un único hash raíz. Esto permite probar que una transacción existe en un bloque sin descargar todas las demás. Muy útil para wallets ligeras.

El peso del bloque se mide en bytes virtuales (vB). El límite es 4 millones de unidades de peso, aproximadamente 1-1.5 MB de datos por bloque.

Transacciones y criptografía #

El modelo UTXO #

Bitcoin no usa cuentas con saldos. En su lugar, rastrea Salidas de Transacciones No Gastadas (UTXOs). Piensa en ellas como monedas digitales de varios tamaños.

Cuando recibes bitcoin, obtienes un UTXO. Cuando gastas, consumes UTXOs completos como entradas y creas nuevos como salidas. Si tienes un UTXO de 1 BTC y quieres enviar 0.3 BTC, gastas el UTXO entero y creas dos salidas: 0.3 BTC para el destinatario y unos 0.7 BTC de vuelta para ti (menos las comisiones).

Tu “balance” es la suma de todos los UTXOs que puedes gastar.

Criptografía de clave pública #

Las transacciones de Bitcoin usan criptografía de clave pública:

Clave privada: Un número secreto de 256 bits. Demuestra la propiedad.
Clave pública: Se deriva matemáticamente de la clave privada. Se comparte públicamente.

Cuando envías bitcoin, firmas la transacción con tu clave privada. Esta firma demuestra que posees los UTXOs sin revelar la clave privada. Cualquiera puede verificar la firma usando tu clave pública.

Dinero programable #

Bitcoin no es solo efectivo digital. Tiene su propio lenguaje de programación llamado Script. Cada transacción incluye un pequeño programa que define las condiciones para gastarla.

La mayoría de transacciones usan scripts simples: “quien pueda demostrar que posee esta clave pública puede gastar estas monedas.” Pero Script permite mucho más: wallets multifirma que requieren varias claves, transacciones con bloqueo temporal que no pueden gastarse hasta cierta fecha, y condiciones complejas combinando múltiples requisitos.

Esto convierte a Bitcoin en dinero programable. Para profundizar en Script y tipos de direcciones, mira Dinero Programable.

Bitcoin usa ECDSA (Algoritmo de Firma Digital de Curva Elíptica) con la curva secp256k1. Se eligió esta curva por su eficiencia y porque no la diseñó ninguna agencia gubernamental (a diferencia de las curvas NIST), lo que reduce preocupaciones sobre puertas traseras.

Una clave privada es un entero aleatorio de 256 bits. La clave pública se deriva multiplicando ese número por un punto generador en la curva. Fácil de calcular en un sentido, prácticamente imposible de revertir.

La firma de transacciones implica:

Hashear los datos de la transacción
Crear una firma usando la clave privada
Incluir la firma y clave pública en la transacción

Las banderas SIGHASH controlan qué partes de una transacción cubre la firma:

SIGHASH_ALL: Firma todas las entradas y salidas (más común)
SIGHASH_NONE: Firma solo las entradas
SIGHASH_SINGLE: Firma una salida específica
Estas pueden combinarse con ANYONECANPAY para casos de uso avanzados

Minería y consenso #

¿Cómo se pone de acuerdo una red descentralizada sobre qué transacciones son válidas? Mediante minería proof-of-work.

El puzzle #

Los mineros compiten por encontrar un número (el nonce) que, combinado con el encabezado del bloque y hasheado, produce un resultado por debajo de un valor objetivo. Es como tirar dados hasta sacar un número menor que 100, pero con 2^256 resultados posibles.

El trabajo es:

Difícil de encontrar: Requiere billones de intentos
Fácil de verificar: Una comprobación de hash prueba la solución

Esta asimetría es clave. Cualquiera puede verificar un bloque al instante, pero crearlo requiere trabajo computacional real.

Por qué importa #

La minería sirve para tres propósitos:

Asegura la red: Reescribir la historia significa rehacer todo el trabajo de hash
Emite nuevas monedas: Siguiendo un calendario predecible (halving cada 210.000 bloques)
Procesa transacciones: Incluyéndolas en el registro permanente

Cada 2016 bloques (unas 2 semanas), la red ajusta la dificultad para mantener tiempos de bloque de unos 10 minutos. ¿Se suma más hashpower? Los puzzles se vuelven más difíciles. ¿El hashpower baja? Los puzzles se vuelven más fáciles.

Explora los pools de minería y hashrate en mempool.space/mining.

Cálculo de dificultad: El objetivo es un número de 256 bits. Un hash de bloque válido debe estar por debajo de este objetivo. Objetivo más bajo = puzzle más difícil. La red ajusta cada 2016 bloques según cuánto tardaron realmente esos bloques frente a los 20.160 minutos esperados.

Hashrate y seguridad: La seguridad de Bitcoin viene del coste de reescribir el historial. Con unos 500 EH/s (exahashes por segundo) de hashrate, atacar la red requeriría controlar la mayoría del hashpower. Eso supone miles de millones en hardware y electricidad, y además el ataque haría colapsar el valor del activo.

Incentivos económicos: Los mineros gastan recursos reales (electricidad, hardware). Solo obtienen beneficio si juegan según las reglas. Un minero que crea bloques inválidos desperdicia su trabajo porque los nodos los rechazan. Esto alinea el beneficio individual con la seguridad de la red.

Ataques del 51%: Si un atacante controlara la mayoría del hashpower, en teoría podría hacer doble gasto minando una cadena alternativa. Pero la economía hace esto irracional para grandes valores: el ataque destruye el valor de lo que intentas robar.

Direcciones y wallets #

Las direcciones de Bitcoin se derivan de las claves públicas. Han evolucionado diferentes formatos:

P2PKH: Direcciones legacy que empiezan con “1”
P2SH: Direcciones script que empiezan con “3”
P2WPKH: Direcciones SegWit nativas que empiezan con “bc1q”
P2TR: Direcciones Taproot que empiezan con “bc1p”

Para detalles técnicos de cada tipo, ve Dinero Programable.

Wallets #

Una wallet gestiona tus claves y construye transacciones. No contiene tus monedas: las monedas existen en la blockchain. La wallet contiene las claves que demuestran que puedes gastarlas.

Wallets calientes se conectan a internet. Convenientes para uso diario, más vulnerables. Ejemplos: apps de móvil, extensiones de navegador.

Wallets frías permanecen offline. Más seguras para ahorros. Ejemplos: hardware wallets (Ledger, Trezor), paper wallets.

Wallets HD y frases semilla #

Las wallets modernas son Deterministas Jerárquicas (HD). Una semilla maestra genera claves ilimitadas en una estructura de árbol. Haces backup de la semilla una vez y puedes recuperar todo.

BIP-39 define la frase semilla de 12 o 24 palabras que usa la mayoría de wallets. Estas palabras codifican entropía que deriva todas tus claves. Pierdes la frase, pierdes el acceso. Cualquiera con la frase controla los fondos.

Nunca almacenes frases semilla digitalmente. Escríbelas. Guárdalas de forma segura offline.

¿Cómo de grande es el espacio de claves de BIP-39 en realidad? He construido seed-hunter, una herramienta educativa de código abierto en Go que intenta hacer fuerza bruta sobre una semilla de 12 palabras contra la red real de Bitcoin. Registra cada intento y muestra el progreso en vivo con ETAs que abarcan de 10²⁹ a 10³⁹ años. Un ladrón comprobando un billón de frases semilla por segundo desde el Big Bang habría completado el 0.000_000_008% de la búsqueda hasta ahora. La idea no es romper Bitcoin, sino hacer las matemáticas viscerales y obvias: la termodinámica, no solo la computación, prohíbe el ataque.

La red #

Bitcoin es una red peer-to-peer, sin servidores centrales. Los nodos se conectan entre sí, comparten transacciones y bloques, y hacen cumplir las reglas de forma independiente.

Tipos de nodos #

Nodos completos descargan y validan cada bloque y transacción. Hacen cumplir todas las reglas de consenso y no confían en nadie. Ejecutar un nodo completo significa verificar todo por ti mismo.

Clientes SPV (ligeros) solo descargan encabezados de bloque. Confían en que los mineros ya validaron las transacciones. Menos seguridad, pero funcionan en móviles y dispositivos de baja potencia.

Nodos de minería son nodos completos que también compiten por crear nuevos bloques.

Cómo se propagan las transacciones #

Cuando transmites una transacción:

Tu wallet la envía a los nodos conectados
Cada nodo valida y reenvía a sus pares
En segundos, la transacción alcanza la mayor parte de la red
Los mineros la incluyen en sus bloques candidatos

Los bloques se propagan de forma similar. Cuando un minero encuentra un bloque válido, se extiende por la red en segundos.

Descubrimiento de pares: Los nodos se encuentran mediante semillas DNS (direcciones hardcodeadas que devuelven IPs de nodos activos) y compartiendo direcciones de pares con otros nodos conectados.

Protocolo gossip: La información se propaga mediante mensajes “inv” (inventario). Un nodo anuncia que tiene algo nuevo, y los pares lo solicitan si les interesa. Esto evita desperdiciar ancho de banda con datos duplicados.

Bloques compactos (BIP-152) aceleran la propagación de bloques. Como los nodos ya tienen la mayoría de transacciones en su mempool, los bloques pueden transmitirse solo como el encabezado más IDs cortos de transacciones.

Seguridad y confirmaciones #

Por qué importan las confirmaciones #

Cuando una transacción se incluye en un bloque, tiene 1 confirmación. Cada bloque posterior añade otra confirmación.

Más confirmaciones = más difícil de revertir. Para deshacer una transacción confirmada, un atacante tendría que minar una cadena alternativa más rápido que la red honesta. Cada bloque hace esto exponencialmente más difícil.

Guías generales:

0 confirmaciones: Transacción transmitida pero aún no en un bloque. Puede ser doble gastada.
1 confirmación: En un bloque. La reversión requiere hashpower significativo.
6 confirmaciones: Estándar para grandes cantidades. Reversión prácticamente imposible.

El whitepaper de Satoshi incluye el cálculo de probabilidad. Con un atacante que controla una fracción q del hashpower:

Si q < 0.5: La probabilidad de alcanzar disminuye exponencialmente con cada confirmación
A 6 confirmaciones con q = 0.1 (10% hashpower): Probabilidad de éxito < 0.1%

La regla de “6 confirmaciones” asume un atacante bien financiado con hashpower sustancial pero minoritario. Para transacciones más pequeñas, muchas veces bastan menos confirmaciones.

La finalidad en Bitcoin es probabilística, no absoluta. Pero tras suficientes confirmaciones, la probabilidad de reversión se acerca a cero para cualquier atacante realista.

Alineación de incentivos #

Bitcoin no es solo tecnología ingeniosa. Es un sistema donde el interés propio de cada participante fortalece la red.

Mineros invierten en hardware y electricidad. Solo obtienen beneficio produciendo bloques válidos. Hacer trampas desperdicia su inversión porque los nodos rechazan bloques inválidos al instante.
Nodos hacen cumplir las reglas para proteger sus propios fondos. Un operador de nodo que acepta transacciones inválidas devalúa su propio bitcoin. El interés propio los convierte en validadores honestos.
Usuarios pagan comisiones para que sus transacciones se procesen. Comisiones más altas significan confirmación más rápida. Esto crea demanda de espacio de bloque y financia la seguridad de la red.
Desarrolladores contribuyen a software que ellos mismos usan. Los bugs perjudican sus propias tenencias. Las mejoras benefician a todos, incluyéndoles.
Holders se benefician de la seguridad y adopción de la red. Cuanto más seguro y útil se vuelve Bitcoin, más valiosos son sus fondos. Tienen incentivos para apoyar el ecosistema.

Sin coordinador central. Sin necesidad de confianza. Todos actúan en su propio interés, y el sistema beneficia a todos.

“No confíes, verifica.” Cualquiera puede ejecutar un nodo y verificar cada transacción, cada bloque, cada regla. No hace falta confiar en bancos, gobiernos, ni siquiera en otros usuarios de Bitcoin. Las matemáticas se demuestran solas.

Escalabilidad: Lightning Network #

La capa base de Bitcoin procesa unas 7 transacciones por segundo. Es así por diseño: mantener la descentralización requiere bloques lo suficientemente pequeños para que cualquiera pueda verificar. Pero esto limita cuántas transacciones puede manejar.

Lightning Network resuelve esto con una segunda capa construida sobre Bitcoin. Permite:

Pagos instantáneos: Sin esperar confirmaciones de bloque
Comisiones casi nulas: Fracciones de céntimo
Alta capacidad: Millones de transacciones por segundo

Lightning funciona abriendo “canales de pago” entre partes. Las transacciones dentro de un canal ocurren off-chain, al instante. Solo la apertura y cierre de canales requieren transacciones on-chain. Puedes visualizar la topología de la red y estadísticas en mempool.space/lightning.

La capa base de Bitcoin proporciona seguridad y liquidación final. Lightning proporciona velocidad y escala. Diferentes herramientas para diferentes trabajos.

Si quieres ejecutar tu propio nodo Lightning y tomar control total de tus pagos, escribí una guía sobre cómo Ejecutar tu nodo LN en una Raspberry Pi.

Los canales de pago usan direcciones multifirma 2-de-2. Ambas partes deben firmar para mover fondos. Esto crea una cuenta compartida de la que ninguna puede robar.

HTLCs (Contratos Hash Time-Locked) permiten pagos multi-salto. El mecanismo:

Alice quiere pagar a Carol a través de Bob
Carol genera un secreto y da a Alice el hash
Alice crea un HTLC: “Bob recibe el pago si revela el secreto en 24 horas”
Bob crea un HTLC similar con Carol
Carol revela el secreto a Bob, reclamando el pago
Bob usa el mismo secreto para reclamar de Alice

Si alguien no coopera, el timelock expira y los fondos vuelven. El secreto viaja hacia atrás, los pagos viajan hacia adelante.

Watchtowers monitorean la blockchain buscando intentos de trampa. Si tu contraparte intenta transmitir un estado antiguo del canal, el watchtower puede penalizarla, incluso mientras estás offline.

El panorama general #

Lo que hace notable a Bitcoin no es ningún componente individual, sino cómo encajan todos en un sistema que se refuerza a sí mismo.

La criptografía demuestra la propiedad sin autoridades de confianza. El proof-of-work hace costoso reescribir el historial. Los incentivos económicos convierten la codicia individual en seguridad colectiva. La descentralización elimina puntos únicos de fallo. Y la oferta fija crea escasez digital por primera vez en la historia.

Cada pieza sostiene a las demás. Quita una, y el sistema se debilita. Juntas, crean algo que nunca había existido: dinero que no puede inflarse, transacciones que no pueden censurarse, y propiedad que no puede confiscarse.

Sin bancos. Sin gobiernos. Sin terceros de confianza. Solo matemáticas, código, y una red global de nodos que hacen cumplir las mismas reglas.

Si eso te importa o no depende de dónde vivas y cuánto confíes en tus instituciones. Pero la opción ya existe. Y nadie puede quitártela.

La profundidad técnica de Bitcoin va mucho más allá de lo que cabe en un post. Aquí hay temas que vale la pena explorar si quieres profundizar:

SegWit (Testigo Segregado) fue la actualización de Bitcoin de 2017 que movió los datos de firma fuera de la estructura principal de la transacción. Arregló la maleabilidad de transacciones (un bug que impedía Lightning), introdujo el peso de bloque para un uso más eficiente del espacio, y lo hizo todo manteniendo compatibilidad con nodos antiguos.

Taproot y Schnorr llegaron en 2021, actualizando la criptografía de Bitcoin. Las firmas Schnorr son más pequeñas y permiten agregación (varias firmas se convierten en una). Taproot hace que las condiciones de gasto complejas se vean idénticas a los pagos simples on-chain, mejorando tanto la privacidad como la eficiencia.

Soft forks vs hard forks: ¿Cómo se actualiza Bitcoin sin una autoridad central? Los soft forks añaden nuevas reglas que los nodos antiguos aún aceptan. Los hard forks cambian las reglas de formas que los nodos antiguos rechazan. Entender esta distinción explica por qué Bitcoin evoluciona lentamente y por qué los cambios controvertidos son raros.

Mecánica de comisiones: El mercado de comisiones tiene más matices que “paga más, confirma más rápido”. Replace-By-Fee (RBF) te permite aumentar la comisión de una transacción atascada. Child-Pays-For-Parent (CPFP) permite a los destinatarios acelerar pagos entrantes gastándolos con comisiones altas.

Timelocks: Bitcoin puede bloquear fondos hasta que se cumplan ciertas condiciones. CLTV (CheckLockTimeVerify) bloquea hasta una altura de bloque o marca de tiempo específica. CSV (CheckSequenceVerify) bloquea por un tiempo relativo tras la confirmación. Estas primitivas permiten canales Lightning, esquemas de herencia e intercambios atómicos.

Transacciones coinbase: La única forma en que bitcoin nuevo entra en circulación. Cada bloque comienza con una transacción especial que paga al minero la recompensa del bloque más todas las comisiones. Estas monedas recién acuñadas no pueden gastarse durante 100 bloques, una regla que protege contra reorganizaciones de la cadena.

Cuanto más profundo vas, más encuentras.

Ejecuta tu Nodo LN en una Raspberry Pi

2025-02-17T00:00:00+00:00

En esta guía te muestro cómo configurar un nodo de Lightning Network (LN) con Alby Hub en una Raspberry Pi. Tendrás control total sobre tu nodo. Alby Hub ofrece una versión DIY gratuita para una wallet Lightning auto-custodiada: tus fondos son tuyos, y el código es 100% open-source.

Soporta direcciones Lightning y Nostr, conectando ambos ecosistemas sin problemas. Se integra con docenas de aplicaciones Bitcoin. Con los servicios LSP (Lightning Service Provider) integrados y la app Alby Go, gestionar tu nodo desde el móvil es muy fácil.

Importante: Esto NO es un minero de Bitcoin ni un nodo completo. Es simplemente una Raspberry Pi ejecutándose en una tarjeta SD eficiente en energía y de bajo coste.

⚠️ Aviso ⚠️

Asumo que entiendes los conceptos fundamentales de Bitcoin.
Asumo que sabes cómo funciona la Lightning Network (LN).

De todos modos, he incluido un breve repaso de los fundamentos de Lightning Network abajo.

¿Qué es la Lightning Network? #

La LN es una capa construida sobre Bitcoin que permite transacciones rápidas, baratas y escalables.

¿Por qué? La capa base de Bitcoin es segura pero lenta y cara para pagos pequeños, por los límites de bloque y las comisiones.
¿Cómo? LN usa canales de pago fuera de la cadena. Puedes enviar pagos al instante sin esperar confirmaciones en la blockchain.

Conceptos clave #

Canales de pago: Abres un canal con una transacción on-chain. Después puedes enviar pagos instantáneos e ilimitados dentro de ese canal.
Enrutamiento: No necesitas canal directo con todos. Los pagos se enrutan a través de múltiples nodos conectados.
Comisiones bajas: Solo abrir y cerrar canales requiere comisiones on-chain. El resto cuesta fracciones de céntimo.

Objetivo #

LN hace Bitcoin usable para el día a día. Puedes comprar un café sin esperar 10 minutos por confirmaciones.

En resumen: Lightning Network = Pagos Bitcoin instantáneos + baratos, asegurados por la blockchain de Bitcoin.

Configurando Alby Hub #

Alby Hub es un nodo de Lightning Network gratuito, open-source (idealmente privado).

Requisitos #

Antes de empezar, vas a necesitar las siguientes cosas:

Un ordenador con windows, mac o linux
Raspberry Pi 4 o 5 (Para Zero 2W mira este tutorial!)
- En este tutorial, estoy usando una raspi-4b (~60€)
El cargador para tu raspi (~10€)
Tarjeta de memoria SD (32/64gb) (~10€)
Adaptador de tarjeta SD a USB (para flashear el SO en la raspi) (~10€)

Pasos de instalación #

1. Flashear un kernel Linux en la tarjeta SD #

Sugerencia: Puedes usar RPI imager en tu ordenador. Úsalo para flashear el SO raspi recomendado para ti

En Storage verás tu tarjeta SD después de insertarla en tu portátil.

Una vez hagas clic en “Next”, verás diferentes ajustes. Haz clic en Edit Settings

En Settings > General: establece tu hostname, el nombre de usuario y contraseña para tu usuario admin. Asegúrate de habilitar tu WIFI, de lo contrario tendrás que conectarla al router con un RJ-45.

Para este tutorial, estoy usando testhub como hostname, puedes usar albyhub o lo que prefieras.

En Settings > Services: asegúrate de que el acceso vía SSH está habilitado. Lo vamos a necesitar para instalar Alby Hub.

Haz clic en “Save” y haz clic en “Yes” para iniciar la instalación.

Verás una confirmación. Haz clic en “Yes”. Tardará ~10 mins…

¡Ahora tenemos la SD con un kernel linux fresco listo para usar!

2. Insertar la SD en la raspi #

Extrae la SD del portátil e insértala en la raspi primero.

Una vez insertada la SD, conecta el cable de alimentación. Se encenderá automáticamente en cuanto la conectes.

3. Instalación de Alby Hub #

Tardará ~5mins desde que la encendiste para poder acceder a ella. ¿Cómo puedes asegurarte de que está viva? Abre la terminal y haz ping al hostname que definiste mientras flasheabas la SD en Settings > General, recuerda que terminaba con .local:

ping testhub.local

Es normal si no obtienes respuesta al principio… hasta que la obtienes.

Ahora puedes instalar Alby Hub en tu raspi usando la conexión SSH que habilitaste antes:

# Código fuente: https://github.com/getAlby/hub/tree/master/scripts/pi-aarch64
ssh testhub@testhub.local '/bin/bash -c "$(curl -fsSL https://getalby.com/install/hub/pi-aarch64-install.sh)"'

Se te pedirá que escribas la palabra “yes”; escríbela.

Luego, se te pedirá que introduzcas tu contraseña. Introduce la contraseña que elegiste en Settings > General para el nombre de usuario.

4. Configuración de Alby Hub #

Espera otros 2-3 mins y visita tu host: http://testhub.local/

Tu Alby hub ya está funcionando. ¡Vamos a conectarlo a tu cuenta GetAlby!

Crear una cuenta GetAlby #

🔗 getalby.com

Conectando GetAlby con Alby Hub #

Creé una cuenta llamada testhub.

Izquierda: la cuenta GetAlby. Derecha: el nodo en la raspi.

Haz clic en “Connect Now”.

Haz clic en “Request Authorization Code”.

Obtienes el código de autorización (izquierda) que necesitas insertar en tu configuración (derecha).

Crea una Contraseña para tu Alby Hub instalado en tu raspi. Puede ser diferente de la contraseña que configuraste para tu usuario root en la raspi misma.

Ahora es momento de Vincular tu Cuenta Alby

A menos que especifiques lo contrario, establece el “Budget renewal: Monthly 1M sats” por defecto.

Abriendo canales Lightning #

Recomiendo seguir los Pasos Iniciales para configurar tu Alby Hub.

Abramos el primer canal.

Necesitas pagar ~$20 en sats para abrir un canal de liquidez entrante de 1M sats.

Después del pago, verás el canal abierto. Puede tardar un par de minutos hasta que la transacción de financiación sea minada en el siguiente bloque.

Recibiendo Sats #

Puedes recibir sats usando tu Dirección LN.

Izquierda: Página pública vinculada a tu nodo. Derecha: Página privada de tu Alby Hub.

Opcional: Puedes añadir fondos ln a tu wallet usando los servicios de terceros de GetAlby: getalby.com/topup - ten en cuenta el KYC…

Usando tus Sats #

Después de eso, podrás usarlos a través de la Extensión Alby o AlbyGo.

Tu nodo es la fuente de verdad. Conecta estas apps y podrás usar tus sats en cualquier plataforma sin problemas.

Aviso: la dirección LN testhub fue creada solo para propósitos de testing y tutorial. Mi dirección real es chemaclass ;)

Mantenimiento y solución de problemas #

Actualizando tu nodo #

Como en la instalación, hay un script para actualizar tu nodo. Lo encuentras en el repositorio: GitHub - Script de actualización Alby Hub

ssh testhub@testhub.local '/bin/bash -c "$(curl -fsSL https://getalby.com/install/hub/pi-aarch64-update.sh)"'

Manejando cortes de energía #

Si se va la luz, la Raspberry Pi se apaga. Cuando vuelva, se reinicia sola. Alby Hub te pedirá la contraseña que configuraste antes.

Enlaces relacionados