Si has abierto un monedero de Bitcoin y te han pedido que elijas entre una dirección «Legacy», «SegWit» o «Native SegWit» sin explicarte qué significa cada una, esa elección se remonta a una única actualización realizada en 2017.
SegWit, abreviatura de «Segregated Witness», es una actualización del protocolo de Bitcoin activada en agosto de 2017 que traslada los datos de la firma digital fuera de la estructura principal de la transacción a un campo independiente denominado «witness». Ese único cambio arquitectónico redujo las comisiones por transacción, solucionó una vulnerabilidad de seguridad que llevaba años presente, conocida como «maleabilidad de las transacciones», y creó las condiciones técnicas para la existencia de Lightning Network y Taproot.
Este artículo explica qué hace realmente SegWit, cómo funciona el sistema de peso de bloques, qué implicaciones tienen los distintos tipos de direcciones para las comisiones, y la polémica batalla política que estuvo a punto de dividir la red de Bitcoin antes incluso de que se activara.
Gestiona tus bitcoins con el Aplicación Bitcoin.com Wallet.
Puntos clave
- SegWit (Segregated Witness) es una actualización del protocolo de Bitcoin que se activó el 24 de agosto de 2017, especificada formalmente como BIP 141 y propuesta por Pieter Wuille, Eric Lombrozo y Johnson Lau en diciembre de 2015.
- Separa los datos de la firma digital (el «testigo») del cuerpo principal de la transacción, lo que soluciona una vulnerabilidad de seguridad denominada «maleabilidad de las transacciones» y reduce el tamaño de cada transacción.
- La capacidad de los bloques se mide en unidades de peso (WU) en lugar de en bytes. Los datos de los testigos ocupan 1 WU por byte, frente a las 4 WU por byte que ocupan otros datos, lo que supone un descuento del 75 % en el tamaño de la firma para las transacciones SegWit.
- SegWit nativo (direcciones bc1q) reduce el tamaño de una transacción estándar de unos 226 vbytes a unos 141 vbytes, lo que supone una reducción de las comisiones de aproximadamente un 38 % en comparación con las direcciones tradicionales.
- La garantía de TXID fijo de SegWit fue el requisito técnico previo para la red Lightning. Sin ella, no habría sido posible crear canales de pago de forma segura.
- Su sistema de control de versiones de scripts permitió la implementación de Taproot (SegWit V1, activado en 2021) y ofrece un marco para futuras actualizaciones de Bitcoin sin necesidad de bifurcaciones duras.
- En 2026, aproximadamente el 85 % de las transacciones con bitcoins utilizan SegWit. Se trata del estándar de la red, no de una nueva función.
¿Qué es SegWit?
SegWit, o «Segregated Witness», es una modificación del formato de las transacciones de Bitcoin que separa las firmas digitales —la prueba criptográfica de que tienes derecho a gastar una moneda— de los datos principales de la transacción, y las almacena en una estructura independiente denominada «witness». Esto reduce el tamaño de cada transacción, permite que quepan más transacciones en cada bloque y elimina una vulnerabilidad que había impedido crear canales de pago de forma segura sobre Bitcoin.
El nombre se explica fácilmente: «segregated» significa «separado», y «witness» es el término criptográfico que designa los datos de la firma que demuestran que una transacción es válida. El «witness» responde a la pregunta «¿ha autorizado esto el propietario legítimo?», mientras que el resto de los datos de la transacción responden a «¿adónde van los fondos y por qué importe?».
The official BIP 141 header on GitHub, showing its three co-authors and December 2015 assignment date.La actualización se definió oficialmente como la Propuesta de Mejora de Bitcoin 141 (BIP 141) y fue propuesta por los desarrolladores de Bitcoin Core Pieter Wuille, Eric Lombrozo y Johnson Lau en la conferencia Scaling Bitcoin celebrada en diciembre de 2015. Se activó en la red principal de Bitcoin el 24 de agosto de 2017, en el bloque 481 824, como una bifurcación suave, lo que significa que era compatible con versiones anteriores. Los nodos que no se habían actualizado podían seguir validando los datos básicos de la transacción; los nodos actualizados veían el panorama completo, incluido el testigo.
En 2026, aproximadamente el 85 % de todas las transacciones con bitcoins utilizan SegWit. Ya no es una novedad, sino la norma.
Los problemas que SegWit se diseñó para resolver
SegWit resolvió dos problemas distintos que llevaban años limitando el desarrollo de Bitcoin.
Maleabilidad de las transacciones
Cada transacción de Bitcoin tiene un identificador único denominado TXID, un hash generado a partir de los datos de la transacción. Antes de SegWit, ese hash se calculaba sobre el conjunto de la transacción, incluida la firma.
El problema es el siguiente: una firma criptográfica no puede firmarse a sí misma. Esto dejaba una pequeña ventana de oportunidad en la que cualquiera que retransmitiera tu transacción por la red podía modificar ligeramente la firma de tal forma que siguiera siendo matemáticamente válida, pero generara un TXID diferente. Los fondos seguían llegando a la dirección correcta y la transacción se completaba, pero el identificador había cambiado.
Esto no parece catastrófico para un simple pago. Sin embargo, para los protocolos que encadenan varias transacciones sin confirmar, resulta fatal. La Red Lightning, que funciona creando una serie de compromisos de pago fuera de cadena que hacen referencia a ID de transacciones anteriores, no puede funcionar de forma segura si alguno de esos ID puede cambiar antes de que se confirmen. Un TXID mutable significa que la cadena se rompe, y los fondos pueden quedar bloqueados o ser robados.
La maleabilidad de las transacciones también causó daños reales antes de que se solucionara. La plataforma de intercambio Mt. Gox la citó como uno de los factores que contribuyeron a su quiebra en 2014, aunque los historiadores debaten hasta qué punto fue la causa principal o, por el contrario, una excusa para encubrir una mala gestión más profunda.
SegWit resolvió este problema eliminando por completo las firmas del cálculo del TXID. Ahora, el identificador se calcula únicamente a partir de los campos básicos de la transacción. Modificar la firma ya no altera la identidad de la transacción.
Evita la congestión y el aumento de las tarifas
En 2016 y hasta bien entrado 2017, Bitcoin procesaba aproximadamente 7 transacciones por segundo. Durante los picos de demanda, los atrasos en las transacciones alcanzaban decenas de miles y las comisiones subían a 50 dólares o más por un envío estándar. El problema era estructural: los bloques de Bitcoin tenían un límite de 1 MB, y las firmas representaban aproximadamente el 65 % del tamaño de la transacción.
La solución más obvia, aumentar el límite del tamaño de los bloques, requería una bifurcación dura, lo que significaba que todos los nodos tendrían que actualizarse o quedarse en una cadena incompatible. Las bifurcaciones duras son muy arriesgadas y controvertidas. SegWit encontró una forma de sortear por completo esta limitación.
Cómo funciona SegWit
Separación de los datos de los testigos
En una transacción Bitcoin tradicional, cada entrada incluye un campo ScriptSig que contiene la firma y la clave pública del remitente. En una transacción SegWit, el campo ScriptSig se deja vacío para las entradas SegWit. La firma y la clave pública se trasladan a un nuevo campo «witness» que se añade al final de la transacción.
Dos bytes adicionales, un marcador (0x00) y un indicador (0x01), indican a los nodos compatibles con SegWit que a continuación vienen los datos del testigo. Los nodos anteriores a SegWit simplemente ven un ScriptSig vacío y procesan la transacción como válida según la interpretación anterior de «cualquiera puede gastar», lo que garantiza la compatibilidad con versiones anteriores.
El peso del bloque sustituye al tamaño del bloque
SegWit sustituyó el límite de tamaño de bloque de 1 MB por una nueva métrica: el peso del bloque, con un límite máximo de 4 millones de unidades de peso (WU).
El detalle clave radica en cómo se cuentan los bytes:
- Cada byte de datos de transacciones sin testigo cuesta 4 unidades de peso
- Cada byte de datos de testigo cuesta solo 1 unidad de peso
Dado que las firmas son de gran tamaño y ahora se almacenan en la sección «witness», ocupan una cuarta parte de la capacidad de bloque que solían ocupar. Así es como SegWit aumentó el tamaño efectivo de los bloques hasta unos 1,7-2 MB en la práctica, sin alterar la regla del 1 MB que aplican los nodos antiguos. En el caso de un bloque teórico totalmente SegWit, el máximo es de 4 MB, aunque esto nunca ocurre en la práctica porque cada bloque también contiene datos que no son de testigo.
Bytes virtuales (vBytes): la unidad que aparece en los monederos
Para que las tarifas sigan siendo comparables a las de las transacciones tradicionales, SegWit introdujo los bytes virtuales (vbytes): unidades de peso divididas por 4. En las transacciones tradicionales, los bytes y los vbytes son idénticos. En las transacciones SegWit, los vbytes son menores porque los datos de testigo reducidos disminuyen el número.
Las comisiones de los monederos se expresan en satoshis por vbyte (sat/vB). Una transacción SegWit con menos vbytes paga menos en comisiones con la misma tasa de sat/vB. Este es el mecanismo que explica el ahorro en comisiones que se observa al utilizar una dirección bc1q en lugar de una dirección 1...
Tipos de direcciones SegWit: ¿cuál deberías usar?
SegWit introdujo nuevos formatos de dirección junto con sus cambios técnicos. El tipo de dirección determina cómo codifica tu monedero las condiciones de gasto, lo que afecta a tus comisiones, a tu compatibilidad con otros monederos y al aspecto que tienen tus transacciones en la cadena.
Comparación de tipos de direcciones
1...3...bc1q... 42 caracteresbc1q... 62 caracteresbc1p... 62 caracteres1...3...bc1q... 42 caracteresbc1q... 62 caracteresbc1p... 62 caracteresDatos sobre el volumen de las transacciones: Referencia sobre el tamaño de las transacciones de Bitcoin de Spark.money, 2026. El ahorro en comisiones es aproximado y varía en función de las condiciones del mempool.
Legado (P2PKH, prefijo 1...) Es el formato original de 2009. La firma permanece dentro del cuerpo principal de la transacción, donde cuenta con todo su peso. No supone ningún ahorro en comisiones. Sigue siendo compatible con todos los sistemas, lo cual es la única razón para utilizarlo hoy en día, si se trabaja con software muy antiguo que no admite ningún otro formato.
SegWit anidado (P2SH-P2WPKH, prefijo 3...) envuelve un script SegWit dentro de un sobre P2SH más antiguo. Cuando se activó SegWit en 2017, no todos los monederos y plataformas de intercambio incorporaron de inmediato la compatibilidad con el nuevo formato bc1. El SegWit anidado sirvió de puente de compatibilidad: permite un ahorro parcial en las comisiones y los remitentes que utilizan software más antiguo pueden seguir realizándote pagos. Para 2026, este formato existe principalmente como alternativa. El 3... El prefijo es el mismo que el de las direcciones P2SH que no son SegWit, lo que significa que, solo con la dirección, no se puede saber si se trata de una transacción SegWit.
SegWit nativo (P2WPKH, prefijo bc1q...(42 caracteres) es la opción más adecuada para la mayoría de los usuarios. Utiliza la codificación Bech32, que se escribe íntegramente en minúsculas, ofrece una mejor detección de errores que Base58 y elimina los caracteres que se parecen entre sí (sin la O mayúscula, el cero, la I mayúscula ni la l minúscula). Una transacción P2WPKH estándar de 1 entrada y 2 salidas cuesta unos 141 vbytes, aproximadamente un 38 % menos que la transacción heredada equivalente. Todas las carteras y plataformas de intercambio activas la admiten a partir de 2026.
Multifirma nativa de SegWit (P2WSH, prefijo bc1q...(62 caracteres) es la variante de hash de script, utilizada para carteras multisig y condiciones de gasto complejas. La dirección más larga refleja un hash SHA-256 de 32 bytes en lugar del hash de 20 bytes utilizado por P2WPKH. Si estás ejecutando una configuración multisig 2 de 3, P2WSH es la forma nativa de SegWit de hacerlo.
Taproot (P2TR, prefijo bc1p...(62 caracteres) Es la versión 1 de SegWit, activada en 2021. Utiliza firmas Schnorr en lugar de ECDSA, lo que permite agregar múltiples firmas en una sola, haciendo que las transacciones multisig sean indistinguibles de las de firma única en la cadena. Ofrece las comisiones más bajas para los gastos de firma única y la mejor privacidad. Úsala cuando hayas confirmado que tus destinatarios y sus carteras admiten direcciones bc1p.
Recomendación rápida
Para la mayoría de los usuarios: utilicen SegWit nativo (bc1q). Es compatible con prácticamente todos los monederos y plataformas de intercambio activos, permite ahorrar alrededor de un 38 % en comisiones en comparación con el sistema tradicional y no presenta ningún riesgo de incompatibilidad en 2026 (para los desarrolladores que integren SegWit en el software de monederos, consulten la Guía de desarrollo de la cartera Bitcoin Core.).
Si tu monedero es compatible con Taproot (bc1p) y realizas transacciones con una sola firma con destinatarios cuyos monederos también lo admiten, esto te permite obtener comisiones ligeramente más bajas y una mayor privacidad.
SegWit anidado (3...) es una solución de compatibilidad. Está bien, pero ya no hay motivo para utilizarlo por defecto.
La guerra del tamaño de bloque: por qué SegWit fue tan polémico
Los argumentos técnicos a favor de SegWit eran claros. Sin embargo, el camino hacia su activación no lo era.
Entre 2015 y 2017, Bitcoin se vio envuelta en una de las disputas de gobernanza más polémicas de su historia. En esencia, la cuestión era sencilla: ¿cómo debería una red descentralizada actualizar sus propias reglas cuando las distintas facciones tienen intereses contrapuestos?
El punto muerto de la minería
Según el proceso estándar de actualización BIP9, un soft fork requería que el 95 % de los mineros manifestaran su apoyo en un plazo de dos semanas. A principios de 2017, SegWit llevaba meses listo para activarse, pero seguía sin alcanzar ese umbral.
La oposición más significativa provino de las grandes empresas mineras, en particular de Bitmain, que en aquel momento controlaba una parte sustancial del hashrate de Bitcoin. La razón quedó clara más tarde: Bitmain utilizaba una técnica patentada llamada ASICBoost, una optimización que proporcionaba a su hardware de minería una ventaja significativa en términos de eficiencia. SegWit era estructuralmente incompatible con el ASICBoost oculto. Bloquear SegWit protegía esa ventaja.
BIP 148 y la UASF
En marzo de 2017, un desarrollador anónimo que utilizaba el seudónimo Shaolinfry publicó el BIP 148: una bifurcación suave activada por los usuarios (UASF). En lugar de esperar a la señal de los mineros, el BIP 148 proponía que los nodos económicos —es decir, las plataformas de intercambio, los procesadores de pagos y las empresas que utilizan software de Bitcoin— simplemente comenzaran a rechazar cualquier bloque que no indicara compatibilidad con SegWit a partir del 1 de agosto de 2017.
La lógica era sencilla: los mineros producen bloques, pero estos solo tienen valor si la red los acepta. Si una mayoría económica suficiente ejecutaba nodos BIP 148, los mineros tendrían que activar SegWit o ver cómo sus bloques quedaban huérfanos. El riesgo era igualmente claro: si la adopción era insuficiente, se produciría una bifurcación de la cadena, con dos versiones incompatibles de Bitcoin funcionando en paralelo.
La campaña UASF fue una iniciativa popular y muy sonada. Empezaron a aparecer insignias de la conferencia. Las discusiones en Twitter se intensificaron. La frase «ejecuta tu propio nodo» cobró una nueva urgencia.
El Acuerdo de Nueva York y Bitcoin Cash
Ante la fecha límite del UASF, más de 50 importantes empresas del sector del bitcoin se reunieron en Nueva York en mayo de 2017 y firmaron lo que se conoció como el Acuerdo de Nueva York. Acordaron activar SegWit, pero también llevar a cabo a continuación una bifurcación dura para duplicar el tamaño de los bloques a 2 MB (lo que se conoció como SegWit2x).
El acuerdo no satisfizo plenamente a ninguna de las dos partes. Los desarrolladores que se oponían a los bloques de mayor tamaño consideraban que SegWit2x era una bifurcación dura encubierta con la que no habían dado su consentimiento. Los mineros y las empresas que deseaban bloques más grandes seguían sin conseguir lo que inicialmente pretendían.
El 1 de agosto de 2017, una facción que abogaba por un aumento puro del tamaño de los bloques, sin SegWit, llevó a cabo una bifurcación de Bitcoin para crear Bitcoin Cash (BCH), con un límite de bloque inicial de 8 MB. SegWit se activó en Bitcoin el 24 de agosto de 2017. La bifurcación dura SegWit2x se abandonó en noviembre de 2017 después de que sus organizadores llegaran a la conclusión de que no contaban con el consenso suficiente.
En qué se acordó
El resultado tuvo una importancia que traspasó los detalles técnicos. La UASF había funcionado: fueron los nodos económicos, y no los mineros, los que determinaron qué reglas de consenso se aplicaban. Esto se cita ahora con frecuencia como una demostración de que la gobernanza de Bitcoin recae, en última instancia, en quienes ejecutan y utilizan el software, y no en quienes producen bloques. El 1 de agosto es conocido por algunos sectores de la comunidad como el «Día de la Independencia de Bitcoin».
Lo que ha hecho posible SegWit
La Red Lightning
La Red Lightning se diseñó antes de que existiera SegWit. Sus creadores sabían que no se podía implementar de forma segura hasta que se solucionara el problema de la maleabilidad de las transacciones, ya que los canales de pago dependen de cadenas de transacciones sin confirmar que se refieren entre sí mediante el TXID. La garantía de TXID fijo que ofrece SegWit hizo que esos canales fueran seguros.
La red Lightning se puso en marcha en la red principal de Bitcoin a principios de 2018, aproximadamente seis meses después de la activación de SegWit. Para el primer trimestre de 2025, ya había procesado más de 100 millones de transacciones. Sin SegWit, nada de esa infraestructura existiría.
Taproot y el control de versiones de scripts
SegWit introdujo el control de versiones de script en el formato de transacción de Bitcoin. El programa «witness» comienza con un byte de versión: SegWit V0 es compatible con P2WPKH y P2WSH. Cualquier actualización futura que defina un nuevo número de versión contará con sus propias reglas sin entrar en conflicto con las ya existentes y sin necesidad de otra polémica batalla por la actualización.
SegWit V1 es Taproot, que se activó en noviembre de 2021. Introdujo las firmas Schnorr, el marco MAST (Merkelized Abstract Syntax Trees) para condiciones de gasto complejas y mejoras en la privacidad que hacen que las carteras multisig parezcan idénticas a las transacciones de firma única en la cadena. Todas las capacidades técnicas que introdujo Taproot se basaban en la arquitectura de versiones creada por SegWit.
Números ordinales e inscripciones
La misma estructura de datos de testigos que introdujo SegWit, y que Taproot amplió, hizo técnicamente viable incrustar datos arbitrarios, imágenes, texto y código directamente en las transacciones de Bitcoin. Este es el mecanismo que subyace al protocolo Ordinals y a las inscripciones de Bitcoin, lo que impulsó un aumento en el uso de datos en cadena y llevó la adopción de Taproot a aproximadamente el 42 % de las transacciones en 2024. A medida que la actividad de inscripciones disminuyó, el uso de Taproot se estabilizó en torno al 20 % de las transacciones a finales de 2025, mientras que SegWit V0 sigue siendo el formato dominante con alrededor del 85 %.
SegWit en contexto: cronología de las actualizaciones de Bitcoin
Adopción actual
La adopción de SegWit creció de forma constante tras su activación, alcanzando el 30 % de las transacciones en los primeros meses, para luego superar la barrera del 50 % en los dos años siguientes, a medida que los monederos y las plataformas de intercambio actualizaban su software.
En 2026, aproximadamente el 85 % de las transacciones de Bitcoin utilizan SegWit (fuente: Estadísticas de la red Bitcoin de Spark.money, CoinGecko). El 15 % restante corresponde a transacciones heredadas de carteras y servicios que no se han actualizado. La adopción de Taproot (P2TR, SegWit V1) alcanzó su máximo en aproximadamente el 42 % de las transacciones en 2024, impulsada en gran medida por la actividad de inscripción de Ordinals, antes de estabilizarse en torno al 20 % a finales de 2025, a medida que disminuyó el volumen de inscripciones.
La curva de adopción refleja lo que ocurrió con el propio SegWit: los nuevos formatos de dirección tardan entre uno y tres años en alcanzar una adopción generalizada, a medida que los monederos físicos, las plataformas de intercambio y los procesadores de pagos actualizan su software. La compatibilidad con Taproot sigue ampliándose en las distintas implementaciones de monederos.
SegWit frente a Legacy: resumen de las diferencias
1...bc1q... (nativo) o 3... (anidado)1...bc1q... (nativo) o 3... (anidado)Conclusión
SegWit es la actualización del protocolo que separó los datos de las firmas de Bitcoin de los datos de las transacciones, corrigió una vulnerabilidad de seguridad que existía desde 2009, redujo las comisiones por transacción en aproximadamente un tercio y sentó las bases arquitectónicas para la Red Lightning, Taproot y todo lo que se ha desarrollado a partir de ellos desde entonces.
Desde 2026, es el estándar de transacciones en Bitcoin y procesa la gran mayoría de la actividad en cadena. Los formatos de dirección que introdujo, en particular el SegWit nativo (bc1q), son los que la mayoría de los usuarios deberían utilizar por defecto en la actualidad. La batalla política que rodeó su activación sigue siendo uno de los capítulos más instructivos de la historia de la gobernanza de Bitcoin: una demostración de que, en una red descentralizada, el consenso no es algo que conceden los mineros, sino algo que afirman los usuarios.
