Select Page

¿Qué es SegWit o Testigo Segregado?

Segregated Witness o SegWit (en español: Testigo Segregado) es una actualización de software compatible con versiones anteriores de Bitcoin, la cual fue implementada tras una bifurcación suave en la principal plataforma blockchain del mundo.

Su nombre oficial es BIP141 (Bitcoin Improvement Proposal number 141, que en español significa Propuesta de Mejora de Bitcoin número 141). Con esta actualización, cada bloque de la cadena cuenta con una nueva estructura denominada testigo y la coloca aparte del árbol de Merkle de transacciones Bitcoin. Para cada transacción, los datos de los firmantes y scripts son movidos a dicha estructura, separando tal información del resto de los datos de la operación. El nombre de “Testigo Segregado” se debe a esa segregación de firmas que, si bien son necesarias para validar las transacciones, no son determinantes para los efectos de las transacciones.

Esta innovación tecnológica imposibilita la maleabilidad de terceros y de scriptSig, y aumenta ligeramente el tamaño promedio de los bloques de Bitcoin (de 1 MB a 1,8 MB aproximadamente). Cabe destacar que SegWit no es un software exclusivo de Bitcoin; también ha sido implementado en otras plataformas como Litecoin y Vertcoin.

¿Cómo y por qué surgió SegWit?

Dos de las principales debilidades de Bitcoin se deben a la maleabilidad y la escalabilidad. Para corregirlas, se han ido presentando e implementando algunas propuestas, quizás una de las más importantes hasta los momentos ha sido SegWit.

SegWit se activó el 24 de agosto de 2017 en la red Bitcoin luego de casi dos años de pruebas. El protocolo fue lanzado el 21 de diciembre de 2015 por Eric Lombrozo, Johnson Lau y Pieter Wuille, junto con el aporte de otros desarrolladores como Peter Todd y Gregory Maxwell.

SegWit surgió como potencial solución a las mencionadas limitaciones de Bitcoin. Debido a que las firmas no determinan el estado de una blockchain (aun cuando son necesarias para validar dicho estado) los creadores determinaron que, si dichos datos se separaban de la información ligada al árbol de Merkle, se podían resolver ciertos problemas que entorpecían el crecimiento de la red, como la maleabilidad.

La maleabilidad es una propiedad de algunos algoritmos criptográficos que posibilita que un código pueda ser modificado por un tercero. En Bitcoin (sin SegWit) la maleabilidad de una transacción es considerada un tipo de ataque de denegación de servicio, que da pie a que el identificador de transacciones, conocido como txid (Transaction Identifier), pueda ser alterado en las transacciones no confirmadas. Esto se debe a que los tipos de hash de firma de Bitcoin no protegen el script de la firma (scriptSig), el cual a su vez incluye un tipo de firma (secp256k1) que no se puede “firmar” por sí misma. La forma en como se calcula el txid permite que exista la posibilidad de que un tercero con malas intenciones (o un minero de forma no intencional) modifique el identificador de una determinada transacción.

Debido a que un cambio de identificador no altera a la transacción en sí (puesto que no cambia las entradas y los resultados) se cataloga como una modificación no funcional; sin embargo, representa un problema cuando la transacción aún no ha sido confirmada y el txid de una transacción no coincide con el txid que originó el usuario que envió los fondos, por lo que si se desea rastrear una transacción en la red, esta no sería hallada y como los fondos aún no han llegado a su destino en ese punto, el receptor de los fondos desconfiaría del emisor y probablemente del protocolo Bitcoin en general.

Según Bitcoin.org un cambio en el identificador de una transacción “Se convierte en un problema cuando el resultado de una transacción se gasta antes de que esa transacción se agregue a la cadena de bloques”, esto se puede ejemplificar de la siguiente manera:

Si en una primera transacción Isabel le paga a Iván y luego Iván utiliza esos fondos para pagarle a Jesús en una segunda transacción, y ocurre que un minero por error o un tercero con intención modifica el txid de la transacción de Isabel a Iván y lo confirma con ese txid diferente, entonces el pago de Iván a Jesús será invalidado y por lo tanto, Jesús no recibirá los fondos. En este escenario la honestidad de las partes pasa a jugar un papel trascendental, porque si Iván es honesto, le enviará de nuevo los fondos a Jesús, o si por el contrario es deshonesto, se podrá quedar con las criptomonedas.

De manera que, cuando los fondos lleguen a su destino lo harán con la txid distinta a la de su creador, de modo que este último percibirá que su transacción ha desaparecido de la red. Al modificar el identificador sin invalidar la transacción en cuestión, se invalidarían las transacciones secundarias debido a que las nuevas transacciones se vinculan a las anteriores.

Por otro lado, la necesidad de escalabilidad se ha vuelto casi que inminente en Bitcoin, puesto que la red originalmente no fue creada para el uso masivo que hasta ahora ha tenido. El tamaño promedio del bloque, junto con el intervalo de diez minutos de la prueba de trabajo de Bitcoin, ha conllevado a la saturación de la mempool, donde se acumulan las transacciones pendientes por confirmar.

Cabe destacar que a medida que aumentaba la adopción y el precio de la criptomoneda de Bitcoin, se comenzaron a presentar problemas de congestionamiento en la red, así como también un incremento en las comisiones por transacciones debido a que si se deseaba agilizar alguna transacción se debía pagar una determinada tarifa a los mineros, generando así competencia entre los usuarios de Bitcoin.

Al segregar a las firmas a una estructura nueva para el protocolo que establecía las restricciones en la red, se podría llevar a cabo el cambio que se necesitaba a través de una bifurcación suave, evitando así la creación de una nueva cadena de bloques y consecuentemente, de una nueva criptomoneda. De esa forma también se podría aumentar el tamaño de bloque, al enviar los datos del testigo a otra estructura aparte y permitir que nodos heredados continuaran formando parte de la red.

El efecto que tiene SegWit con respecto al tamaño promedio del bloque es que conlleva a un aumento de 1 MB a 1,8 MB aproximadamente, lo cual se explicará con mayor detalle a continuación.

¿Qué impacto tiene SegWit en el protocolo de Bitcoin?

Antes de SegWit, las reglas de consenso en Bitcoin incluían que cada bloque se limitaba a 1 MB de tamaño; todos los bloques que no cumplían con esa norma eran rechazados. De hecho, en un principio, no existía límite en el tamaño del bloque en Bitcoin, pero por razones de seguridad, Satoshi Nakamoto fijó el límite de 1 MB, debido a ataques de denegación de servicio (DoS) con bloques falsos enormes.

Para hacer de SegWit una bifurcación suave, esta regla aún se mantiene y coexisten nodos legacy (nodos heredados) con nodos SegWit. Sin embargo, con SegWit se introdujo una nueva regla que a su vez conlleva la introducción de un nuevo término, y es el peso del bloque o “block weight”, el cual tiene que ser menor o igual a 4.000.000 bytes.

Esta nueva regla permite que los nodos heredados de Bitcoin Core sigan formando parte de la red, procesando bloques de 1 MB de tamaño como máximo (como venían haciéndolo) y que nodos nuevos o actualizados procesen bloques con tamaño de 1,8 MB. Ahora, para ambos tipos de nodos, el peso del bloque a procesar será como máximo de 4 MB.

Pues bien, cuando se envían bloques con transacciones SegWit a nodos heredados (esto es, nodos que no se actualizaron a SegWit) los datos de las firmas son eliminados, de forma tal que estas transacciones siguen siendo válidas, generando un ahorro de espacio en el bloque, lo que permite que se procesen más transacciones por bloque; todo esto cumpliendo con la regla de 1 MB.

Por su parte, los nodos actualizados a SegWit reciben las transacciones y bloques con los datos de las firmas a través de mensajes alternativos, definidos en la mejora BIP144. Estos bloques llegan a los nodos SegWit con una estructura aparte que incluye a las firmas y pueden tener un tamaño de 1,8 MB.

De forma tal que todos los nodos de Bitcoin recibirán los mismos bloques con las mismas transacciones, pero, dependiendo de su naturaleza, si son nodos actualizados o no, los recibirán sin y con la estructura que contiene los datos de las firmas, respectivamente, haciendo esto a SegWit una bifurcación suave.

Como explica Jimmy Song, desarrollador de Bitcoin Core, no es posible llenar un bloque con transacciones no SegWit y tener más de 1 MB de tamaño, debido a que existe una relación directamente proporcional entre el peso de la transacción no SegWit y su tamaño (por ejemplo: una transacción no SegWit de tamaño de 1.000 bytes tiene un peso de 4.000 bytes). Para el caso de las transacciones SegWit la relación varía en función del tamaño del testigo; por ejemplo, una transacción SegWit de 1.000 bytes de tamaño podría pesar 2500 bytes o 3100 bytes si el tamaño del testigo es de 500 o 300 bytes respectivamente.

Para entender claramente lo anteriormente descrito, es necesario diferenciar los términos tamaño de bloque, peso de bloque y tamaño del testigo, los cuales se presentan a continuación.

Block size, block weight y witness size

“Block size” o tamaño del bloque se expresa en bytes. Este representa el tamaño real del bloque.  Antes de SegWit, la regla de consenso en cuanto al tamaño del bloque era máximo de 1 MB. Esta regla se mantiene para nodos heredados, mas para nodos SegWit, el tamaño de bloque puede ser mayor a 1 MB, hasta 1,8 MB.

“Block weight” se refiere al peso del bloque, el cual está limitado a 4 MB tanto para nodos actualizados (nodos SegWit) como para no actualizados a SegWit (nodos legacy o nodos heredados). Este es el nuevo concepto introducido con SegWit. Esta nueva restricción para los bloques de la cadena se calcula con la siguiente expresión matemática:

Peso del bloque: Tamaño base * 3 + Tamaño total

Donde el tamaño base o “base size” es el tamaño de bloque en bytes sin ningún dato relacionado con las firmas, como se observa en un nodo no actualizado. Por otra parte, el tamaño total o “total size” es el tamaño de bloque en bytes con los datos base y los datos de testigos. Cabe destacar que esta expresión sirve para calcular tanto el peso de una transacción como el peso del bloque.

Entonces, dicha expresión podría expresarse de la siguiente manera también:

Peso de la transacción: (Tamaño de la transacción- datos de testigos)*3 + tamaño de transacción (incluyendo datos de testigos).

Para transacciones no SegWit, la expresión anterior quedaría simplificada como 4 veces el tamaño de bloque debido a que estas no incluirían los datos de las firmas, por lo que su peso es igual a 4 veces su tamaño.

Por otra parte, “Witness size” o tamaño del testigo se expresa en bytes y representa los datos de las firmas de los que son despojadas las transacciones no SegWit.

Como afirma Jimmy Song, los datos del testigo representan aproximadamente 2/3 del tamaño de una transacción SegWit: ”Esto depende del número de entradas p2wpkh o p2wsh”, apunta. Además, Song enfatiza la posibilidad de que transacciones con igual peso tengan distintos tamaños, y que transacciones con igual tamaño tengan distintos pesos. A continuación, se presentan algunos ejemplos compartidos por este desarrollador y algunos de elaboración propia:

       Transacción Tamaño de transacción (bytes) Tamaño de testigo (bytes) Tamaño de transacción- Tamaño de testigo    Peso de transacción                   (bytes)
1    SegWit 1.000 500 500 500*3 + 1.000 = 2.500
2 1.000 300 700 700*3 + 1.000 = 3.100
3 800 400 400 400*3 + 800 = 2.000
4 1.100 800 300 300*3 + 1.100 = 2.000
5 1.500 1.000 500 500*3 + 1.500 = 3.000
6 No SegWit 500 0 500 500*3 + 500 = 2.000
7 400 0 400 400*3 + 400 = 1.600
8 300 0 300 300*3 + 300 = 1.200
9 750 0 750 750*3 + 750 = 3.000
10 850 0 850 850*3 + 850 = 3.400

De la tabla anterior se pueden concluir varios lineamientos:

1- Una transacción SegWit y una transacción no SegWit de diferente tamaño pueden tener el mismo peso (ejemplos 3 y 6; ejemplos 5 y 9).

2- Dos transacciones SegWit de igual tamaño pueden tener diferentes pesos (ejemplos 1 y 2).

3- Dos transacciones SegWit de diferente tamaño pueden tener el mismo peso (ejemplos 3 y 4).

4- El peso de las transacciones no SegWit siempre es cuatro veces su tamaño.

5- En nodos heredados, transacciones de los ejemplos 1, 5 y 6 serán procesadas como de 500 bytes, y en nodos SegWit como de 2.500, 3.000 y 2.000 bytes, respectivamente. Lo mismo para los ejemplos 3 y 7.

Lo anterior es muestra de las siguientes palabras de Song: “Segwit convierte el tamaño de bloque en un concepto menos relevante. El peso del bloque es la métrica más precisa y útil para juzgar los bloques, aunque ciertamente tiene una relación con el tamaño”.

Block weight. Fuente: http://segwit.party/charts/

En las siguientes gráficas obtenidas de SegWit Party, se puede apreciar la relación entre el peso del bloque, el tamaño del bloque y el tamaño del testigo:

En esta primera gráfica se observa únicamente el “block height” de diferentes bloques ya procesados en Bitcoin. Aquí se observa en el eje vertical que el peso del bloque está limitado a 4 MB. Se toma como ejemplo el bloque 512.517, el cual tiene un peso de bloque de 3.992.614 bytes.

En la gráfica que se muestra a continuación se aprecia el “block size” de diversos bloques añadidos a la cadena de Bitcoin y en el eje vertical se observa que este se limita a 1,8 MB. También se aprecia que para el caso del bloque 512.517, el “block size” o tamaño de bloque es 1.319.428 bytes, por lo que se trataría de un bloque SegWit.

Block size. Fuente: http://segwit.party/charts/

En esta tercera gráfica se observa la relación entre los tres conceptos. Para el bloque 512.517, el tamaño de testigo es 428.366 bytes. Si se aplica la ecuación matemática partiendo de los valores de tamaño de bloque y tamaño de testigo, el peso del bloque 512.517 es efectivamente 3.992.614 bytes.

Witness size. Fuente: http://segwit.party/charts/

En dicho bloque, el porcentaje de datos de testigos fue de 32,47%, se procesaron 139 transacciones SegWit y unas 255 transacciones del tipo no SegWit. Esto se puede observar en las siguientes gráficas:

Porcentaje de datos de testigo por bloque. Fuente: http://segwit.party/charts/

Cantidad de transacciones SegWit por bloque. Fuente: http://segwit.party/charts/

Cantidad de transacciones no SegWit por bloque. Fuente: http://segwit.party/charts/

¿Cuáles son las ventajas que trae SegWit para la red Bitcoin y sus usuarios?

Las ventajas que trae SegWit para la red básicamente son dos: imposibilita ataques de maleabilidad y aumenta el tamaño de bloques hasta unos 1,8 MB. De estas dos ventajas se desprenden muchas otras más.

Con SegWit la presencia de datos de testigos se vuelve opcional, y solo se necesitarán cuando los nodos requieran validar una transacción, mas no para verificarla. Consecuentemente, para el método SPV (Simplified Payment Verification, o Verificación de Pago Simplificado) utilizado por los clientes livianos de Bitcoin para la verificación de transacciones, se tendrá una reducción en el tamaño de las pruebas de verificación, los clientes tendrán una mayor privacidad y podrán descargar más transacciones sin tener que aumentar su ancho de banda.

Como afirma Andreas Antonopoulos, es posible que tecnologías de segunda capa para la escalabilidad de Bitcoin, como Lightning Network, puedan ser usadas sin SegWit. Sin embargo, muchas de las herramientas para privacidad y seguridad no funcionarían.

Con SegWit, al separar los datos de las firmas del resto de los datos de una transacción, los datos de las firmas no tienen relevancia en el proceso de identificación de esta.  De esta forma, “la maleabilidad no intencional se vuelve imposible”, aseguraron a través de GitHub. Hay que destacar que las transacciones SegWit solo evitarán la maleabilidad si sus entradas son “segwit spends”.

De acuerdo con el sitio web del proyecto SegWit, al volver imposible la maleabilidad, esta tecnología también: “Permite la creación de cadenas de dependencia de transacción no confirmadas sin riesgo de contraparte, una característica importante para los protocolos fuera de cadena como “Lightning Network””; razón por la cual se afirma que SegWit aumentaría la eficiencia de propuestas de escalabilidad de segunda capa en Bitcoin, porque, al mover las firmas fuera de los datos de la transacción, es imposible modificarlas. Sin SegWit la vulnerabilidad de los identificadores de transacciones no confirmadas de Bitcoin debido a la maleabilidad despertaría en los usuarios incertidumbre y desconfianza hacia las soluciones de segunda capa.

Además, al admitir más transacciones dentro de un bloque, se agiliza un poco el procesamiento de las transacciones en la red, disminuye la competencia por tarifas de prioridad entre usuarios, y consecuentemente, disminuyen las comisiones de la red.

Otro de los beneficios de SegWit es que permite rastrear las transacciones en la blockchain de forma sencilla y confiable a través del txid, puesto que es imposible modificarlo con esta actualización, además se podrían gastar transacciones no confirmadas sin temor de que puedan ser objeto de maleabilidad. Además, el diseño, la comprensión y la supervisión de contratos inteligentes y soluciones de segunda capa se facilita un poco más haciendo uso de SegWit.

¿Es SegWit una solución definitiva a los problemas relacionados con la escalabilidad?

No, SegWit no es una solución definitiva a los problemas relacionados con la escalabilidad de Bitcoin, debido a que el incremento en cuanto a cantidad de transacciones no es significativo. Sin embargo, el hecho de que corrija los problemas de maleabilidad da pie a que se desplieguen con confianza otras tecnologías como Lightning Network.

Con la corrección de maleabilidad, la implementación de Lightning Network es menos complicada,  el uso del espacio en la blockchain es más eficiente y además posibilita la creación de clientes ligeros de Lightning para monitorear la cadena de bloques sin necesidad de que sean nodos completos de Bitcoin.

Algunas carteras y casas de cambios que han adoptado SegWit

Las carteras y casas de cambio son libres de decidir si actualizarse o no a SegWit, pues se trata de un software opcional. Sin embargo, debido a sus beneficios y a la solicitud de los usuarios, muchas casas de cambio y carteras han implementado y también activado SegWit en sus plataformas.

No fue sino hasta hace poco que importantes startups del mercado de bitcoins como Bitfinex y Coinbase anunciaron la habilitación de direcciones Bitcoin con SegWit,. Antes de ellas, muchas casas de cambio y carteras anunciaron la disponibilidad de direcciones actualizadas a SegWit para sus usuarios; tal es el caso de carteras como GreenAddress, Trezor, Ledger, BitGo, Samourai Wallet y de casas de cambio como LocalBitcoins y Binance.

De todas formas, siempre hay que estar atentos a los nuevos anuncios que puedan realizar aquellas casas de cambio y carteras que aun no lo han implementado, aunque muchos usuarios de la comunidad expresaron emigrar a servicios con SegWit disponible, como una medida de presión que al parecer terminó funcionando en el caso específico de Coinbase.

¿Dónde monitorear las transacciones SegWit?

Existen portales web como SegWit Party y Segwit.5gbfree en donde publican continuamente el porcentaje y la cantidad de transacciones SegWit por bloque que se realizan en la red Bitcoin. En ambas páginas vienen haciendo un seguimiento a las transacciones SegWit desde su activación en Bitcoin.

Según la gráfica de la media móvil de porcentaje promedio de transacciones SegWit en los últimos 144 bloques, desde la activación de SegWit hasta la actualidad, el máximo valor que se ha registrado ha sido cercano al 33%. Esta página también reporta continuamente la cantidad de transacciones SegWit y no SegWit por bloque de Bitcoin, así como también lo referente al peso y tamaño del bloque, y a los datos de los testigos (como se observaron en las gráficas anteriores).

Porcentaje de transacciones SegWit en los últimos 140 bloques. Fuente: http://segwit.party/charts/

Existen otros portales como bitinfocharts, en donde reportan el tamaño de bloque promedio, así como también otras estadísticas vinculadas al hash rate, a las comisiones, entre otros. También están las gráficas de Jochen Hoenicke donde presentan el tamaño de la mempool, las comisiones de las transacciones pendientes, entre otros.

¡Mantente al día!