La historia de Bitcoin está marcada por actualizaciones críticas que han definido su trayectoria como moneda digital global. Entre estos hitos técnicos, pocos han sido tan transformadores o tan debatidos como la implementación de Segregated Witness. Conocida comúnmente por su abreviatura, SegWit, esta actualización del protocolo se activó en agosto de 2017 tras un período de intensa discusión comunitaria y construcción de consenso. Representó un momento pivotal para la red, abordando problemas de larga data relacionados con la escalabilidad y la seguridad.
Antes de SegWit, la red de Bitcoin enfrentaba una presión creciente de su base de usuarios en expansión. A medida que aumentaba la adopción, las limitaciones del tamaño original de los bloques se convirtieron en un cuello de botella, lo que llevó a congestión en la red y costos de transacción en aumento. Los desarrolladores y las partes interesadas buscaron una solución que pudiera aliviar estas presiones sin comprometer la naturaleza descentralizada de la blockchain. Segregated Witness surgió como una solución de ingeniería ingeniosa que optimizó la forma en que se almacenaban los datos en lugar de simplemente aumentar el límite de tamaño de los bloques.
La actualización hizo más que solo mejorar la capacidad. Alteró fundamentalmente la mecánica del procesamiento de transacciones al abordar una vulnerabilidad técnica conocida como maleabilidad de transacciones. Al corregir este problema, SegWit sentó las bases necesarias para que soluciones de segunda capa como la Lightning Network prosperaran. Esto allanó el camino para pagos instantáneos y de bajo costo que previamente eran difíciles de implementar de manera segura.
Entender SegWit requiere mirar más allá de las especificaciones técnicas. Implica examinar el modelo de gobernanza de Bitcoin, la economía del espacio en bloques y las dinámicas comunitarias que impulsan la evolución del protocolo. Esta actualización demostró que Bitcoin podía adaptarse y escalar a través de soft forks, preservando la compatibilidad hacia atrás mientras introducía mejoras radicales en eficiencia y utilidad.
El desafío de escalabilidad
Bitcoin fue diseñado originalmente con un límite en el tamaño de los bloques que podían añadirse a la blockchain. Este límite, establecido en 1 megabyte (MB), sirvió como medida de protección contra ataques de spam en los primeros días de la red. Sin embargo, a medida que Bitcoin creció de un experimento obscuro a un activo reconocido globalmente, esta característica de seguridad comenzó a actuar como una restricción al crecimiento.
El cuello de botella del tamaño de bloques
Cada transacción de Bitcoin consiste en datos que deben ser procesados y almacenados por los mineros. Estos datos incluyen entradas, salidas y firmas digitales que prueban la propiedad de los fondos que se gastan. En la era pre-SegWit, toda esta información tenía que competir por espacio dentro del rígido límite de 1 MB por bloque.
A medida que aumentaba la popularidad de la red, la demanda de espacio en bloques frecuentemente excedía la oferta disponible. Los usuarios se veían envueltos en una guerra de pujas, adjuntando tarifas más altas a sus transacciones para incentivar a los mineros a incluirlas en el siguiente bloque. Esta dinámica resultaba en tiempos de confirmación más lentos para los usuarios que pagaban tarifas estándar.
Durante períodos de máxima demanda, la red se congestionaba, haciendo impráctico los pagos pequeños o microtransacciones. La comunidad reconoció que para que Bitcoin funcionara efectivamente tanto como reserva de valor como medio de intercambio, era necesario aumentar el rendimiento de la red. El debate se centró en cómo lograr esta escalabilidad sin sacrificar la seguridad o la descentralización.
El dilema del hard fork
Una solución propuesta para el problema de escalabilidad fue un hard fork. Un hard fork es un cambio radical en el protocolo que hace que bloques/transacciones previamente inválidos sean válidos, o viceversa. En el contexto de escalabilidad, esto habría significado simplemente reescribir el código para permitir bloques más grandes, como 2 MB o 8 MB.
Sin embargo, los hard forks conllevan riesgos significativos. Requieren que todos los nodos de la red actualicen su software simultáneamente. Si un segmento de la comunidad se niega a actualizar o no está de acuerdo con el cambio, la blockchain puede dividirse en dos cadenas separadas. Esto ocurrió con la creación de Bitcoin Cash, que eligió aumentar el tamaño de bloques mediante un hard fork.
Los desarrolladores de Bitcoin Core priorizaron un enfoque más seguro conocido como soft fork. Un soft fork es una actualización compatible hacia atrás, lo que significa que los nodos que ejecutan versiones antiguas del software aún pueden participar en la red. SegWit fue diseñado como un soft fork para asegurar que la red permaneciera unificada mientras entregaba las mejoras de capacidad necesarias.
Consenso y gobernanza
El camino hacia la activación de SegWit destacó la naturaleza única de la gobernanza de Bitcoin. A diferencia de sistemas centralizados donde un líder dicta los cambios, Bitcoin depende del consenso entre un grupo diverso de participantes. Esto incluye mineros, desarrolladores, operadores de nodos y usuarios finales.
La propuesta para SegWit, conocida como Bitcoin Improvement Proposal (BIP) 141, requería un umbral muy alto de apoyo de los mineros para activarse. Específicamente, el 95% de la potencia de hash de minería necesitaba señalar preparación durante un período de dos semanas. Esta barra alta asegura que las actualizaciones tengan un apoyo abrumador antes de ser impuestas, minimizando el riesgo de inestabilidad en la red.
Cómo funciona SegWit bajo el capó
La innovación principal de Segregated Witness se insinúa en su nombre. «Segregated» significa separar, y «Witness» se refiere a las firmas digitales que verifican una transacción. En las transacciones legacy de Bitcoin, los datos de firma digital estaban entrelazados con los datos de la transacción, ocupando una porción significativa del valioso espacio de 1 MB por bloque.
Separando los datos de Witness
SegWit reestructuró el formato de transacción moviendo los datos de witness (firmas) fuera de la estructura principal del bloque. Aunque estos datos aún se registran y validan, se almacenan en una estructura separada que corre paralela al bloque de transacción base. Esta separación fue la clave para desbloquear más capacidad sin aumentar técnicamente el límite de 1 MB para nodos antiguos.
Para visualizarlo, imagina un tren que representa un bloque de Bitcoin. En el sistema legacy, los pasajeros (detalles de transacción) y su equipaje (firmas) estaban todos apiñados en los mismos vagones. El tren tenía un límite estricto en el volumen que podía transportar.
SegWit añadió efectivamente un vagón de carga especializado al final del tren específicamente para el equipaje. Al mover el equipaje pesado fuera de los vagones de pasajeros, el tren podía llevar de repente significativamente más pasajeros dentro de los mismos compartimentos principales. El «equipaje» aún viaja con el tren, pero ya no ocupa el espacio premium necesario para los pasajeros mismos.
Peso de bloque vs. Tamaño de bloque
Para implementar este cambio, SegWit introdujo un nuevo concepto llamado «block weight». La antigua medición del tamaño de bloque en bytes simples fue reemplazada por un sistema que asigna diferentes «pesos» a diferentes partes de una transacción. Esto permitió a la red diferenciar entre datos críticos de transacción y datos de witness.
Bajo este nuevo sistema, los datos base de transacción se cuentan a su tamaño completo, mientras que los datos de witness se descuentan. Específicamente, los datos de witness pesan significativamente menos que los datos de transacción en el cálculo del límite de bloque. Este cambio aumentó efectivamente el límite de tamaño de bloque de 1 MB a un teórico 4 MB de «unidades de peso».
Este cambio incentivó a usuarios y proveedores de billeteras a adoptar direcciones SegWit. Las transacciones que utilizaban el nuevo formato eran más baratas de enviar porque consumían menos «peso» en un bloque en comparación con transacciones legacy. Este incentivo económico ayudó a impulsar la adopción de la actualización en todo el ecosistema.
Bytes virtuales (vBytes)
Con la introducción del peso de bloque, el concepto de tarifas de transacción también evolucionó. Las tarifas comenzaron a calcularse en «virtual bytes» (vBytes) en lugar de bytes crudos. Un vByte es una unidad de medición derivada del peso de la transacción.
Dado que los datos de witness se descuentan, una transacción SegWit tiene un tamaño en vBytes más pequeño que una transacción legacy del mismo tamaño crudo. Esto significa que para la misma tasa de tarifa (satoshis por byte), una transacción SegWit cuesta menos en tarifas totales.
Esta ganancia de eficiencia fue inmediata para los usuarios que cambiaron a billeteras compatibles con SegWit. Permitó a la red procesar más transacciones por segundo, aumentando efectivamente el rendimiento sin los peligros asociados con un hard fork. La optimización demostró que la ingeniería inteligente podía exprimir más rendimiento de la infraestructura existente.
Resolviendo la maleabilidad de transacciones
Aunque la escalabilidad fue la característica principal de SegWit, la actualización resolvió otro defecto técnico crítico conocido como maleabilidad de transacciones. Este problema había atormentado a Bitcoin desde su inicio y actuaba como una barrera mayor para el desarrollo de protocolos avanzados de segunda capa.
La maleabilidad se refiere a la capacidad de un tercero para cambiar el identificador único (TXID) de una transacción antes de que se confirme en la blockchain. Importante, este cambio podía hacerse sin invalidar la transacción misma ni alterar detalles fundamentales como el remitente, receptor o cantidad.
En el sistema legacy, la firma digital se incluía en el cálculo del hash de la transacción (el TXID). Sin embargo, las firmas criptográficas pueden representarse matemáticamente de maneras ligeramente diferentes mientras permanecen válidas. Un atacante o un nodo de relevo podía modificar ligeramente los datos de firma, lo que resultaría en un TXID completamente diferente.
Si el TXID cambiaba, el remitente podría creer que la transacción falló, mientras que el receptor (o atacante) confirmaba la versión modificada. Esto creaba confusión y hacía peligroso encadenar transacciones no confirmadas. Si la primera transacción en una cadena tenía su ID cambiado, cualquier transacción subsiguiente que la referenciara se volvería inválida.
SegWit corrigió esto al remover los datos de firma de la parte de la transacción utilizada para generar el TXID. Dado que el «witness» estaba segregado, cualquier cambio en los datos de firma ya no afectaría el ID de la transacción. Esto hizo que el ID de la transacción fuera inmutable desde el momento en que se creó.
Habilitando la Lightning Network
La corrección de la maleabilidad de transacciones fue el catalizador para la Lightning Network. La Lightning Network es una solución de escalabilidad de capa 2 que depende en gran medida de la capacidad de crear cadenas de transacciones no confirmadas de manera segura.
La base para la capa 2
Para que los canales de pago funcionen, dos partes abren efectivamente una cuenta conjunta en la blockchain y luego intercambian transacciones firmadas de ida y vuelta fuera de cadena. Estas transacciones fuera de cadena actualizan el saldo del canal sin impactar la blockchain principal.
Sin embargo, estas transacciones fuera de cadena dependen de que la «transacción de financiación» inicial esté anclada de manera segura. Si la maleabilidad de transacciones aún fuera posible, un actor malicioso podría alterar potencialmente el ID de la transacción de financiación. Esto invalidaría toda la lógica fuera de cadena subsiguiente en la que las partes habían acordado.
Al asegurar el ID de la transacción, SegWit proporcionó la base sólida necesaria para estos contratos inteligentes. Permitrió a los nodos de Lightning confiar en que las transacciones que firmaban fuera de cadena permanecerían válidas cuando finalmente se liquidaran en la red principal de Bitcoin.
Liquidaciones instantáneas
Con el riesgo de maleabilidad eliminado, la Lightning Network pudo desplegarse de manera segura. Esto habilitó liquidaciones casi instantáneas de pagos entre usuarios en cualquier parte del mundo. Mientras que SegWit proporcionó un aumento modesto de capacidad en cadena, habilitar Lightning ofreció el potencial para escalabilidad fuera de cadena prácticamente ilimitada.
Los usuarios ahora podían realizar millones de transacciones sin sobrecargar la blockchain principal, liquidando solo el resultado final. Esta combinación de eficiencia en cadena (vía SegWit) y escalabilidad fuera de cadena (vía Lightning) representa la estrategia principal de Bitcoin para manejar el volumen de transacciones global.
La saga de activación: BIP 141 y UASF
El despliegue de SegWit no fue solo una actualización técnica; fue un evento histórico en la gobernanza descentralizada. El proceso reveló las complejas dinámicas de poder entre mineros, desarrolladores y usuarios dentro del ecosistema de Bitcoin.
La propuesta (BIP 141)
La actualización SegWit fue propuesta formalmente como Bitcoin Improvement Proposal 141. Para activarse sin problemas, los desarrolladores establecieron un umbral que requería que el 95% de los bloques señalaran apoyo para la actualización dentro de una época de dificultad de dos semanas. Esto estaba destinado a asegurar que la red no se dividiera.
Sin embargo, lograr este consenso resultó difícil. Varios intereses políticos y económicos entre pools de minería mayores llevaron a un estancamiento. Algunos mineros preferían un hard fork para aumentar directamente el tamaño de bloques, mientras que otros eran reacios a actualizar su infraestructura.
Durante meses, la señalización de activación se mantuvo muy por debajo del umbral requerido. Parecía que la actualización podría estancarse indefinidamente, destacando un potencial defecto en la dependencia de la señalización de mineros para actualizaciones de protocolo.
User Activated Soft Fork (BIP 148)
Frustrados por la falta de progreso, surgió un movimiento de base dentro de la comunidad. Esta iniciativa era conocida como User Activated Soft Fork (UASF), o BIP 148. El concepto era revolucionario: en lugar de esperar a que los mineros votaran, la mayoría económica de nodos (usuarios, exchanges y negocios) impondría la actualización ellos mismos.
Los participantes en la UASF ejecutaban una versión del software de Bitcoin que rechazaba cualquier bloque que no señalara apoyo para SegWit después de una fecha determinada. Esto trazó efectivamente una línea en la arena. Si los mineros continuaban ignorando SegWit, sus bloques serían rechazados por una porción significativa de la red, causándoles pérdida de ingresos.
La amenaza de un User Activated Soft Fork cambió el equilibrio de poder. Demostró que aunque los mineros procesan transacciones, los usuarios definen las reglas del protocolo. Ante la presión económica de la UASF, los mineros cedieron, y SegWit se bloqueó y activó en agosto de 2017.
Tipos de direcciones y compatibilidad
Tras la activación de SegWit, el ecosistema de Bitcoin vio el surgimiento de diferentes formatos de direcciones. Entender estos formatos es esencial para usuarios que desean aprovechar las tarifas más bajas y los beneficios de eficiencia que ofrece SegWit.
Direcciones Legacy
El formato original de direcciones de Bitcoin se conoce como Legacy. Estas direcciones típicamente comienzan con el número 1. Las transacciones enviadas desde direcciones Legacy son más grandes en tamaño porque no utilizan la separación de datos de witness. En consecuencia, son las más costosas en términos de tarifas de transacción.
Nested SegWit (P2SH)
Para asegurar una adopción fluida, los desarrolladores introdujeron una capa de compatibilidad conocida como Pay to Script Hash (P2SH). Estas direcciones comienzan con el número 3. Permitieron a los usuarios enviar transacciones SegWit incluso si la billetera del remitente no soportaba completamente el nuevo formato nativo.
Nested SegWit proporcionó un punto intermedio. Ofreció ahorros significativos en tarifas en comparación con direcciones Legacy, aunque no tanto como la implementación nativa completa. Por mucho tiempo, este fue el estándar para muchos exchanges y proveedores de billeteras mientras actualizaban sus sistemas.
Native SegWit (Bech32)
El formato más eficiente es Native SegWit, también conocido como Bech32. Estas direcciones comienzan con bc1. Las direcciones Native SegWit son distintas porque son insensibles a mayúsculas, reduciendo el riesgo de errores de tipeo.
Más importante aún, las transacciones Native SegWit son más pequeñas en bytes virtuales que sus contrapartes Nested. Esto resulta en las tarifas de transacción más bajas posibles para los usuarios. A medida que el ecosistema ha madurado, Native SegWit se ha convertido en el estándar predeterminado para la mayoría de billeteras y servicios modernos.
| Tipo de dirección | Prefijo | Eficiencia de tarifas | Compatibilidad |
|---|---|---|---|
| Legacy | 1... | Baja | Universal |
| Nested SegWit | 3... | Media | Alta |
| Native SegWit | bc1... | Alta | Billeteras modernas |
Más allá de SegWit: Taproot y Ordinals
La implementación exitosa de SegWit demostró que Bitcoin podía someterse a actualizaciones complejas sin disrupting su propuesta de valor principal. Este éxito allanó el camino para innovaciones subsiguientes que han expandido aún más las capacidades de la red.
Taproot y firmas Schnorr
En noviembre de 2021, Bitcoin activó la actualización Taproot. Taproot se construyó directamente sobre la base establecida por SegWit. Introdujo firmas Schnorr, que permitieron una mayor eficiencia y privacidad.
Al igual que SegWit, Taproot alteró cómo se almacenan los datos en la blockchain. Habilitó la agregación de firmas, donde múltiples firmas en una transacción compleja podían combinarse en una sola firma. Esto hizo que contratos inteligentes complejos fueran indistinguibles de transacciones regulares, mejorando la privacidad mientras ahorraba espacio en bloques.
Sin los cambios estructurales introducidos por SegWit, específicamente el sistema de versionado de scripts, actualizaciones como Taproot habrían sido significativamente más difíciles de desplegar. SegWit estableció un camino claro para la extensibilidad futura.
El auge de Ordinals
Más recientemente, la introducción de Bitcoin Ordinals ha aprovechado la infraestructura de SegWit de maneras inesperadas. Ordinals permiten a los usuarios inscribir datos arbitrarios —como imágenes, texto o código— directamente en satoshis individuales.
Esto es posible porque SegWit descontó el «peso» de los datos de witness. Los inscribidores se dieron cuenta de que podían almacenar grandes cantidades de datos en el campo witness de una transacción por una fracción del costo de almacenarlos en el área principal del bloque. Aunque controvertido para algunos que lo ven como spam, Ordinals demostraron la flexibilidad del espacio de datos de witness.
Este caso de uso inesperado destaca la naturaleza robusta del diseño de SegWit. Al crear un carril separado y descontado para datos, la actualización creó inadvertidamente un lienzo para artefactos digitales, diversificando aún más la utilidad de la blockchain de Bitcoin.
Conclusión
Segregated Witness se erige como un testimonio de la resiliencia y adaptabilidad de la red de Bitcoin. Enfrentando un cuello de botella crítico que amenazaba con sofocar el crecimiento, la comunidad se unió detrás de una solución elegante, compatible hacia atrás y visionaria. Al reimaginar cómo se estructura los datos de transacción, SegWit entregó alivio inmediato de tarifas altas mientras preservaba la descentralización que da valor a Bitcoin.
El legado de SegWit se extiende mucho más allá de simples cálculos de peso de bloque. Resolvió la vulnerabilidad persistente de maleabilidad de transacciones, desbloqueando el potencial para soluciones de escalabilidad de capa 2 como la Lightning Network. Además, estableció un precedente para la gobernanza impulsada por usuarios, probando que la mayoría económica puede controlar efectivamente el poder de las entidades mineras.
A medida que Bitcoin continúa evolucionando, las estructuras construidas por SegWit permanecen centrales en su operación. Desde la eficiencia de las direcciones Native SegWit hasta las capacidades avanzadas de Taproot y Ordinals, la actualización redefinió lo que es posible en la blockchain. Aseguró que Bitcoin pudiera escalar para satisfacer la demanda global sin comprometer los principios sobre los que se fundó.
SegWit revolucionó Bitcoin al separar las firmas de los datos de transacción, aumentando efectivamente la capacidad de bloques y corrigiendo errores críticos para habilitar escalabilidad futura.