From c50e12df09031c23e335783eb21b380e759ef0a4 Mon Sep 17 00:00:00 2001 From: ra5pvt1n Date: Mon, 25 May 2026 16:46:23 +0200 Subject: [PATCH] guias bitcoin --- es/bitcoin-01-principiantes.md | 1497 ++++++++++++++++++++++ es/bitcoin-02-intermedio.md | 1012 +++++++++++++++ es/bitcoin-03-tecnico.md | 2134 ++++++++++++++++++++++++++++++++ 3 files changed, 4643 insertions(+) create mode 100644 es/bitcoin-01-principiantes.md create mode 100644 es/bitcoin-02-intermedio.md create mode 100644 es/bitcoin-03-tecnico.md diff --git a/es/bitcoin-01-principiantes.md b/es/bitcoin-01-principiantes.md new file mode 100644 index 0000000..880fe58 --- /dev/null +++ b/es/bitcoin-01-principiantes.md @@ -0,0 +1,1497 @@ +# Bitcoin — Parte 1: Principiantes + +_Hecho desde la comunidad, para la comunidad hispanohablante_ +_Bitcoin Txoko_ + +--- + +## Prólogo + +Hay mucho ruido alrededor de Bitcoin. + +Precio, predicciones, el próximo halving, la próxima altcoin, el próximo escándalo. Una industria entera construida sobre la confusión — porque la confusión vende. + +Esta guía existe para hacer lo contrario. + +Alguien de la comunidad Bitcoin Txoko la escribió. No para vender nada. No para convencer a nadie de que compre. Para responder a una pregunta simple que mucha gente lleva años haciéndose: ¿cómo funciona esto realmente? + +Está hecha desde la comunidad para la comunidad hispanohablante. Porque el conocimiento técnico sobre Bitcoin en español escasea, y lo que existe suele oscilar entre lo superficial y lo especulativo. La comunidad hispanohablante merece algo mejor. + +--- + +### Qué encontrarás aquí + +Esta guía tiene tres partes que escalan en profundidad. + +**Parte 1 — Principiantes.** Empieza desde cero. Qué es Bitcoin, cómo funciona la blockchain, qué son las transacciones, la minería, las claves, las wallets y la seguridad. Si no sabes nada, empieza aquí. + +**Parte 2 — Intermedio.** Para quien ya entiende lo básico y quiere ir más lejos. Privacidad, Lightning Network, cómo conseguir bitcoin de forma soberana, autocustodia avanzada y la economía de Bitcoin. + +**Parte 3 — Técnico.** El protocolo por dentro. Estructura de transacciones y bloques, scripts, criptografía, minería técnica, SegWit, Taproot y la red P2P. Para quien quiere entender Bitcoin a nivel de código. + +Puedes leerla de principio a fin o consultar la parte que necesitas. Al final de cada cuadernillo encontrarás un glosario con los términos técnicos y una sección de preguntas frecuentes. + +--- + +### Qué no encontrarás aquí + +Predicciones de precio. Consejos de inversión. Promesas de libertad financiera. Entusiasmo vacío. + +Bitcoin no necesita que lo vendamos. Solo necesita que lo expliquemos bien. + +Tampoco encontrarás altcoins, NFTs, DeFi ni narrativas _crypto_. Esta guía es Bitcoin-only — no porque ignoremos que existen otras cosas, sino porque creemos que Bitcoin es cualitativamente diferente y que mezclar todo en el mismo cajón genera más confusión que claridad. + +--- + +### Sobre las fuentes + +El material técnico de referencia es [Learn Me A Bitcoin](https://learnmeabitcoin.com) de Greg Walker — el recurso técnico gratuito más riguroso sobre Bitcoin que existe en inglés. Si en algún momento quieres profundizar más allá de lo que encuentres aquí, visita su web. + +Esta guía no es una traducción. Es una reinterpretación — adaptada, reescrita y contextualizada para el público hispanohablante, con perspectiva editorial propia y conexión entre cada concepto técnico y sus implicaciones reales para quien quiere usar Bitcoin con soberanía. + +--- + +### Una nota honesta + +La autocustodia es poder real. También es responsabilidad real. No hay atención al cliente. No hay reversión de errores. No hay nadie a quien llamar. + +Ese es exactamente el punto. + +Bitcoin es la primera vez en la historia que una persona puede custodiar su propio dinero de forma completamente soberana, enviarlo a cualquier parte del mundo sin pedir permiso, y verificar de forma independiente que las reglas son las mismas para todos. + +Con ese poder viene una exigencia proporcional: entender lo que se tiene entre manos. + +Para eso existe esta guía. + +_Hecho desde la comunidad, para la comunidad._ + +--- + +## Índice + +``` + ▶ PARTE 1 — PRINCIPIANTES + ──────────────────────────────────────────────── + + 01 Cómo funciona Bitcoin .................. 7 + el problema del doble gasto · la solución + + 02 La blockchain ......................... 15 + el archivo compartido · por qué es segura + + 03 Los bloques ........................... 21 + qué hay dentro · el bloque génesis + + 04 Las transacciones ..................... 27 + inputs · outputs · UTXOs · fees + + 05 La minería ............................ 35 + el puzzle · la recompensa · el halving + + 06 La dificultad ......................... 43 + el ajuste automático · por qué 10 minutos + + 07 Las claves ............................ 49 + clave privada · clave pública · firmas + + 08 Las direcciones ....................... 57 + tipos · cuál usar · una por transacción + + 09 Los nodos ............................. 63 + qué hacen · por qué importan · corre el tuyo + + 10 Las wallets ........................... 69 + seed phrase · hardware · custodial vs no + + 11 Seguridad ............................. 77 + amenazas · setup básico · lo que nunca debes + + 12 Cómo enviar bitcoin ................... 85 + el proceso · fees · confirmaciones + + ──────────────────────────────────────────────── + Glosario .................................. 93 + Preguntas frecuentes ...................... 103 + Recursos .................................. 111 +``` + +--- + +## Capítulo 1 — Cómo funciona Bitcoin + +**Nivel: Principiante** + +--- + +### Qué es Bitcoin + +Bitcoin es un programa de ordenador. + +Puedes descargarlo y ejecutarlo en tu propio equipo. Cuando lo haces, tu ordenador se conecta a otros ordenadores que están corriendo el mismo programa en cualquier parte del mundo. Juntos forman una red. + +Esa red comparte un archivo. Un archivo que contiene el historial completo de todas las transacciones realizadas con bitcoin desde el principio. Ese archivo se llama la **blockchain**. + +``` +┌──────────┐ ┌──────────┐ ┌──────────┐ +│ Tu PC │◀──────▶│ Nodo B │◀──────▶│ Nodo C │ +│ (Bitcoin)│ │ │ │ │ +└──────────┘ └──────────┘ └──────────┘ + ▲ ▲ ▲ + │ │ │ + ▼ ▼ ▼ +┌──────────────────────────────────────────────────┐ +│ BLOCKCHAIN (copia idéntica) │ +└──────────────────────────────────────────────────┘ +``` + +--- + +### El problema que Bitcoin resuelve + +Para entender Bitcoin hay que entender primero el problema que resuelve. + +Imagina que quieres crear un sistema de pagos que funcione sin ningún punto central de control — sin bancos, sin intermediarios, sin ninguna entidad que apruebe las transacciones. + +En una red así puedes hacer trampa fácilmente. Podrías crear dos transacciones contradictorias que intentan gastar el mismo dinero al mismo tiempo, y enviarlas a distintas partes de la red simultáneamente. + +Esto se llama **doble gasto**. + +``` + ┌─────────────────┐ + │ 1 BTC │ + └────────┬────────┘ + │ + ┌───────────┴───────────┐ + ▼ ▼ + ┌─────────────┐ ┌─────────────┐ + │ → Alice │ │ → Bob │ + │ (válida?) │ │ (válida?) │ + └─────────────┘ └─────────────┘ + ✗ Solo una puede ser válida +``` + +En un sistema centralizado, el banco comprueba su base de datos y rechaza la segunda transacción. Pero sin banco, ¿quién decide cuál de las dos es válida? ¿Cómo se ponen de acuerdo miles de ordenadores independientes? + +Ese era el problema sin resolver antes de Bitcoin. Satoshi Nakamoto lo resolvió en 2008. + +> **El contexto importa.** En septiembre de 2008, Lehman Brothers quebró y desencadenó la mayor crisis financiera desde 1929. Los gobiernos de todo el mundo rescataron a los bancos con dinero público — billones de euros y dólares creados de la nada, socializando las pérdidas de quienes habían generado la crisis. Millones de personas perdieron sus empleos, sus casas y sus ahorros. Meses después, en enero de 2009, Satoshi lanzaba Bitcoin. No fue una coincidencia de fechas. Bitcoin es una respuesta directa a un sistema que había demostrado que no funcionaba para la mayoría de personas. + +--- + +### La solución: minería y bloques + +En lugar de escribir las transacciones inmediatamente, los ordenadores de la red primero las guardan en memoria — en lo que se llama la **mempool**. Cada diez minutos aproximadamente, un ordenador agrupa las transacciones que tiene en su mempool, forma un **bloque**, y lo añade al archivo compartido. + +Para poder añadir ese bloque, el ordenador tiene que resolver un problema matemático que requiere mucho trabajo computacional. A esto se le llama **minería**. + +``` + MEMPOOL BLOQUE BLOCKCHAIN +┌──────────┐ ┌──────────┐ ┌──────────┐ +│ tx_001 │ │ tx_001 │ │ Bloque N │ +│ tx_002 │──mina──▶│ tx_002 │──añade─▶│──────────│ +│ tx_003 │ │ tx_003 │ │ Bloque 1 │ +│ ... │ └──────────┘ │──────────│ +└──────────┘ cada ~10 min │ Bloque 0 │ + └──────────┘ +``` + +Ese trabajo tiene un coste real en energía. Lo que hace que manipular el sistema sea extremadamente caro. Si alguien quisiera reescribir el historial de transacciones, tendría que rehacer todo ese trabajo — y hacerlo más rápido que el resto de la red combinada. + +Si en la red circulan dos transacciones contradictorias, solo una puede entrar en el bloque que se mine. La otra queda descartada. El problema del doble gasto queda resuelto sin necesidad de confianza en ningún intermediario. + +--- + +### Cómo se poseen los bitcoins + +En Bitcoin no hay cuentas con nombres. Poseer bitcoins significa tener las **claves** que permiten moverlos. + +``` + Clave pública Clave privada + (compartir libremente) (guardar en secreto) + │ │ + ▼ ▼ + ┌─────────────┐ ┌─────────────┐ + │ [CANDADO] │◀──abrir────│ [LLAVE] │ + │ + BTC │ │ │ + └─────────────┘ └─────────────┘ + cualquiera puede solo tú puedes + enviar aquí gastar +``` + +Cuando haces una transacción, abres tu caja fuerte con tu clave privada y creas una nueva caja con el candado de quien va a recibir los bitcoins. Esa nueva caja queda registrada en la blockchain de forma permanente. + +Nadie puede abrirla salvo quien tenga la clave privada correcta. Ni el minero que procesó la transacción, ni ningún banco, ni ningún gobierno. + +--- + +### La blockchain como cadena de seguridad + +Los bloques no son simples contenedores de transacciones. Cada bloque contiene una huella digital del bloque anterior. Si alguien quisiera alterar una transacción pasada, tendría que recalcular ese bloque y todos los que vinieron después — más rápido que el resto de la red sigue añadiendo bloques nuevos. + +``` +┌──────────────────────────────────┐ +│ Bloque N-1 │ +│ transacciones + hash anterior │ +│ hash propio: 000a3f... │ +└────────────────┬─────────────────┘ + │ apunta a + ▼ +┌──────────────────────────────────┐ +│ Bloque N │ +│ transacciones + prev: 000a3f... │ +│ hash propio: 000b7c... │ +└────────────────┬─────────────────┘ + │ apunta a + ▼ +┌──────────────────────────────────┐ +│ Bloque N+1 │ +│ transacciones + prev: 000b7c... │ +│ hash propio: 000c1d... │ +└──────────────────────────────────┘ + modificar N → cambia su hash + → N+1 ya no encaja → N+2 ya no encaja +``` + +Cuanto más tiempo ha pasado desde que una transacción fue minada, más difícil e inviable resulta alterarla. + +--- + +### Verifica tú mismo + +Entra en [mempool.space](https://mempool.space) y busca el bloque número **0** — el bloque génesis. Es el primero que minó Satoshi Nakamoto el 3 de enero de 2009. + +Entra en la coinbase transaction de ese bloque — la primera y única transacción que contiene. En el campo de datos verás el mensaje que Satoshi dejó grabado para siempre en la blockchain: + +> _The Times 03/Jan/2009 Chancellor on brink of second bailout for banks_ + +Ese mensaje lleva ahí desde el primer día. Nadie puede borrarlo. Nadie puede modificarlo. Está en miles de copias de la blockchain distribuidas por todo el mundo. + +Eso es Bitcoin en una sola imagen. + +--- + +### Resumen + +Bitcoin es un programa que permite enviar y recibir valor de forma directa, sin intermediarios, a cualquier parte del mundo. + +Funciona porque resuelve un problema técnico muy concreto — el doble gasto — sin necesidad de confiar en ninguna entidad central. Lo resuelve con matemáticas, energía y reglas que cualquiera puede verificar. + +Eso tiene una consecuencia práctica inmediata: nadie puede impedirte usar Bitcoin. Nadie puede congelar tu cuenta porque no tienes cuenta. Nadie puede confiscar tus bitcoins si custodias bien tus claves. Nadie puede decidir a quién puedes o no puedes enviarle dinero. + +Es la primera vez en la historia que eso es posible con dinero digital. + +> Hasta aquí la visión general. Sabemos que Bitcoin es una red que comparte un archivo, que ese archivo se protege con trabajo computacional, y que las claves son lo que da acceso al bitcoin. Pero cada una de esas piezas merece una explicación propia. Empezamos por el archivo: qué es exactamente la blockchain y por qué su estructura la hace prácticamente imposible de falsificar. + +--- + +## Capítulo 2 — La blockchain + +**Nivel: Principiante** + +--- + +### Un archivo compartido por miles de ordenadores + +En el capítulo anterior vimos que Bitcoin es un programa que comparte un archivo entre miles de ordenadores de todo el mundo. Ese archivo es la blockchain. + +La blockchain es el registro permanente de todas las transacciones que se han hecho con bitcoin desde el primer día. Cada vez que alguien envía bitcoin a alguien, esa transacción acaba en este archivo. Para siempre. + +No está guardada en un servidor de una empresa. No hay una copia maestra en ningún banco ni en ningún Estado. Está replicada simultáneamente en miles de ordenadores de personas que han decidido ejecutar el programa de Bitcoin. + +``` + [Madrid] [Berlin] [Tokyo] + ┌──────────┐ ┌──────────┐ ┌──────────┐ + │ Nodo A │ │ Nodo B │ │ Nodo C │ + │ ████████ │ │ ████████ │ │ ████████ │ + │ ████████ │ │ ████████ │ │ ████████ │ + └──────────┘ └──────────┘ └──────────┘ + copia idéntica copia idéntica copia idéntica + sin servidor central +``` + +--- + +### Por qué se llama blockchain + +El nombre describe exactamente su estructura. + +Las transacciones no se añaden una a una al archivo. Se agrupan en **bloques**. Y esos bloques se encadenan unos con otros en orden cronológico, formando una **cadena** — una _blockchain_. + +Cada bloque contiene un grupo de transacciones y una referencia al bloque anterior. Esa referencia es una huella digital — un **hash** — que resume todo el contenido del bloque precedente. + +--- + +### Por qué esa estructura lo hace seguro + +La cadena de hashes no es solo un detalle técnico. Es el mecanismo de seguridad central de la blockchain. + +Imagina que alguien quisiera modificar una transacción antigua — cambiar el destinatario, alterar la cantidad. Para hacerlo tendría que modificar el bloque que la contiene. Pero al modificar ese bloque, su huella digital cambia. Y como el siguiente bloque contiene esa huella, ahora ya no encaja. Ese bloque queda invalidado. Y el siguiente. Y todos los que vinieron después. + +``` +┌──────────────────────────────────┐ +│ Bloque N-1 │ +│ transacciones + hash anterior │ +│ hash propio: 000a3f... │ +└────────────────┬─────────────────┘ + │ apunta a + ▼ +┌──────────────────────────────────┐ +│ Bloque N ← MODIFICADO │ +│ hash propio: cambia a fff9b2... │ +└────────────────┬─────────────────┘ + │ ya no encaja + ▼ +┌──────────────────────────────────┐ +│ Bloque N+1 ← INVALIDADO │ +│ prev: 000b7c... ← no coincide │ +└──────────────────────────────────┘ + cambiar cualquier bloque rompe todos los siguientes +``` + +Para reescribir la historia habría que reconstruir todos los bloques desde el punto alterado hasta el presente — y hacerlo más rápido que el resto de la red sigue construyendo encima. Con más de diez mil nodos minando activamente, eso no es solo difícil. Es económicamente absurdo. + +--- + +### La cadena más larga gana + +¿Qué pasa si dos ordenadores minan un bloque válido casi al mismo tiempo y la red se divide momentáneamente? + +``` + ┌─── Bloque A ───┐ +Bloque N ─────┤ ├─── Bloque A2 ◀── cadena más larga + └─── Bloque B ───┘ ✗ Bloque B descartado + + todos los nodos convergen hacia la cadena más larga +``` + +Los nodos adoptan siempre la cadena con más trabajo acumulado. Cuando se mina el siguiente bloque, una de las dos cadenas pasa a ser más larga, y todos los nodos convergen hacia ella. La cadena más corta queda descartada. + +Nadie decide cuál es la cadena válida. Lo decide el trabajo computacional. Sin necesidad de confiar en ningún coordinador central. + +--- + +### Un registro público y verificable + +Cualquier persona puede descargar la blockchain completa y verificar cada transacción que se ha hecho desde el bloque génesis — el primer bloque, minado por Satoshi Nakamoto el 3 de enero de 2009. + +No hace falta pedir permiso. No hay que identificarse. No depende de que ninguna empresa esté operativa. + +--- + +### Resumen + +La blockchain es un registro permanente de transacciones, estructurado en bloques encadenados mediante hashes criptográficos. Su diseño hace que alterar el pasado sea computacionalmente inviable. Miles de nodos independientes mantienen copias idénticas sin necesidad de coordinación central. + +Eso significa que no hay ningún punto que censurar, ningún servidor que atacar, ninguna empresa que presionar. El historial de transacciones de Bitcoin no depende de ninguna organización — está distribuido entre miles de nodos en todo el mundo, y seguirá ahí mientras haya personas que decidan mantenerlo. + +> Ahora sabemos qué es la blockchain y por qué es segura. Pero hasta ahora hemos hablado de "bloques" como si fueran cajas opacas. En el siguiente capítulo abrimos una de esas cajas: qué hay dentro de un bloque, cómo está estructurado, y qué es ese mensaje que Satoshi dejó escrito en el primero de todos. + +--- + +## Capítulo 3 — Los bloques + +**Nivel: Principiante** + +--- + +### Qué es un bloque + +Un bloque es un contenedor de transacciones. + +Cada cierto tiempo — aproximadamente cada diez minutos — las transacciones que están esperando en la mempool se agrupan en un bloque y se añaden a la blockchain. Ese bloque pasa a ser permanente. + +Puedes pensar en la blockchain como en un libro de contabilidad donde cada página es un bloque. Cada página tiene un número, un contenido, y una referencia a la página anterior. Las páginas no se pueden arrancar ni reescribir sin que se note. + +--- + +### Qué contiene un bloque + +Todo bloque tiene dos partes bien diferenciadas. + +La primera es la **cabecera** — un resumen compacto del bloque. La segunda son las **transacciones** — el contenido real, los movimientos de bitcoin que quedan registrados. + +``` +┌─────────────────────────────────────┐ +│ CABECERA (80 bytes) │ +│ hash del bloque anterior │ +│ merkle root (huella de las txs) │ +│ timestamp │ +│ bits (target) │ +│ nonce │ +├─────────────────────────────────────┤ +│ TRANSACCIONES │ +│ coinbase tx (recompensa del minero) │ +│ tx_001 │ +│ tx_002 │ +│ ... │ +└─────────────────────────────────────┘ +``` + +--- + +### La cabecera como resumen sellado + +La cabecera resume todo el contenido del bloque en un pequeño conjunto de datos. Si cualquier transacción dentro del bloque se modifica, el merkle root cambia. Si el merkle root cambia, el hash del bloque cambia. Si el hash cambia, el bloque ya no encaja en la cadena. + +--- + +### El bloque génesis + +El primer bloque de la historia de Bitcoin se llama el **bloque génesis**. Lo minó Satoshi Nakamoto el 3 de enero de 2009. + +``` +┌─────────────────────────────────────────────────────┐ +│ BLOQUE 0 — 03 enero 2009 │ +│─────────────────────────────────────────────────────│ +│ coinbase tx: │ +│ "The Times 03/Jan/2009 Chancellor on brink of │ +│ second bailout for banks" │ +│─────────────────────────────────────────────────────│ +│ grabado para siempre · verificable ahora mismo │ +└─────────────────────────────────────────────────────┘ +``` + +Era el titular del periódico británico The Times ese día. Satoshi lo eligió como marca de tiempo — prueba de que el bloque no podía haber sido minado antes de esa fecha — pero también como declaración de intenciones. Bitcoin nació el mismo día en que los gobiernos volvían a rescatar con dinero público a los bancos que habían provocado la crisis. No fue una coincidencia. + +--- + +### Límite de tamaño y selección de transacciones + +Un bloque no puede contener transacciones ilimitadas. Tiene un tamaño máximo. + +Cuando hay más transacciones esperando de las que caben en un bloque, los mineros eligen las que pagan más **fee** — la comisión que el remitente ofrece por procesar su transacción. + +Cuando la red está congestionada, las fees suben. Cuando está tranquila, bajan. Es un mercado libre entre usuarios que quieren que sus transacciones sean procesadas y mineros que deciden qué incluir en cada bloque. + +> Este es uno de los trade-offs reales de Bitcoin: la capacidad de cada bloque es finita. A más uso de la red, más competencia por el espacio en bloque, y más caras las transacciones. + +--- + +### Resumen + +Un bloque es un contenedor de transacciones con una cabecera que lo conecta criptográficamente al bloque anterior. Cada bloque es inmutable desde el momento en que es minado. La selección de transacciones que entran en cada bloque la hacen los mineros, guiados por las fees que ofrecen los usuarios. + +Nadie decide qué transacciones merecen ser incluidas según criterios políticos, identidad del remitente, o destino del dinero. Solo importa la fee. Eso hace que Bitcoin sea resistente a la censura: cualquier transacción válida que pague suficiente fee acabará siendo procesada. + +> Ya entendemos la estructura de un bloque. Pero hasta ahora hemos hablado de "transacciones" como si fueran transferencias simples — como mover dinero de una cuenta a otra. No lo son. El modelo que usa Bitcoin es más extraño, más elegante, y tiene consecuencias que no son obvias a primera vista. Eso es lo que veremos a continuación. + +--- + +## Capítulo 4 — Las transacciones + +**Nivel: Principiante** + +--- + +### Cómo se mueve el bitcoin + +Cuando alguien dice "voy a enviar bitcoin", la imagen mental que tenemos es la de monedas moviéndose de un monedero a otro. Es una analogía útil para empezar, pero no es lo que ocurre realmente. + +En Bitcoin no hay monedas que se desplazan. Lo que existe son **outputs** — porciones de bitcoin bloqueadas a una dirección concreta. Cuando "envías" bitcoin, lo que haces es consumir uno o varios outputs que te pertenecen y crear outputs nuevos bloqueados a la dirección del destinatario. + +Es más parecido a billetes que a monedas digitales. No partes un billete — lo gastas entero y recibes cambio. + +``` + INPUT OUTPUTS +┌───────────┐ ┌───────────────┐ +│ 1.00 BTC │ │ 0.80 BTC │ +│ (UTXO) │──── transacción ──▶│ → destinat. │ +└───────────┘ ├───────────────┤ + │ 0.19 BTC │ + │ → cambio │ + ├───────────────┤ + │ 0.01 BTC │ + │ → fee │ + └───────────────┘ +``` + +--- + +### Inputs y outputs + +Toda transacción de Bitcoin tiene dos partes. + +Los **inputs** son los outputs anteriores que estás consumiendo. Para gastarlos necesitas demostrar que te pertenecen — esto se hace con tu clave privada. + +Los **outputs** son los nuevos paquetes de bitcoin que estás creando. Cada output queda bloqueado a una dirección. Solo quien tenga la clave privada de esa dirección podrá gastarlo en el futuro. + +``` +┌──────────┐ +│ 0.3 BTC │──┐ +└──────────┘ │ ┌──────────────┐ + ├── transacción ─▶ 1.0 BTC │ +┌──────────┐ │ │ → destino │ +│ 0.5 BTC │──┤ └──────────────┘ +└──────────┘ │ + │ +┌──────────┐ │ +│ 0.2 BTC │──┘ +└──────────┘ + fee implícita = inputs - outputs +``` + +--- + +### El cambio + +En Bitcoin no puedes gastar "solo una parte" de un output. Tienes que gastarlo entero. Si el output vale 1 BTC y quieres enviar 0,3 BTC, la transacción consume el output completo de 1 BTC y crea dos outputs nuevos: uno de 0,3 BTC para el destinatario y otro de ~0,69 BTC que vuelve a tu propia dirección como cambio. + +> La fee no es un output explícito. Es simplemente la diferencia entre lo que entra y lo que sale. Si los inputs suman 1 BTC y los outputs suman 0,99 BTC, los 0,01 BTC restantes son la fee que se lleva el minero. + +--- + +### El satoshi: la unidad mínima + +Bitcoin es divisible hasta ocho decimales. La unidad mínima se llama **satoshi** — en honor a Satoshi Nakamoto. + +``` +1 BTC = 100.000.000 satoshis +0,001 BTC = 100.000 satoshis +1 satoshi = 0,00000001 BTC +``` + +--- + +### UTXOs — los bitcoins que aún no has gastado + +Cada output que existe en la blockchain está en uno de dos estados: gastado o no gastado. + +Un **UTXO** — _Unspent Transaction Output_ — es simplemente un output que todavía no ha sido usado como input en ninguna transacción. Es bitcoin disponible para gastar. + +``` + Wallet de Alice + ┌─────────────────────────────────┐ + │ UTXO_1: 0.50 BTC [bc1q...a] │ + │ UTXO_2: 0.30 BTC [bc1q...b] │ + │ UTXO_3: 0.20 BTC [bc1q...c] │ + │ ─────────── │ + │ SALDO TOTAL: 1.00 BTC │ + └─────────────────────────────────┘ + no hay saldo guardado — hay outputs sin gastar +``` + +--- + +### Una transacción histórica + +El 22 de mayo de 2010, un programador llamado Laszlo Hanyecz publicó en un foro un mensaje ofreciendo 10.000 BTC a quien le pidiera dos pizzas. Alguien aceptó. + +Fue la primera compra conocida de un bien físico con bitcoin. El 22 de mayo se celebra cada año como el **Bitcoin Pizza Day** — el día en que bitcoin pasó de ser teoría a ser dinero que compra cosas reales. + +Puedes buscar esa transacción hoy mismo en cualquier explorador de bloques. Sigue ahí, permanente e inmutable, como todas las demás. + +--- + +### Verifica tú mismo + +Entra en [mempool.space](https://mempool.space) y busca cualquier transacción reciente. Verás exactamente lo que acabamos de describir: inputs a la izquierda con sus valores, outputs a la derecha con sus direcciones de destino. + +``` + TXID: a3f8c21b9e004d17f65c8b12... + + INPUTS OUTPUTS + ┌────────────────────┐ ┌────────────────────┐ + │ bc1q...a 1.00 BTC │─────▶│ bc1q...b 0.80 BTC │ + └────────────────────┘ ├────────────────────┤ + │ bc1q...c 0.19 BTC │ + └────────────────────┘ + Bloque: 850.421 │ Fee: 0.01 BTC + Confirmaciones: 6 +``` + +--- + +### Resumen + +Una transacción consume outputs existentes (inputs) y crea outputs nuevos. Los outputs no gastados — UTXOs — son el bitcoin disponible. La fee es la diferencia entre lo que entra y lo que sale. + +Este modelo tiene una consecuencia importante para la privacidad: toda la historia de cada bitcoin es pública y trazable. Cualquier persona puede seguir la cadena de transacciones desde el primer día. Eso es una limitación real que conviene entender desde el principio, y que abordaremos en profundidad más adelante. + +> Las transacciones existen. Pero ¿cómo entran en la blockchain? ¿Quién decide cuándo y en qué orden se confirman? Aquí es donde entra la minería — el proceso que añade bloques, crea bitcoin nuevo y hace que atacar la red sea prohibitivamente caro. + +--- + +## Capítulo 5 — La minería + +**Nivel: Principiante** + +--- + +### Qué es minar + +Minar es el proceso por el que los nuevos bloques se añaden a la blockchain. + +Las transacciones esperan en la mempool antes de ser confirmadas. Los mineros son los nodos que recogen esas transacciones, las agrupan en un bloque candidato, y compiten para ser los primeros en añadirlo a la cadena. + +Para añadir un bloque, el minero tiene que resolver un puzzle matemático que requiere trabajo computacional real. Energía real. Hardware real. + +Eso no es un defecto de diseño. Es exactamente el punto. + +--- + +### El puzzle: encontrar un hash válido + +Una **función hash** toma cualquier dato como entrada y produce una cadena de caracteres de longitud fija como salida. Esa salida es completamente impredecible — un pequeño cambio en la entrada produce una salida totalmente diferente. + +Bitcoin usa una función hash llamada SHA-256. Para minar un bloque, el minero tiene que hacer hash de la cabecera de su bloque candidato y conseguir que el resultado sea un número menor que un **objetivo** — el _target_. + +Un resultado válido se reconoce fácilmente: empieza con muchos ceros. + +``` +000000000000000000029a3b2c4d... ← hash válido +a3f8c21b9e004d17f65c... ← hash inválido +``` + +No hay forma de calcular qué entrada produce ese resultado. Solo hay una manera: probar. Una y otra vez. Millones de veces por segundo. Para variar el resultado en cada intento sin cambiar las transacciones, el minero modifica un campo en la cabecera llamado **nonce**. + +``` + MEMPOOL BLOQUE CANDIDATO PUZZLE +┌──────────┐ ┌──────────────────┐ +│ tx_001 │ │ cabecera │ hash(cabecera + nonce) +│ tx_002 │─────▶│ tx_001, tx_002.. │───▶ = 000000000000a3f... +│ tx_003 │ │ nonce: 0 │ ▲ +│ ... │ └──────────────────┘ │ +└──────────┘ incrementar nonce ¿menor que el target? + hasta encontrar │ + hash válido SÍ → bloque válido +``` + +--- + +### Por qué esto funciona como mecanismo de seguridad + +El trabajo computacional tiene un coste real e irreversible. No se puede falsificar. Si alguien quiere reescribir la historia de la blockchain, tiene que rehacer todo ese trabajo — y hacerlo más rápido que la red entera sigue construyendo hacia adelante. + +Esto es lo que Satoshi llamó **prueba de trabajo**: no confíes en que alguien hizo el trabajo, verifica el hash. Si el hash es válido, la prueba está ahí. + +--- + +### La recompensa: de dónde viene el bitcoin nuevo + +Cuando un minero encuentra un bloque válido, puede incluir en ese bloque una transacción especial llamada **coinbase transaction**. + +``` +┌─────────────────────────────────────┐ +│ COINBASE TRANSACTION │ +│─────────────────────────────────────│ +│ INPUT: ninguno (bitcoin nuevo) │ +│ OUTPUT: 3.125 BTC → minero │ +│ + fees de todas las txs │ +│─────────────────────────────────────│ +│ siempre la primera tx del bloque │ +└─────────────────────────────────────┘ +``` + +Así es como se crea bitcoin nuevo. No hay ninguna entidad central que lo emita. Aparece como recompensa por el trabajo de asegurar la red, según unas reglas fijas escritas en el código. + +--- + +### El halving: la emisión que se reduce a la mitad + +El subsidio de bloque no es fijo para siempre. Cada 210.000 bloques — aproximadamente cada cuatro años — se reduce a la mitad. A esto se le llama **halving**. + +``` + 2009 ████████████████ 50 BTC/bloque + 2012 ████████ 25 BTC/bloque + 2016 ████ 12,5 BTC/bloque + 2020 ██ 6,25 BTC/bloque + 2024 █ 3,125 BTC/bloque + 2028 ▌ 1,5625 BTC/bloque + ···· + 2140 · 0 BTC/bloque + solo fees +``` + +Este proceso continuará hasta aproximadamente el año 2140, cuando el último satoshi sea minado. A partir de ahí, los mineros solo cobrarán fees. + +El límite total de bitcoin que existirá jamás es de **21 millones**. Está fijado en el código. Nadie puede cambiarlo sin que toda la red rechace el cambio. + +--- + +### La minería en la práctica: pools + +En los primeros años de Bitcoin, un minero individual podía encontrar bloques con un ordenador doméstico. Hoy el hashrate de la red es tan alto que las probabilidades de que un minero solo encuentre un bloque son ínfimas. + +Por eso la mayoría de mineros trabajan en **pools de minería** — grupos que combinan su poder computacional y reparten la recompensa proporcionalmente al trabajo aportado. + +--- + +### El debate sobre la energía + +Bitcoin consume energía. Es una crítica habitual y merece una respuesta honesta. + +Sí, la prueba de trabajo requiere gasto energético real. Ese gasto es lo que hace que atacar la red sea caro. No se puede eliminar sin eliminar también la seguridad que proporciona. + +La pregunta relevante no es si Bitcoin consume energía, sino si ese consumo está justificado y cómo se produce. La comparativa relevante no es con el consumo de un teléfono móvil sino con el sistema financiero global que Bitcoin propone complementar — bancos, cajeros, centros de datos, transporte de efectivo. + +--- + +### Verifica tú mismo + +En [mempool.space](https://mempool.space) puedes ver en tiempo real la actividad de la red. Si buscas cualquier bloque y entras a ver sus transacciones, la primera de todas es siempre la coinbase transaction — la recompensa del minero. No tiene inputs, solo outputs. El bitcoin sale de la nada, respaldado por el trabajo computacional del bloque. + +--- + +### Resumen + +La minería es el proceso que añade bloques a la blockchain, crea bitcoin nuevo y hace que atacar la red sea extremadamente costoso. Los mineros compiten resolviendo un puzzle computacional y el primero que lo consigue añade su bloque y cobra la recompensa. + +La emisión de bitcoin es predecible, decreciente y limitada. No depende de ningún banco central ni de ninguna decisión política. Está escrita en el código y cualquiera puede verificarla. + +> Los mineros compiten para añadir bloques. Pero si el hashrate de la red sube o baja, los bloques llegarían más rápido o más lento de lo esperado. ¿Cómo mantiene Bitcoin un ritmo constante de un bloque cada diez minutos sin que nadie lo controle? La respuesta es el ajuste de dificultad — uno de los mecanismos más elegantes del protocolo. + +--- + +## Capítulo 6 — La dificultad + +**Nivel: Principiante** + +--- + +### El problema del reloj + +El poder computacional de la red no es constante. Crece cuando se incorporan más mineros, cae cuando algunos se marchan. Sin un mecanismo de corrección, el ritmo de producción de bloques sería impredecible — y con él, la emisión de bitcoin nuevo. + +La solución es el **ajuste de dificultad**. + +--- + +### Cómo funciona el ajuste + +Cada 2.016 bloques — aproximadamente cada dos semanas — la red mide cuánto tiempo tardaron en minarse esos bloques y compara ese tiempo con el objetivo: 20.160 minutos. + +``` + 2.016 bloques tiempo real ajuste + ┌─────────────┐ + │ █ █ █ █ █ │──── 12 días ────▶ target BAJA (más difícil) + │ █ █ █ █ █ │──── 14 días ────▶ target sin cambio + │ █ █ █ █ █ │──── 16 días ────▶ target SUBE (más fácil) + └─────────────┘ + objetivo: un bloque cada 10 minutos +``` + +Si los bloques llegaron más rápido de lo esperado, el target baja — se vuelve más difícil encontrar un hash válido. Si llegaron más lento, el target sube — se vuelve más fácil. + +--- + +### Por qué diez minutos + +Diez minutos es un equilibrio deliberado. Demasiado rápido y los bloques no tienen tiempo de propagarse por la red antes de que se mine el siguiente. Demasiado lento y las transacciones tardan demasiado en confirmarse. + +--- + +### Nadie controla el ajuste + +El ajuste de dificultad es automático. No lo decide ninguna empresa, ningún desarrollador, ningún minero. Cada nodo calcula independientemente cuál debe ser el nuevo target y lo aplica. + +``` + DIFICULTAD ALTA DIFICULTAD BAJA + target muy bajo target más alto + + hash válido: hash válido: + 000000000000a3f... 00000a3f... + (muchos ceros) (pocos ceros) + + más intentos necesarios menos intentos necesarios +``` + +> Si mañana la mitad de los mineros del mundo apagasen sus máquinas, los siguientes 2.016 bloques llegarían más lento de lo normal. Pero entonces el target subiría, la dificultad bajaría, y el ritmo volvería a los diez minutos. Bitcoin se adapta solo. + +--- + +### Verifica tú mismo + +En [mempool.space](https://mempool.space) puedes ver cuándo será el próximo ajuste de dificultad, cuántos bloques faltan, y si se espera que suba o baje. + +--- + +### Resumen + +El ajuste de dificultad mantiene el ritmo de producción de bloques estable en torno a diez minutos, independientemente de cuántos mineros estén activos. Se recalcula automáticamente cada 2.016 bloques. Nadie lo controla — todos los nodos aplican las mismas reglas. + +Ese ritmo constante hace que la emisión de bitcoin sea predecible. No hay sorpresas, no hay decisiones discrecionales. Cualquiera puede calcular cuánto bitcoin existirá en cualquier momento futuro. + +> Sabemos cómo se añaden bloques y cómo se mantiene el ritmo. Pero todavía no hemos explicado algo fundamental: cómo sabe Bitcoin que el bitcoin es tuyo. Cómo puedes demostrar que tienes derecho a gastarlo sin revelar ningún secreto a nadie. Eso es la criptografía de clave pública — y es la pieza que hace posible todo lo demás. + +--- + +## Capítulo 7 — Las claves + +**Nivel: Principiante** + +--- + +### De quién es el bitcoin + +En Bitcoin no hay cuentas. No hay nombre de usuario ni contraseña. No hay ninguna entidad que te registre ni que pueda bloquearte el acceso. + +Lo que hay son **claves**. Quien tiene las claves, tiene el bitcoin. Sin excepciones. + +> **El linaje de Bitcoin.** Mucho antes de que existiera Bitcoin, un grupo de matemáticos, programadores y activistas conocidos como los _cypherpunks_ llevaban años trabajando en herramientas para proteger la privacidad individual frente a gobiernos y corporaciones. En 1993, Eric Hughes escribió en su _Manifiesto Cypherpunk_: _"La privacidad es necesaria para una sociedad abierta en la era electrónica."_ Bitcoin es el heredero directo de esa tradición. Las claves criptográficas no son solo una solución técnica — son la materialización de la idea de que una persona puede tener soberanía real sobre su dinero sin pedirle permiso a nadie. + +--- + +### La clave privada + +Una clave privada es un número aleatorio muy grande. + +Concretamente, un número de 256 bits — tan grande que la probabilidad de que dos personas generen el mismo es prácticamente cero. Hay más claves privadas posibles que átomos en el universo observable. + +``` +Ejemplo de clave privada en hexadecimal: +ea77035f1b1d961f1ad4e4f5de37bc6a928ab03c897ced82d95efdf804d1bde8 +``` + +> La clave privada es lo único que da acceso a tus bitcoins. Si la pierdes, pierdes el acceso. Si alguien la obtiene, puede gastarte los bitcoins. No hay servicio de recuperación. No hay atención al cliente. + +--- + +### La clave pública + +A partir de la clave privada se calcula matemáticamente una **clave pública**. + +``` + CLAVE PRIVADA CLAVE PÚBLICA + (número aleatorio) (punto en la curva) + + ef235aac... ──────────▶ 02b4632d... + + función + matemática + de un solo + sentido + + ◀──────────── IMPOSIBLE ──────────────── +``` + +La relación entre ambas es de un solo sentido: con la clave privada puedes calcular la clave pública, pero con la clave pública es computacionalmente imposible recuperar la clave privada. + +--- + +### La dirección + +En la práctica, no compartes directamente tu clave pública. Se transforma en algo más compacto: una **dirección**. + +``` +Ejemplo de dirección: +bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq +``` + +--- + +### Las firmas digitales + +Cuando quieres gastar bitcoin, necesitas demostrar que eres el propietario del output que estás consumiendo. + +``` + 1. genera clave privada → solo tú + 2. calcula clave pública → puedes compartir + 3. deriva dirección → compartes para recibir + 4. recibes bitcoin → bloqueado a tu dirección + 5. firmas transacción → con tu clave privada + 6. la red verifica firma → con tu clave pública + sin revelar la privada +``` + +--- + +### Resumen + +Las claves son la base de la soberanía en Bitcoin. Tu clave privada es tu identidad y tu acceso — no hay nada más. No depende de ninguna empresa, ningún servidor, ninguna cuenta. Si tienes tu clave privada, tienes tus bitcoins. Si no la tienes, no los tienes. + +> Tienes una clave privada y una clave pública. Pero en la práctica nunca compartes tu clave pública directamente — la conviertes en algo más compacto y seguro: una dirección. En el siguiente capítulo vemos qué tipos de dirección existen, en qué se diferencian, y cuál deberías usar. + +--- + +## Capítulo 8 — Las direcciones + +**Nivel: Principiante** + +--- + +### Qué es una dirección + +Una dirección Bitcoin es lo que compartes cuando quieres recibir bitcoin. + +Técnicamente es una representación compacta de un script de bloqueo. En la práctica es simplemente un identificador que le das a quien te va a enviar bitcoin. Incluye un checksum que detecta errores tipográficos. + +--- + +### Los tipos de dirección + +``` + 1... Legacy P2PKH desde 2009 fees más altas + 3... Script P2SH desde 2012 multisig y más + bc1q... SegWit P2WPKH desde 2017 fees reducidas + bc1p... Taproot P2TR desde 2021 máxima privacidad +``` + +--- + +### Por qué importa el tipo + +Para recibir bitcoin, cualquier tipo válido funciona. Donde el tipo importa es al gastar. + +El primer factor son las **fees**: las transacciones legacy ocupan más espacio en el bloque y por tanto pagan más. Las direcciones `bc1q` (SegWit) y `bc1p` (Taproot) son más eficientes. + +El segundo factor es la **privacidad**. Taproot tiene una ventaja importante: cuando se usa correctamente, una transacción simple y una transacción con condiciones complejas —como un multisig— son indistinguibles desde fuera. Cualquier observador externo ve lo mismo. Con los tipos anteriores, el tipo de transacción queda visible en la blockchain para siempre. + +La recomendación es sencilla: usa una wallet moderna que genere direcciones `bc1q` o `bc1p`. Ambas son buenas opciones — `bc1p` añade ventajas de privacidad si tu wallet lo soporta bien, pero `bc1q` es perfectamente válida y sigue siendo la más extendida. + +--- + +### Una dirección, un uso + +Una práctica fundamental es no reutilizar direcciones. Puede parecer un detalle menor — al fin y al cabo, la dirección funciona igual la segunda vez. Pero las consecuencias para la privacidad son importantes. + +Cuando reutilizas una dirección, cualquier persona puede abrir un explorador de bloques y ver en segundos todos los pagos que has recibido en ella, todos los pagos que has enviado desde ella, y el saldo actual. No necesita saber quién eres — solo necesita conocer una de tus direcciones. A partir de ahí, tiene un hilo del que tirar. + +``` +Dirección reutilizada: bc1q...xyz +├── recibido: 0.05 BTC (tx_001) +├── recibido: 0.12 BTC (tx_002) +├── enviado: 0.10 BTC (tx_003) → ¿a quién? +└── saldo actual visible para cualquiera +``` + +Las wallets modernas generan automáticamente una dirección nueva para cada pago. No hay coste en ello, y es uno de los pasos más simples para mejorar tu privacidad sin ningún esfuerzo adicional. + +--- + +### Resumen + +Una dirección es el formato que usas para recibir bitcoin. Hay varios tipos con distintas características en cuanto a fees y privacidad. Los formatos modernos que empiezan por `bc1` son los recomendados. Usa siempre una dirección nueva para cada pago. + +> Tienes claves. Tienes direcciones. Sabes cómo se mueve el bitcoin y dónde queda registrado. Pero todo eso existe porque hay miles de ordenadores en todo el mundo que en este momento están verificando, propagando y almacenando esa información — sin que nadie se lo pida, sin que nadie los coordine. Esos ordenadores son los nodos. Y entender qué hacen es entender dónde reside realmente el poder en Bitcoin. + +--- + +## Capítulo 9 — Los nodos + +**Nivel: Principiante** + +--- + +### Qué es un nodo + +Un nodo es un ordenador que ejecuta el programa de Bitcoin y está conectado a otros ordenadores que hacen lo mismo. + +La red de Bitcoin es exactamente eso: miles de nodos distribuidos por todo el mundo, sin jerarquía, sin centro, todos iguales entre sí. + +``` + [Nodo A] + │ + ───────┼─────── + │ │ │ +[Nodo B] [Nodo C] [Nodo D] + │ │ +[Nodo E] [Nodo F] + + todos iguales · sin servidor central + cada nodo verifica las reglas de forma independiente +``` + +--- + +### Qué hace un nodo + +Un nodo tiene tres trabajos fundamentales. + +**Primero, seguir las reglas.** Cada nodo tiene programadas las reglas de consenso de Bitcoin. Cuando recibe una transacción o un bloque, lo verifica. Si no cumple las reglas, lo rechaza y no lo propaga. + +**Segundo, compartir información.** Cuando un nodo recibe una transacción válida, la reenvía a los nodos con los que está conectado. En cuestión de segundos, la transacción ha llegado a toda la red. + +**Tercero, mantener una copia de la blockchain.** Cada nodo guarda en su disco el historial completo de todas las transacciones confirmadas desde el bloque génesis. + +``` + recibe tx ──▶ verifica ──▶ ¿válida? + │ + SÍ ─────────┴──────── NO + │ │ + añade a descarta + mempool no propaga + │ + propaga a + sus vecinos +``` + +--- + +### Por qué los nodos son el corazón de Bitcoin + +Los mineros añaden bloques. Los nodos deciden si los aceptan. + +> En Bitcoin, el poder no lo tienen los mineros ni los desarrolladores. Lo tienen los nodos. Son ellos los que en última instancia hacen cumplir las reglas del protocolo. + +--- + +### Por qué ejecutar tu propio nodo + +**Soberanía total.** Sabes con certeza que los pagos que recibes son válidos. No dependes de ningún tercero. + +**Privacidad.** Cuando tu wallet se conecta a un nodo externo, ese nodo sabe qué direcciones estás consultando. Con tu propio nodo, esa información no sale de tu red. + +**Contribuir a la red.** Cada nodo adicional hace Bitcoin más resistente y más difícil de censurar. + +El software de referencia es **Bitcoin Core**. También existen opciones más accesibles como **Umbrel** o **Start9** para instalar en una Raspberry Pi. + +--- + +### Resumen + +Un nodo verifica y propaga transacciones siguiendo las reglas de Bitcoin. Son los nodos los que realmente hacen cumplir esas reglas — no los mineros, no los desarrolladores, no las empresas. Ejecutar el tuyo propio es la forma más directa de participar en Bitcoin sin depender de nadie. + +No confíes. Verifica. + +> Ya sabes cómo funciona Bitcoin por dentro. Ahora viene algo más práctico: cómo interactúas tú con todo esto. Las claves privadas hay que guardarlas en algún sitio. Ese sitio es la wallet — y elegir bien no es trivial. + +--- + +## Capítulo 10 — Las wallets + +**Nivel: Principiante** + +--- + +### Qué es una wallet + +Una wallet no guarda bitcoin. El bitcoin está en la blockchain. + +Lo que guarda una wallet son tus **claves privadas** — y a partir de ellas genera las direcciones, firma las transacciones, y te muestra el saldo consultando la blockchain. Es un gestor de claves con interfaz amigable. + +Esta distinción importa: si pierdes tu wallet pero tienes tus claves, tienes tu bitcoin. Si pierdes tus claves aunque tengas la wallet, has perdido el bitcoin. + +--- + +### La seed phrase: la raíz de todo + +Las wallets modernas son **deterministas** — todas las claves y direcciones que generan se derivan de un único número maestro llamado **seed** o semilla. + +Para que ese número sea fácil de respaldar, se representa como una lista de palabras — generalmente 12 o 24 — tomadas de una lista estándar de 2048 palabras. Esto es la **seed phrase**. + +``` + 12/24 palabras + ┌────────────────────────────────┐ + │ witch collapse practice feed │ + │ shame open despair creek... │ + └───────────────┬────────────────┘ + │ PBKDF2 + ▼ + seed (512 bits) + │ HMAC-SHA512 + ▼ + clave maestra privada + │ + ┌────────┼────────┐ + ▼ ▼ ▼ + cuenta 0 cuenta 1 cuenta 2 + │ + ┌────┴────┐ + ▼ ▼ + recepción cambio + │ + dir_0 dir_1 dir_2 ... (infinitas) +``` + +> La seed phrase es lo más importante que debes proteger. Quien la tenga, tiene acceso a todo tu bitcoin. Nunca la introduzcas en ninguna web. Nunca la fotografíes. Nunca la guardes en un ordenador conectado a internet. Escríbela en papel y guárdala en un lugar seguro. + +--- + +### Tipos de wallet + +**Wallet de software** — Una aplicación en tu móvil o ordenador. Cómoda para cantidades pequeñas de uso cotidiano. El riesgo es que las claves residen en un dispositivo conectado a internet. + +**Wallet de hardware** — Un dispositivo físico diseñado exclusivamente para almacenar claves privadas. Las claves nunca salen del dispositivo. Recomendado para cualquier cantidad que te importe perder. + +``` + CUSTODIAL NO CUSTODIAL + ┌─────────────┐ ┌─────────────┐ + │ Exchange │ │ Tu wallet │ + │ "tienes │ │ Tus claves │ + │ 1 BTC" │ │ Tu bitcoin │ + └─────────────┘ └─────────────┘ + promesa de bitcoin real + un tercero verificable + + not your keys, not your coins +``` + +--- + +### Custodial vs no custodial + +Una **wallet custodial** es aquella en la que otra entidad guarda tus claves por ti. Si la empresa quiebra, te hackean, o decide congelarte la cuenta, tu bitcoin desaparece o queda inaccesible. + +Una **wallet no custodial** es aquella en la que tú controlas tus propias claves. + +> **Por qué esto importa más allá de la teoría.** En 2014, Mt. Gox — el mayor exchange de Bitcoin del mundo en aquel momento — quebró y desapareció con el bitcoin de 850.000 usuarios. En 2022, FTX — valorada en 32.000 millones de dólares — hizo lo mismo. En ambos casos, los usuarios tenían saldos en pantalla pero no tenían claves. Cuando la empresa desapareció, el bitcoin desapareció con ella. _Not your keys, not your coins_ no es un eslogan. Es una lección aprendida a muy alto precio. + +--- + +### La passphrase: una capa adicional + +Las wallets de hardware permiten añadir una **passphrase** — una palabra o frase adicional que genera un conjunto de claves completamente diferente. + +Incluso si alguien encuentra tu seed phrase, sin la passphrase no puede acceder a tu bitcoin real. + +--- + +### Verifica tú mismo + +Instala **Sparrow Wallet** en tu ordenador. Crea una nueva wallet y observa cómo genera la seed phrase. Anótala en papel. Luego cierra la wallet, bórrala, y recupérala introduciendo las mismas palabras. Verás cómo todas las direcciones aparecen exactamente igual. + +Haz este ejercicio sin bitcoin real la primera vez. Cuando lo hayas hecho, la mecánica de la autocustodia deja de ser abstracta. + +--- + +### Resumen + +Una wallet gestiona tus claves privadas — no tu bitcoin. La seed phrase es la copia de seguridad maestra. Usa siempre wallets no custodiales. Para cantidades significativas, usa una wallet de hardware. + +> Tienes una wallet y sabes que la seed phrase es lo más importante que debes proteger. Pero protegerla de qué, exactamente, y cómo. La seguridad en Bitcoin tiene reglas propias — sin banco que te cubra las espaldas, cada decisión cuenta. + +--- + +## Capítulo 11 — Seguridad + +**Nivel: Principiante** + +--- + +### El modelo de amenazas en Bitcoin + +La seguridad en Bitcoin es diferente a la seguridad en la banca tradicional. + +En la banca, si alguien te roba, puedes llamar al banco. En Bitcoin no hay ninguno de esos mecanismos. Una transacción confirmada es irreversible. Si alguien accede a tus claves, puede vaciar tu wallet y no hay nada que hacer. + +La responsabilidad de la seguridad es completamente tuya. + +--- + +### Las dos amenazas principales + +``` + AMENAZA DIGITAL AMENAZA FÍSICA + ┌─────────────────┐ ┌─────────────────┐ + │ malware │ │ robo del papel │ + │ phishing │ │ incendio │ + │ sitios falsos │ │ inundación │ + └────────┬────────┘ └────────┬────────┘ + │ │ + ▼ ▼ + hardware wallet backup en metal + (claves offline) (copia redundante) +``` + +--- + +### El setup básico recomendado + +- **Hardware wallet** para guardar las claves fuera de internet +- **Dos copias físicas de la seed phrase** en dos ubicaciones distintas +- **Seed phrase separada de la hardware wallet** + +``` + PAPEL METAL (acero inoxidable) + ┌─────────┐ ┌─────────┐ + │ seed │ │ SEED │ + │ phrase │ │ PHRASE │ + │ escrita │ │ GRABADA │ + └─────────┘ └─────────┘ + arde · se moja resiste fuego · agua · tiempo + se deteriora dura décadas +``` + +> El mayor riesgo para tu bitcoin no suele ser un hacker sofisticado. Eres tú mismo — un sistema demasiado complejo que luego no recuerdas cómo recuperar, una seed guardada en un solo lugar, una passphrase memorizada que olvidas. La simplicidad es seguridad. + +--- + +### Lo que nunca debes hacer + +- **Guardar la seed en digital** — foto, nota de móvil, email, nube +- **Introducir la seed en una web** — no existe ninguna web legítima que la necesite +- **Confiar en la memoria** — es un complemento del backup físico, nunca un sustituto +- **No hacer la prueba de recuperación** — antes de guardar bitcoin real, recupera la wallet desde cero +- **Hablar de cuánto bitcoin tienes** — la discreción es parte de la seguridad + +--- + +### Amenazas a tener en cuenta + +**Clipboard hijacking.** Malware que sustituye la dirección que has copiado por otra del atacante. Verifica siempre los primeros y últimos caracteres de una dirección antes de confirmar. + +**Supply chain.** Hardware wallets compradas de fuentes no oficiales pueden estar comprometidas. Compra siempre directamente al fabricante. + +**El ataque de los 5 dólares.** Si alguien sabe que tienes bitcoin y está dispuesto a presionarte físicamente, la mejor defensa es la discreción. La passphrase con una wallet señuelo es una medida útil. + +--- + +### La herencia: un problema que nadie quiere pensar + +Bitcoin es dinero al portador. Si mueres sin dejar instrucciones claras sobre cómo acceder a tus claves, tus herederos no podrán recuperar tu bitcoin. No hay servicio de atención al cliente al que llamar. No hay procedimiento legal que lo resuelva. El bitcoin simplemente quedará inaccesible para siempre. + +El mínimo necesario es un documento físico, guardado en un lugar seguro conocido por tus herederos, que incluya: + +- **Dónde está la seed phrase** — ubicación exacta de cada copia +- **Qué wallet usar** — nombre del software o del dispositivo hardware +- **Si existe passphrase** — y cómo acceder a ella, guardada siempre separada de la seed +- **Qué direcciones son tuyas** — para que puedan verificar el saldo antes de intentar nada +- **Los pasos para recuperar la wallet** — explicados como si la persona no supiera nada de Bitcoin + +Ese documento es tan sensible como la seed phrase misma. Quien lo tenga puede acceder a tu bitcoin. Guárdalo con el mismo cuidado. + +No hay solución perfecta. Pero no hacer nada es la peor opción — y la más común. + +--- + +### Resumen + +La seguridad en Bitcoin requiere protegerte de dos amenazas: el robo digital y la pérdida física. La solución para la primera es una hardware wallet. La solución para la segunda es redundancia física con materiales duraderos. + +La autocustodia es poder real. Ese poder viene con responsabilidad real. No es complicado — pero requiere hacerlo bien una vez. + +> Ya tienes las bases. Sabes qué es Bitcoin, cómo funciona, cómo se custodian las claves y cómo protegerlas. Queda una última pieza práctica: hacer una transacción real. Qué ocurre exactamente desde que decides enviar bitcoin hasta que la otra persona lo recibe. + +--- + +## Capítulo 12 — Cómo enviar bitcoin + +**Nivel: Principiante** + +--- + +### El proceso completo + +Enviar bitcoin parece sencillo — introduces una dirección, un importe, pulsas enviar. Pero detrás de esos tres pasos ocurren cosas que vale la pena entender para tomar buenas decisiones. + +--- + +### Paso 1 — La dirección del destinatario + +Pídela directamente. La regla más importante: **verifica siempre la dirección antes de confirmar.** Una vez enviada, la transacción no se puede deshacer. + +--- + +### Paso 2 — El importe + +La mayoría de wallets permiten introducir la cantidad en BTC o en satoshis. Si tu wallet lo permite, activa la visualización en satoshis — es la unidad nativa y evita confusiones con decimales. + +--- + +### Paso 3 — La fee + +La fee determina la prioridad de tu transacción en la mempool. + +``` + MEMPOOL + ┌─────────────────────────────────┐ ← fee alta + │ tx_a │ 50 sat/vbyte │ + │ tx_b │ 45 sat/vbyte │ + │ tx_c │ 30 sat/vbyte │ + │ tx_d │ 10 sat/vbyte │ ← fee baja + │ ... │ │ + └────────────────┬────────────────┘ + │ minero selecciona + ▼ las de más fee + BLOQUE (espacio limitado) +``` + +--- + +### Qué ocurre después + +Tu transacción entra en la mempool y se propaga por la red en segundos. Cuando un minero la incluye en un bloque recibe su primera **confirmación**. + +``` + tu tx bloque N bloque N+1 bloque N+2 + ──────▶ ┌────────┐ ┌──────────┐ ┌──────────┐ + │ tx ✓ │◀─│ prev: N │◀│ prev: N+1│ + └────────┘ └──────────┘ └──────────┘ + 1 confirm. 2 confirm. 3 confirm. + cada bloque encima = una confirmación más +``` + +Para la mayoría de pagos, una confirmación es suficiente. Para importes elevados, esperar tres o más da mayor certeza. + +--- + +### Rastrear tu transacción + +En [mempool.space](https://mempool.space), pega el TXID en el buscador y verás en tiempo real si la transacción está en la mempool y cuándo se espera que sea minada. + +--- + +### Si una transacción tarda demasiado + +Si la fee fue baja y la red se congestionó, tu transacción puede quedarse estancada. La solución es **RBF** — _Replace by Fee_: reemplazar la transacción por una nueva con fee más alta. La mayoría de wallets modernas tienen esta opción como "acelerar transacción". + +--- + +### Resumen + +Enviar bitcoin es irreversible. Verifica siempre la dirección antes de confirmar. Elige la fee según la urgencia. Usa un explorador de bloques para rastrear el estado de tus transacciones. + +El proceso completo ocurre sin intermediarios, sin permisos, sin horarios bancarios. Cualquier cantidad, a cualquier persona, en cualquier parte del mundo. + +--- + +### Una nota sobre Lightning Network + +Todo lo que hemos visto en este capítulo describe transacciones en la **capa base** de Bitcoin — la blockchain. Para pagos pequeños, rápidos y con fees mínimas existe **Lightning Network** — una segunda capa construida sobre Bitcoin que permite enviar satoshis de forma casi instantánea y prácticamente sin coste. + +La cubrimos en detalle en la Parte 2 de esta guía. + +--- + +_Con este capítulo concluye la Parte 1 — Principiantes._ + +--- + +## Glosario + +**Bitcoin (con mayúscula)** — El protocolo, la red, el sistema. + +**bitcoin (con minúscula)** — La unidad monetaria. + +**Blockchain** — El archivo compartido por todos los nodos que contiene el historial completo de transacciones de Bitcoin, estructurado en bloques encadenados criptográficamente. + +**Bloque** — Contenedor de transacciones que se añade a la blockchain aproximadamente cada diez minutos. + +**Bloque génesis** — El primer bloque de la blockchain de Bitcoin, minado por Satoshi Nakamoto el 3 de enero de 2009. + +**BTC** — Símbolo de la unidad bitcoin. + +**Cabecera de bloque** — La parte del bloque que contiene el hash del bloque anterior, el merkle root, el timestamp, el nonce y los bits. + +**Coinbase transaction** — La primera transacción de cada bloque, creada por el minero para reclamar el subsidio de bloque y las fees. No tiene inputs. + +**Clave privada** — Número aleatorio de 256 bits que da acceso al bitcoin asociado a las direcciones derivadas de él. Debe mantenerse en secreto absoluto. + +**Clave pública** — Dato matemáticamente derivado de la clave privada. Se puede compartir libremente. + +**Confirmación** — Cada bloque minado encima del bloque que contiene una transacción. + +**Custodia** — Control sobre las claves privadas. + +**Dificultad** — Medida de cuánto trabajo computacional se requiere para minar un bloque. Se ajusta automáticamente cada 2.016 bloques. + +**Dirección** — Identificador derivado de la clave pública que se usa para recibir bitcoin. + +**Doble gasto** — Intento de gastar el mismo bitcoin en dos transacciones simultáneas. + +**Fee** — Comisión que el remitente de una transacción ofrece a los mineros. + +**Firma digital** — Dato matemático producido con la clave privada que demuestra autorización sobre una transacción sin revelar la clave. + +**Función hash** — Función matemática que transforma cualquier dato en una cadena de longitud fija. + +**Halving** — Reducción a la mitad del subsidio de bloque que ocurre cada 210.000 bloques. + +**Hardware wallet** — Dispositivo físico diseñado para almacenar claves privadas offline. + +**Hash** — El resultado de aplicar una función hash a un dato. + +**Hashrate** — Poder computacional total de la red de minería. + +**Input** — Referencia a un output anterior que se consume en una transacción. + +**Lightning Network** — Segunda capa de pagos construida sobre Bitcoin. + +**Mempool** — Conjunto de transacciones válidas que han sido difundidas por la red pero todavía no han sido incluidas en un bloque. + +**Merkle root** — Hash que resume todas las transacciones de un bloque en un único valor. + +**Minería** — Proceso por el que los nodos compiten para añadir bloques a la blockchain. + +**Nodo** — Ordenador que ejecuta el software de Bitcoin, verifica transacciones y bloques, y mantiene una copia de la blockchain. + +**Nonce** — Campo de la cabecera de bloque que los mineros modifican en cada intento. + +**Output** — Porción de bitcoin creada en una transacción, bloqueada a una dirección concreta. + +**P2PKH** — _Pay to Public Key Hash_. Script de bloqueo usado por las direcciones Legacy (1…). + +**P2SH** — _Pay to Script Hash_. Script que permite condiciones complejas de gasto. + +**P2TR** — _Pay to Taproot_. Script moderno que mejora privacidad y eficiencia. + +**P2WPKH** — _Pay to Witness Public Key Hash_. Script de SegWit nativo para pagos estándar. + +**Passphrase** — Palabra o frase adicional que se combina con la seed phrase para generar un conjunto de claves completamente diferente. + +**Prueba de trabajo** — Mecanismo por el que los mineros demuestran haber realizado trabajo computacional real. + +**RBF** — _Replace by Fee_. Mecanismo que permite reemplazar una transacción no confirmada por una nueva con fee más alta. + +**Satoshi** — Unidad mínima de bitcoin. Un satoshi equivale a 0,00000001 BTC. + +**Seed / Semilla** — Número maestro del que se derivan todas las claves privadas de una wallet determinista. + +**Seed phrase** — Lista de 12 o 24 palabras que representa la seed de forma legible. + +**SegWit** — _Segregated Witness_. Actualización de Bitcoin activada en 2017. + +**SHA-256** — Función hash criptográfica usada por Bitcoin. + +**Subsidio de bloque** — Bitcoin nuevo que el minero puede reclamar al minar un bloque exitosamente. + +**Taproot** — Actualización de Bitcoin activada en 2021. + +**Target** — Número por debajo del cual debe estar el hash de un bloque para que sea considerado válido. + +**Timestamp** — Marca de tiempo incluida en la cabecera de cada bloque. + +**TXID** — _Transaction ID_. Identificador único de una transacción. + +**UTXO** — _Unspent Transaction Output_. Output que todavía no ha sido gastado. + +**Wallet** — Software que gestiona claves privadas, genera direcciones y firma transacciones. + +--- + +## Preguntas frecuentes + +**¿Es Bitcoin seguro?** +El protocolo de Bitcoin lleva funcionando sin interrupciones desde 2009. Nunca ha sido hackeado. Los robos y pérdidas que se producen ocurren en la capa de custodia — exchanges, wallets mal configuradas, errores humanos — no en el protocolo en sí. + +**¿Es ilegal?** +En la mayoría de países, no. Bitcoin es legal en España, en la Unión Europea, en Estados Unidos, en México, en Argentina y en la mayor parte del mundo. + +**¿Puedo comprar fracciones de un bitcoin?** +Sí. Bitcoin es divisible hasta ocho decimales. La unidad mínima es el satoshi (0,00000001 BTC). + +**¿Qué pasa si pierdo mi seed phrase?** +Si pierdes tu seed phrase y no tienes ninguna copia, pierdes el acceso a tu bitcoin de forma permanente. No hay ningún mecanismo de recuperación. + +**¿Cuánto cuesta enviar bitcoin?** +Depende de la congestión de la red en ese momento y del tipo de dirección que uses. Puedes consultar el estado actual de las fees en mempool.space. + +**¿Por qué hay un límite de 21 millones?** +Es una decisión de diseño de Satoshi Nakamoto. Un límite fijo hace que bitcoin sea predeciblemente escaso — nadie puede crear más. + +**¿Quién controla Bitcoin?** +Nadie lo controla de forma centralizada. Los desarrolladores proponen cambios, los mineros los activan, y los nodos deciden si los aceptan. + +**¿Qué pasa con Bitcoin en 2140 cuando ya no haya recompensa de bloque?** +A partir de 2140 los mineros solo cobrarán fees por las transacciones que incluyan en cada bloque. + +**¿Es anónimo?** +No. Bitcoin es seudónimo. Todas las transacciones son públicas y trazables en la blockchain. + +**¿Y si un gobierno lo prohíbe?** +Ya ha ocurrido en algunos países. Bitcoin sigue funcionando en todos ellos. La red no tiene un punto central que se pueda apagar. + +**¿Puedo perder bitcoin por un bug del software?** +El código de Bitcoin Core ha sido auditado durante más de quince años por miles de desarrolladores. El mayor riesgo no es el software sino la custodia. + +**¿Qué pasa si alguien genera la misma clave privada que yo?** +Es teóricamente posible pero prácticamente imposible. Hay 2²⁵⁶ claves privadas posibles — un número que supera el número de átomos en el universo observable. + +--- + +## Recursos + +- [learnmeabitcoin.com](https://learnmeabitcoin.com) — Greg Walker. Fuente técnica principal de esta guía. +- [mempool.space](https://mempool.space) — Explorador de bloques y visualizador de la mempool en tiempo real. +- [bitnodes.io](https://bitnodes.io) — Mapa de nodos Bitcoin activos en todo el mundo. +- [Bitcoin Whitepaper](https://bitcoin.org/bitcoin.pdf) — Satoshi Nakamoto, 2008. diff --git a/es/bitcoin-02-intermedio.md b/es/bitcoin-02-intermedio.md new file mode 100644 index 0000000..e1e5173 --- /dev/null +++ b/es/bitcoin-02-intermedio.md @@ -0,0 +1,1012 @@ +# Bitcoin — Parte 2: Intermedio + +_Hecho desde la comunidad, para la comunidad hispanohablante_ +_Bitcoin Txoko_ + +--- + +## Índice + +``` + ▶ PARTE 2 — INTERMEDIO + ──────────────────────────────────────────────── + + 01 Privacidad en Bitcoin ................. 7 + seudónimo · análisis · CoinJoin · Tor + + 02 Lightning Network ..................... 17 + canales · routing · HTLCs · corredores · onion routing + + 03 Cómo conseguir bitcoin ................ 31 + KYC · sin KYC · plataformas P2P · BTCPay + + 04 Autocustodia avanzada ................. 41 + multisig · descriptor · air-gap · herencia + + 05 La economía de Bitcoin ................ 53 + 21M · halving · escasez · deflación · críticas + + ──────────────────────────────────────────────── + Glosario .................................. 63 + Preguntas frecuentes ...................... 75 + Recursos .................................. 83 +``` + +--- + +## Capítulo 1 — Privacidad en Bitcoin + +**Nivel: Intermedio** + +--- + +### Bitcoin no es anónimo + +Todas las transacciones de Bitcoin son públicas. + +Cualquier persona puede consultar el historial completo de cualquier dirección ahora mismo. Sin contraseña. Sin permiso. Sin intermediarios. + +Lo que ofrece Bitcoin por defecto no es anonimato — es **seudónimo**. Tu nombre no aparece en ningún registro. Pero todo lo que haces con tu dirección sí aparece, de forma permanente y visible para cualquiera. + +``` + bc1qxy2...f5mdq + + ┌─────────────────────────────────────────────┐ + │ bloque 850.100 recibió 0.50 BTC │ + │ bloque 850.234 envió 0.30 BTC │ + │ bloque 850.891 recibió 0.10 BTC │ + │ bloque 851.002 envió 0.25 BTC │ + │ ... │ + └─────────────────────────────────────────────┘ + visible para cualquiera · ahora mismo · sin permiso +``` + +> **Por qué importa.** El historial financiero de una persona revela sus hábitos, sus relaciones, sus vulnerabilidades. Satoshi lo sabía. En el whitepaper hay una sección dedicada a la privacidad — no como característica opcional sino como parte del diseño. La recomendación es usar una dirección nueva para cada transacción. No como opción avanzada. Como práctica básica desde el primer día. La vigilancia financiera no necesita escuchas telefónicas. Basta con los datos de pago. + +--- + +### La diferencia entre seudónimo y anónimo + +Anónimo significa que nadie puede saber quién eres ni qué haces. Seudónimo significa que nadie sabe quién eres hasta que algo te conecta con tu dirección. + +``` + ┌─────────────────────────────────────────┐ + │ exchange con KYC │ + │ dirección publicada en redes │──┐ + │ recibido de conocido │ │ + └─────────────────────────────────────────┘ │ + ▼ + bc1qxy2...f5mdq + │ + ▼ + historial financiero completo + público · permanente · trazable +``` + +Esa conexión puede ser voluntaria — publicar tu dirección en redes sociales — o involuntaria — comprar en un exchange con KYC y retirar a esa dirección. En ambos casos el resultado es el mismo: tu seudónimo deja de serlo. + +--- + +### Cómo se rastrea el dinero + +Las transacciones no existen de forma aislada. Cada output es el input de la siguiente. La blockchain es un grafo continuo donde todo está conectado. + +Existen empresas especializadas en rastrear flujos de fondos usando heurísticas. La más conocida: si una transacción combina varios inputs, probablemente todos pertenecen al mismo usuario. + +``` + ┌─────────────┐ + │ bc1q...aaa │──┐ + └─────────────┘ │ ┌──────────────────────┐ + ├──▶│ TRANSACCIÓN │ + ┌─────────────┐ │ └──────────────────────┘ + │ bc1q...bbb │──┘ + └─────────────┘ + │ + ▼ + "probable mismo propietario" + heurística usada en análisis de blockchain +``` + +El output de cambio también es información. Cuando gastas un UTXO que vale más de lo que envías, la transacción crea dos outputs: uno para el destinatario y otro que vuelve a ti. Cualquier analista puede intentar identificar cuál es cuál. + +``` + INPUT: 1.00 BTC + │ + ▼ + ┌──────────────────────────────────┐ + │ TRANSACCIÓN │ + └──────┬───────────────────────────┘ + │ + ┌────┴─────────────────────┐ + ▼ ▼ + 0.40 BTC → destinatario 0.59 BTC → cambio (tú) + │ + ▼ + revela otra dirección tuya +``` + +--- + +### CoinJoin + +CoinJoin rompe ese vínculo combinando los inputs y outputs de varias personas en una sola transacción. + +``` + Alice 0.10 BTC ──┐ + Bob 0.10 BTC ──┼──▶ ┌─────────────────────┐ + Carol 0.10 BTC ──┘ │ COINJOIN TX │ + └──┬──────┬──────┬─────┘ + ▼ ▼ ▼ + 0.10 0.10 0.10 + BTC BTC BTC + + ¿qué input pagó a qué output? imposible saberlo + los importes iguales eliminan la heurística de rastreo +``` + +Nadie necesita confiar en nadie. Cada participante firma únicamente su propio input. Nadie puede robar los fondos de otro. + +La implementación de referencia más sólida técnicamente es **JoinMarket** — un mercado donde los participantes se organizan directamente sin coordinador central. Más allá de JoinMarket, el ecosistema de herramientas CoinJoin ha evolucionado mucho y sigue cambiando. Antes de usar cualquier herramienta concreta, vale la pena verificar su estado actual — la comunidad Bitcoin es la mejor fuente para eso. + +--- + +### La red también deja rastro + +Cuando tu wallet emite una transacción, se conecta a nodos de Bitcoin desde tu dirección IP. Esa IP es un dato que puede vincularse a ti — independientemente de lo bien que hayas gestionado tus direcciones. + +La solución es **Tor** — una red que enruta tu tráfico a través de múltiples nodos cifrados antes de llegar a destino. + +``` + SIN TOR CON TOR + tu wallet tu wallet + │ IP: tuya │ + ▼ ▼ + nodo Bitcoin red Tor (cifrado en capas) + sabe tu IP │ + ▼ + nodo Bitcoin + ve IP de Tor + no sabe quién eres +``` + +Bitcoin Core tiene soporte nativo para Tor. La mayoría de implementaciones de nodo completo — Umbrel, Start9 — lo activan por defecto. Si corres tu propio nodo con Tor, todas las transacciones que emites salen sin exponer tu IP real. + +--- + +### Las buenas prácticas como hábito + +La privacidad en Bitcoin no es un switch que se activa una vez. Es el resultado de decisiones consistentes. + +``` + ┌─────────────────────────────────────────────────┐ + │ PRÁCTICAS BÁSICAS │ + │ │ + │ · dirección nueva para cada pago │ + │ · no publicar direcciones en redes sociales │ + │ · retirar siempre de exchanges a wallet propia│ + │ · correr nodo propio con Tor │ + │ │ + │ PRÁCTICAS AVANZADAS │ + │ │ + │ · CoinJoin antes de consolidar UTXOs │ + │ · separar UTXOs según origen │ + │ · Lightning para pagos cotidianos │ + └─────────────────────────────────────────────────┘ +``` + +Ninguna de estas prácticas garantiza anonimato completo. Lo que hacen es elevar el coste del análisis hasta un punto donde la mayoría de adversarios no tiene incentivo suficiente para seguir el rastro. + +--- + +### Vélo tú mismo + +Entra en [mempool.space](https://mempool.space) y busca una transacción con muchos inputs y outputs del mismo valor. Es probable que sea una CoinJoin — observa cómo es imposible seguir el rastro desde los inputs hasta los outputs. + +Ahora busca una transacción ordinaria con un solo input y dos outputs de importes diferentes. Intenta identificar cuál es el pago y cuál es el cambio. Eso es exactamente lo que hace el análisis de blockchain. + +--- + +### Resumen + +Bitcoin es seudónimo, no anónimo. La blockchain es pública y permanente. Cualquier conexión entre una dirección y una identidad real convierte ese seudónimo en historial financiero visible para cualquiera. + +La privacidad se construye con decisiones consistentes: una dirección por transacción, CoinJoin cuando tiene sentido, Tor para no exponer la IP. + +_La privacidad no es tener algo que esconder. Es tener algo que proteger._ + +--- + +> Las transacciones on-chain siempre dejan huella. Pero hay pagos que ni siquiera necesitan aparecer en la blockchain — instantáneos, casi gratuitos, con toda la seguridad de Bitcoin como respaldo. Eso es Lightning Network. + +--- + +## Capítulo 2 — Lightning Network + +**Nivel: Intermedio** + +--- + +### Bitcoin no está diseñado para pagar un café + +La capa base de Bitcoin hace una cosa extraordinariamente bien: registrar transacciones de forma permanente e irreversible en miles de nodos de todo el mundo. + +Ese proceso tarda diez minutos como mínimo. Cuesta una fee que compite con otras transacciones. Y tiene sentido — es exactamente lo que hace Bitcoin seguro. + +Pero para pagar un café, es excesivo. + +Lightning Network no intenta cambiar eso. Construye una segunda capa encima. + +``` + ┌────────────────────────────────────────┐ + │ LIGHTNING NETWORK │ + │ pagos instantáneos · fees mínimas │ + │ privacidad mejorada · off-chain │ + ├────────────────────────────────────────┤ + │ BLOCKCHAIN BITCOIN │ + │ liquidación final · seguridad │ + │ inmutabilidad · on-chain │ + └────────────────────────────────────────┘ +``` + +--- + +### La idea + +¿Qué pasaría si dos personas pudieran hacerse pagos entre ellas sin escribir cada uno en la blockchain? + +Solo necesitan registrar dos cosas: cuando empiezan a transaccionar y cuando terminan. Todo lo que ocurre en medio se gestiona entre ellos directamente — con la garantía de que cualquiera puede ir a la blockchain en cualquier momento si el otro intenta hacer trampa. + +Eso es un **canal de pago**. La blockchain actúa como árbitro de última instancia — siempre disponible, solo necesario al principio y al final. + +--- + +### Cómo se abre un canal + +Para abrir un canal, dos partes crean una transacción en la blockchain que bloquea bitcoin en una dirección especial — una multisig 2-de-2. Ninguna puede mover esos fondos sin la firma de la otra. + +``` + Alice pone 1.000.000 sats + Bob pone 1.000.000 sats + │ + ▼ + ┌─────────────────────────┐ + │ MULTISIG 2-de-2 │ ← transacción on-chain + │ 2.000.000 sats │ (apertura del canal) + │ [llave Alice + Bob] │ + └─────────────────────────┘ + ninguno puede mover sin firma del otro +``` + +A partir de aquí cada pago es una actualización de saldo firmada por ambos — válida, lista para publicarse, pero guardada — no publicada. + +``` + on-chain off-chain + ┌──────────────┐ ┌────────────────────────────────────┐ + │ apertura │ │ pago 1 pago 2 pago 3 │ + │ A:1.000.000 │ │ A:900.000 A:950.000 A:920.000 │ + │ B:1.000.000 │ │ B:1.100.000 B:1.050.000 B:1.080.000│ + └──────────────┘ └────────────────────────────────────┘ + 1 transacción miles de pagos posibles + registrada sin tocar la blockchain +``` + +--- + +### Qué impide hacer trampa + +Si Alice guarda la primera versión del saldo — cuando tenía más bitcoin — ¿qué le impide publicarla? + +Cada actualización revoca la anterior. Si Alice publica un estado antiguo, Bob tiene un plazo para demostrarlo y reclamar todos los fondos del canal como penalización. + +``` + Estado actual: Alice 900.000 / Bob 1.100.000 + + Alice intenta publicar estado antiguo: + Estado antiguo: Alice 1.000.000 / Bob 1.000.000 + │ + ▼ + Bob detecta el fraude + dentro del plazo + │ + ▼ + Bob reclama TODOS los fondos + Alice pierde todo lo que tenía +``` + +Hacer trampa no solo no funciona. Puede costarte todo lo que tenías. + +--- + +### Routing + +Un canal entre dos personas solo sirve para que esas dos personas se paguen. Para pagar a alguien sin canal directo, Lightning enruta el pago a través de otros nodos. + +``` + Alice ──[canal]──▶ Bob ──[canal]──▶ Carol + + Alice quiere pagar a Carol + No tienen canal directo + El pago salta por Bob + + Bob cobra fee mínima (fracciones de satoshi) + Bob no puede robar el pago → HTLCs +``` + +--- + +### Por qué Bob no puede robar el pago + +El protocolo usa **HTLCs** — contratos que funcionan con un secreto y su huella digital. + +``` + 1. Carol genera secreto = "xyz" + huella = hash("xyz") + + 2. Alice → Bob: "te pago si conoces secreto de hash(xyz)" + Bob → Carol: "te pago si conoces secreto de hash(xyz)" + + 3. Carol revela "xyz" → cobra de Bob + Bob usa "xyz" → cobra de Alice + + resultado: + ┌─────────────────────────────────────────────┐ + │ el pago llega completo o se devuelve solo │ + │ nadie puede quedarse el dinero a medias │ + └─────────────────────────────────────────────┘ +``` + +--- + +### Los corredores de nodos + +El routing no se resuelve solo. Para que un pago llegue de Alice a Carol, alguien tiene que tener bitcoin en el lugar correcto, en el momento correcto, en la dirección correcta. + +Esa persona es el **corredor de nodos** — operadores que mantienen nodos bien conectados con liquidez suficiente en múltiples canales para que los pagos puedan fluir por la red. + +``` + ┌─────────────────────────────────────────────────┐ + │ CORREDOR DE NODOS │ + │ │ + │ · abre canales estratégicos con muchos pares │ + │ · mantiene liquidez en ambas direcciones │ + │ · cobra fees de routing (fracciones de sat) │ + │ · su uptime es crítico para la red │ + └─────────────────────────────────────────────────┘ +``` + +Gestionar liquidez es el trabajo central de un corredor. Un canal tiene dos lados. Si Alice ha enviado mucho a través de un nodo, ese nodo acumula liquidez en la dirección de Alice y se queda sin liquidez en la dirección contraria. Los pagos que intenten pasar por ese tramo en sentido contrario fallarán. El corredor detecta ese desequilibrio y lo corrige — moviendo liquidez de donde sobra a donde falta, a veces pagando él mismo fees de routing para hacerlo. Ese trabajo continuo es lo que mantiene la red fluida. + +Los corredores de nodos son la infraestructura invisible que hace que Lightning funcione en la práctica. Sin ellos, la red sería un conjunto de islas desconectadas. + +> **Un rol nuevo en el ecosistema Bitcoin.** Ser corredor de nodos no requiere permiso de nadie. Cualquiera puede abrir canales, gestionar liquidez y cobrar fees de routing. Es una actividad técnica con incentivos económicos reales — y una forma directa de contribuir a la infraestructura de la red mientras se obtiene algo a cambio. + +--- + +### Privacidad en Lightning + +Los pagos dentro de un canal no aparecen en la blockchain. Los pagos enrutados usan **onion routing** — cada nodo recibe la información cifrada en capas, como una cebolla. Solo puede descifrar su propia capa — ve de dónde viene el pago y adónde enviarlo, pero no el origen ni el destino final. + +``` + Alice ──▶ Nodo1 ──▶ Nodo2 ──▶ Carol + + Nodo1 sabe: recibí de Alice · envío a Nodo2 + Nodo2 sabe: recibí de Nodo1 · envío a Carol + Nodo1 NO sabe que el destino es Carol + Nodo2 NO sabe que el origen es Alice +``` + +--- + +### Lightning en la práctica + +Lightning es una red activa con miles de nodos y millones de pagos procesados cada mes. **Bitrefill** permite gastar bitcoin en recargas de móvil y tarjetas regalo en decenas de países — bitcoin funcionando como medio de pago real en el día a día. + +Usar Lightning bien implica entender sus requisitos operativos. Para recibir pagos necesitas liquidez entrante — alguien tiene que haber abierto un canal hacia ti con fondos disponibles. Para enviar necesitas liquidez saliente. Abrir y cerrar canales cuesta fees on-chain. Un canal cerrado de forma forzosa — cuando una parte no coopera — puede implicar esperar días antes de recuperar los fondos. + +Ninguno de estos requisitos es un defecto. Son las consecuencias naturales de cómo está diseñado el sistema — y conocerlos de antemano es lo que permite usarlo bien. + +``` + BITCOIN ON-CHAIN LIGHTNING + ┌────────────────┐ ┌────────────────┐ + │ ahorros │ │ pagos diarios │ + │ cantidades │ │ micropagos │ + │ grandes │ │ remesas │ + │ liquidación │ │ comercio │ + │ final │ │ instantáneo │ + └────────────────┘ └────────────────┘ + base de seguridad ◀──▶ medio de pago +``` + +--- + +### Vélo tú mismo + +Entra en [amboss.space](https://amboss.space) y observa el grafo de la red Lightning. Cada punto es un nodo. Cada línea es un canal con bitcoin bloqueado dentro. Observa cómo algunos nodos tienen decenas o cientos de canales — esos son los corredores. + +Busca el identificador de cualquier canal y búscalo en [mempool.space](https://mempool.space). Encontrarás la transacción de financiación — la única huella on-chain que ese canal ha dejado hasta que se cierre. + +--- + +### Resumen + +Lightning Network es una red de canales de pago construida sobre Bitcoin. Pagos instantáneos, fees mínimas, mejor privacidad — sin escribir cada transacción en la blockchain. Los corredores de nodos son la infraestructura que hace posible el routing en la práctica. + +Bitcoin como base. Lightning como movimiento. + +_Cualquier persona puede enviar cualquier cantidad a cualquier otra en cualquier parte del mundo — instantáneamente, sin permiso y sin intermediario. Gestionar bien esa infraestructura es también una forma de contribuir._ + +--- + +> Sabemos cómo funciona Bitcoin y cómo moverlo. Lo que todavía no hemos abordado es cómo conseguirlo sin entregar nuestra identidad en el proceso. + +--- + +## Capítulo 3 — Cómo conseguir bitcoin + +**Nivel: Intermedio** + +--- + +### El primer problema de la soberanía + +Puedes tener la mejor hardware wallet del mundo. Puedes correr tu propio nodo. Pero en algún momento tienes que conseguir el bitcoin. + +Y ahí empieza la primera tensión real entre comodidad y soberanía. + +La forma más fácil es registrarte en una plataforma centralizada, dar tu nombre y tu documento de identidad. En minutos tienes bitcoin en una cuenta. + +Eso se llama **KYC** — _Know Your Customer_. Y tiene consecuencias que van mucho más allá del trámite. + +``` + Tu nombre + DNI + │ + │ exchange con KYC + ▼ + ┌──────────────────────────────────────┐ + │ base de datos del exchange │ + │ nombre: Juan García │ + │ compró: 0.05 BTC el 12/03/2024 │ + │ retiró a: bc1q...xyz │ + └──────────────────────────────────────┘ + │ + ▼ + bc1q...xyz → historial público para siempre +``` + +--- + +### Qué significa comprar con KYC + +Cuando compras bitcoin en una plataforma con KYC, esa plataforma sabe quién eres, cuánto compraste, cuándo lo compraste y a qué dirección lo retiraste. + +Esa dirección queda vinculada a tu identidad para siempre. Y la blockchain es pública y permanente. + +Esos datos se almacenan. Pueden robarse. Pueden compartirse con gobiernos. Pueden filtrarse. + +> **Ha ocurrido.** Exchanges, fabricantes de hardware wallets, plataformas de gestión de clientes — todos han sufrido filtraciones. Datos de usuarios que compraron bitcoin de forma completamente legal acabaron en manos de criminales. La pregunta no es si tienes algo que esconder. Es si quieres que tu historial financiero exista en un servidor que no controlas. + +--- + +### La alternativa: sin KYC + +Existen formas de adquirir bitcoin sin identificarse. Son legales en la mayoría de jurisdicciones. + +``` + ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ + │ MINERÍA │ │ INTERCAMB. │ │ PLATAFORMA │ + │ │ │ DIRECTO │ │ P2P │ + │ bitcoin sin │ │ │ │ │ + │ historial │ │ efectivo │ │ sin custodia│ + │ previo │ │ sin registro│ │ sin KYC │ + └─────────────┘ └─────────────┘ └─────────────┘ + sin vínculo con tu identidad +``` + +--- + +### Cómo funcionan las plataformas P2P + +El mecanismo es siempre el mismo: el bitcoin del vendedor queda bloqueado en un contrato mientras el comprador realiza el pago. Cuando el vendedor confirma que recibió el pago, el bitcoin se libera. Sin empresa en el medio. Sin custodia. Sin identificación. + +``` + VENDEDOR COMPRADOR + │ │ + │ deposita bitcoin │ paga en fiat + ▼ │ (bizum, transferencia...) + ┌──────────────────────────────────┐ │ + │ CONTRATO (escrow) │◀──┘ + │ bitcoin bloqueado │ + └──────────────┬───────────────────┘ + │ + │ vendedor confirma pago recibido + ▼ + bitcoin liberado al comprador + + ◀── fiat ──────────────────────── bitcoin ──▶ +``` + +El ecosistema ha evolucionado de forma interesante. + +**Hodl-Hodl** fue una de las primeras en implementar intercambio P2P no custodial con contratos multisig on-chain. **Bisq** lleva el concepto más lejos — software completamente descentralizado sin ningún servidor central. **RoboSats** adapta el modelo a Lightning con identidades efímeras que desaparecen al terminar el intercambio. + +**negrunch** es un desarrollador que ha explorado cómo llevar el intercambio P2P a interfaces cotidianas. Primero creó **p2plnbot** — un bot de Telegram que permite comprar y vender bitcoin sobre Lightning directamente desde la app de mensajería, sin instalar nada. Después construyó **Mostro** — el mismo concepto pero sobre Nostr, una red descentralizada donde no hay servidor central que bloquear. + +``` + Hodl-Hodl ──▶ contratos multisig on-chain + │ + ▼ + Bisq ──▶ software descentralizado · sin servidor + │ + ▼ + RoboSats ──▶ Lightning · identidades efímeras + │ + ▼ + p2plnbot ──▶ bot de Telegram · Lightning + │ + ▼ + Mostro ──▶ protocolo sobre Nostr · sin servidor central + + cada paso: menos centralización · más resistencia +``` + +--- + +### Ganar bitcoin + +Conseguir bitcoin no siempre significa comprarlo. + +Si alguien te paga en bitcoin por tu trabajo o servicios, has adquirido bitcoin sin pasar por ninguna plataforma. Sin KYC. **BTCPay Server** es la herramienta de referencia para esto — software libre que cualquiera puede instalar para recibir pagos en bitcoin directamente, sin intermediarios y sin ceder ningún dato. + +**Bitrefill** permite cerrar el círculo desde el otro lado — gastar bitcoin directamente en recargas de móvil y tarjetas regalo sin convertirlo a fiat. + +``` + trabajo / servicios + │ + │ cobro en bitcoin + │ (BTCPay Server) + ▼ + bitcoin + │ + │ gasto directo + │ (Bitrefill) + ▼ + bienes y servicios + │ + └──▶ sin conversión a fiat en ningún punto +``` + +--- + +### Retira siempre a tu propia wallet + +Sea cual sea la forma en que consigas bitcoin, hay una regla sin excepciones: retíralo a una wallet que controles tú. + +Bitcoin en una plataforma no es bitcoin tuyo. Es una promesa. Ya hemos visto lo que ocurre cuando esas promesas se rompen. + +_Not your keys, not your coins._ + +--- + +### Vélo tú mismo + +Entra en [bisq.network](https://bisq.network) y observa el libro de órdenes sin registrarte. Nadie sabe que estás mirando. No hay cuenta. No hay KYC. Compara esa experiencia con cualquier exchange centralizado que hayas usado — la diferencia es inmediata. + +--- + +### Resumen + +Comprar con KYC es cómodo pero crea un vínculo permanente entre tu identidad y tu historial en Bitcoin. + +Las alternativas existen — minería, intercambio directo, plataformas P2P. El ecosistema ha evolucionado desde contratos on-chain hasta protocolos sobre Nostr. Esa diversidad es resiliencia construida deliberadamente. + +_La soberanía monetaria empieza en el momento en que el bitcoin está en tu wallet y las llaves están en tu poder._ + +--- + +> Tienes bitcoin. Ahora la pregunta es cómo custodiarlo de forma robusta a largo plazo. Una seed phrase en papel es un buen comienzo — no siempre es suficiente. + +--- + +## Capítulo 4 — Autocustodia avanzada + +**Nivel: Intermedio** + +--- + +### Una sola llave para todo + +Imagina que tienes una caja fuerte con todo lo que posees dentro. Una sola llave. Guardada en un cajón de casa. + +Si alguien entra a robar, lo pierdes todo. Si hay un incendio, lo pierdes todo. Si mueres sin decirle a nadie dónde está la llave, tus herederos lo pierden todo. + +Una seed phrase en un papel funciona exactamente igual. Es el punto de partida correcto — pero tiene un problema estructural: es un único secreto en un único lugar. + +``` + ┌───────────────────────────────┐ + │ SEED PHRASE │ + │ (papel) │ + └───────────────┬───────────────┘ + │ + ┌──────────┼──────────┐ + ▼ ▼ ▼ + ROBO INCENDIO PÉRDIDA + │ │ │ + └──────────┴──────────┘ + │ + ▼ + acceso perdido + para siempre +``` + +--- + +### Cuándo tiene sentido ir más lejos + +No todo el mundo necesita más que el setup básico. La complejidad tiene un coste real — en tiempo, en dinero, en posibilidad de cometer errores. + +Un setup demasiado complejo que no entiendes bien es más peligroso que uno simple que dominas completamente. + +--- + +### Multisig: distribuir el control + +**Multisig** — _multi-signature_ — requiere varias claves para autorizar una transacción. + +El esquema más común es **2-de-3**: tienes tres claves, necesitas dos para gastar. + +``` + CLAVE 1 CLAVE 2 CLAVE 3 + [casa] [familiar] [caja seguridad] + + necesitas cualquier combinación de 2 de 3 + + ┌──────────────────────────────────────────┐ + │ perder 1 clave → sin problema (quedan 2)│ + │ robar 1 clave → inútil (necesita 2) │ + │ atacar requiere comprometer 2 ubicaciones│ + └──────────────────────────────────────────┘ +``` + +--- + +### El descriptor + +Hay un elemento tan importante como las propias claves que casi nadie menciona: el **descriptor de la wallet**. + +El descriptor es el archivo que describe la configuración completa del multisig — qué claves lo forman y en qué esquema. Sin él, aunque tengas las claves físicas, recuperar el acceso es extraordinariamente difícil. + +``` + CLAVE 1 CLAVE 2 CLAVE 3 + │ │ │ + └───────────┴───────────┘ + │ + ▼ + ┌──────────────────────────────────┐ + │ DESCRIPTOR │ + │ wsh(multi(2,xpub1,xpub2,xpub3))│ + │ esquema + claves + configuración│ + └──────────────────────────────────┘ + sin descriptor → las claves solas no son suficientes + guardar descriptor junto a cada clave +``` + +--- + +### Air-gap + +Un hardware wallet convencional se conecta al ordenador por USB para firmar. Si el ordenador está comprometido, esa conexión es un vector de ataque. + +Un **dispositivo air-gap** nunca se conecta a nada. Firma transacciones leyendo y generando códigos QR con su cámara. + +``` + ORDENADOR DISPOSITIVO AIR-GAP + (conectado) (nunca conectado) + + construye tx + │ + │ genera QR + ▼ + [■■■■■] ─────────────────▶ escanea QR + │ + firma offline + │ + escanea QR ◀───────────── genera QR + │ + │ publica tx + ▼ + red Bitcoin + + en ningún punto hay cable entre firmante e internet +``` + +--- + +### La herencia + +¿Qué pasa con tu bitcoin si mueres? + +La blockchain no tiene mecanismo de herencia. No hay soporte al cliente. No hay proceso judicial que fuerce la apertura de una clave privada. Si nadie sabe cómo acceder a tus claves, ese bitcoin desaparece para siempre — no para ti, sino para las personas que vienen después. + +``` + ┌──────────────────────────────────┐ + │ bitcoin perfectamente seguro │ + │ nadie puede acceder sin claves │ + └────────────────┬─────────────────┘ + │ + propietario fallece + │ + ▼ + ┌──────────────────────────────────┐ + │ herederos sin instrucciones │ + │ sin claves · sin acceso │ + │ bitcoin perdido para siempre │ + └──────────────────────────────────┘ + solución: documento detallado en lugar accesible +``` + +--- + +### Calibra tu setup + +``` + CANTIDAD SETUP RECOMENDADO + ───────────────────────────────────────────── + pequeña ──▶ hardware wallet + seed metal + significativa──▶ multisig 2-de-3 + descriptor + muy grande ──▶ multisig + air-gap + herencia + ───────────────────────────────────────────── + regla: setup más simple que cubre tus riesgos + y que entiendes completamente +``` + +> **Prueba siempre antes.** Antes de guardar bitcoin real en cualquier setup nuevo, recupéralo desde cero usando solo los backups. Si no puedes hacerlo, el setup no está terminado. Un sistema que no has probado no es un sistema de seguridad — es una esperanza. + +--- + +### Vélo tú mismo + +Descarga **Sparrow Wallet** y crea una wallet multisig 2-de-3 sin hardware wallet real — Sparrow permite usar claves de prueba. Observa cómo genera el descriptor y qué información contiene. Luego reconstruye la wallet desde cero usando solo el descriptor y las claves. + +Cuando lo hayas hecho, el multisig deja de ser abstracto. + +--- + +### Resumen + +El setup correcto es el más simple que cubre tus riesgos reales y que entiendes completamente. No el más sofisticado posible. + +Multisig elimina el único punto de fallo. El descriptor es tan importante como las claves. El air-gap elimina una clase entera de ataques. La herencia es un problema real que merece una solución real. + +_Las llaves distribuidas. El descriptor guardado. La recuperación probada. El plan documentado. Eso es soberanía real._ + +--- + +> Sabemos cómo conseguir bitcoin y cómo custodiarlo. Queda una pregunta que aparece siempre: ¿por qué vale lo que vale? ¿Qué hace que bitcoin sea escaso de verdad? + +--- + +## Capítulo 5 — La economía de Bitcoin + +**Nivel: Intermedio** + +--- + +### El dinero también tiene código fuente + +El euro tiene una política monetaria. La decide el Banco Central Europeo en reuniones periódicas. Puede cambiar. Ha cambiado muchas veces. + +Bitcoin también tiene una política monetaria. Pero está escrita en código. Y cambiarla requiere que toda la red lo acepte — algo prácticamente imposible cuando esa política protege el valor de lo que todos tienen. + +``` + EURO / DÓLAR BITCOIN + ┌────────────────┐ ┌────────────────┐ + │ Banco Central │ │ protocolo │ + │ decide emisión │ │ código abierto │ + │ puede cambiar │ │ verificable │ + │ en cualquier │ │ 21M límite │ + │ momento │ │ inmutable │ + └────────────────┘ └────────────────┘ + confianza en verificación + instituciones independiente +``` + +--- + +### 21 millones + +El límite de bitcoin es 21 millones de unidades. No es una promesa. Es una regla del protocolo que cada nodo verifica de forma independiente. + +``` + año subsidio por bloque total emitido aprox. + ────────────────────────────────────────────────── + 2009 50 BTC 0 BTC + 2012 25 BTC 10.500.000 BTC + 2016 12,5 BTC 15.750.000 BTC + 2020 6,25 BTC 18.375.000 BTC + 2024 3,125 BTC 19.687.500 BTC + 2028 1,5625 BTC 20.343.750 BTC + ···· ······· ··············· + 2140 0 BTC 21.000.000 BTC + ────────────────────────────────────────────────── + cada halving reduce la emisión a la mitad +``` + +--- + +### Por qué la escasez importa + +``` + COSTE DE LÍMITE VERIFICABLE + PRODUCCIÓN CONOCIDO POR CUALQUIERA + ───────────────────────────────────────────────────── + Oro alto (minería) no no + Fiat casi cero no no + Bitcoin alto (energía) sí (21M) sí (ahora mismo) +``` + +--- + +### Inflación y deflación + +``` + DINERO FIAT BITCOIN + ┌──────────────────────┐ ┌──────────────────────┐ + │ oferta: ilimitada │ │ oferta: fija (21M) │ + │ emisión: discrecional│ │ emisión: predecible │ + │ inflación: ~2%/año │ │ deflación potencial │ + │ │ │ │ + │ 100€ hoy │ │ 1 BTC hoy │ + │ = 50€ en 35 años │ │ = 1 BTC en 35 años │ + │ (poder adquisitivo)│ │ (mismo amount) │ + └──────────────────────┘ └──────────────────────┘ +``` + +--- + +### La crítica seria + +Los economistas ortodoxos argumentan que la deflación es dañina — si tu dinero vale más mañana tienes incentivo para no gastarlo hoy, lo que frena la economía. + +Es un argumento que merece respuesta honesta. + +La preferencia temporal — cuánto valoras el presente frente al futuro — es una propiedad humana, no una consecuencia del tipo de dinero que usas. Las personas seguirán consumiendo lo que necesitan. Lo que cambia es el incentivo a consumir lo que no necesitan a crédito. + +La deflación que históricamente ha sido devastadora — como la Gran Depresión — fue consecuencia de contracción crediticia, no de escasez monetaria programada. Son fenómenos distintos que con frecuencia se confunden. + +--- + +### Lo que Bitcoin no resuelve + +La honestidad intelectual obliga a reconocerlo. + +Bitcoin no elimina la desigualdad — quien llegó antes acumuló más cuando era casi gratuito. No elimina la volatilidad — su precio en fiat fluctúa enormemente. No es neutral — favorece estructuralmente a quienes ahorran frente a quienes gastan. + +Reconocer esos límites no debilita el argumento. Lo hace más honesto. + +--- + +### Vélo tú mismo + +Entra en [mempool.space](https://mempool.space) y busca el bloque más reciente. Verás el subsidio actual por bloque — 3,125 BTC tras el halving de 2024. Calcula cuántos bloques faltan para el próximo halving y cuándo ocurrirá aproximadamente. + +Esa información es pública, verificable y no depende de ninguna fuente externa. Está en la propia blockchain. + +--- + +### Resumen + +Bitcoin tiene una política monetaria predecible, verificable y prácticamente imposible de cambiar. Su escasez no es una promesa — es una regla que cualquier nodo puede verificar ahora mismo. + +La deflación que implica tiene ventajas reales para el ahorro y genera debates legítimos. Las críticas más serias merecen ser entendidas, no descartadas. + +Lo que hace diferente a Bitcoin no es que sea perfecto. Es que sus reglas son públicas y no dependen de la buena voluntad de ninguna institución. + +_Un dinero cuyas reglas no puede cambiar ningún gobierno es una proposición nueva en la historia humana._ + +--- + +_Con este capítulo concluye la Parte 2 — Intermedio._ + +--- + +## Glosario + +**Air-gap** — Dispositivo que nunca se conecta a internet ni a ningún ordenador por cable. Firma transacciones mediante códigos QR para eliminar cualquier vector de ataque digital. + +**Análisis de blockchain** — Técnica que usa heurísticas estadísticas para rastrear el flujo de fondos en la cadena de bloques e inferir relaciones entre direcciones. + +**BIP** — _Bitcoin Improvement Proposal_. Documento formal que propone un cambio o mejora al protocolo de Bitcoin. + +**Bisq** — Software descentralizado de intercambio P2P sin servidor central. + +**BTCPay Server** — Software libre para recibir pagos en bitcoin directamente, sin intermediarios ni custodia de terceros. + +**CoinJoin** — Técnica que combina los inputs de varias personas en una sola transacción con outputs del mismo importe, haciendo imposible rastrear qué input corresponde a qué output. + +**Corredor de nodos** — Operador que mantiene un nodo Lightning bien conectado con liquidez suficiente en múltiples canales para que los pagos puedan fluir por la red. Cobra fees de routing como compensación por ese servicio. + +**Descriptor** — Archivo que describe la configuración completa de una wallet multisig. Imprescindible para recuperar el acceso junto con las claves. + +**Heurística** — Patrón estadístico usado en análisis de blockchain para inferir relaciones entre direcciones. + +**Hodl-Hodl** — Plataforma P2P de intercambio de bitcoin no custodial que usa contratos multisig on-chain. + +**HTLC** — _Hashed Timelock Contract_. Contrato usado en Lightning Network que garantiza que un pago enrutado llega completo a su destino o se devuelve automáticamente al origen. + +**JoinMarket** — Implementación de CoinJoin sin coordinador central donde los participantes se organizan directamente en un mercado abierto. + +**KYC** — _Know Your Customer_. Requisito legal que obliga a los servicios financieros regulados a identificar a sus usuarios. + +**Liquidez entrante** — Bitcoin disponible en el lado del canal que apunta hacia ti. Determina cuánto puedes recibir a través de ese canal. + +**Liquidez saliente** — Bitcoin disponible en el lado del canal que apunta desde ti. Determina cuánto puedes enviar a través de ese canal. + +**Mostro** — Protocolo P2P de intercambio de bitcoin construido sobre Nostr. + +**Multisig** — _Multi-signature_. Mecanismo que requiere múltiples firmas para autorizar una transacción. + +**Onion routing** — Técnica de enrutamiento que cifra el pago en capas sucesivas, como una cebolla. Cada nodo intermediario solo puede descifrar su propia capa — ve el salto anterior y el siguiente, nunca el origen ni el destino final del pago. + +**Output de cambio** — Output que vuelve al remitente cuando el UTXO gastado tiene más valor del necesario. + +**p2plnbot** — Bot de Telegram que permite comprar y vender bitcoin sobre Lightning Network. Creado por negrunch. + +**Preferencia temporal** — Concepto económico que describe cuánto valoras el presente frente al futuro. + +**RoboSats** — Plataforma P2P de intercambio de bitcoin sobre Lightning Network con identidades efímeras. + +**Tor** — Red de anonimización que enruta el tráfico a través de múltiples nodos cifrados para ocultar la dirección IP del usuario. + +--- + +## Preguntas frecuentes + +**¿Bitcoin es realmente privado?** +No. Bitcoin es seudónimo — tu nombre no aparece en ninguna transacción, pero todo lo que haces con una dirección es público y permanente. Si alguien conecta tu identidad real con una dirección, tiene acceso a tu historial financiero completo. La privacidad hay que construirla activamente con buenas prácticas. + +**¿CoinJoin es legal?** +En la mayoría de países, sí. CoinJoin es una técnica de privacidad, no una herramienta para actividades ilegales. Algunos servicios tienen políticas propias sobre fondos que han pasado por CoinJoin. Eso es una decisión comercial de cada plataforma, no un indicador de ilegalidad. + +**¿Lightning es seguro?** +Sí, con matices. El protocolo está bien diseñado y lleva años funcionando en producción. Los riesgos principales son operativos — usar software sin mantenimiento activo, o confiar en servicios custodiales en lugar de gestionar tus propios canales. + +**¿Puedo perder bitcoin en un canal Lightning?** +En circunstancias muy específicas, sí. Si publicas un estado antiguo del canal intentando hacer trampa, puedes perder todos los fondos del canal. En uso normal y honesto, no hay riesgo de pérdida. + +**¿Es mejor comprar con o sin KYC?** +Depende de tus prioridades. Con KYC es más fácil y más rápido, pero creas un vínculo permanente entre tu identidad y tu actividad en Bitcoin. Sin KYC preservas la privacidad pero requiere más esfuerzo. + +**¿Qué pasa si el exchange donde compré bitcoin quiebra?** +Si no has retirado a tu propia wallet, ese bitcoin probablemente desaparece con el exchange. Ha ocurrido repetidamente — Mt. Gox, FTX, y muchos otros. Retira siempre a una wallet que controles tú. + +**¿Cuántas claves necesito en un multisig?** +El esquema más común y equilibrado es 2-de-3. Puedes perder una clave y seguir teniendo acceso, pero alguien que robe una sola no puede gastar nada. Lo más importante no es el esquema sino entenderlo completamente y tener el descriptor guardado junto a las claves. + +**¿El bitcoin en Lightning es menos seguro que el bitcoin on-chain?** +Es diferente, no necesariamente menos seguro. El bitcoin on-chain en cold storage tiene el nivel más alto de seguridad para almacenamiento a largo plazo. El bitcoin en Lightning está activo en canales — adecuado para pagos cotidianos. + +**¿Qué es una wallet custodial y por qué debería evitarla?** +Una wallet custodial es aquella donde otra empresa guarda tus claves privadas. Tienes un saldo en pantalla pero no controlas el bitcoin. Una wallet no custodial te da el control completo. Not your keys, not your coins. + +**¿Bitcoin es deflacionario? ¿Es eso malo?** +Bitcoin es potencialmente deflacionario por su oferta fija. Hay debate legítimo sobre si la deflación frena la economía. La deflación históricamente devastadora fue resultado de contracción crediticia, no de escasez monetaria programada como la de Bitcoin. + +**¿Puedo minar bitcoin desde casa?** +Sí, con dispositivos como Bitaxe. Las probabilidades de encontrar un bloque solo son muy bajas con hardware pequeño, pero no son cero. Más allá de la rentabilidad, minar desde casa contribuye a descentralizar el hashrate de la red. + +**¿Qué pasa si pierdo el descriptor de mi wallet multisig?** +Recuperar el acceso se vuelve muy difícil aunque tengas todas las claves físicas. El descriptor contiene la configuración exacta. Por eso es tan importante guardar copias del descriptor en cada ubicación donde tengas una clave. + +**¿Qué es un corredor de nodos y necesito serlo para usar Lightning?** +No. Para usar Lightning como usuario — enviar y recibir pagos — no necesitas gestionar canales ni liquidez. Puedes usar una wallet Lightning que lo gestiona por ti. Un corredor de nodos es quien mantiene la infraestructura que hace posible que esos pagos lleguen a su destino — un rol técnico con incentivos económicos reales, pero opcional para el usuario común. + +--- + +## Recursos + +- [learnmeabitcoin.com](https://learnmeabitcoin.com) — Greg Walker. Fuente técnica principal. +- [mempool.space](https://mempool.space) — Explorador de bloques en tiempo real. +- [amboss.space](https://amboss.space) — Grafo de la red Lightning. +- [bisq.network](https://bisq.network) — Exchange P2P descentralizado. +- [kycnot.me](https://kycnot.me) — Directorio de servicios sin KYC. +- [sparrowwallet.com](https://sparrowwallet.com) — Wallet de escritorio para multisig. diff --git a/es/bitcoin-03-tecnico.md b/es/bitcoin-03-tecnico.md new file mode 100644 index 0000000..9764c63 --- /dev/null +++ b/es/bitcoin-03-tecnico.md @@ -0,0 +1,2134 @@ +# Bitcoin — Parte 3: Técnico + +_Hecho desde la comunidad, para la comunidad hispanohablante_ +_Bitcoin Txoko_ + +--- + +## Índice + +``` + ▶ PARTE 3 — TÉCNICO + ──────────────────────────────────────────────── + + 01 Transacciones en profundidad .......... 7 + estructura raw · sighash · TXID · vbytes + + 02 Scripts ............................... 19 + pila · P2PKH · P2SH · P2TR · OP_CHECKSIGADD + + 03 Claves y direcciones .................. 31 + secp256k1 · ECDSA · Schnorr · HD wallets · paths + + 04 Bloques en profundidad ................ 45 + cabecera · version bits · bits · merkle · nonce + + 05 Mining técnico ........................ 57 + candidato · ancestor feerate · coinbase · Stratum V2 + + 06 La cadena de bloques técnico .......... 69 + reorganizaciones · 51% · soft fork · UASF · BIPs + + 07 SegWit ................................ 81 + maleabilidad · witness · BIP143 · wTXID · guerra + + 08 Taproot ............................... 95 + Schnorr · MAST · clave modificada · tapscript · activación + + 09 La red ................................ 109 + mensajes · handshake · propagación · compact blocks · Tor + + ──────────────────────────────────────────────── + Glosario .................................. 123 + Preguntas frecuentes ...................... 137 + Recursos .................................. 149 +``` + +--- + +## Capítulo 1 — Transacciones en profundidad + +**Nivel: Técnico** + +--- + +### Una transacción es datos + +En la Parte 1 vimos qué hace una transacción — mover bitcoin de una dirección a otra. Ahora vamos a ver qué es exactamente por dentro. + +Una transacción es una cadena de bytes. Nada más. Sin magia, sin formato propietario. Cualquier ordenador que entienda el protocolo puede leerla, verificarla y propagarla. + +``` + ┌─────────────────────────────────────────────────┐ + │ TRANSACCIÓN │ + ├─────────────────────────────────────────────────┤ + │ versión 4 bytes little-endian │ + ├─────────────────────────────────────────────────┤ + │ [marker] 1 byte 0x00 (solo SegWit) │ + │ [flag] 1 byte 0x01 (solo SegWit) │ + ├─────────────────────────────────────────────────┤ + │ nº inputs variable compact size │ + │ input_0 variable │ + │ input_1 variable │ + ├─────────────────────────────────────────────────┤ + │ nº outputs variable compact size │ + │ output_0 variable │ + │ output_1 variable │ + ├─────────────────────────────────────────────────┤ + │ [witness] variable (solo SegWit) │ + ├─────────────────────────────────────────────────┤ + │ locktime 4 bytes little-endian │ + └─────────────────────────────────────────────────┘ + campos en [ ] solo presentes en transacciones SegWit +``` + +--- + +### Una transacción real, campo a campo + +Aquí una transacción legacy real descompuesta en sus bytes: + +``` + 01000000 ← versión (1, little-endian) + 01 ← número de inputs (1) + + ── INPUT ────────────────────────────────────── + 9945a5a4...78 01000000 ← TXID (32 bytes, byte order natural) + ← VOUT (4 bytes, little-endian): output 1 + 6a ← tamaño del ScriptSig (106 bytes) + 47304402...ac ← ScriptSig (firma + clave pública) + fdffffff ← sequence + + ── OUTPUTS ───────────────────────────────────── + 02 ← número de outputs (2) + + e99e060000000000 ← amount output 0 (453.241 sats, little-endian) + 19 ← tamaño del ScriptPubKey (25 bytes) + 76a914...88ac ← ScriptPubKey (P2PKH) + + 0046c32300000000 ← amount output 1 (little-endian) + 19 ← tamaño del ScriptPubKey + 76a914...88ac ← ScriptPubKey (P2PKH) + + 00000000 ← locktime (0, sin restricción) +``` + +Todo lo que Bitcoin hace — mover valor, establecer condiciones, probar propiedad — está codificado en esa secuencia de bytes. No hay nada más. + +--- + +### El input por dentro + +``` + ┌─────────────────────────────────────────────────┐ + │ INPUT │ + ├─────────────────────────────────────────────────┤ + │ TXID 32 bytes natural byte order │ + │ VOUT 4 bytes little-endian │ + │ ScriptSig variable compact size + script │ + │ Sequence 4 bytes little-endian │ + └─────────────────────────────────────────────────┘ + + TXID + VOUT = puntero único a un output concreto + en toda la blockchain +``` + +Un detalle importante: el TXID se almacena en **natural byte order** — el mismo orden en que aparece en exploradores de bloques. Es una excepción al little-endian que usa el resto de campos. + +El campo **Sequence** tiene dos usos. Si vale `0xFFFFFFFD` o menos, señaliza que la transacción puede ser reemplazada por otra con fee más alta — esto es RBF. Con versión 2 de transacción, los valores bajos de sequence activan **timelocks relativos** — el output no puede gastarse hasta que hayan pasado N bloques desde que fue minado. + +--- + +### El output por dentro + +``` + ┌─────────────────────────────────────────────────┐ + │ OUTPUT │ + ├─────────────────────────────────────────────────┤ + │ Amount 8 bytes little-endian (satoshis) │ + │ ScriptPubKey variable compact size + script │ + └─────────────────────────────────────────────────┘ +``` + +El Amount se expresa siempre en satoshis — nunca en BTC. 1 BTC se almacena como `00e1f50500000000` en little-endian. Amount igual a cero es válido — se usa en outputs `OP_RETURN` para incrustar datos en la blockchain sin mover valor. + +--- + +### Cómo se firma una transacción + +Firmar una transacción es lo que prueba que tienes derecho a gastar un output. El proceso tiene más pasos de lo que parece. + +Para firmar, el nodo no usa la transacción tal como está. Construye una versión especial para el hash que se va a firmar — el **sighash**. En el caso más común (SIGHASH_ALL): + +``` + 1. toma la transacción completa + 2. vacía todos los ScriptSig de todos los inputs + 3. pone el ScriptPubKey del output que se va a gastar + en el ScriptSig del input que se está firmando + 4. añade el sighash type (01000000 para SIGHASH_ALL) + 5. SHA256(SHA256(resultado)) → hash a firmar + 6. ECDSA(clave privada, hash) → firma (r, s) + 7. codifica en DER + append del sighash type byte +``` + +``` + SIGHASH_ALL (01) firma todos los inputs y outputs + la tx completa no puede modificarse + + SIGHASH_NONE (02) firma inputs · no firma outputs + cualquiera puede añadir outputs + + SIGHASH_SINGLE (03) firma inputs · solo firma output + con mismo índice que el input + + SIGHASH_ANYONECANPAY puede combinarse con los anteriores + (bit 0x80) solo firma el propio input + otros pueden añadir más inputs +``` + +El tipo más común es SIGHASH_ALL. Los otros tipos permiten construcciones más complejas — transacciones donde múltiples personas firman independientemente, o donde el destino queda abierto. + +--- + +### El TXID y el wTXID + +``` + TXID: + SHA256(SHA256( + versión + inputs(con ScriptSig) + outputs + locktime + )) + → witness NO entra en el cálculo + → modificar witness no cambia el TXID ← eso resuelve SegWit + + wTXID: + SHA256(SHA256( + versión + marker + flag + inputs + outputs + witness + locktime + )) + → incluye todos los campos + → usado para el merkle root del witness commitment + en la coinbase transaction +``` + +La distinción entre TXID y wTXID no es solo técnica. Es la base sobre la que se construye Lightning Network — los canales necesitan TXIDs estables para poder referenciar transacciones de compromiso que todavía no han sido publicadas. + +--- + +### Tamaño, peso y vbytes + +Una transacción tiene tres medidas de tamaño distintas y las tres aparecen en exploradores de bloques: + +``` + BYTES tamaño raw en disco · todos los bytes × 1 + + WEIGHT bytes normales × 4 + bytes de witness × 1 + límite del bloque: 4.000.000 wu + + VBYTES weight / 4 + usado para comparar fees entre txs legacy y SegWit + fee rate se expresa en sat/vbyte + + ejemplo transacción P2WPKH típica: + ┌─────────────────────────────────────────┐ + │ 116 bytes no-witness × 4 = 464 wu │ + │ 110 bytes witness × 1 = 110 wu │ + │ total weight = 574 wu │ + │ vbytes = 143,5 vb │ + └─────────────────────────────────────────┘ + misma transacción en legacy: ~190 bytes = 760 wu + SegWit es ~25% más eficiente en términos de peso +``` + +--- + +### Locktime + +``` + locktime = 0 puede minarse en cualquier bloque + locktime < 500.000.000 altura de bloque mínima para minar + locktime ≥ 500.000.000 timestamp Unix mínimo para minar + + condición adicional: al menos un input debe tener + sequence < 0xFFFFFFFE + si todos los inputs tienen sequence = 0xFFFFFFFF + el locktime se ignora + + como un cheque posfechado: + válido · firmado · pero no cobrable hasta la fecha indicada +``` + +--- + +### Verifica tú mismo + +Entra en [learnmeabitcoin.com/tools/transaction-decoder](https://learnmeabitcoin.com/tools/transaction-decoder) y pega cualquier transacción en raw. Verás cada campo desglosado y etiquetado con su valor decodificado. + +Para obtener una transacción en raw desde tu propio nodo: + +``` +bitcoin-cli getrawtransaction [TXID] true +``` + +Busca en el output el campo `hex` — esa es la transacción en bytes crudos. Luego decódificala en el explorador y relaciona cada fragmento hexadecimal con su campo correspondiente. + +--- + +### Resumen + +Una transacción es una secuencia precisa de bytes: versión, inputs, outputs, witness opcional y locktime. Cada input referencia un output anterior con TXID y VOUT. Firmar requiere construir un sighash — una versión especial de la transacción que se hashea y firma con ECDSA. El TXID excluye el witness, lo que hace los identificadores estables ante modificaciones de firma. El tamaño en vbytes aplica el descuento del witness para calcular fees de forma uniforme. + +_Una transacción no es una orden a ningún banco. Es un dato matemáticamente válido que cualquier nodo del mundo puede verificar de forma completamente independiente._ + +--- + +> Los inputs y outputs tienen scripts — código que define las condiciones de gasto. Entender esos scripts es entender cómo Bitcoin bloquea y desbloquea el valor. + +--- + +## Capítulo 2 — Scripts + +**Nivel: Técnico** + +--- + +### Bitcoin no transfiere monedas + +Bitcoin no mueve monedas de una dirección a otra. Lo que hace es resolver un problema y crear uno nuevo. + +Cada output lleva un **candado** — un ScriptPubKey que define las condiciones para poder gastarlo. Gastar ese output significa aportar el ScriptSig o datos witness que satisfacen esas condiciones. + +``` + OUTPUT (candado) INPUT (llave) + ┌────────────────┐ ┌────────────────┐ + │ ScriptPubKey │ │ ScriptSig / │ + │ │ │ Witness │ + │ condiciones │◀──cumple───│ datos para │ + │ de gasto │ │ desbloquear │ + └────────────────┘ └────────────────┘ + + nodo ejecuta ScriptSig + ScriptPubKey + si el resultado deja TRUE en la pila → válido +``` + +--- + +### Script: un lenguaje de pila + +Script es el lenguaje de programación de Bitcoin. Opera sobre una **pila** — una estructura de datos donde los elementos se apilan y se sacan en orden inverso (LIFO). Cada opcode empuja datos o ejecuta una operación sobre los elementos de la pila. + +Es deliberadamente limitado — no tiene bucles, no es Turing completo. Eso lo hace predecible y verificable en tiempo constante. + +``` + pila vacía → empuja datos → ejecuta opcode → resultado + + [ ] → [firma] [pubkey] → OP_CHECKSIG → [TRUE] + ↑ + output desbloqueado +``` + +--- + +### P2PKH: ejecución paso a paso + +**P2PKH** — _Pay to Public Key Hash_ — es el script detrás de las direcciones `1...`. Ver su ejecución completa es entender cómo funciona Script. + +``` + ScriptSig: [firma] [clave pública] + ScriptPubKey: OP_DUP OP_HASH160 [hash160] OP_EQUALVERIFY OP_CHECKSIG + + ejecución: + ┌────────────────────────────────────────────────────┐ + │ inicio: pila = [ ] │ + │ ScriptSig empuja datos: │ + │ pila = [firma] [pubkey] │ + │ │ + │ OP_DUP: duplica el tope │ + │ pila = [firma] [pubkey] [pubkey] │ + │ │ + │ OP_HASH160: SHA256 + RIPEMD160 del tope │ + │ pila = [firma] [pubkey] [hash(pubkey)]│ + │ │ + │ [hash160]: empuja el hash del ScriptPubKey │ + │ pila = [firma] [pubkey] [hash(pk)] │ + │ [hash esperado] │ + │ │ + │ OP_EQUALVERIFY: compara los dos topes │ + │ si no coinciden → fallo inmediato │ + │ pila = [firma] [pubkey] │ + │ │ + │ OP_CHECKSIG: verifica firma contra pubkey │ + │ pila = [TRUE] │ + └────────────────────────────────────────────────────┘ + resultado: TRUE → output desbloqueado +``` + +--- + +### Comparativa de scripts estándar + +``` + tipo ScriptPubKey unlock via + ────────────────────────────────────────────────────────── + P2PK [pubkey] OP_CHECKSIG ScriptSig + P2PKH OP_DUP OP_HASH160 <20b> OP_EQ... ScriptSig + P2MS OP_M [pubkeys] OP_N OP_CHECKMULTISIG ScriptSig + P2SH OP_HASH160 <20b> OP_EQUAL ScriptSig + P2WPKH OP_0 <20b> Witness + P2WSH OP_0 <32b> Witness + P2TR OP_1 <32b> Witness + OP_RETURN OP_RETURN no gastable +``` + +--- + +### P2SH: el script que esconde scripts + +P2SH resuelve un problema de tamaño. Antes de P2SH, un multisig 2-de-3 requería que quien pagara incluyera las tres claves públicas en el ScriptPubKey — caro para el remitente, visible para todos. + +Con P2SH, el output solo guarda el hash del script. El script real se revela al gastar. + +``` + CREAR OUTPUT: + redeemScript = OP_2 [pubkey1] [pubkey2] [pubkey3] OP_3 OP_CHECKMULTISIG + ScriptPubKey = OP_HASH160 hash160(redeemScript) OP_EQUAL + → 23 bytes · complejidad invisible hasta el gasto + + GASTAR: + ScriptSig = OP_0 [firma1] [firma2] [redeemScript] + → se revela el script · se verifica hash · se ejecuta + + ventaja: quien crea el output no paga por la complejidad + coste lo asume quien gasta +``` + +--- + +### P2MS y el bug de OP_CHECKMULTISIG + +El multisig legacy tiene un bug histórico. `OP_CHECKMULTISIG` extrae un elemento más de la pila de lo necesario — un error off-by-one que Satoshi nunca corrigió para no romper compatibilidad. + +``` + ScriptSig correcto para 2-de-3: + OP_0 [firma1] [firma2] + ↑ + dummy value obligatorio + OP_CHECKMULTISIG lo consume pero no lo usa + si no está → fallo de script +``` + +Este bug tiene implicaciones de privacidad: todo multisig legacy es identificable en la blockchain. Taproot lo resuelve por completo. + +--- + +### P2TR: dos caminos de gasto + +P2TR es el script más flexible de Bitcoin. Un output P2TR puede gastarse de dos formas completamente distintas — y la elección del camino no es visible desde fuera hasta que se gasta. + +``` + ScriptPubKey: OP_1 [tweaked pubkey 32 bytes] + + ┌─────────────────────────────────────────────────┐ + │ KEY PATH SPEND SCRIPT PATH SPEND │ + │ │ + │ witness: witness: │ + │ [firma Schnorr] [script inputs] │ + │ (64 bytes) [leaf script] │ + │ [control block] │ + │ │ + │ 1 elemento 3+ elementos │ + │ indistinguible de revela el script usado │ + │ pago simple otros scripts ocultos │ + └─────────────────────────────────────────────────┘ + + el nodo decide qué path usar + según cuántos elementos hay en el witness +``` + +El key path es el caso ideal — una firma Schnorr de 64 bytes, sin revelar ninguna condición adicional. Un canal Lightning cerrado cooperativamente, un multisig donde todos están de acuerdo, un contrato que expira bien — todo se ve igual desde fuera. + +El script path se usa cuando el key path no es posible — disputa en un canal, timeout de un contrato, condición alternativa. Revela el script usado pero mantiene ocultos todos los demás. + +--- + +### OP_CHECKSIGADD: multisig nativo en Taproot + +El multisig legacy usa `OP_CHECKMULTISIG` con su bug histórico. Taproot introduce `OP_CHECKSIGADD` — una forma limpia de construir multisig sin bugs y más eficiente. + +``` + MULTISIG LEGACY (P2MS / P2SH) + OP_2 [key1] [key2] [key3] OP_3 OP_CHECKMULTISIG + → bug del dummy value + → identifica multisig en la blockchain + → todas las claves visibles al gastar + + MULTISIG TAPROOT (tapscript con OP_CHECKSIGADD) + [key1] OP_CHECKSIG + [key2] OP_CHECKSIGADD + [key3] OP_CHECKSIGADD + OP_2 OP_EQUAL + + ejecución para 2-de-3 con [sig1] [sig3]: + key1 OP_CHECKSIG → válida → [1] + key2 OP_CHECKSIGADD → inválida → [1] + key3 OP_CHECKSIGADD → válida → [2] + OP_2 OP_EQUAL → 2 = 2 → TRUE +``` + +La ventaja sobre el legacy: sin dummy value, sin bug, las firmas ausentes son ignoradas en orden. Y si se usa vía key path con agregación de firmas Schnorr, el multisig es completamente invisible desde fuera. + +--- + +### Verifica tú mismo + +Entra en [mempool.space](https://mempool.space) y busca cualquier transacción reciente. Haz clic sobre cualquier output y verás su ScriptPubKey. Identifica el tipo por su patrón: + +``` + OP_DUP OP_HASH160 ... → P2PKH (dirección 1...) + OP_HASH160 ... OP_EQUAL → P2SH (dirección 3...) + OP_0 + 20 bytes → P2WPKH (dirección bc1q... corta) + OP_0 + 32 bytes → P2WSH (dirección bc1q... larga) + OP_1 + 32 bytes → P2TR (dirección bc1p...) + OP_RETURN → datos (no gastable) +``` + +Para ver un script path spend de Taproot en acción busca la transacción `797505b104b5fb840931c115ea35d445eb1f64c9279bf23aa5bb4c3d779da0c2` — verás el witness con tres elementos: script inputs, leaf script y control block. + +--- + +### Resumen + +Script es un lenguaje de pila que define las condiciones de gasto en Bitcoin. P2PKH evalúa hash de clave y verifica firma. P2SH oculta la complejidad hasta el gasto. P2TR ofrece dos caminos: key path con firma Schnorr invisible, o script path que revela solo la condición usada. `OP_CHECKSIGADD` reemplaza el multisig legacy sin sus bugs históricos. + +_Bitcoin no sabe quién eres. Solo sabe si has resuelto el puzzle. Y cuanto más sofisticado es el puzzle, menos revela quién lo resolvió._ + +--- + +> Los scripts de bloqueo usan claves públicas y sus hashes. Pero ¿cómo se generan esas claves? ¿Qué matemáticas hay detrás y cómo se organizan en un árbol de derivación? + +--- + +## Capítulo 3 — Claves y direcciones + +**Nivel: Técnico** + +--- + +### Todo empieza con un número aleatorio + +Una clave privada es un número entre 1 y 2²⁵⁶ — generado en tu dispositivo, sin servidor, sin registro. El espacio de claves es tan grande que generar la misma clave dos veces es astronómicamente improbable. + +``` +Ejemplo de clave privada en hexadecimal: +ef235aacf90d9f4aadd8c92e4b2562e1d9eb97f0df9ba3b508258739cb013db2 +``` + +--- + +### La curva elíptica secp256k1 + +La clave pública se deriva multiplicando la clave privada por el **punto generador G** de la curva `secp256k1` — definida por `y² = x³ + 7`. + +``` + clave privada k → clave pública P = k × G + + k × G no es multiplicación aritmética ordinaria + es adición repetida de un punto sobre la curva elíptica + + dado P, calcular k es el problema del logaritmo discreto + computacionalmente inviable con los medios actuales +``` + +La clave pública es un punto `(x, y)` en la curva. En formato comprimido se almacena solo la coordenada `x` más un prefijo que indica la paridad de `y`: + +``` + punto en la curva: (x, y) + + y par: 02 + x (32 bytes) = 33 bytes total + y impar: 03 + x (32 bytes) = 33 bytes total + + la coordenada y se puede recalcular desde x + → no hace falta almacenarla completa +``` + +--- + +### Pipeline completo de derivación de dirección + +``` + clave privada (32 bytes) + │ k × G (multiplicación en curva elíptica) + ▼ + clave pública comprimida (33 bytes) + │ SHA256 + ▼ + hash intermedio (32 bytes) + │ RIPEMD160 + ▼ + hash160 de clave pública (20 bytes) ← HASH160 + │ + │ según tipo de dirección: + ├── P2PKH: versión 0x00 + hash160 → Base58Check → 1... + ├── P2SH: versión 0x05 + hash160 → Base58Check → 3... + ├── P2WPKH: OP_0 + hash160 → Bech32 → bc1q... (corta) + └── P2TR: OP_1 + x-only pubkey → Bech32m → bc1p... +``` + +P2TR es la excepción — no usa el hash de la clave pública sino la clave pública directamente en formato x-only de 32 bytes, ya modificada con el tweak de Taproot. + +--- + +### Firmas ECDSA + +``` + FIRMAR + ┌────────────────────────────────────────┐ + │ inputs: clave privada k │ + │ hash de la tx H │ + │ nonce aleatorio r (secreto) │ + │ │ + │ r = (r × G).x mod n │ + │ s = r⁻¹ × (H + k × r) mod n │ + │ │ + │ output: firma (r, s) en formato DER │ + └────────────────────────────────────────┘ + + VERIFICAR + ┌────────────────────────────────────────┐ + │ inputs: clave pública P │ + │ hash de la tx H │ + │ firma (r, s) │ + │ │ + │ u1 = H × s⁻¹ mod n │ + │ u2 = r × s⁻¹ mod n │ + │ punto = u1 × G + u2 × P │ + │ │ + │ válido si punto.x mod n = r │ + └────────────────────────────────────────┘ + la clave privada nunca sale del dispositivo + cualquier nodo verifica con la clave pública +``` + +El nonce `r` debe ser diferente en cada firma. Si se reutiliza el mismo nonce para dos transacciones distintas, la clave privada queda expuesta matemáticamente. Es una de las vulnerabilidades más graves en la práctica. + +--- + +### Schnorr: lineal y agregable + +Taproot introduce **firmas Schnorr** como alternativa a ECDSA. La diferencia clave es la linealidad — varias firmas pueden combinarse matemáticamente en una sola. + +``` + ECDSA (r, s): no lineal · no agregable · 71-72 bytes DER + Schnorr (R, s): lineal · agregable · 64 bytes + + agregación Schnorr para multisig: + claves: P1, P2, P3 + nonces: R1, R2, R3 → R = R1 + R2 + R3 + firmas: s1, s2, s3 → s = s1 + s2 + s3 + + resultado: una firma (R, s) de 64 bytes + indistinguible de un pago simple de una sola persona +``` + +--- + +### HD wallets: un árbol de claves desde una semilla + +Una HD wallet (_Hierarchical Deterministic_) deriva todas sus claves desde una única semilla maestra. La semilla se genera desde la seed phrase mediante PBKDF2, y desde ella se deriva la clave maestra con HMAC-SHA512. + +``` + seed phrase (12/24 palabras) + │ PBKDF2 (2048 iteraciones) + ▼ + seed (512 bits) + │ HMAC-SHA512 + ▼ + clave maestra privada (m) + chain code + │ + │ derivación de hijos + ▼ + árbol de claves extendidas (xprv/xpub) +``` + +Cada **clave extendida** tiene dos variantes: privada (`xprv`) para firmar, pública (`xpub`) para derivar direcciones de recepción sin exponer claves privadas. Eso permite, por ejemplo, generar todas las direcciones de recepción en un servidor sin poner las claves privadas en ese servidor. + +--- + +### Derivation paths: la dirección exacta de cada clave + +La estructura estándar, definida por BIP44, es: + +``` + m / purpose' / coin_type' / account' / change / index + + cada segmento: + m clave maestra + purpose' esquema de derivación (hardened) + coin_type' tipo de moneda (hardened) + account' cuenta separada (hardened) + change 0 = recepción · 1 = cambio (normal) + index índice de la dirección (normal, empieza en 0) + + ' = hijo hardened (índice + 2.147.483.648) + solo derivable desde clave privada + protege la clave maestra si un xpub se compromete +``` + +Los paths estándar para Bitcoin según tipo de dirección: + +``` + BIP44 m/44'/0'/0'/0/0 → P2PKH dirección 1... + BIP49 m/49'/0'/0'/0/0 → P2SH-P2WPKH dirección 3... + BIP84 m/84'/0'/0'/0/0 → P2WPKH dirección bc1q... + BIP86 m/86'/0'/0'/0/0 → P2TR dirección bc1p... +``` + +--- + +### Un path anotado carácter a carácter + +``` + m / 84' / 0' / 0' / 0 / 5 + + m → clave maestra privada + 84' → purpose: BIP84 (P2WPKH, bc1q) + hardened: solo derivable con clave privada + 0' → coin type: Bitcoin mainnet + hardened + 0' → cuenta número 0 + hardened · "pot" separado de fondos + 0 → external chain (recepción) + normal: xpub puede derivar estas claves + (útil para watch-only wallets) + 5 → sexta dirección generada (índice empieza en 0) + la que se entrega al pagador +``` + +Si el índice change fuera `1` en lugar de `0`, sería la sexta dirección de cambio — la que la wallet usa para devolverte el cambio de tus propias transacciones. + +--- + +### Gap limit + +Las wallets no derivan claves infinitamente. Siguen el **gap limit** — por defecto 20 direcciones consecutivas sin uso. Si al escanear la blockchain las 20 siguientes direcciones están vacías, la wallet asume que no hay más fondos en esa rama. + +``` + índices: 0 1 2 3 4 5 6 7 ... 25 26 + uso: ✓ ✓ ✗ ✓ ✗ ✗ ✗ ✗ ... ✗ ✗ + + gap de 20 consecutivas sin uso → wallet detiene la búsqueda + si saltaste índices al generar claves manualmente + → fondos en índices > gap pueden no aparecer al recuperar +``` + +--- + +### Verifica tú mismo + +Entra en [iancoleman.io/bip39](https://iancoleman.io/bip39) — sin conexión a internet — y genera una seed phrase de prueba. Cambia el path a `m/84'/0'/0'` y observa cómo se derivan las claves y direcciones bc1q. Cambia el índice de change de 0 a 1 y observa cómo aparecen las direcciones de cambio. + +Luego prueba `m/86'/0'/0'` para ver las direcciones Taproot bc1p derivadas del mismo seed. + +--- + +### Resumen + +La clave privada es un número aleatorio. La clave pública es un punto en secp256k1. ECDSA firma con clave privada y verifica con clave pública — el nonce nunca debe repetirse. Schnorr permite agregar firmas en una sola. Las HD wallets derivan todo desde una semilla mediante árboles de claves extendidas. Los derivation paths son la dirección exacta de cada clave en ese árbol — purpose, coin, account, change e index. + +_La seed phrase no es una contraseña. Es una llave maestra que genera un universo de claves. Entender su estructura es entender exactamente qué se pierde cuando se pierde._ + +--- + +> Las claves y sus derivaciones definen quién puede gastar qué. Esos gastos se agrupan en bloques. ¿Qué hay exactamente dentro de un bloque a nivel técnico? + +--- + +## Capítulo 4 — Bloques en profundidad + +**Nivel: Técnico** + +--- + +### Un bloque es una cabecera y una lista de transacciones + +``` + ┌─────────────────────────────────────────────────┐ + │ CABECERA DE BLOQUE (80 bytes exactos) │ + ├──────────────┬──────────────────────────────────┤ + │ versión │ 4 bytes little-endian │ + │ prev block │ 32 bytes natural byte order │ + │ merkle root │ 32 bytes natural byte order │ + │ time │ 4 bytes little-endian │ + │ bits │ 4 bytes little-endian │ + │ nonce │ 4 bytes little-endian │ + └──────────────┴──────────────────────────────────┘ + hash(cabecera) = SHA256(SHA256(80 bytes)) + debe ser < target para ser válido +``` + +Los 80 bytes exactos de la cabecera no son un detalle arbitrario. Los nodos ligeros (SPV) solo descargan cabeceras — 80 bytes por bloque en lugar de 1-2 MB. Con más de 880.000 bloques, eso es la diferencia entre ~70 MB y ~1,5 TB. + +--- + +### El campo versión y la señalización de soft forks + +El campo versión empezó siendo un entero simple. Desde BIP9 en 2015 se interpreta como un **campo de bits** donde cada bit puede asignarse a una propuesta de upgrade diferente. + +``` + versión en bits (32 bits): + 0b 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 + │ │ │ + │ │ └── bits 0-28: señalización de upgrades + │ └──── bit 29: reservado + └────── bits 30-31: deben ser 001 (BIP9) + + 0x20000000 versión por defecto · sin señalizar nada + 0x20000002 señalizando SegWit (bit 1 activo) + 0x20000004 señalizando Taproot (bit 2 activo) + + los mineros también usan bits no asignados como extranonce + → versiones "raras" en bloques recientes son normales +``` + +--- + +### El campo bits: target en formato compacto + +El campo `bits` es una representación compacta del target en 4 bytes. Su estructura: + +``` + bits: 1705dd01 (ejemplo) + ──┬───── + │ + primer byte: 17 (hex) = 23 (decimal) = exponente + siguientes 3: 05dd01 = coeficiente + + target = coeficiente × 256^(exponente - 3) + = 0x05dd01 × 256^(23-3) + = 0x05dd01 × 256^20 + = 000000000000000005dd01000000000000000000000000000000000000000000 + + el hash del bloque debe ser menor que ese número + → cuantos más ceros al inicio, más difícil +``` + +El target completo tiene 32 bytes pero el campo bits solo almacena 4 — pierde precisión. Esa pérdida de precisión es deliberada e irrelevante en la práctica: la diferencia entre el target exacto y el aproximado es mínima comparada con el espacio de búsqueda de hashes. + +--- + +### El árbol de Merkle + +El merkle root resume todas las transacciones del bloque en 32 bytes. Su construcción: + +``` + transacciones: tx_A tx_B tx_C tx_D + + nivel 1 (hojas): H(A) H(B) H(C) H(D) + │ │ │ │ + nivel 2: H(AB) H(CD) + │ │ + merkle root: H(ABCD) + + si el número de txs es impar: + el último hash se duplica antes de combinar + H(CC) en lugar de un par faltante +``` + +Modificar cualquier transacción cambia su hash, lo que cambia el hash del nivel superior, lo que cambia el merkle root, lo que invalida la cabecera. La integridad de todas las transacciones queda comprometida en esos 32 bytes de la cabecera. + +--- + +### Prueba de Merkle para nodos ligeros + +El árbol de Merkle tiene una segunda utilidad crucial: permite demostrar que una transacción concreta está en un bloque sin descargar todas las transacciones. + +``` + ¿está tx_C en el bloque? + + solo necesitas: + H(C) + H(D) + H(AB) + merkle root del bloque + + verificación: + H(C) + H(D) → H(CD) + H(AB) + H(CD) → H(ABCD) + ¿H(ABCD) = merkle root de la cabecera? → SÍ + + datos transferidos: 3 hashes × 32 bytes = 96 bytes + en lugar de descargar el bloque completo (~1 MB) +``` + +Esto es la base del SPV — _Simplified Payment Verification_ — que usan las wallets móviles. Confían en los hashes de bloque sin verificar todas las transacciones. + +--- + +### Nonce y extranonce + +El nonce es el campo que los mineros modifican para variar el hash de la cabecera sin tocar las transacciones. + +``` + nonce: 4 bytes → 2^32 = 4.294.967.296 valores posibles + + hashrate actual de la red: ~800 EH/s + = 800 × 10^18 hashes por segundo + + 4.294.967.296 intentos se agotan en: + 4.294.967.296 / (800 × 10^18) ≈ 0,000000005 segundos + + el nonce se agota casi instantáneamente + → necesidad del extranonce en la coinbase tx + + flujo cuando se agota el nonce: + ┌──────────────────────────────────────┐ + │ 1. nonce de 0 a 0xFFFFFFFF → agotado│ + │ 2. incrementar extranonce │ + │ en ScriptSig de coinbase tx │ + │ 3. cambia TXID de coinbase │ + │ 4. cambia merkle root │ + │ 5. nueva cabecera de 80 bytes │ + │ 6. nuevo espacio de 4.294.967.296 │ + └──────────────────────────────────────┘ +``` + +--- + +### El timestamp y sus límites + +El campo `time` de la cabecera tiene reglas específicas que los nodos verifican: + +``` + time válido: + > mediana de los últimos 11 bloques (MTP) + < tiempo del nodo + 2 horas + + no puede ser anterior a los 11 bloques previos + no puede ser más de 2 horas en el futuro + + consecuencia: el timestamp de un bloque no es exacto + puede estar hasta 2 horas adelantado + puede retroceder respecto al bloque anterior + solo la mediana de 11 bloques es confiable +``` + +--- + +### Verifica tú mismo + +Entra en [mempool.space](https://mempool.space) y busca cualquier bloque reciente. Haz clic en “Details” para ver la cabecera raw. Identifica los seis campos e intenta decodificar el campo `bits` — extrae el exponente (primer byte) y el coeficiente (siguientes 3 bytes) y calcula el target aproximado. + +Busca también el bloque génesis — altura 0. Su campo `previous block` son 32 bytes de ceros. No hay nada antes que él. + +Desde tu propio nodo: + +``` +bitcoin-cli getblockheader [hash] true +``` + +--- + +### Resumen + +Un bloque es una cabecera de 80 bytes más transacciones. El campo versión señaliza soft forks mediante bits individuales. El campo bits codifica el target en 4 bytes con el esquema exponente-coeficiente. El merkle root compromete todas las transacciones en 32 bytes y permite pruebas de inclusión eficientes para nodos ligeros. El nonce se agota casi instantáneamente — el extranonce en la coinbase es el mecanismo real de variación. + +_Un bloque válido es la prueba de que alguien gastó energía real buscando exactamente ese hash. Eso es lo que hace que falsificarlo sea prohibitivamente caro._ + +--- + +> Sabemos cómo está estructurado un bloque. Lo que falta es ver cómo se construye uno desde cero — qué decisiones toma un minero antes de empezar a hacer hashes. + +--- + +## Capítulo 5 — Mining técnico + +**Nivel: Técnico** + +--- + +### Antes de minar hay que construir + +Un **bloque candidato** es el bloque que un minero intenta añadir a la blockchain. No hay un único bloque candidato que todos los mineros compartan — cada minero construye el suyo desde su propia mempool. Puede haber diferencias menores entre candidatos, pero la mayoría de transacciones se solapan. + +``` + MEMPOOL (transacciones sin confirmar) + ordenadas por ancestor feerate (sat/vbyte) + │ + │ minero selecciona + ▼ + ┌─────────────────────────────────────┐ + │ BLOQUE CANDIDATO │ + ├─────────────────────────────────────┤ + │ 1. coinbase tx (recompensa) │ ← siempre primera + │ 2. tx con ancestor feerate mayor │ + │ 3. siguiente por feerate │ + │ ... │ + │ N. última tx que cabe │ ← límite 4M weight units + └─────────────────────────────────────┘ + padres siempre antes que hijos + tx inválida en el bloque → bloque rechazado por la red +``` + +--- + +### Ancestor feerate: el orden real de selección + +Un minero no selecciona transacciones solo por su feerate individual. Si una transacción de fee baja tiene un hijo con fee muy alta, el minero las evalúa juntas — el **ancestor feerate** es la fee combinada de la transacción y todos sus ancestros pendientes dividida entre su tamaño combinado. + +``` + tx_padre: 2 sat/vbyte · 100 vbytes · fee: 200 sats + tx_hijo: 18 sat/vbyte · 100 vbytes · fee: 1800 sats + + ancestor feerate del hijo: + (200 + 1800) / (100 + 100) = 10 sat/vbyte + + el minero los incluye juntos como paquete + el hijo arrastra al padre aunque el padre tenga fee baja + → técnica de fee bumping: CPFP (Child Pays For Parent) +``` + +--- + +### La coinbase transaction por dentro + +``` + ┌─────────────────────────────────────────────────┐ + │ COINBASE TX │ + ├─────────────────────────────────────────────────┤ + │ INPUT: │ + │ TXID: 0000...0000 (32 bytes ceros) │ + │ VOUT: 0xFFFFFFFF (índice especial) │ + │ ScriptSig: altura de bloque (BIP34) │ + │ + extranonce del minero │ + │ + datos arbitrarios (hasta 100b) │ + ├─────────────────────────────────────────────────┤ + │ OUTPUT principal: │ + │ subsidio: 3,125 BTC (tras halving 2024) │ + │ + suma de fees de todas las txs del bloque │ + ├─────────────────────────────────────────────────┤ + │ OUTPUT witness commitment (SegWit): │ + │ OP_RETURN + merkle root de wTXIDs │ + └─────────────────────────────────────────────────┘ + única tx sin inputs reales · bitcoin creado desde cero + no puede gastarse hasta 100 bloques después (coinbase maturity) +``` + +El output de witness commitment es obligatorio en bloques con transacciones SegWit — compromete todos los wTXIDs del bloque en un OP_RETURN de la coinbase, sellando los datos witness de todas las transacciones. + +--- + +### El cálculo del nuevo target + +Cada 2016 bloques cada nodo recalcula el target de forma independiente: + +``` + nuevo target = target actual × (tiempo real / tiempo esperado) + + tiempo esperado = 2016 bloques × 10 min = 20.160 minutos + + ejemplo: + bloques minados en 12 días (17.280 min) en lugar de 14: + nuevo target = target × (17.280 / 20.160) + = target × 0,857 + → target más bajo → más difícil + + ejemplo contrario, minados en 16 días (23.040 min): + nuevo target = target × (23.040 / 20.160) + = target × 1,142 + → target más alto → más fácil + + límite de ajuste: máximo ×4 o ÷4 en un solo periodo + evita oscilaciones bruscas si el hashrate cambia radicalmente +``` + +Todos los nodos calculan exactamente el mismo resultado porque comparten la misma blockchain. No hay coordinación — es aritmética determinista sobre datos compartidos. + +--- + +### Pool mining vs solo mining: la matemática real + +``` + POOL MINING SOLO MINING + ┌─────────────────────┐ ┌─────────────────────┐ + │ hashrate pool: │ │ Bitaxe S21: │ + │ ~100 EH/s │ │ ~4 TH/s │ + │ │ │ │ + │ bloque cada ~10 min │ │ prob. bloque/día: │ + │ recompensa dividida │ │ 4×10¹²/ │ + │ entre participantes │ │ (800×10¹⁸ × 600) │ + │ según hashrate │ │ ≈ 1 en 120.000.000 │ + │ aportado │ │ días (~330.000 años)│ + └─────────────────────┘ └─────────────────────┘ + ingresos predecibles lotería matemáticamente justa + varianza mínima varianza máxima +``` + +La lotería es honesta porque cada hash tiene exactamente la misma probabilidad de ser válido independientemente de quién lo genere. El protocolo no discrimina por tamaño. + +--- + +### Stratum: el protocolo de los pools + +Los pools se comunican con sus mineros mediante el protocolo **Stratum**. El pool distribuye trabajo a cada minero con un rango de nonces asignado — así miles de mineros pueden trabajar en paralelo sin repetir intentos. + +``` + pool → minero: "trabaja en este bloque candidato + con nonces en el rango X-Y" + + minero → pool: "encontré un hash por debajo + del target del pool" (share) + + pool verifica el share → acumula trabajo del minero + si algún share es válido para la red → bloque encontrado + → recompensa distribuida proporcionalmente a shares aportados +``` + +El pool tiene su propio target más fácil que el de la red — así puede medir la contribución de cada minero aunque ninguno encuentre un bloque real. Los shares son la unidad de trabajo del pool. + +--- + +### Stratum V2: soberanía en la selección de transacciones + +En el Stratum clásico, el pool decide qué transacciones entran en el bloque candidato. Los mineros solo hacen hashes — no controlan el contenido del bloque. + +**Stratum V2** cambia esto. Permite que el minero construya su propio bloque candidato con las transacciones que él elige, y solo use el pool para combinar hashrate y distribuir recompensas. Es un cambio relevante para la descentralización y la resistencia a la censura — un pool que quiera censurar transacciones ya no puede hacerlo si sus mineros usan Stratum V2 con selección propia. + +--- + +### Verifica tú mismo + +Entra en [mempool.space](https://mempool.space) y observa el bloque candidato actual en la sección de mining. Verás las transacciones ordenadas por feerate y el peso total acumulado. + +Desde tu propio nodo puedes construir un bloque candidato y ver exactamente qué transacciones seleccionaría: + +``` +bitcoin-cli getblocktemplate '{"rules": ["segwit"]}' +``` + +El resultado incluye la lista completa de transacciones candidatas, el target actual en hex, el valor del subsidio y el coinbase que debes construir. + +--- + +### Resumen + +Un bloque candidato requiere coinbase tx válida, transacciones válidas ordenadas de padres a hijos, y peso total dentro del límite de 4M weight units. El orden de selección usa ancestor feerate — no feerate individual. El target se recalcula cada 2016 bloques con aritmética determinista. Los pools distribuyen trabajo mediante Stratum y miden contribuciones con shares. Stratum V2 devuelve la selección de transacciones al minero individual. + +_La minería no es solo encontrar un hash. Es construir el bloque correcto antes de empezar a buscarlo._ + +--- + +> Los mineros añaden bloques. Pero ¿qué pasa cuando dos mineros encuentran un bloque válido casi al mismo tiempo, o cuando alguien con mucho hashrate intenta reescribir la historia? + +--- + +## Capítulo 6 — La cadena de bloques técnico + +**Nivel: Técnico** + +--- + +### La cadena más larga gana + +Todos los nodos siguen una regla simple: la cadena válida con más trabajo acumulado es la cadena correcta. No la más larga en número de bloques — la que representa más prueba de trabajo total. + +``` + bloque 0 ── bloque 1 ── bloque 2 ── bloque 3 ── bloque 4 + │ + bloque 3' + (descartado) + + bloque 3' puede tener un hash válido + pero la cadena que construye sobre él + tiene menos trabajo acumulado + todos los nodos convergen hacia la cadena más larga +``` + +--- + +### Reorganizaciones + +Una reorganización ocurre cuando un nodo recibe una cadena alternativa con más trabajo acumulado que su cadena activa. El nodo descarta sus bloques actuales y adopta la nueva cadena. + +``` + situación: dos bloques válidos minados casi simultáneamente + + nodo A: ... ── bloque 99 ── [bloque 100a] ← adopta primero + nodo B: ... ── bloque 99 ── [bloque 100b] ← adopta primero + + se mina bloque 101 encima de 100a: + + cadena con 100a: ... ── 99 ── 100a ── 101 (más larga) + cadena con 100b: ... ── 99 ── 100b (descartada) + + nodo B reorganiza: descarta 100b · adopta 100a + 101 + txs en 100b que no estaban en 100a → vuelven a mempool +``` + +Las reorganizaciones naturales de un bloque ocurren aproximadamente cada 45 días. Las de más de un bloque son extremadamente raras en condiciones normales — señal casi segura de un ataque activo o un fallo grave. + +--- + +### El ataque del 51%: qué puede y qué no puede hacer + +``` + CON 51% DEL HASHRATE PUEDES: + ┌─────────────────────────────────────────────────┐ + │ · revertir transacciones propias recientes │ + │ (doble gasto) │ + │ · excluir transacciones de tus bloques │ + │ (censura temporal) │ + │ · ganar todas las recompensas de bloque │ + │ durante el ataque │ + └─────────────────────────────────────────────────┘ + + CON 51% DEL HASHRATE NO PUEDES: + ┌─────────────────────────────────────────────────┐ + │ · crear bitcoin de la nada │ + │ · robar bitcoin de wallets ajenas │ + │ · cambiar las reglas del protocolo │ + │ · gastar outputs que no te pertenecen │ + │ · alterar transacciones antiguas con │ + │ muchas confirmaciones (coste prohibitivo) │ + └─────────────────────────────────────────────────┘ +``` + +Los nodos verifican las reglas del protocolo independientemente del hashrate. Un bloque con bitcoin creado de la nada o con una firma inválida es rechazado por todos los nodos aunque tenga un hash perfecto. El hashrate solo decide el orden de las transacciones — no su validez. + +--- + +### La matemática del doble gasto + +La probabilidad de que un atacante con fracción `q` del hashrate consiga revertir una transacción con `z` confirmaciones decrece exponencialmente: + +``` + q = fracción del hashrate del atacante + z = número de confirmaciones a revertir + + q = 0.10 (10% hashrate): + z=1 → probabilidad éxito: ~20% + z=3 → ~1% + z=6 → ~0.1% + + q = 0.30 (30% hashrate): + z=1 → ~45% + z=3 → ~18% + z=6 → ~5% + + q = 0.40 (40% hashrate): + z=5 → ~55% ← todavía posible con menos del 51% + + con < 50% hashrate: posible pero requiere suerte + con > 50% hashrate: es cuestión de tiempo + nunca ha ocurrido en Bitcoin mainnet +``` + +Cuantas más confirmaciones tiene una transacción, más trabajo habría que rehacer para revertirla. Para transacciones con 6 confirmaciones y hashrate de red actual, el coste energético de un ataque exitoso sería de cientos de millones de dólares. + +--- + +### Soft fork vs hard fork: la diferencia técnica precisa + +``` + HARD FORK SOFT FORK + expande reglas restringe reglas + (antes inválido → ahora válido) (antes válido → ahora inválido) + + nodos sin actualizar: nodos sin actualizar: + rechazan nuevos bloques aceptan nuevos bloques + → cadena se divide → siguen la cadena más larga + + ┌─────────────────────┐ ┌─────────────────────┐ + │ dos cadenas │ │ una sola cadena │ + │ incompatibles │ │ compatible │ + │ para siempre │ │ nodos viejos siguen │ + └─────────────────────┘ └─────────────────────┘ +``` + +La distinción es más sutil de lo que parece. Un soft fork restringe lo que es válido — los nodos antiguos ven los nuevos bloques como válidos aunque no entiendan las nuevas restricciones. Un hard fork expande lo que es válido — los nodos antiguos ven bloques que violan sus reglas y los rechazan. + +Todos los upgrades de Bitcoin hasta hoy han sido soft forks. El único hard fork conocido fue accidental — en 2013, un cambio de base de datos entre versiones creó una división temporal que se resolvió haciendo que los mineros retrocedieran a la versión anterior. + +--- + +### El proceso BIP y la activación + +``` + 1. propuesta → BIP escrito · publicado en GitHub + discusión pública abierta + + 2. implementación → código en Bitcoin Core + revisión por pares + + 3. señalización → mineros activan bit en campo versión + BIP9: ventanas de 2016 bloques + + 4. umbral → 90-95% de bloques señalizando + en una ventana de tiempo + + 5. lock-in → upgrade comprometido para activarse + no puede revertirse + + 6. activación → en altura de bloque específica + todos los nodos aplican las nuevas reglas + + SegWit (BIP141): propuesto dic 2015 → activado ago 2017 + Taproot (BIP341): propuesto ene 2020 → activado nov 2021 +``` + +--- + +### UASF: cuando los usuarios toman el control + +En 2017, durante la guerra de los bloques, un sector de la comunidad lanzó el movimiento **UASF** — _User Activated Soft Fork_. La idea: si los mineros no señalizaban SegWit, los nodos actualizados empezarían a rechazar bloques que no lo activaran a partir de una fecha determinada. + +``` + mecanismo normal (MASF): + mineros señalizan → umbral → lock-in → activación + + UASF: + nodos anuncian fecha límite + "a partir del bloque X solo aceptamos bloques SegWit" + → mineros que no activan SegWit quedan fuera de la cadena válida + → incentivo económico para activar + + resultado 2017: mineros cedieron antes de la fecha límite + SegWit se activó · sin división de cadena +``` + +El UASF demostró empíricamente que el poder en Bitcoin no está en quien mina sino en quien verifica. Los nodos tienen la última palabra sobre qué cadena es válida — los mineros solo construyen bloques que esos nodos aceptarán o rechazarán. + +--- + +### Verifica tú mismo + +Desde tu propio nodo puedes ver el historial de reorganizaciones que ha observado: + +``` +bitcoin-cli getchaintips +``` + +El resultado muestra todas las cadenas conocidas — la activa y los stale blocks que tu nodo ha visto. El campo `branchlen` indica cuántos bloques tiene cada rama alternativa. + +Para seguir el estado de BIPs activos y propuestos: [github.com/bitcoin/bips](https://github.com/bitcoin/bips) + +--- + +### Resumen + +La cadena válida es siempre la de mayor trabajo acumulado. Las reorganizaciones naturales son infrecuentes y de un bloque. Un atacante con 51% puede revertir transacciones propias recientes pero no puede crear bitcoin, robar fondos ajenos ni cambiar las reglas del protocolo — eso lo deciden los nodos. Los soft forks restringen reglas y son compatibles hacia atrás. El UASF de 2017 demostró que los usuarios que ejecutan nodos tienen más poder que los mineros. + +_El hashrate decide el orden. Los nodos deciden las reglas. Esa distinción es la base de la descentralización real de Bitcoin._ + +--- + +> Sabemos cómo se construyen y evolucionan los bloques. Queda una pieza fundamental: SegWit — la actualización que hizo posible Lightning Network y que sigue siendo la base de la mayoría de transacciones modernas. + +--- + +## Capítulo 7 — SegWit + +**Nivel: Técnico** + +--- + +### Un problema que casi mata a Lightning antes de nacer + +En 2015, Joseph Poon y Thaddeus Dryja publicaron el whitepaper de Lightning Network. La idea era brillante — pagos instantáneos off-chain usando la blockchain solo como árbitro de última instancia. + +Pero había un problema que hacía Lightning matemáticamente imposible con el protocolo tal como existía en ese momento. + +--- + +### La maleabilidad de transacciones + +Cada transacción tiene un TXID calculado hasheando todos sus datos — incluyendo las firmas en el ScriptSig. Las firmas ECDSA tienen una propiedad matemática incómoda: dado un par `(r, s)` válido, el par `(r, -s mod n)` también es válido para el mismo mensaje. + +``` + firma original: (r, s) + firma modificada: (r, -s mod n) + + ambas firmas son válidas para la misma transacción + mismo efecto económico · bitcoin llega igual + pero los datos de la tx son diferentes → TXID diferente + + TXID original: aaa... + TXID modificado: bbb... + + cualquier nodo intermedio podía modificar el ScriptSig + antes de propagar la transacción + sin invalidarla · pero cambiando su TXID +``` + +Para Lightning esto es fatal. Un canal requiere construir transacciones de compromiso que referencian el TXID de la transacción de financiación — que todavía no ha sido minada. Si ese TXID puede cambiar antes de ser minada, las transacciones de compromiso quedan invalidadas. Lightning era imposible. + +--- + +### La solución: segregar el testigo + +SegWit resuelve la maleabilidad moviendo las firmas fuera del cuerpo principal de la transacción al campo **witness** — y excluyendo ese campo del cálculo del TXID. + +``` + LEGACY SEGWIT + ┌──────────────────────┐ ┌──────────────────────┐ + │ versión │ │ versión │ + │ inputs │ │ marker 0x00 │ + │ ScriptSig [firma] │ │ flag 0x01 │ + │ outputs │ │ inputs │ + │ locktime │ │ ScriptSig vacío │ + └──────────────────────┘ │ outputs │ + │ witness [firma] │ + TXID = hash(todo) │ locktime │ + firma dentro → TXID mutable └──────────────────────┘ + + TXID = hash(sin witness) + firma fuera → TXID estable +``` + +Con el witness excluido del TXID, modificar la firma no cambia el identificador de la transacción. Lightning pasa de ser imposible a ser construible. + +--- + +### El nuevo sighash para SegWit: BIP143 + +SegWit también cambió cómo se calcula el sighash — los datos que se firman al gastar un output SegWit. El algoritmo legacy tenía un problema de escalado cuadrático: al firmar una transacción con N inputs, cada firma requería hashear la transacción completa N veces. + +BIP143 introduce un nuevo algoritmo de sighash para P2WPKH y P2WSH que resuelve esto: + +``` + LEGACY SIGHASH (O(n²)): + para cada input a firmar: + hashear toda la transacción modificada + → con N inputs: N hasheados de tx completa + + BIP143 SIGHASH (O(n)): + componentes precalculados una sola vez: + · hash de todos los outpoints (TXID+VOUT) + · hash de todas las sequences + · hash de todos los outputs + cada firma usa estos hashes precalculados + → escala linealmente con el número de inputs +``` + +Para hardware wallets esto es especialmente importante — firmar transacciones grandes con el algoritmo legacy requería descargar y verificar la transacción completa múltiples veces. BIP143 lo hace eficiente. + +--- + +### El descuento del witness y el aumento efectivo de bloque + +``` + datos normales: 1 byte = 4 weight units (wu) + datos witness: 1 byte = 1 weight unit (wu) + límite del bloque: 4.000.000 wu + + transacción P2PKH típica (legacy): + ┌──────────────────────────────────────────┐ + │ 150 bytes no-witness × 4 = 600 wu │ + │ 106 bytes ScriptSig × 4 = 424 wu │ + │ total: 1.024 wu │ + └──────────────────────────────────────────┘ + + transacción P2WPKH equivalente (SegWit): + ┌──────────────────────────────────────────┐ + │ 150 bytes no-witness × 4 = 600 wu │ + │ 107 bytes witness × 1 = 107 wu │ + │ total: 707 wu │ + └──────────────────────────────────────────┘ + ~31% más eficiente · fees ~31% más baratas + + aumento efectivo del bloque: + un bloque típico es ~60% datos de firma + 400.000 bytes no-witness × 4 = 1.600.000 wu + 600.000 bytes witness × 1 = 600.000 wu + total: 2.200.000 wu + → caben 4.000.000 / 2.200.000 × 1 MB ≈ 1,8 MB de txs +``` + +SegWit no aumentó el límite de bloque a 4 MB. Aumentó la capacidad efectiva para transacciones típicas a aproximadamente 1,8 MB. + +--- + +### El wTXID y el witness commitment + +Con el witness excluido del TXID surge un nuevo problema: alguien podría modificar los datos witness de una transacción ya minada sin cambiar su TXID. + +La solución es el **wTXID** — un identificador que incluye todos los campos de la transacción, witness incluido: + +``` + TXID = SHA256(SHA256(versión + inputs + outputs + locktime)) + wTXID = SHA256(SHA256(versión + marker + flag + + inputs + outputs + witness + locktime)) + + los mineros calculan un merkle root de todos los wTXIDs + y lo incluyen en un output OP_RETURN de la coinbase tx + → witness commitment + + si alguien modifica el witness de cualquier tx: + su wTXID cambia → el merkle root de wTXIDs cambia + → el witness commitment de la coinbase no coincide + → bloque inválido +``` + +--- + +### SegWit como soft fork + +El truco que hizo posible implementar SegWit sin un hard fork es elegante. Para los nodos antiguos que no entienden SegWit, los nuevos scripts P2WPKH y P2WSH parecen outputs gastables por cualquiera — su ScriptPubKey tiene una estructura que los nodos legacy interpretan como siempre válida. + +``` + P2WPKH ScriptPubKey: OP_0 <20 bytes> + + nodo legacy: "OP_0 empuja datos · resultado no vacío · válido" + acepta el bloque · no verifica el witness + (no sabe que existe el campo witness) + + nodo SegWit: "P2WPKH · verifica firma en el witness" + aplica las reglas completas + + los nodos legacy siguen la cadena más larga + que construyen los nodos actualizados + sin saber que están siguiendo reglas nuevas +``` + +--- + +### La guerra de los bloques + +SegWit llegó en medio del conflicto más intenso de la historia de Bitcoin. Un sector — principalmente grandes mineros y algunas empresas — quería aumentar el límite de bloque directamente mediante hard fork. Otro defendía SegWit como solución técnicamente superior y compatible hacia atrás. + +En agosto de 2017, después del UASF que forzó la mano de los mineros, SegWit se activó. Quienes no aceptaron el resultado lanzaron Bitcoin Cash — un hard fork con bloques de 8 MB. + +> **Lo que reveló la guerra de los bloques.** El conflicto demostró empíricamente algo que hasta entonces era solo teoría: los mineros no controlan Bitcoin. Cuando los grandes pools amenazaron con no activar SegWit, la comunidad respondió con el UASF — nodos que rechazarían bloques sin SegWit a partir de una fecha. Los mineros cedieron. El poder no está en quien mina. Está en quien verifica. + +--- + +### Verifica tú mismo + +Busca en [mempool.space](https://mempool.space) cualquier transacción con dirección `bc1q`. En la vista de detalles observa el campo witness — verás las firmas completamente separadas del cuerpo de la transacción. Compara el campo `size` con el campo `vsize` — la diferencia es el descuento del witness aplicado. + +Para ver el witness commitment en una coinbase transaction, busca cualquier bloque reciente, entra en la primera transacción y localiza el output `OP_RETURN` — contiene el merkle root de los wTXIDs de todas las transacciones del bloque. + +--- + +### Resumen + +SegWit resolvió la maleabilidad de transacciones moviendo las firmas al campo witness y excluyéndolo del cálculo del TXID. Sin esa corrección Lightning era imposible. BIP143 introdujo un nuevo algoritmo de sighash que escala linealmente. El descuento del witness hace las transacciones ~31% más baratas y aumenta la capacidad efectiva del bloque a ~1,8 MB. El wTXID commitment protege los datos witness en la coinbase. Se implementó como soft fork sin romper compatibilidad. + +_A veces la solución más elegante es mover unas firmas de sitio. Lo que cambia cuando lo haces puede ser todo._ + +--- + +> SegWit preparó el terreno. Taproot construyó encima — firmas más eficientes, privacidad mejorada, contratos complejos que se ven como pagos simples. + +--- + +## Capítulo 8 — Taproot + +**Nivel: Técnico** + +--- + +### La pregunta que Taproot responde + +Cuando Alice y Bob abren un canal Lightning y lo cierran cooperativamente, la transacción de cierre aparece en la blockchain como lo que es — una transacción multisig con datos de canal. Cualquier analista puede identificarla. + +¿Y si esa transacción de cierre pudiera ser indistinguible de un pago ordinario de una sola persona? ¿Y si un multisig 2-de-3, un contrato con timelock, un canal Lightning — todos pudieran verse exactamente igual desde fuera cuando se resuelven de forma cooperativa? + +Eso es Taproot. + +--- + +### Schnorr: la firma que ECDSA no podía ser + +Las firmas Schnorr llevan más tiempo que ECDSA — fueron propuestas en 1990. Satoshi eligió ECDSA en 2009 porque las patentes de Schnorr no expiraron hasta 2008, demasiado tarde para incluirlo en el diseño original. Para 2021 esos problemas habían desaparecido. + +La diferencia técnica clave es la **linealidad**: + +``` + ECDSA (r, s): + firma = función no lineal de clave privada + hash + nonce + dos firmas NO pueden combinarse matemáticamente + multisig requiere revelar todas las claves y firmas + + Schnorr (R, s): + firma = nonce × G + clave privada × hash + ecuación lineal → firmas son sumables + + agregación de claves y firmas: + P_agg = P1 + P2 + P3 (suma de claves públicas) + s_agg = s1 + s2 + s3 (suma de firmas parciales) + R_agg = R1 + R2 + R3 (suma de nonces públicos) + + resultado: una firma (R_agg, s_agg) de 64 bytes + verificable contra P_agg + indistinguible de firma de una sola persona +``` + +Además las firmas Schnorr son más compactas — 64 bytes frente a los 71-72 bytes de DER de ECDSA. Y el byte de sighash type al final es opcional en Taproot, lo que ahorra otro byte en el caso más común. + +--- + +### MAST: ocultar lo que no usas + +Antes de Taproot, P2SH y P2WSH revelaban el script completo al gastarlo — todas las condiciones, incluso las que no se usaron. Con MAST solo se revela la condición que se ejerció. + +``` + contrato con tres condiciones: + A: Alice firma sola (caso normal) + B: Bob firma después de 30 días (timeout) + C: Alice y Bob firman juntos (cooperativo) + + árbol de Merkle de scripts: + ┌──────────────────────────────────────────────┐ + │ merkle root │ + │ / \ │ + │ H(AB) H(C) │ + │ / \ │ + │ H(A) H(B) │ + └──────────────────────────────────────────────┘ + + si se usa condición A: + witness revela: script_A + H(B) + H(C) + → B y C permanecen ocultas para siempre + → un observador externo no sabe que B y C existían + + si se usa condición C (cooperativa): + → key path spend · solo una firma Schnorr + → nadie sabe que A y B existían +``` + +--- + +### La clave modificada: el corazón de Taproot + +El mecanismo que une todo es la **tweaked public key** — una clave pública que parece ordinaria pero que contiene un compromiso con todos los scripts alternativos. + +``` + clave interna: P (tu clave pública normal) + merkle root: M (hash raíz del árbol de scripts) + + tweak = hash_taptweak(P || M) + clave modificada Q = P + tweak × G + + ┌─────────────────────────────────────────────────┐ + │ Q parece una clave pública normal de 32 bytes │ + │ pero contiene un compromiso criptográfico │ + │ con todos los scripts del árbol │ + │ nadie sabe qué hay dentro hasta que se gasta │ + └─────────────────────────────────────────────────┘ + + ScriptPubKey P2TR: OP_1 [Q 32 bytes] + dirección resultante: bc1p... +``` + +Si no hay scripts alternativos — solo quieres un pago simple — el merkle root es vacío y el tweak se aplica igualmente. El output sigue siendo P2TR pero sin MAST. + +--- + +### Key path vs script path: ejecución completa + +``` + KEY PATH SPEND + ┌─────────────────────────────────────────────────┐ + │ witness: [firma Schnorr 64 bytes] │ + │ │ + │ verificación: │ + │ 1. ¿un solo elemento en witness? → key path │ + │ 2. firma válida para Q (clave modificada)? │ + │ → output desbloqueado │ + │ │ + │ nota: el firmante usa la clave privada │ + │ modificada internamente para firmar │ + │ p_tweaked = p + tweak (mod n) │ + └─────────────────────────────────────────────────┘ + + SCRIPT PATH SPEND + ┌─────────────────────────────────────────────────┐ + │ witness: [script inputs] [leaf script] │ + │ [control block] │ + │ │ + │ verificación: │ + │ 1. ¿dos o más elementos? → script path │ + │ 2. extraer clave interna P del control block │ + │ 3. recalcular tweak desde P + merkle path │ + │ 4. reconstruir Q y verificar que coincide │ + │ con el ScriptPubKey │ + │ 5. ejecutar leaf script con script inputs │ + │ → si TRUE → output desbloqueado │ + └─────────────────────────────────────────────────┘ + + el nodo decide qué path usar según + cuántos elementos hay en el witness +``` + +--- + +### Tapscript: Script con mejoras + +Los scripts dentro de un Taproot script path spend usan **tapscript** — una variante de Script con algunas diferencias importantes: + +``` + SCRIPT estándar vs TAPSCRIPT + ┌───────────────────────────────────────────────┐ + │ OP_CHECKMULTISIG: eliminado en tapscript │ + │ → sustituido por OP_CHECKSIGADD │ + │ │ + │ OP_CHECKSIG en tapscript: │ + │ → usa Schnorr en lugar de ECDSA │ + │ → falla si firma inválida pero firma vacía │ + │ se permite (facilita multisig variable) │ + │ │ + │ opcodes reservados para upgrades futuros: │ + │ OP_SUCCESS opcodes → siempre TRUE │ + │ permite añadir nuevos opcodes como soft fork │ + │ sin invalidar scripts existentes │ + └───────────────────────────────────────────────┘ +``` + +Los `OP_SUCCESS` opcodes son especialmente importantes para la gobernanza futura — permiten añadir nuevas funcionalidades a tapscript mediante soft fork sin complicaciones de compatibilidad. + +--- + +### La activación de Taproot + +``` + oct 2020 BIPs 340/341/342 publicados + (Schnorr, Taproot, Tapscript) + │ + ▼ + ene-abr 2021 debate sobre mecanismo de activación + Speedy Trial vs UASF (LOT=true) + │ + ▼ + may 2021 Speedy Trial comienza + mineros señalizan bit 2 en campo versión + │ + ▼ + 12 jun 2021 umbral 90% alcanzado en bloque 687.284 + lock-in confirmado · no puede revertirse + │ + ▼ + 14 nov 2021 bloque 709.632 + Taproot activado + sin división · sin guerra de bloques +``` + +El debate sobre Speedy Trial fue intenso — algunos argumentaban que daba demasiado poder a los mineros sobre el calendario de activación. El resultado fue un compromiso: Speedy Trial con ventanas cortas de 2016 bloques, tres meses máximo. Si los mineros no alcanzaban el umbral en ese tiempo, el proceso se reiniciaba. + +> **Lo que reveló la activación de Taproot.** A diferencia de 2017, Taproot se activó sin división ni guerra. La comunidad había aprendido. El mérito técnico era claro, el proceso fue transparente, y el debate sobre el mecanismo de activación — aunque intenso — se resolvió con consenso real. Bitcoin puede evolucionar sin romperse cuando el cambio tiene mérito genuino y el proceso respeta a todos los participantes. + +--- + +### Verifica tú mismo + +Busca en [mempool.space](https://mempool.space) una transacción con dirección `bc1p`. Observa el ScriptPubKey — verás `OP_1` seguido de 32 bytes. Esos 32 bytes son la clave modificada Q. + +Para ver un key path spend busca una transacción donde el witness tenga un solo elemento de 64 bytes — es una firma Schnorr pura. + +Para ver un script path spend busca la transacción `797505b104b5fb840931c115ea35d445eb1f64c9279bf23aa5bb4c3d779da0c2` — el witness tiene tres elementos: script inputs, leaf script y control block. + +Consulta [taproot.watch](https://taproot.watch) para ver la adopción de Taproot en tiempo real. + +--- + +### Resumen + +Taproot combina tres innovaciones. Schnorr permite firmas de 64 bytes agregables — un multisig es indistinguible de un pago simple en el key path. MAST organiza scripts alternativos en un árbol de Merkle y solo revela el usado. La clave modificada compromete todos los scripts en una clave pública que parece ordinaria. Tapscript sustituye OP_CHECKMULTISIG por OP_CHECKSIGADD y añade OP_SUCCESS para upgrades futuros. Se activó en noviembre de 2021 sin división. + +_La privacidad perfecta no es que nadie sepa que hiciste algo complejo. Es que nadie sepa que era complejo._ + +--- + +> Hemos recorrido toda la pila técnica. Queda una última pieza: cómo todo esto viaja de nodo en nodo hasta llegar a cualquier parte del mundo en segundos. + +--- + +## Capítulo 9 — La red + +**Nivel: Técnico** + +--- + +### Sin servidor central + +Cuando pulsas enviar en tu wallet, tu transacción no va a ningún servidor central. Va a un nodo. Ese nodo la verifica y la reenvía a otros nodos. En cuestión de segundos, tu transacción ha llegado a miles de ordenadores distribuidos por todo el mundo. + +Todo esto ocurre mediante un protocolo P2P bien definido — mensajes binarios con estructura precisa que cualquier implementación puede entender y verificar. + +--- + +### La estructura de un mensaje + +Todos los mensajes entre nodos tienen la misma estructura: un **header** fijo de 24 bytes seguido de un payload variable. + +``` + HEADER (24 bytes siempre): + ┌──────────────┬───────┬──────────────────────────┐ + │ magic bytes │ 4 B │ identifica la red │ + │ command │ 12 B │ tipo de mensaje (ASCII) │ + │ size │ 4 B │ tamaño del payload │ + │ checksum │ 4 B │ primeros 4B del hash │ + └──────────────┴───────┴──────────────────────────┘ + + PAYLOAD (variable): + datos específicos del tipo de mensaje +``` + +Los **magic bytes** son el delimitador que identifica el inicio de cada mensaje en el stream TCP. Son distintos para cada red: + +``` + Mainnet: f9beb4d9 + Testnet3: 0b110907 + Regtest: fabfb5da + + cuando un nodo recibe bytes del socket + busca f9beb4d9 para saber dónde empieza + un nuevo mensaje +``` + +--- + +### Cómo se descubren los nodos + +``` + nodo nuevo arranca por primera vez + │ + ▼ + 1. lista de conexiones anteriores (peers.dat) + si existe → intenta reconectar + │ + ▼ si no hay conexiones previas + 2. DNS seeds (servidores de confianza que + devuelven IPs de nodos activos): + seed.bitcoin.sipa.be (Pieter Wuille) + dnsseed.bitcoin.dashjr.org (Luke Dashjr) + seed.bitcoin.sprovoost.nl (Sjors Provoost) + │ + ▼ si DNS falla + 3. lista hardcodeada en Bitcoin Core + (chainparamsseeds.h) + │ + ▼ + conecta con varios nodos + solicita sus listas de peers (mensaje getaddr) + guarda nuevas IPs en peers.dat + → ya integrado en la red +``` + +El objetivo es solo conectar con un nodo fiable. Desde ahí ese nodo comparte sus peers y el grafo de conexiones crece orgánicamente. + +--- + +### El handshake + +Antes de intercambiar transacciones o bloques, dos nodos deben establecer la conexión mediante un handshake de cuatro mensajes: + +``` + Nodo A Nodo B + │ │ + │──── version ──────────────────────▶│ + │ (protocolo, altura, servicios, │ + │ IP, timestamp, user agent) │ + │ │ + │◀─── version ──────────────────────│ + │ │ + │◀─── verack ───────────────────────│ + │ │ + │──── verack ───────────────────────▶│ + │ │ + │ canal abierto · listos para │ + │ intercambiar txs y bloques │ +``` + +El mensaje `version` contiene la versión del protocolo, la altura del bloque más reciente conocido por el nodo, los servicios que ofrece y su dirección IP. El `verack` es un acknowledgement sin payload — solo el header con el comando `verack`. + +El orden importa. Si se envían los mensajes fuera de orden el nodo remoto rechaza la conexión. Demasiados handshakes fallidos pueden resultar en un ban temporal de la IP. + +--- + +### Cómo viaja una transacción: inv / getdata / tx + +Los nodos no envían transacciones completas a todos sus peers de forma proactiva — eso desperdiciaría ancho de banda. En su lugar usan un mecanismo de tres mensajes: + +``` + tu wallet emite tx + │ + ▼ + Nodo A recibe tx · verifica · añade a mempool + │ + │ inv [tipo: MSG_TX, hash: TXID] + ▼ "tengo esta transacción, ¿la quieres?" + Nodo B recibe inv + │ + │ getdata [tipo: MSG_TX, hash: TXID] + ▼ "sí, dámela" + Nodo A responde + │ + │ tx [datos completos de la transacción] + ▼ + Nodo B verifica · propaga a sus vecinos + · · · + en segundos: miles de nodos tienen la tx +``` + +Para transacciones SegWit el tipo en el mensaje `getdata` cambia de `MSG_TX` (01000000) a `MSG_WITNESS_TX` (01000040) — así el nodo receptor obtiene los datos witness completos. + +--- + +### Compact blocks: propagación rápida de bloques + +Cuando se mina un bloque nuevo, propagarlo rápido es crítico — cuanto más tarde llega a otros mineros, más tiempo trabajan en vano sobre la cadena antigua. + +El mecanismo **compact blocks** (BIP152) resuelve esto: + +``` + PROPAGACIÓN TRADICIONAL COMPACT BLOCKS + ┌────────────────────┐ ┌────────────────────┐ + │ bloque completo │ │ header │ + │ 1-4 MB │ │ + short IDs (6B) │ + │ esperar descarga │ │ de cada tx │ + │ antes de verificar │ │ ~20 KB total │ + └────────────────────┘ └────────┬───────────┘ + │ + nodo reconstruye bloque + desde su propia mempool + (ya tiene casi todas las txs) + │ + solo solicita las txs + que le faltan (getblocktxn) + │ + bloque completo en ms + │ + verifica y propaga +``` + +Los short IDs son hashes truncados a 6 bytes derivados del TXID y un nonce del bloque — suficientes para identificar unívocamente cada transacción en la mempool local. + +--- + +### Mensajes de mantenimiento + +Además de txs y bloques, los nodos intercambian mensajes de mantenimiento continuamente: + +``` + ping → nodo envía nonce aleatorio de 8 bytes + pong → nodo responde con el mismo nonce + si no hay respuesta en tiempo → desconectar + + addr → lista de IPs de nodos conocidos + getaddr → solicitar lista de peers + + mempool → solicitar txs pendientes del peer + feefilter → "solo envíame txs con fee > X sat/vbyte" + reduce tráfico en nodos con muchos peers +``` + +--- + +### Nodo completo vs nodo ligero (SPV) + +``` + NODO COMPLETO NODO LIGERO (SPV) + ┌────────────────────┐ ┌────────────────────┐ + │ descarga toda la │ │ solo headers │ + │ blockchain │ │ 80 bytes × 880K+ │ + │ verifica cada tx │ │ bloques ≈ 70 MB │ + │ independientemente│ │ │ + │ ~700 GB disco │ │ verifica txs con │ + │ ~4-10 GB RAM │ │ pruebas de Merkle │ + │ │ │ confía en nodos │ + │ no confía en nada │ │ completos para │ + │ soberanía total │ │ el estado UTXO │ + └────────────────────┘ └────────────────────┘ +``` + +El nodo ligero tiene una limitación importante: no puede verificar que un output no ha sido ya gastado sin consultar a un nodo completo. Sabe que una transacción existe en un bloque (gracias a la prueba de Merkle) pero no sabe si el UTXO que gasta seguía sin gastar en el momento de confirmación. + +--- + +### Tu IP es un dato + +``` + SIN NODO PROPIO CON NODO PROPIO + TOR + ┌────────────────────┐ ┌────────────────────┐ + │ wallet consulta │ │ wallet consulta │ + │ servidor externo │ │ tu propio nodo │ + │ │ │ nodo usa Tor │ + │ el servidor sabe: │ │ │ + │ · tus direcciones │ │ nadie sabe: │ + │ · tu saldo │ │ · qué direcciones │ + │ · tu actividad │ │ son tuyas │ + │ · tu IP │ │ · tu IP real │ + └────────────────────┘ └────────────────────┘ +``` + +Bitcoin Core tiene soporte nativo para Tor. Configurado correctamente, todas las conexiones salientes usan la red Tor — los peers solo ven una dirección `.onion`, no tu IP real. + +--- + +### Verifica tú mismo + +Entra en [bitnodes.io](https://bitnodes.io) y observa el mapa de nodos activos en tiempo real. + +Desde tu propio nodo puedes inspeccionar todas las conexiones activas: + +``` +bitcoin-cli getpeerinfo +``` + +Para conectarte manualmente a un nodo y ver los mensajes raw, el protocolo está completamente documentado en [learnmeabitcoin.com/technical/networking](https://learnmeabitcoin.com/technical/networking). + +--- + +### Resumen + +La red Bitcoin es un protocolo P2P de mensajes binarios sobre TCP. Cada mensaje lleva magic bytes, comando, tamaño y checksum. Los nodos se descubren mediante DNS seeds y listas de peers. El handshake establece la conexión en cuatro mensajes. Las transacciones viajan mediante inv/getdata/tx. Compact blocks acelera la propagación de bloques nuevos reconstruyéndolos desde la mempool local. Los nodos ligeros verifican inclusión pero no estado UTXO. Tor elimina la exposición de IP. + +_La red no tiene centro. Cada nodo es igual a los demás. Eso es exactamente lo que la hace imposible de apagar._ + +--- + +_Con este capítulo concluye la Parte 3 — Técnico._ + +_La guía completa cubre ahora desde los conceptos más básicos hasta los mecanismos criptográficos más profundos del protocolo. Tres partes. Una sola idea: Bitcoin funciona porque cualquiera puede verificarlo._ + +--- + +## Glosario + +**Ancestor feerate** — Fee rate combinado de una transacción y todos sus ancestros pendientes en la mempool, dividido entre su tamaño combinado. Es la métrica real que usan los mineros para ordenar transacciones en el bloque candidato. + +**BIP143** — Propuesta que define el nuevo algoritmo de sighash para transacciones SegWit. Resuelve el escalado cuadrático del algoritmo legacy precalculando componentes compartidos entre todos los inputs. + +**Bech32** — Formato de codificación de direcciones usado por P2WPKH y P2WSH (direcciones bc1q). Usa un alfabeto de 32 caracteres que evita confusiones entre letras similares y tiene detección de errores mejorada. + +**Bech32m** — Variante de Bech32 usada por P2TR (direcciones bc1p). Usa un polinomio de checksum diferente que mejora la detección de errores para longitudes de datos distintas. + +**BIP152** — Propuesta que define compact blocks — el mecanismo de propagación de bloques que envía short IDs en lugar del bloque completo, permitiendo que los nodos reconstruyan el bloque desde su mempool. + +**Compact blocks** — Mecanismo de propagación de bloques que envía la cabecera más identificadores cortos de 6 bytes por transacción. El nodo receptor reconstruye el bloque desde su mempool y solo solicita las transacciones que le faltan. + +**Control block** — Elemento del witness en un script path spend de Taproot. Contiene la clave interna, la versión de tapscript y el merkle path necesario para demostrar que el leaf script usado estaba comprometido en la clave modificada. + +**CPFP** — _Child Pays For Parent_. Técnica donde el destinatario de una transacción atascada crea una transacción hijo con fee alta para arrastrar a la transacción padre mediante el ancestor feerate combinado. + +**Curva elíptica secp256k1** — Curva matemática definida por `y² = x³ + 7` usada por Bitcoin para la criptografía de clave pública. La seguridad se basa en la dificultad computacional del logaritmo discreto sobre esta curva. + +**Derivation path** — Ruta que indica la posición exacta de una clave en el árbol de una HD wallet. Formato: `m / purpose' / coin_type' / account' / change / index`. El apóstrofo indica hijo hardened. + +**DNS seed** — Servidor de nombres mantenido por desarrolladores de confianza que devuelve listas de direcciones IP de nodos Bitcoin activos. Usado por Bitcoin Core para el descubrimiento inicial de peers. + +**ECDSA** — _Elliptic Curve Digital Signature Algorithm_. Algoritmo de firma digital usado en Bitcoin desde sus inicios. Las firmas tienen formato DER y tamaño variable de 71-72 bytes. Sustituido por Schnorr en Taproot. + +**Extranonce** — Campo en el ScriptSig de la coinbase transaction que los mineros modifican para ampliar el espacio de búsqueda cuando el nonce de la cabecera se agota. + +**Extended public key (xpub)** — Clave pública extendida que permite derivar todas las claves públicas hijas de una rama sin exponer ninguna clave privada. Usada en watch-only wallets. + +**Fee rate** — Comisión expresada en satoshis por vbyte (sat/vbyte). Métrica estándar para comparar la prioridad de transacciones en la mempool. + +**Gap limit** — Número de direcciones consecutivas sin actividad que una wallet HD escanea antes de asumir que no hay más fondos en esa rama. Por defecto 20 en Bitcoin Core. + +**Handshake** — Intercambio inicial de cuatro mensajes (version → version ← verack ← verack →) entre dos nodos Bitcoin para establecer la conexión antes de intercambiar transacciones o bloques. + +**Hash160** — Resultado de aplicar SHA256 seguido de RIPEMD160 a una clave pública. Produce 20 bytes y es la base de las direcciones P2PKH y P2WPKH. + +**HD wallet** — _Hierarchical Deterministic wallet_. Wallet que deriva todas sus claves de forma determinista desde una única semilla maestra mediante HMAC-SHA512. + +**Key path spend** — Forma de gastar un output P2TR usando directamente la firma Schnorr de la clave modificada. El witness contiene un único elemento de 64 bytes. Indistinguible de un pago simple desde fuera. + +**Leaf script** — Script individual dentro del árbol MAST de un output Taproot. Se revela solo cuando se usa ese camino de gasto específico. + +**Locktime** — Campo de 4 bytes en una transacción que especifica la altura de bloque o timestamp Unix mínimo a partir del cual puede ser minada. + +**Magic bytes** — Cuatro bytes (`f9beb4d9` en mainnet) que preceden cada mensaje en el protocolo P2P de Bitcoin. Permiten identificar el inicio de un nuevo mensaje en el stream TCP. + +**MAST** — _Merkelized Abstract Syntax Tree_. Técnica que organiza múltiples condiciones de gasto en un árbol de Merkle. Solo se revela la condición usada al gastar; las demás permanecen ocultas. + +**Merkle proof** — Conjunto mínimo de hashes necesarios para demostrar que una transacción concreta está incluida en un bloque sin descargar todas las transacciones del bloque. + +**Natural byte order** — Orden en que se almacenan los TXIDs en los campos de input de una transacción. Equivalente a little-endian para este campo específico. + +**OP_CHECKSIGADD** — Opcode de tapscript que verifica una firma y suma 1 al contador de la pila si es válida. Reemplaza `OP_CHECKMULTISIG` sin su bug histórico del dummy value. + +**OP_SUCCESS** — Clase de opcodes reservados en tapscript que devuelven TRUE inmediatamente. Permiten añadir nuevas funcionalidades en upgrades futuros mediante soft fork sin invalidar scripts existentes. + +**P2TR** — _Pay to Taproot_. Script que bloquea un output a una clave modificada de 32 bytes. Permite gasto vía key path (firma Schnorr) o script path (árbol MAST). + +**P2WPKH** — _Pay to Witness Public Key Hash_. Script SegWit que bloquea un output al hash de una clave pública, con los datos de desbloqueo en el campo witness. + +**P2WSH** — _Pay to Witness Script Hash_. Script SegWit que bloquea un output al hash de un script arbitrario, con el script completo y sus datos de desbloqueo en el witness. + +**Script path spend** — Forma de gastar un output P2TR revelando uno de los leaf scripts alternativos comprometidos en la clave modificada. El witness contiene script inputs, leaf script y control block. + +**Sequence** — Campo de 4 bytes en cada input de una transacción. Señaliza RBF cuando vale `0xFFFFFFFD` o menos. Con versión 2 de transacción, valores bajos activan timelocks relativos. + +**Sighash** — Hash que se firma al autorizar el gasto de un input. Se construye hasheando una versión modificada de la transacción según el tipo de sighash (ALL, NONE, SINGLE, ANYONECANPAY). + +**Sighash type** — Byte que especifica qué partes de la transacción cubre la firma. SIGHASH_ALL (0x01) es el más común — cubre todos los inputs y outputs. + +**Stratum** — Protocolo de comunicación entre pools de minería y sus mineros. El pool distribuye trabajo asignando rangos de nonces y recibe shares para medir la contribución de cada minero. + +**Stratum V2** — Versión actualizada de Stratum que permite al minero individual construir su propio bloque candidato con las transacciones que elige, en lugar de delegar esa decisión al pool. + +**Tapscript** — Variante de Script usada dentro de los leaf scripts de Taproot. Sustituye `OP_CHECKMULTISIG` por `OP_CHECKSIGADD`, usa firmas Schnorr y añade OP_SUCCESS para extensibilidad futura. + +**Tweaked public key** — Clave pública modificada usada en P2TR. Se calcula sumando a la clave interna el punto `tweak × G`, donde tweak es el hash del merkle root de los scripts alternativos. + +**UASF** — _User Activated Soft Fork_. Mecanismo de activación de soft fork impulsado por los nodos de usuarios en lugar de los mineros. Demostrado en 2017 durante la activación de SegWit. + +**Version bits (BIP9)** — Sistema de señalización de upgrades donde cada bit del campo versión de la cabecera de bloque puede asignarse a una propuesta diferente. Los mineros señalizan activando el bit correspondiente. + +**wTXID** — _Witness TXID_. Identificador de transacción calculado incluyendo todos los campos — versión, marker, flag, inputs, outputs, witness y locktime. Usado para el witness commitment en la coinbase. + +**X-only public key** — Clave pública de 32 bytes usada en Taproot que omite el byte de prefijo de paridad. Se asume siempre coordenada y par. Ahorra un byte y simplifica la aritmética Schnorr. + +--- + +## Preguntas frecuentes + +**¿Por qué el TXID se calcula sin el witness?** +Porque el witness contiene las firmas, y las firmas ECDSA podían modificarse matemáticamente sin invalidar la transacción — la maleabilidad. Si el TXID incluyera el witness, un nodo intermedio podría cambiar el TXID antes de que la transacción fuera minada, rompiendo cualquier protocolo que dependa de referenciar esa transacción por su ID. SegWit resolvió esto excluyendo el witness del cálculo del TXID. El wTXID sí incluye el witness y se usa internamente para el witness commitment en la coinbase. + +**¿Qué pasa si reutilizo el mismo nonce en dos firmas ECDSA distintas?** +La clave privada queda expuesta matemáticamente. Con dos firmas `(r, s1)` y `(r, s2)` firmadas con el mismo nonce sobre mensajes distintos `H1` y `H2`, cualquiera puede calcular la clave privada con álgebra básica. Ha ocurrido en la práctica — wallets con generadores de números aleatorios defectuosos han perdido fondos exactamente por este motivo. Schnorr es más robusto en este aspecto porque usa nonces deterministas derivados de la clave privada y el mensaje. + +**¿Qué diferencia hay entre TXID y wTXID?** +El TXID se calcula hasheando versión, inputs, outputs y locktime — sin el witness. El wTXID incluye también marker, flag y witness. Para transacciones legacy sin witness, TXID y wTXID son idénticos. Para transacciones SegWit son distintos. Los mineros construyen dos árboles de Merkle: uno de TXIDs para la cabecera del bloque, y otro de wTXIDs cuyo root se incluye en un output OP_RETURN de la coinbase como witness commitment. + +**¿Por qué el campo bits en la cabecera del bloque pierde precisión respecto al target real?** +Porque el target completo tiene 32 bytes y el campo bits solo 4 — el primer byte es el exponente y los tres siguientes son el coeficiente. La precisión que se pierde es mínima en la práctica: la diferencia entre el target aproximado y el exacto es infinitesimal comparada con el espacio de búsqueda de 2²⁵⁶ hashes posibles. El campo bits existe como conveniencia — los nodos podrían calcular el target internamente sin él. + +**¿Puede un minero incluir transacciones inválidas en su bloque candidato?** +Puede incluirlas en el candidato que construye — nadie se lo impide técnicamente. Pero si mina ese bloque y lo propaga, todos los nodos de la red lo rechazarán. El minero habrá gastado energía real encontrando un hash válido para un bloque que nadie acepta. El incentivo económico es el mecanismo de seguridad — minar bloques inválidos es simplemente caro y sin recompensa. + +**¿Qué es CPFP y en qué se diferencia de RBF?** +CPFP — _Child Pays For Parent_ — es una técnica donde el destinatario de una transacción atascada crea una transacción hijo que gasta el output de la padre con una fee muy alta. Los mineros evalúan el ancestor feerate combinado del paquete padre-hijo, lo que arrastra a la transacción padre aunque su fee individual sea baja. RBF — _Replace by Fee_ — lo hace el remitente original, reemplazando su propia transacción sin confirmar por una nueva con fee más alta. RBF requiere que la transacción original haya señalizado con sequence < 0xFFFFFFFE. CPFP no requiere ninguna señalización previa. + +**¿Qué es el gap limit y por qué importa al recuperar una wallet?** +Las wallets HD derivan claves en secuencia pero no escanean infinitamente. El gap limit — por defecto 20 en Bitcoin Core — define cuántas direcciones consecutivas sin actividad escanea la wallet antes de asumir que no hay más fondos en esa rama. Si en algún momento generaste claves saltando índices, o usaste un path de derivación no estándar, los fondos en índices por encima del gap podrían no aparecer al recuperar. La solución es aumentar el gap limit en el software de recuperación o conocer exactamente qué paths y qué índices usaste. + +**¿Por qué Taproot usa claves x-only de 32 bytes en lugar de 33?** +Las claves públicas comprimidas estándar tienen 33 bytes — 32 de coordenada x más un byte de prefijo (02 o 03) que indica si la coordenada y es par o impar. En Taproot ese byte de prefijo se omite porque se asume siempre que y es par — si la clave tiene y impar, se usa su negación, que tiene y par. Esto ahorra un byte por clave y simplifica la aritmética en las verificaciones de firma Schnorr. + +**¿Qué son los OP_SUCCESS opcodes en tapscript y para qué sirven?** +Son opcodes reservados que en tapscript hacen que el script devuelva TRUE inmediatamente sin ejecutar nada más. Esto los hace seguros para reasignar en upgrades futuros mediante soft fork: si se añade una nueva funcionalidad a un OP_SUCCESS opcode, los scripts que lo usan pasan de “siempre TRUE” a ejecutar la nueva lógica. Los nodos sin actualizar siguen viendo TRUE y aceptan el bloque. Los nodos actualizados ejecutan las nuevas reglas. Es el mecanismo de extensibilidad más limpio que tiene Bitcoin para añadir nuevos opcodes. + +**¿Por qué un nodo ligero SPV no puede verificar completamente una transacción?** +Porque solo descarga cabeceras de bloque — no las transacciones. Puede verificar que una transacción específica está incluida en un bloque usando una prueba de Merkle. Pero no puede verificar que el UTXO que esa transacción gasta no había sido ya gastado previamente — para eso necesitaría el UTXO set completo, que solo mantienen los nodos completos. Un SPV confía en que la cadena más larga es válida y en que los nodos completos a los que consulta son honestos. + +**¿Qué información revela el campo version del mensaje de handshake?** +Revela la versión del protocolo que soporta el nodo, la altura del último bloque conocido, los servicios que ofrece — si es nodo completo, si soporta SegWit, si tiene filtros de bloom activos — su dirección IP y puerto, y su user agent que incluye la versión del software. Todo esto antes de que se haya intercambiado una sola transacción. Es información relevante para quienes monitorean la red y pueden correlacionar IPs con wallets si no se usa Tor. + +**¿Puede cambiarse el límite de 21 millones mediante soft fork?** +No. Aumentar el límite de emisión requiere un hard fork — es una expansión de reglas, no una restricción. Crearía bloques que los nodos sin actualizar considerarían inválidos porque la coinbase reclamaría más bitcoin del permitido. En la práctica, cualquier propuesta de cambiar los 21 millones sería rechazada por la inmensa mayoría de nodos y usuarios que tienen incentivo económico directo en que ese límite no cambie. Es la regla más inviolable del protocolo — no por imposibilidad técnica sino por imposibilidad económica y política. + +--- + +## Recursos + +- [learnmeabitcoin.com](https://learnmeabitcoin.com) — Greg Walker. Fuente técnica principal. +- [mempool.space](https://mempool.space) — Explorador de bloques en tiempo real. +- [learnmeabitcoin.com/tools/](https://learnmeabitcoin.com/tools/) — Herramientas para explorar claves, transacciones y bloques. +- [iancoleman.io/bip39](https://iancoleman.io/bip39) — Generador de seed phrases y derivación de claves (usar offline). +- [bitnodes.io](https://bitnodes.io) — Mapa de nodos Bitcoin activos. +- [amboss.space](https://amboss.space) — Grafo de la red Lightning. +- [taproot.watch](https://taproot.watch) — Adopción de Taproot en tiempo real. +- [solo.ckpool.org](https://solo.ckpool.org) — Pool de minería en solitario. +- [github.com/bitcoin/bips](https://github.com/bitcoin/bips) — Repositorio de Bitcoin Improvement Proposals. +- [learnmeabitcoin.com/technical/networking](https://learnmeabitcoin.com/technical/networking) — Protocolo de red P2P de Bitcoin documentado en detalle. +- [Bitcoin Whitepaper](https://bitcoin.org/bitcoin.pdf) — Satoshi Nakamoto, 2008.