Bitcoin se consolidaría como medio de pago masivo con la adopción de covenants

Uno de los grandes desafíos de Bitcoin es su adopción masiva como método de pago. Para alcanzar ese objetivo se han propuesto distintas herramientas. Entre ellas, la red Lightning, que en la actualidad ha alcanzado un importante nivel de desarrollo. Sin embargo, todavía no ha alcanzado su potencial y es aquí donde podría ser crucial un desarrollo como los covenants.

El desarrollador de Bitcoin John Law publicó un artículo, resumido a través de la lista de desarrolladores de Bitcoin y de la red Lightning, que propone un método para crear fábricas de canales de pago a través de covenants (o convenios) simples. Estos canales de pago estarían dirigidos a usuarios ocasionales.

Los covenants son métodos para programar condiciones en las transacciones de Bitcoin y asegurar a su vez su cumplimiento. En la actualidad, no han sido integrados al consenso de Bitcoin (y quizá su implementación tarde o no ocurra), pero desde 2022 el debate en torno a estas funciones cobró relevancia. Algunos dudan de la integridad técnica de los covenants, sugieren que es muy temprano para usarlos en Bitcoin. Pero no todos opinan de esta manera.

“Si bien se ha demostrado que los convenios mejoran Bitcoin de varias maneras, la escalabilidad de Lightning no suele figurar como una de ellas”, explica Law. Otros desarrolladores como Jameson Loop coinciden que los covenants llevarían beneficios a Bitcoin, como reportó CriptoNoticias.

La clave está en los usuarios ocasionales y los covenants

Law argumenta que los métodos actuales para crear canales de pago, incluidos los que utilizan multifirmas como CoinJoin, están limitados a generar algunas decenas o centenas de canales por cada UTXO o cada transacción con fondos. Una UTXO (Unspent Transaction Output) es una salida de transacción no gastada en la cadena de bloques de Bitcoin.

Además, al crear canales de pago en la red Lightning las personas involucradas se comprometen a firmar por cada transacción, lo que puede crear un problema de coordinación si se trata de numerosos firmantes. De esta manera, explica el programador, “si un UTXO requiere firmas de un conjunto de 1.000 usuarios ocasionales y si 999 de ellos firman, pero uno no, las 999 firmas que se obtuvieron no se pueden utilizar”. Por su naturaleza, los usuarios ocasionales no siempre están disponibles.

Según Law, covenants simples como CTV (OP_CHECKTEMPLATEVERIFY) y APO (SIGHASH_ANYPREVOUT) permitirían que una única transacción pequeña restrinja los fondos, con la condición de que se gasten posteriormente en una o varias transacciones predefinidas.

OP_CHECKTEMPLATEVERIFY es un código de operaciones que permite a los scripts (o instruccionesde programa) de Bitcoin verificar el cumplimiento de un conjunto de condiciones. Estas condiciones pueden incluir la estructura de la transacción, la cantidad de Bitcoin que se envía y la firma del remitente.

SIGHASH_ANYPREVOUT es un modificador de firma que permite a los usuarios firmar transacciones sin especificar todas las entradas de la transacción. Esto es útil para los contratos inteligentes, ya que permite a los usuarios firmar transacciones sin saber de antemano cuáles serán todas las entradas de la transacción.

Con estas funciones, es posible que un único usuario dedicado pueda crear un millón de canales para usuarios ocasionales, quienes no tendrían que preocuparse por cumplir condiciones específicas, puesto que solo tendrían que interactuar con el contrato una vez cada pocos meses. Aunque se han propuesto otros métodos para que una sola entidad genere múltiples canales y enrute pagos de terceros, ninguno cumple con la condición de liberar a los usuarios que no administran nodos de un número de tareas significativo.

Un mecanismo similar al utilizado por Ark permite que cada uno de los canales de pago se coloque opcionalmente en la cadena, pero también permite que el financiador de la fábrica reclame los fondos del canal que no se hayan puesto en la cadena después de su vencimiento. Esto puede ser extremadamente eficiente: se puede crear un árbol de tiempo de espera fuera de la cadena que financie millones de canales utilizando una única pequeña transacción dentro de la cadena. Después del vencimiento, el financiador de la fábrica puede reclamar los fondos en otra pequeña transacción en cadena, y los usuarios individuales retiran sus fondos a través de LN a sus otros canales antes de la fecha de vencimiento de la fábrica.

Bitcoin Optech, newsletter sobre desarrollo

Un abanico de opciones

Los covenants podrían proporcionar otras características a los usuarios de Lightning. Por ejemplo, se podrían admitir cambios de tamaño de canales fuera de la cadena o utilizar el mismo capital para ofrecer simultáneamente liquidez entrante a usuarios ocasionales y enrutar pagos no relacionados para otros usuarios.

Además, se podría cobrar a los usuarios ocasionales sanciones ajustables por intentar poner un estado antiguo en la cadena (con lo cual podrían intentar engañar a otra persona y obtener un beneficio económico), y permitir a los usuarios ocasionales monitorear la cadena de bloques durante solo unos minutos cada pocos meses, sin emplear un servicio de watchtower o nodos especiales que funcionan como torres de vigilancia.  

Algunas críticas

El desarrollador Anthony Towns expresó su preocupación frente a lo que él denomina el problema del “rebaño atronador” o “spam de caducidad forzada”, como se denomina en el White paper de Lightning.

De acuerdo con este problema técnico, si un usuario dedicado falla accidental o deliberadamente, requeriría que muchos usuarios ocasionales envíen transacciones a la cadena principal al mismo tiempo.  

Por ejemplo, “una fábrica con un millón de usuarios puede requerir una confirmación urgente de hasta un millón de transacciones, más una confirmación no confidencial de hasta dos millones de transacciones adicionales, para que esos usuarios vuelvan a colocar esos fondos en nuevos canales”, explica Bitcoin Optech.

Si el problema ocurre de manera inesperada, hay poco que los usuarios puedan hacer, más allá de coordinarse y esperar varios días para que se confirmen sus transacciones. Además, si hay una fecha de vencimiento del contrato, es probable que los usuarios ocasionales requieran que la fábrica de canales transfiera sus fondos varias semanas antes de ese momento, o incluso varios meses antes.