Bitcoin - La Bifurcación Suave de la Discordia

Algunos desarrolladores están impulsando nuevamente una soft fork que tiene mucho menos consenso que las anteriores.

Bitcoin Soft Fork

No es fácil alterar el código de bitcoin. Se nos incentiva a no modificar nunca la parte del código correspondiente al límite de los 21 millones.

Algunas evoluciones son, sin embargo, necesarias, otras mucho menos. Desafortunadamente, siempre habrá desarrolladores que quieran aportar su mal grano de arena.

Las evoluciones del código se proponen a través de «Pull Requests». La mayoría son menores, pero algunas son mayores. Se convierten entonces en BIP (Bitcoin Improvement Proposals) que a veces son «soft forks».

Para recordarlo, un hard fork es una evolución del código incompatible con el anterior. El ejemplo típico es BCH (Bitcoin Cash). Los nodos de la red BTC no validan los bloques BCH porque pueden superar el límite de 1 MB por bloque. Tal modificación desencadena un hard fork.

En el caso de una soft fork, los dos códigos coexisten en la misma blockchain. Se habla de retrocompatibilidad. Por ejemplo, podríamos modificar el tamaño de los bloques a 0,3 MB. Es menos que el límite de 1 MB y, por lo tanto, es retrocompatible con el protocolo original.

Las últimas soft forks en fecha fueron SegWit (2016) y Taproot (2021). Algunos desarrolladores están actualmente impulsando una nueva fork para permitir la creación de «covenants» mediante la adición de nuevos OP_codes.

Blockstream Research ha publicado recientemente un resumen bastante técnico sobre el tema:

Is OP_CAT happening?

The covenants proposal was recently assigned BIP 347, and now it's up to the community to decide.

Blockstreamer @kiarabickers breaks down the pros and cons and attempts to answer the question on most Bitcoiners' minds: Is it safe?https://t.co/2nSj6JQ7ja pic.twitter.com/uxiAz0zx1H

— Blockstream (@Blockstream) July 2, 2024

Hop Hop

Es esencial comprender la mecánica de las transacciones de bitcoin para entender qué son los covenants. La magia se opera gracias a un lenguaje de ejecución informática llamado «script». Es un lenguaje muy simple que comprende un número limitado de instrucciones.

Estas instrucciones se llaman OP_codes. Véanse como pequeños engranajes digitales que se ponen en marcha en el momento de la validación de una transacción.

Concretamente, realizar una transacción de bitcoin significa crear un «utxo» a partir de uno (o varios) otros «utxo» que se destruyen en el proceso. Un utxo es un fragmento de código (un script) que vincula matemáticamente una cantidad de bitcoins a una dirección de bitcoin (una clave pública).

En resumen, realizar una transacción significa cambiar la clave pública (la dirección de bitcoin) a la que está vinculada la cantidad de bitcoins.

Durante una transacción, el OP_code estrella es OP_CHECKSIG. Este último verifica que la firma corresponde a la clave pública del utxo que se está gastando. Si todo está en orden, se crea un nuevo utxo que contiene la clave pública del receptor.

En general, Bitcoin Script es un lenguaje de programación «stack based» bastante simple que limita el campo de posibilidades.

Blockstream escribe al respecto:

«En el estado actual de las cosas, no es posible preconfigurar la forma en que los bitcoins de un utxo pueden ser gastados o la velocidad a la que pueden ser gastados. La única solución es improvisar utilizando PSBT (transacciones de bitcoin parcialmente firmadas) que no pueden incluir correctamente las tarifas de transacción […].

La simplicidad del lenguaje de programación Script, aunque está en el corazón del modelo de seguridad de Bitcoin, introduce limitaciones importantes en su capacidad para soportar los contratos inteligentes más elementales.»

Más aritmética en el stack

«Stack based» significa que los datos necesarios para la mecánica de las transacciones se colocan en una «pila» donde se realizan operaciones lógicas.

Ejemplo del mecanismo de verificación de una transacción:

El OP_code OP_DUP duplicará la clave pública de un utxo y la colocará en la pila.

El OP_code OP_HASH va a hashear esta clave (lo que la transforma en una dirección a la que los bitcoins han sido matemáticamente vinculados en el utxo).

OP_EQUALVERIFY verifica que el hash resultante pertenece al utxo en cuestión.

OP_CHECKSIG verifica que la firma proporcionada corresponde a la clave pública del utxo.

Bitcoin Script posee un poco menos de 100 OP_codes no triviales. Pero el hecho es que no es posible multiplicar, dividir o concatenar (combinar) datos que se encuentran en la pila.

Satoshi desactivó varios OP_codes en 2010 (OP_OR, OP_MUL [multiplicar], OP_DIV [dividir] y OP_CAT [concatenar]). Estos OP_codes fueron eliminados porque sus implementaciones originales presentaban vulnerabilidades explotables que podrían comprometer la seguridad de la red.

Sin embargo, su ausencia dificulta la creación de ciertas condiciones de gasto exóticas (smart contracts). Principalmente, la imposibilidad de definir en el utxo condiciones de gasto basadas en los datos de transacción.

Blockstream explica :

«Si el script tuviera la capacidad de interpretar más detalles dentro de los datos de la transacción, podríamos construir contratos mucho más robustos que permitan aplicar condiciones específicas de gasto.»

Covenants

Actualmente, el único «smart contract» posible con el bitcoin es simplemente el acto clásico de bloquear y desbloquear bitcoins vinculados a una clave pública. Realizar una transacción en resumen.

Los covenants tienen como objetivo crear un nuevo tipo de utxo que permite al emisor de una transacción imponer ciertas condiciones sobre la forma en que el destinatario podrá gastar los bitcoins posteriormente.

Aquí hay dos OP_codes que se agrupan bajo el término «covenants» con capacidades limitadas que frecuentemente aparecen en el debate:

OP_CHECKTEMPLATEVERIFY (CTV): La principal utilidad destacada es la posibilidad de que varias personas compartan un mismo utxo (BIP119 propuesta por Jeremy Rubin) en caso de tarifas de transacción demasiado altas. Es una sCaLing sOluTIon que realmente no lo es, entre otras posibilidades más o menos interesantes.

OP_VAULT: Este covenant permite a un usuario determinar cuándo y dónde los bitcoins pueden ser movidos, incluyendo en transacciones posteriores.

Si un empleado con acceso a las claves privadas intenta robar bitcoins, la compañía podrá transferir los fondos a una dirección de recuperación predeterminada antes de que los bitcoins sean transferidos a una dirección perteneciente al ladrón.

OP_CAT: Este OP_code es aún más controvertido ya que puede ser «recursivo». Es decir, se aplica no solo a la próxima transacción, sino también a todas las transacciones posteriores que gasten los bitcoins involucrados. Se pueden aplicar condiciones de gasto de manera recurrente/perpetua.

¿Realmente necesita Bitcoin estos OP_codes?

Los covenants recursivos plantean la cuestión de la unicidad de la moneda. Un bitcoin cuya transacción está condicionada necesariamente vale menos que un bitcoin cuya transacción no está condicionada. Un billete de 100 euros vale más que un vale de compra de 100 euros válido en una sola tienda…

Además, OP_CAT está respaldado por Taproot Wizards, un grupo de desarrolladores problemáticos liderados por el intrigante Udi Wertheimer. Sus esfuerzos por arruinar la descentralización de bitcoin popularizando las inscripciones (Ordinals, stamps, etc) deberían encender luces de advertencia…

Finalmente, la utilidad real de estos OP_codes aún está por demostrar. Aparte de los exchanges, ¿qué compañías necesitan OP_Vault? En cuanto a CTV, ¿qué problema se busca resolver? Después de 15 años de existencia, solo hay 16 millones de utxo que contienen más de 2600 dólares, sabiendo que pueden crearse alrededor de 150 millones de utxo cada año.

Todas estas propuestas tienen en común el apostar que el bitcoin se convertirá en un medio de pago popular. Todavía estamos lejos de eso. No hay prisa.

¿Es posible que estas «soluciones» cada vez más complejas sean la expresión de una cierta forma de negación? Hay que admitir que el bitcoin no puede competir con Mastercard (comisiones de conversión y transacción demasiado altas).

¿Blasfemia o análisis objetivo? Tal vez no deberíamos pedir demasiado al bitcoin cuya principal oferta es ser una reserva de valor absoluta, y no una alternativa al sistema fiat. Tal vez es mejor no integrar gadgets inútiles que introducirán nuevas vulnerabilidades sin ningún beneficio. Recientemente se han descubierto una decena de vulnerabilidades…

Si te gustó este artículo, apreciarás éste sobre el ataque DoS de las inscripciones.