Se dividen las opiniones frente a una actualización que integraría covenants en Bitcoin

En la actualidad existen numerosas propuestas para mejorar Bitcoin que apuntan a que el protocolo sea más versátil o más escalable. Algunas de estas propuestas han sido discutidas durante años; otras, como los covenants o convenios, tienen relativamente poco tiempo en la palestra, pero atraen mucha atención, por lo que representaría su integración en el código de Bitcoin.

En este sentido, el desarrollador de Bitcoin Core, James O’Beirne, propuso cambios en el borrador de una herramienta que permitiría ejecutar un softfork, o bifurcación suave, para integrar un conjunto de características en Bitcoin, incluidas en las propuestas BIP-118, BIP-119 y BIP-345. Estas herramientas o funciones permitirían autorizar distintas transferencias con una misma firma digital, hacer operaciones de lote para el control de congestión de transacciones, crear instancias para crear canales de pago o bóvedas de seguridad de fondos.

Los convenios o pactos son restricciones para realizar un determinado pago y su implementación requiere que se ejecuten cambios en el código base de Bitcoin.

Hay varios motivos que conducen a los desarrolladores de Bitcoin a ser meticulosos cuando se revisa una propuesta de este tipo. El principal factor tiene que ver con la revisión del código de las nuevas herramientas. Los desarrolladores de Bitcoin Core solo implementan un cambio de esta naturaleza cuando ha sido revisada por varias personas durante suficiente tiempo, de modo que se pueda probar adecuadamente.

“Puede que este no sea el camino que finalmente tomemos, pero tener una posibilidad tangible sobre la mesa es importante para avanzar en el debate técnico”, explica O’Beirne.

Lo cierto es que esta propuesta parece haber reanimado la discusión sobre si los coventans (convenios o pactos) son necesarios en la actualidad.

No todos están de acuerdo

Entre los comentarios que recibió la propuesta, hay quienes coinciden en que la BIP-118 o SIGHASH_ANYPREVOUT para Taproot Scripts es prescindible, debido a que “desperdicia” soluciones que ya se están implementando, por ejemplo, las claves sighash (firma de hash) de la última versión de Tapscript, un lenguaje de scripting utilizado para habilitar una variedad de nuevos tipos de transacciones como parte de la actualización Taproot de Bitcoin. Tapscript es similar al script, el lenguaje de scripting heredado de Bitcoin, con algunas alteraciones.

El desarrollador y CTO de Lightning Lab, Olaoluwa Osuntokun, también preguntó a O’Beirne si no consideraba que la BIP-119 o CHECKTEMPLATEVERIFY (CTV) tiene más sentido si utiliza Tapscript. No estuvieron de acuerdo sobre cómo se implementaría en los breves mensajes que intercambiaron.

Desacuerdo sobre la metodología de revisión

Una de las voces más contundentes que criticó la propuesta es la de Antoine Riard, desarrollador de Bitcoin Core. Según Riard, “es prácticamente imposible proporcionar una revisión técnica sólida” sin una prueba de concepto de los códigos de operaciones y primitivas (unidades de programación básicas) para establecer qué es lo que permiten exactamente.

Fiatjaf, el creador del protocolo Nostr, por su parte, sostuvo que una prueba de concepto era inferior a una descripción teórica que contemple todos los escenarios. Frente a esto, Riard sostiene que en algunos casos una descripción matemática es suficiente (citó los cálculos sobre incentivos de minería del capítulo 11 del white paper de Bitcoin); además citó otros casos de descripción teórica y de seguridad que complementarían una revisión de este estilo.

“De hecho, creo que todas son descripciones ‘válidas’ y se completan entre sí, es decir, describen con mayor precisión un caso de uso”, sostuvo. “Las pruebas de conceptos, los experimentos y las descripciones formalizadas o lógicas tienen cientos de años de trayectoria exitosa en el campo de la ingeniería civil, mecánica y de software”, argumentó.

Como recordatorio, Bitcoin es un ecosistema de 500 mil millones de dólares que se utiliza como infraestructura crítica en la vida diaria de las personas en países emergentes o zonas de guerra. Como comunidad técnica, si tenemos un deseo sincero de que este sistema sobreviva con perspectivas de décadas y siga siendo confiable, debemos cumplir con los más altos estándares de ingeniería, o al menos no rebajar los estándares de desarrollo que han sido configuración en el pasado, por ejemplo, con el proceso de diseño, revisión e implementación del código principal.

Antoine Riard, desarrollador de Bitcoin Core.

Además, recordó que “el diseñador original o el equipo de diseño de Bitcoin Core” introdujo el “infame” código de operaciones OP_VER en las primeras versiones del cliente, que provocaba un hardfork accidental por consenso de los nodos de la red, aunque afortunadamente nadie llegó a utilizar este código de operaciones.

Personalmente, estoy bien si no tenemos bifurcaciones blandas de covenants durante los próximos 10 años, a pesar del interés personal en numerosos casos de uso aportados o mejorados por las primitivas de covenant. No es que nos falten cambios importantes para fortalecer Bitcoin, reducir los costos computacionales de los nodos completos o hacerlo más utilizable para el usuario final.

Antoine Riard, desarrollador de Bitcoin Core.

El desarrollador continuó ofreciendo muchos más detalles sobre su punto de vista respecto al código que la propuesta busca revisar. Sin embargo, su opinión se puede reducir a la siguiente frase: “Todo lo que Bitcoin necesita hacer para tener éxito a largo plazo es simplemente sobrevivir y ya es ambicioso”.

Estas no son las únicas opiniones que cuestionan la integración de covenants en Bitcoin. Como reportó CriptoNoticias, varios desarrolladores expresaron su preocupación ante una potencial bifurcación para introducir la BIP-119 el año pasado. Sin embargo, como reconoce el propio Riard, los covenants podrían traer beneficios sobre el uso y la escalabilidad de la red, como comentan otros desarrolladores.