Hechos clave:
-
La idea es que una transacción "patrocinante" incluya otras con comisiones más bajas.
-
Esta propuesta todavía debe ser auditada antes de su hipotética implementación.
Actualmente, en el protocolo de Bitcoin existen dos formas de destrabar una transacción que quedó en espera de confirmaciones en la blockchain, en momentos de alta congestión de la red. Y podría existir una opción más segura, según propone Jeremy Rubin, colaborador de Bitcoin Core.
La propuesta de Rubin busca sustituir los mecanismos de reemplazo por comisión o replace by fee (RBF), mediante la cual una nueva transacción con mayor comisión sustituye a la transacción original estancada; y los CPFP (los niños pagan por los padres), mecanismo con el cual se emite una nueva transacción que gaste parte de las monedas no gastadas en la transacción original aumentando la comisión para los mineros.
Principalmente, la idea es contar con transacciones “patrocinantes” que sirvan de puente para que transacciones con bajas comisiones sean incluidas en un bloque por los mineros.
La propuesta de Rubin contempla habilitar de forma opcional que las transacciones contengan “una salida final especial”, tal como lo explica el boletín de Bitcoin Optech más reciente, publicado este 23 de septiembre.
La transacción que tenga esa salida, la denominada como patrocinante, solo entraría en un bloque (se confirmaría) en caso de que todas las transacciones asociadas a ella entren también en ese bloque. Y al tener una comisión más alta, esa transacción sería incluida por los mineros rápidamente.
“Esto significa que un minero que quiera una tarifa alta de una transacción de patrocinante será incentivado a confirmar transacciones patrocinadas de tarifa baja”, expone el boletín. El mismo texto agrega que, más allá de su función de patrocinar, se trata de “transacciones normales de Bitcoin”.
A través del repositorio Github de la propuesta, el cofundador de la Iniciativa de Monedas Digitales del MIT expuso que las transacciones de patrocinio podrían ofrecer mayor seguridad que aplicar RBF o CPFP, sobre todo para las soluciones de segunda capa como la red de canales de pago, Lightning.
En cuanto al mecanismo en sí, Rubin confirmó en contacto con CriptoNoticias que “la anterior (transacción) no necesita, según las especificaciones actuales, ningún modificador especial, solo la siguiente transacción –la patrocinante- necesita un conjunto de indicadores especiales”.
Posibles contras de la propuesta
Según el boletín de Bitcoin Optech, RBF y CPFP incluso podrían usarse para atacar protocolos como la red Lightning de Bitcoin. En el caso de Lightning, hay posibles soluciones como los “canales ancla”, reportados recientemente en CriptoNoticias. Sin embargo, dicha opción no sería aplicable para la capa principal de Bitcoin, expone el texto.
Con este nuevo mecanismo para promover la inclusión de transacciones, Rubin busca una herramienta que “permita a terceros arbitrarios no conectados imponer tarifas a una transacción arbitraria”, describe en su presentación de Github.
Adicionalmente, expone que, si bien los mineros podrían permitir múltiples transacciones patrocinantes, esto no es necesario para que funcione el mecanismo. Actualmente, Rubin se mantiene trabajando en la implementación de esta herramienta que, en sus propias palabras, “no se ha auditado cuidadosamente” todavía.
Como describe el propio boletín de Bitcoin Optech, otros desarrolladores han recibido con buenos ojos la propuesta de Rubin. Sin embargo, también ha habido algunas objeciones.
Antoine Riard, desarrolador de Chaincode Labs, apuntó que una contraparte malintencionada podría usar el mecanismo para fijar una entrada en particular con intenciones de ataque. Por ejemplo, mencionó el caso de los Contratos Bloquedos por Hash y por Tiempo (HTLC) en el caso de la red Lightning de Bitcoin.
Por otra parte, Suhas Daftuar, cofundador de Chaincode, consideró que la propuesta de Rubin atenta contra la misma naturaleza original de Bitcoin, ya que “rompe la garantía de seguridad de reoganización de la cadena”.
Como escribió Satoshi Nakamoto, ‘en el caso de una reorganización de la cadena de bloques […], las transacciones deben poder ingresar a la cadena en un bloque posterior’. Este principio se rompe con las transacciones de los patrocinadores que solo son válidas en el mismo bloque que las transacciones que patrocinan.
Suhas Daftuar, cofundador de Chaincode Labs.
Al respecto, Rubin nos aseguró que, si bien considera que esa propiedad debe conservarse, el cambio que ha planteado “puede verse como una mera optimización”.
Una mempool más eficiente para Bitcoin
En agosto pasado, Rubin había presentado también una propuesta para mejorar la eficiencia en la selección de transacciones por parte de los mineros y así hacer de la mempool un sistema más eficiente.
Como reseñamos en su momento, la intención detrás de esa propuesta es “mejorar la forma en que se seleccionan las transacciones”, según su creador. En síntesis, Rubin planteó una serie de modificaciones para mejorar el procesamiento de transacciones en Bitcoin, particularmente en escenarios de congestión de la red.
Estos aportes llegan poco después de que el desarrollador recibiera una subvención para dedicarse enteramente a su trabajo en Bitcoin. Rubin, al igual que otros desarrolladores recientemente, fue becado con 50.000 dólares por el programa Open Source Developer Grant de BitMEX.
Además de Rubin, desarrolladores como Amiti Uttarwar o Gleb Naumenko recibieron fondos este año de parte de BitMEX para dedicarse de manera exclusiva a sus aportes en Bitcoin Core.
