Bitcoin: la bifurcación suave de Discord

Algunos desarrolladores están presionando nuevamente para que se realice una bifurcación suave que tenga mucho menos consenso que las anteriores.

Bifurcación suave de Bitcoin

No es fácil alterar el código de Bitcoin. Tenemos el incentivo de no modificar nunca la parte del código correspondiente al límite de 21 millones.

Algunas evoluciones son, sin embargo, necesarias, otras no tanto. Por desgracia, siempre habrá desarrolladores que quieran aportar su granito de arena.

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

Como recordatorio, 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 de BCH porque pueden superar el límite de 1 MB por bloque. Un cambio de este tipo desencadena un hard fork.

En el caso de una bifurcación suave, los dos códigos coexisten en la misma cadena de bloques. Esto se llama compatibilidad con versiones anteriores. Por ejemplo, podríamos cambiar el tamaño del bloque a 0,3 MB. Esto es menor que el límite de 1 MB y, por lo tanto, compatible con versiones anteriores del protocolo original.

Las últimas bifurcaciones suaves fueron SegWit (2016) y Taproot (2021). Algunos desarrolladores están presionando para que se realice una nueva bifurcación que permita la creación de “pactos” mediante la adición de nuevos OP_codes.

Blockstream Research publicó recientemente un resumen bastante detallado sobre el tema:

Brinca brinca

Es fundamental entender la mecánica de las transacciones de bitcoin para entender qué son los pactos. La magia ocurre gracias a un lenguaje de ejecución informático llamado “script”. Es un lenguaje muy simple con un número limitado de instrucciones.

Estas instrucciones se denominan OP_codes. Considérelas como pequeños engranajes digitales que se ponen en marcha cuando se valida una transacción.

En concreto, realizar una transacción de bitcoins significa crear un “utxo” a partir de otro (o varios) “utxo” que se destruye 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 esencia, 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. Esto verifica que la firma coincida con la clave pública del utxo gastado. 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 “apilado” bastante simple que limita el campo de posibilidades.

Blockstream escribe sobre esto:

“Tal como están las cosas actualmente, no es posible preconfigurar cómo se pueden gastar los bitcoins de una utxo ni la velocidad a la que se pueden gastar. La única solución es experimentar con PSBT (transacciones de bitcoin parcialmente firmadas) que no pueden incluir adecuadamente las tarifas de transacción, entre otras limitaciones”.

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

Más aritmética en la pila

“Basado en pila” significa que los datos necesarios para la mecánica de las transacciones se colocan en una “pila” donde se realizan operaciones lógicas.

Ejemplo de un mecanismo de verificación de transacciones:

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

El OP_code OP_HASH convertirá esta clave en hash (lo que la transformará en una dirección a la que se vincularon matemáticamente los bitcoins en la utxo)

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

OP_CHECKSIG verifica que la firma proporcionada coincida con la clave pública del utxo.

Bitcoin Script tiene poco menos de 100 OP_codes no triviales. Sin embargo, no es posible multiplicar, dividir ni concatenar (combinar) datos en la pila.

Satoshi deshabilitó varios OP_codes en 2010 (OP_OR, OP_MUL [multiply]OP_DIV [divide]y OP_CAT [concatenate]). Estos OP_codes se eliminaron porque sus implementaciones originales tenían 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 (contratos inteligentes). Cabe destacar la imposibilidad de definir condiciones de gasto en la utxo en función de los datos de transacción.

Blockstream explica:

“Si el script tuviera la capacidad de interpretar más detalles dentro de los datos de las transacciones, podríamos construir contratos mucho más sólidos que permitan condiciones de gasto específicas”.

Pactos

Actualmente, el único “contrato inteligente” posible con bitcoin es simplemente el acto clásico de bloquear y desbloquear bitcoins vinculados a una clave pública. Es decir, realizar una transacción, en esencia.

Los pactos tienen como objetivo crear un nuevo tipo de utxo que permita al remitente de una transacción imponer ciertas condiciones sobre cómo el destinatario puede gastar los bitcoins posteriormente.

A continuación se presentan dos OP_codes agrupados bajo el término “pactos” con capacidades limitadas que a menudo surgen en el debate:

OP_CHECKTEMPLATEVERIFY (CTV):La principal utilidad que se plantea es la posibilidad de que varias personas compartan la misma utxo (BIP119 propuesta por Jeremy Rubin) en caso de que las comisiones por transacción sean excesivamente altas. Es una solución de escalado que en realidad no lo es, entre otras posibilidades más o menos interesantes.

OP_BÓVEDA:Este pacto permite al usuario determinar cuándo y dónde se pueden mover los bitcoins, incluso en transacciones posteriores.

Si un empleado con acceso a las claves privadas intenta robar bitcoins, la empresa puede transferir los fondos a una dirección de recuperación predeterminada antes de que los bitcoins se transfieran a una dirección perteneciente al ladrón.

OP_GATO:Este OP_code es aún más controvertido porque puede ser “recursivo”, es decir, se aplica no solo a la siguiente transacción, sino también a todas las transacciones posteriores que gastarán los bitcoins en cuestión. Por lo tanto, las condiciones de gasto se pueden aplicar de forma recurrente o perpetua.

¿Bitcoin realmente necesita estos OP_codes?

Los pactos recursivos plantean la cuestión de la unicidad de la moneda. Un bitcoin cuyo gasto está condicionado vale necesariamente menos que un bitcoin cuyo gasto no está condicionado. Un billete de 100 euros vale más que un vale de 100 euros válido en una única tienda…

Además, OP_CAT cuenta con el apoyo de Taproot Wizards, una dudosa camarilla de desarrolladores liderada por el intrigante Udi Wertheimer. Sus esfuerzos por arruinar la descentralización de Bitcoin popularizando las inscripciones (ordinales, sellos, etc.) deberían hacer sonar las alarmas…

Finalmente, queda por demostrar la utilidad real de estos OP_codes. Además de los exchanges, ¿qué empresas necesitan OP_Vault? En cuanto a CTV, ¿qué problema estamos intentando 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 se pueden crear alrededor de 150 millones de utxo cada año.

Todas estas propuestas tienen en común que apuestan a que el bitcoin se convertirá en un medio de pago popular. Aún estamos lejos de eso. Así que no hay prisa.

¿Podrían ser estas “soluciones” cada vez más complejas la expresión de una cierta forma de negacionismo? Tendremos que admitir que Bitcoin no puede competir con Mastercard (altas comisiones de conversión y de transacción).

¿Blasfemia o análisis objetivo? Tal vez no deberíamos esperar demasiado de Bitcoin, cuya principal oferta es ser una reserva absoluta de valor, no una alternativa al sistema fiduciario. Tal vez sea mejor no integrar artilugios inútiles que introducirán nuevas vulnerabilidades sin motivo. Recientemente se revelaron una docena de vulnerabilidades…

Si te ha gustado este artículo, te gustará este otro sobre el ataque DoS a las inscripciones.

Nicolás T.

Periodista especializado en Bitcoin, geopolítica, economía y energía.