BIP 119: propuesta para automatizar transacciones en lote entre usuarios de Bitcoin

Es sabido que la adopción de Bitcoin va en crecimiento. Pero este protocolo aún no tiene la capacidad de procesamiento aspirada para una adopción masiva de usuarios, debido a la ocasional congestión de la red que retrasa la confirmación de transacciones y propicia el aumento de las comisiones.

La propuesta de escalabilidad BIP-119, que aborda este problema, viene recaudando apoyo de miembros de la comunidad Bitcoin desde que fue publicada el año pasado por Jeremy Rubin, programador informático egresado del MIT y cofundador de iniciativas de esa universidad por Bitcoin y las criptomonedas.

Rubin propone aumentar la capacidad interna de Bitcoin, permitiendo que un número mayor de transacciones pueda realizarse con menor esfuerzo y costo en su emisión, mediante la implementación del comando OP_CHECKTEMPLATEVERIFY (OP_CTV). Esta solución, observa Rubin, no debería realizarse de forma contenciosa, sino mediante una bifurcación suave.

Aunque las transacciones en lote (batching) son una solución válida, a consideración de Rubin, estas son pesadas en datos y en algún momento pueden llegar a congestionar la red. OP_CTV podría en primera instancia separar las transacciones en lote en dos partes: una transacción emisora y otra transacción receptora. De este modo, se evitaría realizar una transacción en lote con múltiples salidas; ya que se procesaría a través de un enlace entre ambas transacciones, donde la transacción receptora tenga un menor costo y pueda igualmente distribuir los fondos eficientemente con las múltiples salidas que posea.

El comando (OP_CTV), implementado por esta solución de escalabilidad, realiza esta operación de envío masivo de fondos a diversas direcciones con la introducción de los covenants —o transacciones acordadas— mencionados en la justificación de la propuesta disponible en GitHub. Esta característica fue criticada notablemente en el foro BitcoinTalk por Gregory Maxwell en 2014, quien en principio propuso implementar pruebas de conocimiento cero (SNARK). Pero, debido a la ausencia de un lenguaje de contratos inteligentes más eficiente para lidiar con este procedimiento en Bitcoin, el mismo autor descartó su implementación.

Básicamente, los covenants son “acuerdos” en cómo se gasta un bitcoin sucesivamente a través de una serie de transacciones, más allá de la autoridad que tenga una llave privada sobre las monedas en cuestión.

Los covenants son restricciones sobre cómo una moneda puede gastarse más allá de quien sea el propietario. Los covenants pueden ser útiles en la construcción de contratos inteligentes. Al ser difíciles de implementar y al existir el riesgo de introducir elementos que reduzcan la fungibilidad, estos no han sido considerados seriamente para incluirse en Bitcoin.

Esta BIP introduce un covenant simple llamado “Template” que nos abre las puertas a una cantidad importante de usos sin riesgo significativo.

Jeremy Rubin, autor BIP-119.

En la conferencia Scaling Bitcoin, donde Rubin expuso su idea bajo el nombre OP_SECURETHEBAG, el autor dio un ejemplo sobre cómo funciona el comando; señalando que se debe crear un lote (batch) de transacciones, para luego crear una transacción comprometida hacia una segunda fase de batching y entrega final de los BTC (cierre de la salida) a los receptores.

En teoría, la transacción final ejecutada en la segunda fase (receptora) tiene un costo muy bajo en comisiones de red. No obstante, la primera transacción del ciclo (emisora) pagaría comisiones promedio según su peso en memoria, el cual sería considerablemente menor al que requiere enviar todas las transacciones por separado, previniendo la congestión del mempool de Bitcoin.

Son varios los ejemplos que a simple vista se advierten sobre implementar OP_CTV. Entre los principales beneficiados de esta nueva propuesta estarían las casas de cambio. Como custodios de los fondos de sus clientes, siempre hay solicitudes de retiro que atender. En momentos de alta demanda, pueden emitir una transacción OP_CTV para agilizar dicho proceso, ahorrando en comisiones y gastos operativos, evitando saturar la red Bitcoin.

Igualmente, una vez comience a masificarse la adopción de Bitcoin, aquellos comerciantes que deseen realizar pagos o transacciones con sus múltiples proveedores, clientes y empleados de forma simultánea, pueden beneficiarse de OP_CTV. Esto aplica también para las industrias en torno a Bitcoin, donde por ejemplo, los pools de minería podrían distribuir rápidamente y a bajo costo entre sus participantes las recompensas recabadas por los mineros.

Podríamos encontrar otro ejemplo en un sistema de pago de servicios básicos o suscripciones, que suelen facturar una vez al mes. Así una persona podría pagar el servicio eléctrico y de agua, su servicio de streaming favorito y el saldo de su teléfono celular al mismo tiempo con una sola transacción de bitcoins.

En este sentido, durante la anterior Bitcoin Expo del MIT realizada el mes de abril pasado, Rubin demostró otros casos de uso, como la creación de vaults (bóvedas) automatizadas, las cuales pueden configurarse con OP_CTV para realizar transacciones periódicas entre carteras frías y calientes, introduciendo diferentes variables en este flujo de transacciones según convengan los participantes.

CoinJoin, minería y Lightning Network con OP_CTV

En exclusiva para CriptoNoticias, Rubin explicó que algunos de los beneficios de utilizar OP_CTV es que este tipo de transacciones pueden enlazarse con Lightning Network también, expandiendo las posibilidades de esta implementación y poniéndola a la altura de las necesidades y capacidad de la red Bitcoin.

En este modelo, los mineros serían uno de los grupos que más utilizarían Lightning Network y ejecutarían la apertura y cierre de los canales de esta red.

Según argumenta Rubin en la página web Utxos.org, los mineros pueden partir de los datos de un bloque minado anteriormente para minar nuevos bloques a partir de allí. Este bloque, que llamaremos calificado, sería un bloque determinado en base a ciertos parámetros; como por ejemplo, un bloque con una antigüedad no mayor a un tiempo T, los bloques entre los tiempos T1 y T2, o el último bloque antes de una cantidad N de bloques pasados.

Elegir un bloque calificado para minar a partir de esa altura permitiría revertir el hecho de que actualmente los mineros de Bitcoin comparten la recompensa obtenida por sus actividades con el pool o grupo de minería; luego desde aquí, estas son repartidas entre todos los participantes, según su aporte a la red.

En contraparte, los mineros podrían reunir la totalidad de las recompensas y compartirlas con los mineros calificados en ese momento. OP_CTV permite crear una sola transacción con varios inputs y varios outputs, según sea el caso, evitando crear 1 transacción por cada pago que deba realizarse.

También, al abrir un canal entre participantes, se puede firmar la apertura o cierre de inputs y outputs, permitiendo asignar «manualmente» los montos correspondientes a cada entrada y salida siempre que exista consenso entre las partes. Haciendo efectivo un pago o transmisión de fondos y evitando así el aumento del volumen de transacciones on-chain para estos fines; dejando un árbol de canales abiertos entre las partes, donde solo sería necesario actualizar los saldos de la entrada y la salida para simplificar la transferencia de valor.

Puedes pensar en esos canales de Lightning Network como un circuito retroalimentado. Concretamente, si tengo un canal A y un canal B abiertos entre dos participantes, donde A tiene 100 satoshis, de los cuales 25 le pertenecen, y B tiene 660 satoshis, de los cuales 60 pertenecen a A, podríamos cerrar el canal definitivamente, o actualizarlos para que A tenga 85 satoshis y B tenga 600 satoshis y luego cerrar A. Si aplicamos esta idea a transacciones de OP_CTV, el minero podría minar durante un largo tiempo hasta tener, digamos, 1 BTC, y retirarlos definitivamente a través de una sola salida (UTXO).

Jeremy Rubin, desarrollador BIP 119.

Tras hacerle la observación de que esto requeriría una gran cantidad de nodos habilitados para Lightning Network, Rubin comenta que no habrá problema en que los mineros realicen esta actividad, pues así serían también responsables de incrementar la liquidez de Lightning Network.

Rubin explica también, en la mencionada página web, que un minero debe poder minar por sí mismo al menos 1 BTC para poder entrar a estos grupos de minería sin confianza (no requieren coordinación o de partes confiables). Este logro se obtendría a través de grupos de minería basados en la confianza (pools convencionales), donde primeramente se conduzca al minero a trabajar hasta alcanzar los niveles apropiados de hash rate. Sin embargo, estos grupos serían de tamaño reducido para evitar riesgos. Estos planteamientos contribuyen sin duda a la descentralización de la minería de Bitcoin, según Rubin.

Rubin ejecutó un escenario de simulación acerca del impacto que tendría en la mempool de Bitcoin ejecutar OP_CTV, donde se muestra que los picos de congestión de la red podrían pasar rápidamente cuando se ejecuten transacciones de este tipo en periodos de alta demanda y tráfico.

Con respecto a los efectos que tiene OP_CTV en la privacidad de la red, al preguntársele específicamente por métodos como CoinJoin, Rubin no mostró preocupación, dando sus razones para confiar en que sería positivo combinarlos.

OP_CTV hace mucho más fácil realizar CoinJoin de gran alcance, porque reduce drásticamente las comisiones. También hace más fácil utilizar un canal de Lightning Network como salida (output) de un CoinJoin. Igualmente ayuda a ocultar estos datos, ya que los outputs de la transacción no se conocen inmediatamente esta se realiza. También se pueden utilizar firmas post hoc para cambiar los outputs que se estén creando (algo menos complejo de realizar que en LN).

Jeremy Rubin, desarrollador BIP 119.

Rubin añade que desde OP_CTV se pueden realizar CoinJoin de forma más equilibrada, ya que se pueden crear varios inputs en una misma transacción, permitiendo mezclar las monedas de varios usuarios en un solo ciclo de CoinJoin, haciendo incluso más costeables las comisiones, ya que este lote de transacciones sería más ligero que lo que serían todas las transacciones realizadas por separado.

¿Qué opina Reddit?

Siendo Reddit uno de los sitios de foros líderes en su tipo, muy utilizado por las comunidades de Bitcoin y criptomonedas, Rubin organizó un AMA —Ask Me Anything, conocido en español como Pregúntame lo que sea—, donde recibió los comentarios de la comunidad el pasado jueves 7 de junio.

En el evento virtual discute las dudas y observaciones de algunos usuarios con respecto a la posibilidad de cambiar los inputs de la transacción y hacerlas maleables en determinado periodo de tiempo, a lo que Rubin respondió argumentando que una vez la transacción se compromete no hay manera de cambiar los inputs, ya que el punto de OP_CTV es que las salidas finales tengan la certeza de que el ciclo se cumplirá con el aval de la firma de todas las entradas firmantes.

Entre las tareas a las que se está avocando en este momento para hacer viable la BIP-119, Rubin enumera la reestructuración del mempool de Bitcoin, crear un lenguaje de contratos inteligentes de Bitcoin, desarrollar software abierto en ese lenguaje para mejorar las interfaces y custodia de fondos con CTV.

El desarrollador explica además que entre las observaciones recibidas por otros colegas, se encuentra la que señala que la abundancia de transacciones en lote pueden llegar a ocupar mucho espacio en la red; un momento en el futuro donde nuevamente las comisiones se hagan competitivas y la red vuelva a ralentizarse. Rubin ejecutó simulaciones con diversos escenarios y condiciones, hallando que OP_CTV ayuda a reducir las comisiones y la congestión del mempool.

En general la percepción en torno a la propuesta ha sido positiva, ya que Rubin se ha avocado a complementar la propuesta con muchísimo material de estudio y discusión, que principalmente está reunido en su página web. Aunque esto sea así, aún falta mucho camino para que esta propuesta sea implementada, aunque para Rubin, más vale comenzar a discutirla ahora, que deber evaluarla en un escenario de urgencia como el que contextualizó el debate por la implementación de SegWit en 2017.