Segwit: una mirada profunda a la evolución de bitcoin

SegWit, o Segregated Witness, fue una actualización de protocolo para Bitcoin que cambió la forma en que se formatean las transacciones. Su objetivo era solucionar problemas con la malleabilidad de transacciones, donde pequeños cambios en los datos de las transacciones podían perturbar la cadena de bloques. Al resolver este problema, SegWit también incrementó la capacidad de tamaño de bloque, permitiendo que más transacciones encajaran dentro de cada bloque. Esta mejora conduce a tiempos de procesamiento más rápidos y potencialmente tarifas de transacción más bajas.

Una dirección SegWit comienza con "3" o con "bc1". Ofrece una mejor protección, así como tarifas más bajas al ocupar menos espacio en el bloque. En 2024, casi todas las transacciones de Bitcoin utilizan SegWit.

La propuesta de SegWit provino de Pieter Wuille en 2015, y se activó exitosamente en Bitcoin Core en 201En este artículo, explicaremos qué significa SegWit para Bitcoin y cómo allanó el camino para futuras innovaciones como Taproot y Lightning.

¿Cómo soluciona SegWit la malleabilidad de transacciones?

SegWit soluciona la malleabilidad de transacciones al separar las firmas de los datos de la transacción. Una transacción puede ser manipulada de dos maneras. Primero, después de que una transacción se firma, se pueden agregar datos adicionales a un ScriptSig, la parte de la transacción que contiene la firma y otros datos utilizados para desbloquear el Bitcoin. Segundo, la firma en sí, que está contenida dentro del ScriptSig, se puede cambiar.

Estas opciones son posibles porque una firma no puede firmarse a sí misma y, por lo tanto, no puede hacerse inmutable. Dado que el ScriptSig y las firmas que contiene forman parte del txid preimage, si se cambian, el txid cambiará. SegWit elimina esta posibilidad al eliminar todos los datos del ScriptSig. Esto se logra moviendo los datos del ScriptSig, generalmente firmas y claves públicas, al Witness, una nueva parte de las transacciones SegWit que no se incluye en el hash para calcular el txid.

El ScriptSig para las entradas SegWit se vuelve inmutable después de la firma, y los datos necesarios para desbloquear Bitcoin, que no son inmutables, se incluyen en el Witness. Esto significa que el ScriptSig no se puede cambiar y, por lo tanto, el txid no se puede cambiar sin invalidar toda la transacción. En otras palabras, los cambios en los datos de la firma ya no afectan el hash de la transacción.

SegWit habilita la red Lightning

La activación de SegWit permitió el lanzamiento de la red Lightning como una segunda capa sobre la red Bitcoin. Hasta que se activó SegWit, la red Lightning era inviable porque dependía en gran medida de las transacciones de Bitcoin no confirmadas y, por lo tanto, era susceptible a los ataques mientras la malleabilidad de transacciones era posible.

¿Cómo incrementó SegWit el tamaño de bloque?

Para aumentar el tamaño del bloque, SegWit introdujo el concepto de peso de bloque como una nueva forma de medir el tamaño de los datos de la transacción. Esto permitió que la red incluyera más transacciones dentro de cada bloque sin aumentar directamente el límite de tamaño de bloque. Por lo tanto, SegWit fue técnicamente un soft fork porque alteró una de las reglas de consenso más importantes de una manera compatible con versiones anteriores.

Antes de SegWit, cada bloque estaba limitado a 1 MB de datos, lo que equivale a aproximadamente 1650 transacciones en un bloque completo. SegWit introdujo el peso de bloque, que reemplazó el tamaño de bloque como el factor limitante para un bloque. Hoy en día, los bloques completos contienen alrededor de 2700 transacciones.

El tamaño de bloque es una medida del número total de bytes en una transacción. Antes de SegWit, este límite se establecía en 1 MB, o 1 millón de bytes.

El peso de bloque se calcula en unidades de peso. Un byte de los datos no Witness de una transacción vale 4 unidades de peso, mientras que un byte de datos Witness vale 1 unidad de peso. El límite de peso de bloque se establece en 4 millones de unidades de peso. Es importante destacar que, para un bloque que solo contiene transacciones no SegWit, este límite de 4 millones de unidades de peso equivaldría al antiguo límite de 1 millón de bytes.

Este nuevo método de medición permite que el aumento del tamaño de bloque siga siendo un soft fork, pero también otorga a los mineros y usuarios de Bitcoin incentivos financieros para utilizar SegWit. Los usuarios de Bitcoin pueden ahorrar en tarifas de transacción si utilizan transacciones SegWit, porque los datos Witness ocupan menos del límite de peso de bloque, y los mineros que incluyen transacciones SegWit pueden incluir más transacciones en sus bloques, lo que genera mayores ingresos por tarifas.

Razón detrás del "descuento Witness" de SegWit

SegWit introdujo el concepto de unidades de peso a Bitcoin. Al mismo tiempo, la actualización especificó que los datos almacenados en el nuevo witness contarían como "1" unidad de peso, mientras que los campos de transacción heredados contarían como "4" unidades de peso. Expresado de manera diferente, los datos del witness tienen un descuento de 0,25 en comparación con el estándar 1 para los campos de datos heredados.

El factor de descuento de cuatro ayuda a equilibrar los incentivos entre crear una salida y gastar una. Antes de SegWit, era mucho más costoso gastar una salida; esto se debe a que las firmas y los scripts de gasto de una transacción estándar contenían más datos que la salida anterior (Bytes en lugar de vBytes de Bitcoin).

Esta discrepancia tendía a tener el efecto de incentivar a los usuarios a crear más salidas de las que gastaban. Si se hubiera permitido que este escenario se desarrollara en un horizonte lo suficientemente largo, podría haber inflado el conjunto UTXO de Bitcoin hasta el punto en que el usuario promedio no podría ejecutar un nodo de manera viable.

Para verificar rápidamente las transacciones, los nodos mantienen una copia del conjunto UTXO almacenada en RAM (memoria de acceso aleatorio). Pero la RAM es un recurso finito y los desarrolladores de Bitcoin querían minimizar el costo de ejecutar un nodo para el beneficio de la descentralización de la red. El "descuento del witness" lo logra al equilibrar aproximadamente el costo de crear y gastar salidas.

Los nuevos tipos de scripts de SegWit

SegWit introdujo dos nuevos tipos de scripts, que son diferentes formas de enviar Bitcoin en la cadena de bloques utilizando el lenguaje de scripting de Bitcoin, Script. SegWit introdujo nuevos tipos de scripts para hacer uso del campo Witness : Pay-to-Witness-Pubkey-Hash (P2WPKH) y Pay-to-Witness-Script-Hash (P2WSH).

Los tipos de scripts que preceden a SegWit, como P2PKH y P2SH, se conocen como tipos de scripts heredados.

Pay-to-Witness-Pubkey-Hash (P2WPKH)

Antes de SegWit, la gran mayoría de los usuarios utilizaban scripts Pay-to-Pubkey-Hash (P2PKH), que bloqueaban Bitcoin al hash de una clave pública. Funcionando de manera casi idéntica, SegWit introdujo Pay-to-Witness-Pubkey-Hash (P2WPKH). La principal diferencia era que cuando los usuarios gastaban una salida P2WPKH, la firma y la clave pública se almacenaban en el Witness. El ScriptSig se dejaba en blanco para evitar la malleabilidad del txid.

Pay-to-Witness-Script-Hash (P2WSH)

El segundo tipo de script heredado más popular es Pay-to-Script-Hash (P2SH), que permite que Bitcoin se envíe al hash de un script arbitrario, llamado redeemScript. Este Bitcoin puede ser canjeado por cualquiera que pueda proporcionar el redeemScript y cumplir con los requisitos especificados en él.

Antes de SegWit, P2SH se usaba más comúnmente para multisig, ya que ahorraba espacio y privacidad en comparación con alternativas como multisig simple.

SegWit implementó Pay-to-Witness-Script-Hash (P2WSH), que funciona de manera similar a P2SH. Las salidas P2WSH se pueden gastar proporcionando el Witness Script, el equivalente SegWit del redeemScript, y las firmas y claves públicas requeridas por el Witness Script. De manera similar a las entradas P2WPKH que dejan el ScriptSig en blanco, las entradas P2WSH deben tener campos ScriptSig en blanco y colocar el Script Witness, compuesto por las firmas y claves públicas requeridas, en el campo del witness.

SegWit envuelto

La introducción de dos nuevos tipos de scripts fue un cambio importante en el protocolo Bitcoin, y no se podía esperar que las muchas billeteras, aplicaciones y servicios diferentes se adaptaran inmediatamente a este gran cambio. Para facilitar y hacer más incremental la adopción de SegWit, se construyó un puente entre los tipos de scripts heredados y los tipos de scripts SegWit.

Este puente se llama SegWit envuelto, y es una forma de script P2SH heredado. Los scripts SegWit envueltos toman un script SegWit nativo, P2WPKH o P2WSH, y lo utilizan como el redeemScript de un script P2SH. Los dos tipos de scripts SegWit envueltos son, por lo tanto, P2SH-P2WPKH y P2SH-P2WSH.

Este diseño permite que las billeteras más antiguas y otro software envíen Bitcoin a direcciones SegWit incluso si no son compatibles con SegWit. El receptor de una transacción SegWit envuelta puede gastar Bitcoin como una entrada SegWit, y así ahorrar en tarifas.

¿Qué es Bech32?

SegWit también introdujo un nuevo esquema de codificación llamado Bech32. Antes de SegWit, las direcciones y claves privadas de Bitcoin se habían codificado utilizando Base58, un esquema que utilizaba letras en mayúsculas y minúsculas.

Bech32 fue propuesto y aceptado como una mejora sobre Base58 porque nunca usa mayúsculas y minúsculas mezcladas, lo que lo hace más legible, más fácil de leer o transcribir, y más adecuado para la codificación QR. Además, Bech32 tiene un mecanismo de detección de errores incorporado para ayudar a los usuarios y las billeteras a detectar e incluso reparar errores tipográficos o cambios en una dirección.

Bech32 hace que las direcciones SegWit nativas sean fácilmente reconocibles, ya que solo usan letras minúsculas y comienzan con "bc1". Debido a que Bech32 solo usa 32 caracteres, estas direcciones son ligeramente más largas que las direcciones Base58, pero ocupan menos espacio en la cadena de bloques.

Bech32 también se utiliza para codificar facturas de Lightning, que comienzan con 'lnbc1'.

Historia y activación de SegWit

La actualización de SegWit fue una actualización extremadamente controvertida para Bitcoin, y tuvo un impacto duradero en el proceso de desarrollo y la comunidad. Sin embargo, el éxito de Bitcoin ante tal desafío demostró a muchos lo resistente que es Bitcoin.

SegWit se propuso por primera vez para Bitcoin Core en 2015 como BIP141 para resolver la malleabilidad de transacciones y liberar más espacio en la cadena de bloques. Sin embargo, durante este tiempo, los miembros de la comunidad estaban preocupados por la capacidad de escalado de Bitcoin y su capacidad para manejar un número creciente de transacciones.

En un intento de escalar Bitcoin, algunos miembros de la comunidad Bitcoin propusieron SegWit2x, que introdujo SegWit y duplicó el límite de peso de bloque a 8 unidades de peso, equivalente a 2 MB. SegWit2x obtuvo el apoyo del 95% de los mineros, medido por la tasa de hash. Más de 50 empresas de la industria Bitcoin firmaron un acuerdo llamado Acuerdo de Nueva York, comprometiéndose a activar SegWit2x y duplicar el tamaño del bloque.

El Acuerdo de Nueva York (NYA) fue una desviación del proceso de consenso de código abierto de Bitcoin. Por esta razón, el NYA no recibió suficiente apoyo de los operadores de nodos y desarrolladores y finalmente fracasó.

En cambio, un desarrollador anónimo, previamente desconocido, propuso BIP 148, que obtuvo el apoyo de los operadores de nodos y pudo implementar SegWit mientras rechazaba SegWit2x. Para impulsar este cambio, muchos nodos adoptaron implementaciones alternativas de Bitcoin Core, lo que obligó a los mineros a adoptar SegWit o arriesgarse a que sus bloques fueran rechazados.

Desde su activación, la adopción de SegWit ha ido aumentando constantemente. Sin embargo, no todas las billeteras y intercambios han implementado SegWit.

¿Por qué los operadores de nodos se opusieron a SegWit2x?

Los operadores de nodos almacenan toda la cadena de bloques, y muchos operadores de nodos utilizan máquinas pequeñas de baja potencia para hacerlo. SegWit2x habría más que duplicado la tasa de crecimiento de la cadena de bloques, lo que obligó a los operadores de nodos a almacenar una cantidad de datos que crecía rápidamente. Esto impondría costos a los operadores de nodos, ralentizaría los tiempos de descarga de bloque inicial (IBD) y desalentaría a los usuarios de ejecutar un nodo.

La mayoría de los desarrolladores también se opusieron a SegWit2x por razones similares. Temían que si menos personas pudieran ejecutar nodos, la red se volvería más centralizada y, por lo tanto, menos resistente a la censura y la captura.

¿Cómo sé si mi dirección Bitcoin es SegWit?

Hoy en día, muchas billeteras Bitcoin son compatibles con SegWit de forma predeterminada. Las direcciones Bitcoin SegWit suelen comenzar con un "3" o "bc1".

Las direcciones que comienzan con "3" se conocen como Pay to Script Hash (P2SH), que es compatible con SegWit.

Las direcciones que comienzan con "bc1" son direcciones Bech32 y representan direcciones SegWit nativas que utilizan completamente las mejoras de eficiencia de SegWit.

Si su dirección comienza con "1", es una dirección heredada y no es compatible con SegWit.

¿Puedo enviar BTC a una dirección SegWit?

Puede enviar BTC a una dirección SegWit desde direcciones heredadas y SegWit. La red Bitcoin admite transacciones entre diferentes tipos de direcciones para mantener la compatibilidad y garantizar que los usuarios puedan enviar y recibir Bitcoin independientemente del formato de dirección que utilicen.

¿Debo elegir SegWit o SegWit nativo?

Elegir entre SegWit y SegWit nativo ( Bech32 ) depende de sus necesidades:

• SegWit (P2SH) : Ofrece compatibilidad con servicios que aún no son compatibles con direcciones Bech32 , pero aún proporciona algunos beneficios de SegWit , como tarifas reducidas y mayor capacidad de transacción.
• SegWit nativo (Bech32) : Proporciona todos los beneficios de SegWit , incluidas tarifas aún más bajas y potencialmente confirmaciones de transacción más rápidas debido a su eficiencia. Sin embargo, es menos compatible con billeteras y servicios más antiguos.

Si prioriza la máxima compatibilidad, SegWit (P2SH) podría ser la mejor opción. Para las tarifas más bajas y si interactúa principalmente con plataformas que lo admiten, SegWit nativo ( Bech32 ) es preferible.

Lo que aprendimos de SegWit

Los argumentos que se lucharon en torno a SegWit y SegWit2x demostraron que los nodos, no los mineros, las empresas o incluso los desarrolladores, controlan la red. Los nodos que ejecutan su propio software pudieron anular a una abrumadora mayoría de mineros e implementar SegWit mientras rechazaban SegWit2x.

Esto inspira confianza en los usuarios de Bitcoin de que las reglas de consenso de Bitcoin, incluido el límite máximo de 21 millones de Bitcoin, no se pueden cambiar sin el consentimiento de los operadores de nodos.

Impacto económico de SegWit

La introducción de SegWit ha tenido implicaciones económicas significativas para la red Bitcoin, particularmente en lo que respecta a las tarifas de transacción y los ingresos de los mineros. Al permitir que se incluyan más transacciones en cada bloque, SegWit aumentó efectivamente el rendimiento de la red sin la necesidad de un hard fork.

Este aumento en la capacidad ha llevado a una reducción en las tarifas de transacción. El aumento de la capacidad del bloque permite más transacciones por bloque, lo que puede conducir a mayores tarifas de transacción totales recaudadas por bloque. Los mineros se verán incentivados a maximizar el peso del bloque a medida que las ganancias aumenten con el peso del bloque.

Si quieres conocer otros artículos parecidos a Segwit: una mirada profunda a la evolución de bitcoin puedes visitar la categoría Finanzas / Inversiones.