La evolución de Bitcoin no ha estado marcada por cambios frecuentes, sino por actualizaciones puntuales que redefinen sus límites. Entre ellas, SegWit ocupa un lugar clave por haber modificado la forma en que la red procesa transacciones, sin alterar sus reglas fundamentales ni fragmentar el consenso.
1 ¿Qué es SegWit y por qué se creó en Bitcoin?
Segregated Witness (SegWit), cuya traducción es “Testigo Segregado”, consiste en una actualización del protocolo de Bitcoin que modifica el formato de las transacciones para mejorar su eficiencia y seguridad.
Técnicamente, se trata de una bifurcación suave (soft fork) del protocolo implementada como la Propuesta de Mejora de Bitcoin BIP141, diseñada para realizar cambios compatibles con versiones anteriores sin dividir la cadena de bloques en dos redes distintas.
El contexto en el que surgió SegWit está directamente relacionado con las limitaciones de escalabilidad de Bitcoin. La red procesa un número limitado de transacciones por segundo debido al límite de 1 MB por bloque con el que fue diseñada.
Límite para preservar la naturaleza descentralizada
Vale destacar que este límite no fue arbitrario: se estableció como un mecanismo de protección para preservar la descentralización, evitando que bloques demasiado grandes encarecieran los requisitos de almacenamiento, ancho de banda y procesamiento necesarios para ejecutar un nodo completo. No obstante, en momentos de alta demanda, esta restricción provoca congestión en la red, aumento de comisiones y mayores tiempos de confirmación.
SegWit fue propuesto en 2015 por desarrolladores como Pieter Wuille e implementado en la red en agosto de 2017 para mitigar estos problemas sin aumentar el tamaño de bloque de forma radical.
Objetivos de SegWit
Los objetivos técnicos de SegWit eran múltiples y complementarios. Por un lado, Por un lado, buscaba poner fin a la maleabilidad de las transacciones, una característica del diseño original de Bitcoin que permitía modificar ciertos elementos de una transacción —específicamente su firma criptográfica— sin alterar su validez ni el movimiento real de fondos.
Debido a que el identificador de transacción (TXID) se calculaba incluyendo la firma, pequeños cambios en esta podían generar un identificador distinto para una misma transacción antes de su confirmación en un bloque. Esto no permitía robar fondos ni violar las reglas de consenso, pero sí introducía incertidumbre técnica.
El problema se volvía especialmente relevante cuando una transacción dependía de otra no confirmada. Si el TXID de la primera cambiaba antes de ser incluida en un bloque, cualquier transacción construida sobre ella debía ajustarse, lo que complicaba el diseño de sistemas que necesitaban encadenar operaciones de forma segura y predecible. Esta limitación era un obstáculo directo para el desarrollo de soluciones de segunda capa como Lightning Network.
Por otro lado, al separar los datos de firma, SegWit libera espacio dentro de los bloques, mejorando la eficiencia y aumentando la cantidad de transacciones que pueden incluirse sin incrementar drásticamente el tamaño máximo de cada bloque. Esto fue clave para hacer que la red Bitcoin fuera más escalable de manera progresiva y sin alterar sus reglas de consenso de forma disruptiva.
¿Por qué Segregated Witnes?
El nombre “Segregated Witness” hace referencia a que las firmas digitales, que actúan como “testigos” de la validez de la transacción, se separan del resto de la estructura de la transacción. En el formato original, las firmas formaban parte de los datos utilizados para calcular el TXID; como podían modificarse sin invalidar la transacción, también podían alterar su identificador antes de la confirmación, dando lugar a la maleabilidad. SegWit excluye las firmas del cálculo del TXID y las ubica en una estructura separada, estabilizando el identificador y optimizando el uso del espacio en bloque.
2 ¿Cómo funciona SegWit?
SegWit reorganiza la forma en que Bitcoin almacena y valida las transacciones al separar los datos de firma (witness) del resto de la transacción. Antes de SegWit, cada transacción llevaba la información de entrada, salida y las firmas criptográficas juntas, lo que aumentaba considerablemente el espacio que ocupaban dentro de un bloque.
Con SegWit, esa firma —el «witness»— se extrae y se coloca en una estructura de datos separada dentro del bloque. A partir de esta actualización, el límite deja de medirse estrictamente en 1 MB de bytes y pasa a definirse en términos de “peso de bloque”, con un máximo de 4 millones de weight units.
Técnicamente, cada byte de datos de firma en el witness pesa menos —es decir, tiene menor “peso de bloque”— que los bytes de la transacción base, lo que permite empaquetar más transacciones en un solo bloque y usar mejor el espacio disponible.
El bloque más pesado tras SegWit
Como dato curioso, el bloque más “pesado” registrado en la red tras la activación de SegWit alcanzó aproximadamente 3.993.000 weight units, muy cercano al límite teórico de 4 millones.
Estructura de las transacciones en SegWit
En cuanto a la nueva estructura de las transacciones, una transacción SegWit típicamente consiste en:
- La transacción base, que incluye inputs, outputs y reglas básicas de valor,
- Y una sección separada de witness data, donde están las firmas y scripts necesarios para desbloquear los fondos.
Esta organización hace que el cálculo del identificador de transacción (TXID) se base únicamente en la parte base de la transacción, excluyendo los datos de firma. Al no depender de esos datos para el TXID, se elimina el problema de maleabilidad, que permitía que firmas ligeramente distintas sobre la misma transacción generaran identificadores distintos.
Aunque el witness se coloca en una estructura separada, no está fuera de la cadena ni “off-chain”: todos los nodos actualizados descargan y validan estos datos como parte de la cadena de bloques. Sin embargo, aquí es donde entra una diferencia crucial respecto a los nodos que no han actualizado a SegWit.
SegWit vs los nodos legacy
Respecto a SegWit, se denomina nodos legacy a aquellos nodos que operan bajo las reglas de consenso anteriores a la activación de esta actualización y que no han sido modificados para interpretar el nuevo formato de transacciones.
El término “legacy” no implica que estos nodos sean inseguros o inválidos, sino que desconocen la estructura específica del witness, introducida por SegWit. Precisamente por esta razón, SegWit fue diseñado como una soft fork, de modo que los nodos legacy puedan seguir participando en la red sin necesidad de actualizarse.
Gracias a este diseño, los nodos legacy todavía pueden verificar que las transacciones SegWit forman parte válida de la cadena, aun sin procesar ni comprender los datos del witness. Esto es posible porque los bloques SegWit incluyen un compromiso criptográfico del witness (witness commitment), que se inserta dentro de la estructura del bloque.
De esta forma, los nodos que no reconocen SegWit pueden verificar la continuidad de la cadena y la Prueba de trabajo sin necesidad de evaluar las firmas segregadas, mientras que los nodos actualizados sí validan esos datos de manera completa.
Lo que puede hacer un nodo legacy
En la práctica, esto significa que un nodo legacy aún puede:
- Validar que un bloque cumple con las reglas generales de tamaño y formato,
- Comprobar que la Prueba de trabajo (Proof of Work) es válida,
- Leer la estructura básica de las transacciones, aunque sin interpretar los datos del witness.
Estas capacidades son suficientes para que el nodo acepte el bloque como válido según las reglas antiguas, garantizando la compatibilidad hacia atrás que caracteriza a una soft fork.
Por el contrario, los nodos actualizados a SegWit interpretan y verifican completamente tanto la transacción base como los datos del witness, incluidas las firmas criptográficas.
Direcciones legacy vs direcciones SegWit (bech32)
Las direcciones también cambiaron con la llegada de SegWit. Las direcciones legacy (anteriores) suelen comenzar con “1” o “3”, mientras que las direcciones SegWit modernas utilizan el formato bech32, que comienza con “bc1”.
Ejemplos:
- Dirección legacy (P2PKH):
1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
- Dirección legacy tipo script (P2SH):
3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy
- Dirección SegWit (bech32):
bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kygt080
El formato bech32 fue introducido para mejorar la eficiencia de las direcciones y reducir errores al copiarlas. Además, es compatible con SegWit y permite transacciones con menor peso en la red, contribuyendo a optimizar el uso del espacio en los bloques.
3 Bitcoin antes y después de SegWit
Antes de SegWit, la maleabilidad obligaba a los desarrolladores a diseñar soluciones complejas para manejar transacciones dependientes entre sí. Cualquier aplicación que necesitara encadenar transacciones —o reaccionar ante una transacción aún no incluida en un bloque— debía asumir que su identificador podía cambiar en el proceso. Esto afectaba tanto a servicios de pago como al desarrollo de mecanismos más avanzados sobre Bitcoin.
La corrección de este problema era clave para el crecimiento del ecosistema. Al estabilizar el TXID y hacerlo independiente de las firmas, SegWit eliminó una fuente histórica de incertidumbre técnica y permitió construir protocolos que dependen de referencias fiables a transacciones pendientes.
Este cambio fue especialmente relevante para el desarrollo de soluciones de segunda capa, como Lightning Network, que requieren identificadores inmutables para abrir y gestionar canales de pago de forma segura.
En este sentido, SegWit no solo resolvió un inconveniente técnico heredado de las primeras versiones de Bitcoin, sino que sentó una base más sólida para la evolución del protocolo y la expansión de su funcionalidad sin comprometer sus principios de compatibilidad y consenso.
¿SegWit aumenta el tamaño del bloque de Bitcoin?
Aunque SegWit no aumenta el tamaño nominal de los bloques de Bitcoin, sí incrementa la capacidad de transacciones por bloque al separar las firmas (witness) de los datos principales de la transacción. Gracias al sistema de “peso de bloque” (block weight), los bloques pueden contener hasta un 60 % más de transacciones efectivas dentro del límite de consenso, mejorando la escalabilidad y reduciendo la congestión de la red sin alterar el límite tradicional de 1 MB.
4 ¿Cómo afecta SegWit a las comisiones y a la experiencia del usuario?
SegWit modifica la manera en que se calculan las comisiones al introducir el concepto de tamaño virtual (vsize), que reemplaza al tamaño tradicional en bytes para estimar el costo de una transacción.
El vsize es una métrica ponderada que refleja la estructura real de la transacción tras SegWit, donde los datos de firma (witness) pesan menos que los datos base, y por ello suelen requerir menos satoshis por unidad de espacio en comparación con transacciones legacy. Esto hace que las comisiones se expresen en satoshis por vbyte (sat/vB), lo que permite estimar fees de forma coherente con el mercado actual de bloques.
Este cambio genera incentivos económicos importantes para el uso de direcciones SegWit. Al ocupar menos vbytes por transacción equivalente, los usuarios que envían desde formatos SegWit (como P2WPKH o P2SH-SegWit) suelen pagar menores comisiones para lograr la misma prioridad de inclusión en un bloque.
En otras palabras, SegWit permite que transacciones de igual propósito consuman menos espacio efectivo dentro de un bloque, lo que tiende a reducción del coste por envío en comparación con direcciones tradicionales.
Su utilidad cuando la mempool se congestiona
Además, en periodos de alta demanda de la red, cuando la mempool se congestiona y los usuarios compiten por espacio limitado en los bloques, SegWit contribuye a aliviar presiones de tarifas al permitir que los bloques procesen más transacciones efectivas dentro del mismo límite de consenso.
Al reducir el peso promedio de cada transacción, se disminuye la competencia directa por el espacio en bloque, lo que puede traducirse en fees globalmente más contenidos y una experiencia de usuario más predecible durante picos de actividad.
5 SegWit, la controversia y su legado en Bitcoin
La implementación de SegWit como soft fork fue una decisión deliberada para introducir cambios compatibles con versiones anteriores del protocolo Bitcoin. A diferencia de un hard fork, un soft fork introduce reglas más restrictivas para la validación de bloques y transacciones, sin invalidar retroactivamente los bloques ya aceptados. Esto permite que los nodos que no se actualizan sigan participando en la red, aunque no reconozcan las nuevas reglas
Esto fue clave para introducir SegWit sin crear una bifurcación incompatible. Sin embargo, el debate sobre escalabilidad sí generó tensiones que desembocaron en bifurcaciones posteriores, como Bitcoin Cash.
¿SegWit tiene desventajas o limitaciones?
Si bien SegWit introdujo mejoras importantes en eficiencia y diseño del protocolo, su adopción fue gradual. Durante los primeros años tras su activación, muchas wallets y exchanges tardaron en implementar soporte completo para direcciones SegWit, lo que limitó inicialmente el impacto real en comisiones y uso de espacio en bloque. Esta adopción progresiva redujo los beneficios inmediatos esperados para el conjunto de la red.
Sin embargo, la propuesta generó debate y controversia importantes dentro de la comunidad debido a cómo se abordaba la escalabilidad de Bitcoin. Algunos participantes consideraban que SegWit no aumentaba lo suficiente la capacidad de la red y que se dependía demasiado de soluciones fuera de la cadena.
En este contexto surgió el proyecto SegWit2x, una propuesta que combinaba la activación de SegWit con un hard fork para duplicar el tamaño de los bloques de 1 MB a 2 MB, con el objetivo de mejorar la escalabilidad de forma más agresiva.
Aunque SegWit2x logró apoyo de grupos de mineros y empresas tras el llamado “Acuerdo de Nueva York”, encontró resistencia en desarrolladores, operadores de nodos y buena parte de la comunidad por preocupaciones de consenso, centralización y falta de apoyo amplio, y finalmente fue cancelado antes de su activación por falta de consenso general.
¿Qué fue el Acuerdo de Nueva York?
El Acuerdo de Nueva York (New York Agreement) fue un pacto alcanzado en mayo de 2017 entre empresas y pools de minería que propuso la hoja de ruta SegWit2x: activar SegWit mediante una soft fork y luego aumentar el tamaño del bloque a 2 MB mediante un hard fork. El acuerdo generó críticas por negociarse fuera del proceso abierto de consenso de Bitcoin, por lo que la ampliación a 2 MB fue cancelada. SegWit se activó de forma independiente, y poco después se produjo una bifurcación que dio origen a Bitcoin Cash, reflejando las tensiones del debate sobre escalabilidad dentro del ecosistema.
6 Proyectos posteriores: Lightning Network y Taproot
En contraste con aquella controversia, SegWit sentó bases importantes para mejoras posteriores del protocolo y para capas secundarias. Como mencionábamos en párrafos anteriores, una de las innovaciones más relevantes habilitadas por SegWit fue la Lightning Network, una solución de segunda capa que permite pagos casi instantáneos y de bajo costo al abrir canales de pago fuera de la cadena principal —una posibilidad que dependía de la corrección de la maleabilidad de transacciones introducida por SegWit.
A su vez, el desarrollo de Taproot —activado en 2021— es considerado el upgrade técnico más significativo después de SegWit. Aunque Taproot no depende directamente de SegWit como requisito funcional, se apoya en el modelo de witness que SegWit introdujo, ya que ese esquema de transacciones y estructura técnica es lo que permite implementar innovaciones como Schnorr signatures, MAST y nuevas formas de scripts más eficientes y privadas.
Taproot extiende las capacidades del protocolo al optimizar firmas, mejorar privacidad y ampliar la flexibilidad de contratos inteligentes sobre Bitcoin, sin cambiar las reglas fundamentales de consenso ni requerir un hard fork.
En conjunto, la controversia en torno a SegWit y SegWit2x refleja la naturaleza descentralizada del desarrollo de Bitcoin, donde los cambios se debaten ampliamente y requieren consenso entre nodos, desarrolladores, operadores y usuarios.
El legado de SegWit no solo pasó por la corrección técnica de limitaciones históricas, sino por allanar el camino para Lightning, Taproot y otras capas secundarias, configurando una evolución que busca aumentar la escalabilidad y funcionalidad del protocolo sin comprometer su seguridad ni su consenso.
