Hechos clave:
-
La BIP-119 aún no ha sido minuciosamente analizada a nivel técnico, dicen algunos.
-
Los covenants esconden algunos riesgos que en principio no son advertidos.
La Bitcoin Improvement Proposal 119 o BIP-119 es una creación del desarrollador Jeremy Rubin, quien apunta con ella a introducir parámetros avanzados para las transacciones de Bitcoin, como por ejemplo, que unos bitcoins solo puedan ser enviados a una dirección en específico y no a otra.
Pero, además, y de manera importante, también puede condicionar el gasto de esos bitcoins en el futuro, de forma que una vez sean enviados a una dirección inicial, a partir de allí solo puedan enviarse hacia otras direcciones especificadas.
Este tipo de restricciones se conocen como covenants y se ejecutan bajo el comando OP_CTV, que en sus dos casos de uso básicos permite crear una suerte de bóveda (vault). Con esta instrucción, por ejemplo, los fondos de una wallet fría o de hardware solo se podrían retirar hacia otra dirección bajo control del dueño de fondos.
Además, la BIP 119 podría permitir hacer transacciones en lote con cierta regularidad o ritmo, de manera armoniosa. Por ejemplo, sería posible que cuando una cierta cantidad de bitcoins se depositen en una wallet, desde esta se ejecuten otros pagos hacia otras direcciones.
Así el dueño o encargado de un comercio podría, hipotéticamente, depositar la cantidad de bitcoins necesaria para pagar a sus empleados, y desde esta wallet los pagos se ejecutarían oportunamente y de manera automatizada a cada una de las wallets o monederos de los trabajadores.
Este tipo de transacciones en lote también puede programarse para ejecutarse con otros parámetros. Por ejemplo, cuando las comisiones de la red promedien menos de 4 satoshis por byte (vbyte, el peso en datos de estas transacciones).
El argumento técnico: ¿OP_CTV es un desarrollo realmente seguro?
La discusión sobre OP_CTV, la función que introduce la BIP-119, sigue a través del correo de desarrolladores de Bitcoin. Estas son algunas de las opiniones recientes, desde el punto de vista técnico, de algunos de estos programadores.
En primer lugar, el desarrollador Anthony Towns consideró que, según su análisis, la mayoría de transacciones de prueba de CTV parecen estar programadas con Sapio, un lenguaje creado por Jeremy Rubin con el objetivo de «hacer contratos inteligentes en Bitcoin». Towns opina que quizá, por esta razón, la CTV no ha tenido mucha examinación pública todavía.
Además, cree que introducir la BIP-119 puede generar riesgos para todos los usuarios de Bitcoin, incluso aquellos que no tienen el deseo de utilizar sus funcionalidades, debido a los cambios que se deben hacer en el mecanismo de consenso.
Esto último lo secundó el desarrollador Matt Corallo, quien advirtió que una actualización o soft fork de este tipo debería proveer el mayor beneficio posible a la mayor cantidad de usuarios posible.
Por otro lado, Russell O’Connor, también desarrollador, señaló que no parece existir mucha compatibilidad del script o comando OP_CTV con otros scripts de Bitcoin como base58check, bech32 (SegWit) o bech32m (Taproot), por lo que existiría la necesidad de que las wallets desarrollen herramientas que permitan usar la BIP-119 sin problemas de coordinación entre las direcciones de cartera utilizadas.
David Harding mostró su preocupación por el hecho de que CTV puede ser un tipo de convenio o covenant que al largo plazo no sea muy utilizado, ya sea por baja demanda de los usuarios o porque surjan otros tipos de covenants mejor diseñados. «Esto dejaría a los desarrolladores del futuro con la carga de mantener el código y tener que analizar cómo serían las interacciones potenciales de CTV con otros cambios venideros del consenso», argumentó.
Esta serie de opiniones son las más fundamentadas a nivel técnico, a diferencia de las opiniones de carácter político que cubrimos en una entrega previa, y que suelen verse más a menudo en las redes sociales. Los desarrolladores de Bitcoin Core aún no están seguros de la necesidad y viabilidad de la BIP-119.
El siniestro antecedente: los covenants de Gregory Maxwell
Tan temprano como en agosto de 2013, el desarrollador Gregory Maxwell explicó un tipo de covenant o restricción de gasto de BTC basado en el protocolo CoinWitness. Pero a modo de ejercicio intelectual, ilustró algunas formas aterradoras en las que estas restricciones podrían resultar.
Básicamente, explicó en un post que al agregar cláusulas arbitrarias para gastar unos bitcoins, todo en adelante podría salir mal. Maxwell argumenta que al requerir que unos bitcoins sean gastados de una forma en específico «habrás creado una moneda que esté sujeta para siempre a una condición de gasto [covenant] y restringir para siempre su uso y el de sus descendientes, degradando su fungibilidad».
En otras palabras, estos bitcoins condicionados a gastarse de una forma en específico serían diferentes al resto de bitcoins circulantes en la red, lo que podría causar que otras personas no los quieran recibir ni transaccionar con ellos, e incluso que estos bitcoins tengan un precio de compra y venta diferente al resto en el mercado.
Así, Maxwell invitó a otros lectores del foro BitcoinTalk, donde publicó su argumento, a imaginar otras formas aterradoras de covenants. La comunidad de bitcoiners de ese entonces respondió.
El otro desafío técnico: ¿Cuál es la mejor forma de alcanzar el consenso en Bitcoin?
La forma en que Jeremy Rubin propuso activar la BIP-119, amenazando con lanzar un cliente propio y apelar a una speedy trial hecha por los mineros, como ocurrió con Taproot, fue uno de los puntos que más polémica levantó en torno al debate.
De esta manera, el aspecto más debatido en principio no fueron las cualidades técnicas de la BIP-119, sino el mejor método de activación. El desarrollador Keagan McClelland aprovecha el debate de la BIP-119 para proponer una discusión sobre cuál es la mejor forma de alcanzar un consenso en Bitcoin.
Junto con el debate de CTV existe ahora un segundo debate que no fue tratado por completo durante la activación de Taproot. Existe mucho argumento sobre qué es una Speedy Trial y qué no, qué es la BIP 8 [soft-fork activado por los usuarios] y qué no, etc.
Una razón significativa para perder las buenas formas en este debate es que, debido a que no tenemos formas de medir el apoyo de un usuario hacia los cambios propuestos, esto envariablemente en que las personas digan que su circulo social aprueba o rechaza una propuesta, y que sus círculos representan a la mayoría de usuarios de Bitcoin como un todo.
Keagan McClelland
Proponiendo esta discusión, McClelland asegura que apelar a los mineros tal vez no sea la mejor opción para hacer cambios en el software de Bitcoin, pues estos pueden tener incentivos diferentes a los que tiene el mercado de usuarios (por ejemplo, un soft fork que suba las comisiones mínimas por transacción o que aumente el tiempo de producción de bloques).
La discusión continuó con comentarios de otros desarrolladores, quienes plantearon otros mecanismos para la activación de este tipo de propuestas.
Dado el precedente teórico sobre los covenants como el expuesto por Gregory Maxwell y la comunidad temprana de Bitcoin, a los desarrolladores no les queda claro si la BIP-119 es deseable para todos sus usuarios y para el protocolo mismo.
En una próxima entrega explicaremos el lado social de este debate y qué representa para Bitcoin.
