Explicación de SegWit: Peso de los bloques, tarifas y direcciones

Segregated Witness, o SegWit, es una bifurcación suave de Bitcoin que separa los datos de testigo de la serialización de la transacción utilizada para el identificador de transacción (txid). Los datos de testigo permanecen como parte de la transacción y el bloque completos; no se transfieren fuera de la cadena. BIP141 introduce nuevas reglas de validación y ponderación de bloques, manteniendo la compatibilidad con la vista de bloque de los nodos heredados.

SegWit limita el peso de los bloques a 4,000,000 de unidades de peso. Los bytes que no son testigos se contabilizan cuatro veces y los bytes testigos una vez. Por lo tanto, el tamaño total de los bytes serializados depende de la composición de la transacción y puede alcanzar los 4 MB en bloques con muchos testigos; 1.8–2.1 MB no es un límite del protocolo. Un byte virtual corresponde a cuatro unidades de peso, redondeadas al alza para obtener el tamaño virtual de la transacción. (Fuente: BIP141 Segregated Witness )

SegWit elimina los datos de testigo del cálculo del txid, solucionando así la maleabilidad involuntaria basada en testigos para las transacciones que cumplen los requisitos. No hace que todos los identificadores de transacción sean inmutables: modificar campos que no son de testigo, reemplazar una transacción o incluir entradas heredadas maleables aún puede tener consecuencias. Esta mejora facilita la construcción de cadenas de transacciones pre-firmadas, incluidas las utilizadas por Lightning.

Origen e Historia

Antecedentes de la investigación: SegWit se basa en discusiones previas sobre la maleabilidad de las transacciones, la separación de testigos y las actualizaciones de protocolo compatibles.

Diciembre de 2015: Pieter Wuille presenta Segregated Witness en Scaling Bitcoin en Hong Kong, explicando sus ventajas en cuanto a maleabilidad y capacidad.

Especificaciones técnicas: BIP141 define los cambios en el consenso, BIP143 especifica el hash de firmas para los programas testigo de la versión 0, y BIP144 describe los cambios en el servicio entre pares y la serialización. Se trata de especificaciones distintas con diferentes alcances y autores.

Mayo de 2017: Litecoin activó SegWit en su red antes que Bitcoin, sirviendo como banco de pruebas real que demostró la estabilidad y seguridad de la actualización en un entorno de producción. La exitosa activación de Litecoin reforzó la confianza en la implementación de SegWit en Bitcoin.

Julio-agosto de 2017: BIP91, BIP148 y el proceso de activación existente desempeñan diferentes roles en el controvertido período de implementación de SegWit. Bitcoin Cash se divide el 1 de agosto; SegWit se activa en Bitcoin más adelante ese mismo mes.

24 de agosto de 2017 : SegWit se activó oficialmente en la red principal de Bitcoin en el bloque 481,824. Esta activación representó la conclusión de uno de los debates más polémicos en la historia de Bitcoin, conocido como la "Guerra del Tamaño del Bloque".

Tras la activación: Las carteras y los servicios adoptan SegWit nativo y encapsulado. Las direcciones nativas de la red principal de la versión 0 comienzan con bc1q; una dirección que comienza con 3 es P2SH y no necesariamente es SegWit.

Noviembre de 2021: Taproot se activa utilizando la versión 1 del testigo, con firmas Schnorr y compromisos del árbol de scripts.

Uso actual: SegWit sigue formando parte de las reglas de consenso de Bitcoin. Los porcentajes de adopción y la capacidad pública de Lightning son métricas cambiantes que requieren un conjunto de datos actualizado y una metodología clara.

En términos simples

1. Imagina enviar una carta en un sobre. La carta es el mensaje propiamente dicho (los detalles del pago) y el sello de cera es tu firma que prueba su autenticidad. Antes de SegWit, tanto la carta como el sello debían caber dentro de un sobre pequeño. SegWit te permite colocar el sello en una bolsa aparte, de modo que el sobre principal pueda contener más cartas mientras los sellos se siguen llevando para su verificación.
2. Piensa en una regla de envío que aplica tarifas diferentes según el peso de dos tipos de material. SegWit modifica la forma en que los datos se contabilizan para la capacidad; todos los datos de validación necesarios siguen viajando en el bloque completo.
3. Imaginemos una fila de control de pasaportes en un aeropuerto. Antes de SegWit, cada viajero tenía que llevar consigo todo su archivo de documentos personales a través de la estrecha puerta. SegWit permite a los viajeros pasar por la puerta solo con su pasaporte, mientras que sus archivos completos de documentos se envían a través de un canal separado y más amplio que funciona en paralelo.
4. Imagina una tarjeta de recetas con un límite de palabras. Antes de SegWit, tanto las instrucciones de cocina como las notas al pie debían caber en una sola tarjeta. SegWit traslada las notas al reverso y las contabiliza con descuento, de modo que los chefs pueden incluir más pasos de cocina en el anverso de cada tarjeta.
5. Imagina una cabina de peaje en una autopista donde se cobra por pasajero. SegWit es como cambiar la regla para que los pasajeros del asiento trasero paguen una cuarta parte del precio: la cabina de peaje sigue gestionando el mismo número de coches, pero cada coche transporta efectivamente a más personas por el mismo peaje total.

Importante: Los nodos heredados aceptan la vista simplificada según las reglas antiguas, pero no aplican la validación de testigos de SegWit. Los nodos actualizados sí aplican dichas reglas. Las carteras necesitan scripts y construcción de transacciones compatibles para gastar correctamente las salidas de SegWit. (Fuente: Serialización de testigos BIP144 )

Características técnicas clave

Peso del bloque y nuevo modelo de capacidad

• Sustituye el límite de tamaño de bloque de 1 MB por un límite de peso de bloque de 4,000,000 de unidades de peso (4 MWU).
• Los datos no testigos cuestan 4 WU por byte; los datos testigos cuestan 1 WU por byte.
• El tamaño total serializado varía según la composición del testigo y puede llegar a los 4 MB; el número de transacciones no es fijo.
• Los nodos heredados reciben una serialización sin formato compatible; los nodos actualizados también validan los compromisos y las reglas de los testigos.

Corrección de la maleabilidad de la transacción

• Antes de SegWit, el txid se calculaba sobre toda la transacción, incluidas las firmas.
• Históricamente, los cambios permitidos en los datos de desbloqueo podían modificar un txid sin alterar el pago previsto. La validez de dichos cambios depende del consenso vigente y de las normas de política.
• El txid excluye los datos de testigo. Esto impide que los cambios exclusivos del testigo lo alteren, y no cualquier modificación posible de la transacción.
• Un identificador de transacción de testigo independiente (wtxid) cubre la transacción completa, incluidos los datos del testigo.

Cómo funciona una transacción SegWit

1. La billetera del remitente construye una transacción con entradas que hacen referencia a transacciones anteriores. UTXOs y resultados que especifican las direcciones de los destinatarios y los importes.
2. Las entradas de testigo nativas usan un scriptSig vacío; las entradas de testigo envueltas en P2SH incluyen el programa de testigo de redención. Otras entradas en una transacción mixta aún pueden tener scriptSig heredados. (Fuente: Desarrollo de billetera SegWit para Bitcoin Core)
3. La transacción se serializa con un byte marcador (0x00) y un byte indicador (0x01) que señalan el formato SegWit.
4. El txid aplica un hash a la serialización sin testigo, incluidos los campos scriptSig reales; estos no están universalmente vacíos.
5. El wtxid se calcula aplicando un hash a la transacción serializada completa, incluidos los datos de testigo.
6. Un compromiso de testigo en la transacción coinbase se compromete con la raíz Merkle del testigo, junto con la estructura de raíz Merkle de la transacción ordinaria del bloque.
7. Los nodos verifican tanto la validez de la transacción estándar como la integridad de los datos del testigo al validar el bloque.

Tipos de direcciones SegWit

• SegWit encapsulado en P2SH: Las direcciones de la red principal comienzan con 3, pero el mismo prefijo también representa scripts P2SH que no son SegWit. BIP49 especifica una convención común para la derivación de monederos encapsulados.
• SegWit nativo versión 0: Las direcciones de la red principal comienzan con bc1q y utilizan Bech32. El ahorro en comisiones depende de los tipos de entrada y salida, la cantidad y la tasa de comisión.
• Taproot: Las direcciones de la versión 1 de la red principal comienzan con bc1p y utilizan Bech32m. Otras versiones futuras de testigos también utilizan Bech32m, pero no es necesario que comiencen con bc1p.

Habilitación de la red Lightning

• La red Lightning se basa en transacciones pre-firmadas que hacen referencia a txids específicos.
• La maleabilidad de las transacciones antes de SegWit significaba que los txids podían cambiar después de la transmisión, rompiendo los contratos del canal de pago.
• Eliminar la maleabilidad de los ID de transmisión basados ​​en testigos favorece una construcción de canales robusta; Lightning aún presenta sus propios riesgos de liquidez, monitoreo y protocolo.
• Las implementaciones de Lightning utilizan formatos de financiación y gasto compatibles; operar un canal requiere más que elegir una dirección SegWit.

Ventajas desventajas

Gestión de riesgos

Riesgo de compatibilidad de direcciones

• Es posible que las carteras antiguas y algunos exchanges no admitan el envío a direcciones bech32 (bc1).
• Verifique que el servicio de envío sea compatible con el tipo de dirección y la red exactos del destinatario. En algunos casos, SegWit envuelto puede ofrecer compatibilidad, pero no dé por sentado que todas las direcciones con prefijo 3 corresponden a una billetera SegWit.
• Consulte la documentación de servicio actual en lugar de asumir que la compatibilidad se basa en una fecha de adopción antigua.

Riesgo de cuota de adopción parcial

• El remitente paga la comisión por transacción, que depende de los datos utilizados y de la transacción completa. Recibir una salida SegWit puede reducir el costo de usar esa salida posteriormente.
• Utilice salidas SegWit nativas compatibles cuando sea apropiado y compare los tamaños virtuales reales y las estimaciones de tarifas.

Datos de testigos y uso de recursos

• Las transacciones con gran cantidad de testigos pueden generar bloques serializados más grandes dentro del límite de peso. El uso del espacio de testigos permitido no constituye inherentemente una vulnerabilidad del protocolo.
• Las reglas de ponderación y de scripts del consenso restringen los bloques; las políticas de retransmisión de nodos y de minería imponen límites adicionales y distintos. Los límites de las políticas no deben confundirse con los límites del consenso.
• La tendencia de Ordinales e Inscripciones de 2023 demostró esta dinámica, ya que se utilizaron grandes cargas útiles de datos de testigo para inscribir imágenes y datos en la cadena.

Riesgo de migración para los servicios

• Las plataformas de intercambio y los procesadores de pagos que migran de formatos de direcciones antiguos a formatos SegWit deben gestionar la transición con cuidado para evitar la pérdida de fondos o errores contables.
• Medidas de mitigación: ejecutar sistemas heredados y SegWit en paralelo durante la migración; realizar pruebas exhaustivas en la red de prueba antes de la implementación en la red principal.

Relevancia cultural

El debate sobre la escalabilidad, conocido como la Guerra del Tamaño de Bloque, involucró enfoques técnicos y de gobernanza contrapuestos. Bitcoin Cash se dividió el 1 de agosto de 2017; Bitcoin SegWit se activó el 24 de agosto con un máximo de 481,824 bloques. Estos fueron eventos independientes.

La frase «UASF» (User-Activated Soft Fork, bifurcación suave activada por el usuario) se convirtió en un lema entre los partidarios de SegWit, quienes abogaban por que los operadores de nodos impusieran la activación de SegWit independientemente de las señales de los mineros. El movimiento UASF de BIP148 demostró el poder de los nodos económicos (intercambios, empresas, usuarios) sobre los mineros a la hora de determinar la ruta de actualización de Bitcoin, sentando un precedente sobre cómo se evaluarían los futuros cambios de protocolo.

La activación de SegWit también marcó un punto de inflexión en la gobernanza de Bitcoin. El fracaso del Acuerdo de Nueva York (SegWit2x), que proponía activar SegWit seguido de un aumento de 2 MB en el tamaño del bloque, reforzó el principio de que ningún acuerdo a puerta cerrada entre los actores de la industria podía dictar los cambios en el protocolo de Bitcoin sin un consenso más amplio de la comunidad.

En el mundo de los desarrolladores, SegWit es reconocido como una elegante solución de ingeniería que resolvió varios problemas simultáneamente —escalabilidad, maleabilidad y capacidad de actualización— mediante un único cambio compatible con versiones anteriores. El sistema de versionado de testigos que introdujo se ha convertido en el mecanismo principal para implementar actualizaciones posteriores, siendo Taproot (witness v1) el ejemplo más destacado.

La "guerra del tamaño de los bloques" ha sido ampliamente documentada en el libro de Jonathan Bier, The Blocksize War (2021), que se ha convertido en una lectura recomendada para cualquiera que busque comprender el modelo de gobernanza de Bitcoin y la dinámica social del desarrollo de protocolos descentralizados.

Ejemplos del mundo real

1. SegWit y procesamiento por lotes de transacciones

• Escenario: Un servicio quiere reducir el coste total en la cadena de bloques de muchos retiros.
• Mecanismo: SegWit puede reducir el peso de la entrada, mientras que el procesamiento por lotes distribuye la sobrecarga de la transacción entre múltiples salidas. Se trata de optimizaciones independientes.
• Resultado: Tanto SegWit como el procesamiento por lotes pueden reducir los costos, pero sus beneficios dependen de la estructura de la transacción y la tasa de comisión. El procesamiento por lotes comparte los gastos generales; SegWit modifica la ponderación de los datos de entrada elegibles.

2. Crecimiento de Lightning Network impulsado por SegWit

• Escenario: Los protocolos de los canales de pago necesitan referencias fiables a las transacciones de financiación y compromiso.
• Implementación: Los nodos Lightning abren canales de pago mediante la creación de transacciones SegWit multifirma 2 de 2 en la capa base de Bitcoin. Los pagos subsiguientes dentro del canal se realizan fuera de la cadena a través de transacciones de compromiso actualizadas que hacen referencia al txid de la transacción de financiación SegWit original.
• Resultado: SegWit admite el diseño de transacciones de Lightning, pero la capacidad del canal, la liquidez del enrutamiento, el número de nodos y el éxito del pago son medidas distintas. El protocolo no establece una capacidad fija ni una valoración en dólares para 2026.

3. Alivio de la congestión de Mempool durante el Bull Run de 2021

• Escenario: Durante el mercado alcista de Bitcoin de 2021, el volumen de transacciones se disparó, lo que provocó una importante congestión en la memoria caché y un aumento de las comisiones.
• Mecanismo: Con la misma tarifa, un tamaño virtual menor reduce la tarifa total. La inclusión sigue dependiendo de la tarifa, los paquetes ancestrales, la política del minero y el espacio de bloque disponible.
• Resultado: SegWit mejora la eficiencia del espacio de bloques para los tipos de transacciones adecuados. No garantiza la inclusión en el siguiente bloque ni una ventaja de comisiones doble o triple para todos.

4. Ordinales e inscripciones que utilizan el espacio de testigo

• Escenario: A principios de 2023, el desarrollador Casey Rodarmor lanzó el Protocolo de ordinales, que utiliza el espacio de datos de testigo de SegWit para inscribir datos arbitrarios (imágenes, texto, HTML) directamente en la cadena de bloques de Bitcoin.
• Mecanismo: Los datos de inscripción se transportan en los datos de testigo de la ruta del script de Taproot y reciben ponderación de testigo. Otros datos de bloques y transacciones siguen consumiendo peso, por lo que una carga útil no puede ocupar los 4,000,000 de bytes completos independientemente de la sobrecarga.
• Resultado: Las inscripciones ilustran un uso intensivo del espacio de las manzanas por parte de los testigos y han reavivado el debate sobre la asignación de recursos. Los recuentos y las cifras de adopción requieren un conjunto de datos fechado.

Tabla de comparación

Términos relacionados

• Propuesta de mejora de Bitcoin (BIP) — El proceso formal para proponer y documentar cambios en el protocolo Bitcoin; SegWit se implementó a través de BIP141, BIP143 y BIP144.
• Maleabilidad de las transacciones — Cambios que alteran un identificador de transacción sin necesariamente cambiar su pago previsto; SegWit aborda los formularios basados ​​en testigos bajo condiciones específicas.
• Lightning Network — La principal red de canales de pago de capa 2 de Bitcoin, que permite transacciones instantáneas y de bajas comisiones; habilitada directamente por la solución de maleabilidad de SegWit.
• Tenedor blando — Una actualización de protocolo compatible con versiones anteriores, donde los nodos no actualizados aún aceptan bloques de los nodos actualizados; SegWit se implementó como una bifurcación suave para evitar la división de la red.
• Peso del bloque: la métrica introducida por SegWit que reemplaza el límite de tamaño de bloque anterior, medida en unidades de peso (WU) con un máximo de 4,000,000 WU por bloque.
• Bech32: codificación de direcciones utilizada para la versión nativa de testigo 0; Bech32m se utiliza para las versiones 1 y posteriores.
• Raíz principal — Una actualización de Bitcoin de 2021 que se basa en la versión 1 del testigo de SegWit para introducir firmas Schnorr, MAST y una mayor privacidad para transacciones complejas.
• UTXO (salida de transacción no gastada) — El modelo contable fundamental en Bitcoin; las transacciones SegWit modifican la forma en que se estructuran y verifican las condiciones de gasto de UTXO.
• Programa de testigo: el formato scriptPubKey introducido por SegWit que especifica la versión del testigo y el hash del programa, lo que permite la verificación segregada de las condiciones de gasto.
• Bitcoin Cash: una bifurcación dura de Bitcoin creada el 1 de agosto de 2017 por defensores de bloques más grandes que no estaban de acuerdo con el enfoque de escalado de SegWit.
• La guerra del tamaño de los bloques: el debate comunitario de varios años sobre la escalabilidad de Bitcoin que culminó con la activación de SegWit y la bifurcación de Bitcoin Cash, dando forma a la cultura de gobernanza de Bitcoin.
• Protocolo Ordinals: un protocolo para inscribir datos arbitrarios en Bitcoin utilizando el descuento del espacio de testigos de SegWit, lo que permite una funcionalidad similar a la de los NFT en la cadena de bloques de Bitcoin.

Preguntas Frecuentes

P: ¿Qué significa realmente “Testigos Segregados” en lenguaje sencillo?

«Segregado» significa separado, y «Testigo» se refiere a las firmas criptográficas que prueban que una transacción está autorizada. Por lo tanto, «Testigo Segregado» significa, literalmente, separar las firmas de los datos principales de la transacción. Las firmas se incluyen en el bloque para fines de verificación, pero se colocan en una estructura separada que se contabiliza con un descuento al calcular la capacidad del bloque.

P: ¿Cuánto se ahorra en comisiones con las transacciones SegWit en comparación con las transacciones tradicionales?

El ahorro depende del tipo de script, la cantidad de entradas y salidas, y la tasa de comisión. Con una tasa fija de sat/vB, un tamaño virtual menor resulta más económico. Compare las estimaciones de la billetera para la transacción real en lugar de asumir un descuento universal.

P: ¿Es obligatoria la adopción de SegWit para los usuarios de Bitcoin?

Los usuarios aún pueden recibir y gastar resultados heredados, pero los nodos antiguos no aplican todas las reglas de consenso más recientes. Se requiere software compatible con SegWit para una validación adecuada de los testigos y los formatos de gasto admitidos. No es necesario un porcentaje de adopción actual para utilizarlo.

P: ¿Cómo hizo posible SegWit la creación de la red Lightning?

Lightning se basa en transacciones pre-firmadas que hacen referencia a salidas de financiación. SegWit elimina los cambios en el txid basados ​​en testigos bajo las condiciones requeridas, lo que contribuye a que dichas referencias sean fiables. Sin embargo, no elimina todos los riesgos de seguridad o disponibilidad de Lightning.

P: ¿Cuál es la diferencia entre las direcciones bech32 y bech32m?

En la red principal de Bitcoin, las direcciones de testigo de la versión 0 comienzan con bc1q y utilizan Bech32. Las direcciones de Taproot de la versión 1 comienzan con bc1p y utilizan Bech32m. Bech32m se aplica a las versiones 1 a 16; las versiones superiores tienen otros prefijos y no representan automáticamente a Taproot. (Fuente: Codificación de direcciones Bech32m de BIP350 )

P: ¿SegWit solucionó el problema de escalabilidad de Bitcoin?

SegWit mejora la eficiencia del peso y admite diseños de canales de pago, pero no proporciona un rendimiento ilimitado. Las ganancias de capacidad dependen de la composición de las transacciones, y los sistemas en capas introducen sus propias desventajas operativas.

P: ¿Por qué algunas personas critican SegWit?

Los críticos han planteado varias objeciones. Algunos argumentaron que un aumento directo del tamaño del bloque habría sido más sencillo y eficaz. Otros sostuvieron que el mecanismo de despliegue de bifurcación suave (que utiliza el truco de "cualquiera puede gastar" para la retrocompatibilidad) era una solución poco elegante. La controversia de los Ordinales reavivó el debate sobre si el descuento de datos de testigo incentiva usos no monetarios del espacio de bloque que no fueron previstos originalmente por los diseñadores de SegWit.

Conclusión

SegWit mejora el diseño de las transacciones de Bitcoin mediante la separación de testigos y la contabilidad del peso de los bloques. Utilice software y formatos de dirección compatibles, y calcule las comisiones a partir de la transacción real en lugar de asumir ahorros fijos o capacidad ilimitada.

Fuentes

BIP141 Testigo segregado

Desarrollo de billetera SegWit para Bitcoin Core

Codificación de direcciones BIP350 Bech32m

Serialización de testigos BIP144

Datos de inscripción ordinal

Límite de bloques adaptativo de Bitcoin Cash para mayo de 2024