Los soft forks de Bitcoin: historia de cada cambio de consenso
Una cronología completa de los cambios de consenso en Bitcoin y las lecciones de gobernanza que dejaron.
Fecha de publicación: Febrero 2026 Autor: aprendeBTC Tiempo de lectura: ~19 minutos
Bitcoin tiene fama de ser imposible de cambiar. Es parcialmente cierto: cambiar las reglas de consenso de Bitcoin es extraordinariamente difícil. Pero no es imposible. Desde 2012, Bitcoin ha tenido varios "soft forks" — cambios compatibles hacia atrás que añaden nuevas funcionalidades sin romper el software existente.
Cada soft fork cuenta una historia sobre cómo se gobierna Bitcoin, qué prioriza la comunidad, y qué tan difícil es llegar a consenso. Esta es la historia completa.
Qué es un soft fork
Un soft fork es un cambio en las reglas de Bitcoin que hace válidas menos cosas que antes. Las transacciones y bloques que eran inválidos siguen siendo inválidos. Algunas transacciones y bloques que antes eran válidos ahora son inválidos. Pero los nodos antiguos (que no han actualizado) siguen viendo la cadena como válida — simplemente no entienden las nuevas reglas.
Esto contrasta con un hard fork, que hace válidas cosas que antes eran inválidas. Un hard fork requiere que todos los nodos actualicen o se quedan en una cadena separada.
Los soft forks son la forma preferida de actualizar Bitcoin porque:
1. No fuerzan a nadie a actualizar inmediatamente 2. No dividen la red si algunos nodos no actualizan 3. Son más seguros (no pueden eliminar restricciones, solo añadirlas)
BIP 16 — Pay to Script Hash (P2SH) — Abril 2012
El primer soft fork significativo de Bitcoin introdujo P2SH, una forma de crear direcciones para scripts arbitrarios.
El problema: antes de P2SH, si querías que alguien te pagara a un script complejo (por ejemplo, multisig 2-de-3), tenías que darles el script entero. Esto era largo, propenso a errores, y revelaba las condiciones de gasto antes de usarlas.
La solución: P2SH permite representar cualquier script como un hash de 20 bytes. El pagador solo ve una dirección normal (empezando por 3). El receptor proporciona el script original solo cuando gasta los fondos.
Cómo se activó: mediante señalización de mineros. Si el 55% de los bloques en una ventana de 7 días señalizaban soporte, el soft fork se activaba. Fue el primer soft fork con este mecanismo.
Controversia: Gavin Andresen impulsó P2SH. Hubo alternativas propuestas (OP_EVAL, OP_CHECKMULTISIG nativo) que algunos consideraban técnicamente superiores. P2SH ganó por ser más pragmático y tener apoyo de Gavin, quien entonces lideraba el desarrollo.
Legado: P2SH habilitó multisig práctico y sentó las bases para scripts más complejos. Las direcciones "3..." siguen siendo comunes hoy.
BIP 65 — OP_CHECKLOCKTIMEVERIFY (CLTV) — Diciembre 2015
Este soft fork añadió un nuevo opcode que permite bloquear fondos hasta un momento específico en el futuro.
El problema: antes de CLTV, podías crear transacciones con timelock usando el campo nLocktime. Pero esto tenía limitaciones: el timelock estaba en la transacción que gastaba, no en las condiciones de gasto del output. No podías crear un output que nadie pudiera gastar antes de cierta fecha.
La solución: OP_CHECKLOCKTIMEVERIFY permite poner la condición temporal directamente en el script. El output no puede gastarse hasta que pase el tiempo especificado, independientemente de qué transacción intente gastarlo.
Casos de uso: herencias (fondos que solo se pueden reclamar después de cierta fecha), pagos escrow con fecha límite, canales de pago unidireccionales.
Activación: mediante señalización de mineros usando "version bits" (BIP 9), un mecanismo más flexible que el de P2SH.
BIP 68, 112, 113 — Relative Timelocks (CSV) — Julio 2016
Un conjunto de tres BIPs que habilitaron timelocks relativos (relativos a cuándo se confirmó la transacción anterior, no a una fecha absoluta).
BIP 68: redefinió el campo nSequence para codificar timelocks relativos.
BIP 112: añadió OP_CHECKSEQUENCEVERIFY (CSV), similar a CLTV pero para tiempos relativos.
BIP 113: cambió cómo se calcula el tiempo en timelocks (usando tiempo medio de bloques anteriores en lugar del timestamp del bloque actual).
Por qué importa: los timelocks relativos son esenciales para Lightning Network. Los canales Lightning usan CSV para dar tiempo a detectar intentos de fraude: si tu contraparte intenta cerrar el canal con un estado antiguo, tienes un periodo (definido por CSV) para publicar la transacción de penalización.
Sin CSV, Lightning no funcionaría como lo conocemos.
BIP 141, 143, 147 — Segregated Witness (SegWit) — Agosto 2017
El soft fork más importante y controvertido desde la creación de Bitcoin.
El problema principal: transaction malleability. Antes de SegWit, era posible modificar el txid de una transacción sin invalidarla (cambiando la firma de forma que sigue siendo válida pero tiene un hash diferente). Esto rompía protocolos que dependían de conocer el txid antes de que la transacción se confirmara — incluyendo Lightning Network.
Otro problema: escalar transacciones. Los bloques estaban llenos. Aumentar el límite era controvertido. SegWit ofrecía un aumento efectivo de capacidad sin cambiar el límite de 1 MB.
La solución: SegWit "separa" (segregates) las firmas (witness data) del resto de la transacción. El txid se calcula sin incluir las firmas, eliminando malleability. Las firmas se cuentan con un "descuento" de peso, permitiendo más transacciones por bloque.
Detalles técnicos:
- Introdujo "weight units" en lugar de bytes para medir tamaño de bloque. El límite pasó a ser 4 millones de weight units (equivalente a ~2.3 MB si todas las transacciones son SegWit)
- Creó dos nuevos tipos de salida: P2WPKH (native SegWit para claves individuales) y P2WSH (native SegWit para scripts)
- Habilitó versiones de script futuras, facilitando futuros soft forks
La guerra de activación: SegWit fue el campo de batalla de la Guerra del Tamaño de Bloque. Los mineros (especialmente Bitmain) bloquearon su activación durante más de un año. El movimiento UASF (User Activated Soft Fork) forzó la mano: usuarios amenazaron con rechazar bloques que no señalizaran SegWit a partir del 1 de agosto de 2017.
Ante la amenaza de división, los mineros capitularon. SegWit se activó el 24 de agosto de 2017.
Legado: SegWit habilitó Lightning Network, mejoró la privacidad futura con Taproot, y demostró que los usuarios tienen poder sobre los mineros.
BIP 340, 341, 342 — Taproot — Noviembre 2021
El soft fork más reciente, y probablemente el más ambicioso técnicamente.
BIP 340 — Firmas Schnorr: reemplazó las firmas ECDSA por firmas Schnorr para outputs Taproot. Schnorr tiene propiedades matemáticas superiores: las firmas son más pequeñas, y múltiples firmas pueden agregarse en una sola (útil para multisig).
BIP 341 — Taproot: introdujo un nuevo tipo de output (P2TR) que puede gastarse de dos formas:
1. Key path: con una firma simple, como si fuera una dirección normal 2. Script path: revelando un script específico de un árbol de scripts (MAST)
La magia: si todas las partes de un contrato complejo cooperan, pueden gastar con el key path, y nadie ve que había condiciones complejas. Solo si hay disputa se revela el script. Esto mejora privacidad y eficiencia.
BIP 342 — Tapscript: actualizó Bitcoin Script para outputs Taproot, añadiendo nuevos opcodes y preparando el terreno para futuras mejoras.
Activación: después de la controversia de SegWit, la comunidad debatió extensamente cómo activar Taproot. Finalmente se usó "Speedy Trial": los mineros tenían un periodo corto para señalizar 90% de soporte. Si lo lograban, Taproot se activaría meses después. Si no, habría que buscar otra estrategia.
Los mineros señalizaron rápidamente. Taproot se activó el 14 de noviembre de 2021 en el bloque 709.632.
Legado: Taproot mejora la privacidad (muchas transacciones complejas parecen pagos simples), reduce costes (firmas más pequeñas, scripts más eficientes), y habilita contratos más sofisticados. La adopción ha sido gradual pero continua.
El debate sobre futuros soft forks
Después de Taproot, la comunidad ha debatido qué viene después — y si debería venir algo.
Propuestas activas:
OP_CTV (CheckTemplateVerify): permite crear "covenants" — outputs que restringen a qué direcciones pueden ir los fondos. Casos de uso incluyen bóvedas de seguridad, canales de pago mejorados, y "congestion control" (pre-comprometer transacciones futuras).
OP_CAT: un opcode antiguo que Satoshi deshabilitó por preocupaciones de seguridad. Rehabilitarlo permitiría concatenar datos en scripts, habilitando muchas construcciones nuevas. Algunos lo ven como peligrosamente poderoso.
OP_VAULT: diseñado específicamente para crear bóvedas de seguridad donde los fondos tienen un "periodo de enfriamiento" antes de poder gastarse, con opción de cancelar durante ese periodo.
ANYPREVOUT (APO): modificación a los sighashes que facilitaría Eltoo, una versión mejorada de canales Lightning.
El debate de la osificación
Algunos argumentan que Bitcoin debería "osificarse" — dejar de hacer cambios significativos al protocolo:
- Cada cambio tiene riesgo de introducir bugs
- Los cambios requieren coordinar a miles de participantes
- Bitcoin ya funciona. ¿Por qué arriesgarse?
- La dificultad de cambiar Bitcoin es una feature, no un bug
Otros argumentan lo contrario:
- Sin mejoras, Bitcoin se quedará atrás en funcionalidad
- Hay mejoras claras que beneficiarían a todos
- La osificación prematura congela bugs y limitaciones actuales
- Otros sistemas que no evolucionan mueren
No hay consenso. Lo que sí es claro es que cada futuro soft fork será más difícil que el anterior. La barra está muy alta.
Lecciones de gobernanza
Los soft forks de Bitcoin revelan cómo se gobierna realmente la red:
1. Los desarrolladores proponen, no imponen. Los BIPs son propuestas. Ningún desarrollador puede forzar un cambio.
2. Los mineros señalizan, pero no deciden. La señalización de mineros es una forma de medir consenso, pero UASF demostró que los usuarios pueden forzar activación si los mineros bloquean.
3. Los usuarios tienen el poder final. Quien ejecuta nodos decide qué reglas sigue. Si suficientes usuarios rechazan un cambio, el cambio no ocurre.
4. El consenso es difícil pero funciona. El proceso es lento, conflictivo, y frustrante. Pero ha producido mejoras significativas sin dividir la red (excepto Bitcoin Cash, que fue un fork hostil, no un soft fork).
5. Cada cambio hace el siguiente más difícil. La comunidad es cada vez más cautelosa. Esto protege contra cambios malos pero también ralentiza mejoras buenas.
Bitcoin no es inmutable. Es muy, muy difícil de cambiar. Eso es diferente.
Fuentes
- Bitcoin Improvement Proposals (github.com/bitcoin/bips)
- Bitcoin Optech para explicaciones técnicas
- "The Blocksize War" de Jonathan Bier para contexto de SegWit