Este es un editorial de opinión de Shinobi, un educador autodidacta en el espacio de Bitcoin y presentador de podcasts de Bitcoin orientado a la tecnología.
Gran sorpresa, los usuarios de Bitcoin están discutiendo furiosamente sobre un conjunto de cambios propuesto que se incluirá en la próxima versión de Bitcoin Core. Opt-in replace-by-fee (RBF) es una característica de la política de mempool que se propuso en 2015 para brindar a los usuarios una herramienta para lidiar con picos rápidos en las tarifas que hacen que sus transacciones queden bloqueadas sin confirmar en el mempool durante largos períodos de tiempo.
Obviamente, esto será un problema para cualquier uso de Bitcoin si el volumen de transacciones crece en promedio para ser consistentemente más alto que la cantidad de transacciones que se pueden procesar en la cadena de bloques, por lo que, a menos que piense que eso nunca sucederá, esta es una funcionalidad necesaria en el la red.
El reemplazo de transacciones estaba realmente incluido y era posible en la versión original del software antes de que Satoshi Nakamoto desapareciera. Eventualmente deshabilitó la función porque la forma en que la implementó originalmente creó un vector para ataques de denegación de servicio contra nodos. Su implementación permitió el reemplazo de cualquier transacción sin pagar una tarifa más alta, lo que esencialmente habría permitido a los usuarios enviar una transacción y luego comenzar a transmitir una cantidad ilimitada de reemplazos a la red. Obviamente, esto permitiría enviar spam a los nodos con cantidades masivas de datos que no requieren prueba de trabajo y aumentaría prohibitivamente el costo de ejecutar un nodo.
A lo largo de los años, se han discutido algunas propuestas diferentes para un esquema de reemplazo de transacciones renovado y más seguro. Repasaremos rápidamente todo esto.
FBR completo
La variante más simple de RBF. Cualquier transacción puede ser reemplazada siempre que el reemplazo de la transacción original pague una tarifa más alta que la que está reemplazando. De esa manera, todas las transacciones son reemplazables, pero el requisito de pagar una tarifa más alta cada vez que reemplaza una evita un spam infinito de nuevas versiones de los nodos de sobrecarga de transacciones.
RBF seguro por primera vez
Esto proponía permitir que todas las transacciones fueran reemplazadas en el mempool, con una advertencia especial; todas las salidas en la transacción original también deben incluirse en la transacción de reemplazo, incluida la salida de cambio. Todavía requiere aumentar la tarifa para reemplazar una transacción, pero el requisito de mantener las mismas salidas significa que debe agregar una nueva entrada y una segunda salida de cambio, porque ninguna de las salidas originales se puede modificar. Esto da como resultado transacciones más grandes que tienen que pagar más en tarifas totales para garantizar que el reemplazo pague una tasa de tarifa más alta.
FBR retrasado
Aquí había una propuesta para permitir que cualquier transacción sea reemplazada en el mempool, pero solo después de que haya pasado una cierta cantidad de bloques desde que el nodo vio la transacción original. La idea era que esto permitiría que las transacciones atascadas en entornos de tarifas altas se reemplazaran y confirmaran más rápido, pero el tiempo de demora en la rapidez con la que se podría reemplazar evitaría intentos de doble gasto sin confirmación.
Optar por RBF
Esto es lo que se implementó en 2016 como se define en BIP 125. Las transacciones solo se pueden reemplazar si establecen un indicador específico en la transacción que opta por el reemplazo, o si uno de sus antepasados lo hizo en el caso de una cadena de transacciones no confirmadas, para permitir personas que reciben fondos para saber si una transacción no confirmada será reemplazable o no en el mempool.
La gran controversia hoy en día es que la próxima versión de Core, 0.24, introducirá una bandera de política de mempool RBF completa. ¿Qué significa esto? Brindará a los usuarios una opción configurable para cambiar su política de mempool local de RBF opcional a RBF completo; por defecto, la opción se dejará desactivada (los nodos usarán RBF completo). Entonces, ¿por qué la gente está en armas por este cambio? Las empresas que aceptan transacciones de confirmación cero dependen de que la gran mayoría de los mempools de los nodos se nieguen a reemplazar las transacciones que no han optado por RBF con un indicador de transacción. Lo hacen conectando tácticamente su nodo a una gran cantidad de otros nodos repartidos por toda la red. Esto les permite detectar muy rápidamente la presencia de una transacción de doble gasto en la red, ya que debe hacerse casi de inmediato si una transacción no está marcada como RBF para tener una buena oportunidad de llegar a los mineros. También vale la pena señalar que todas las empresas en la red no pueden hacer esto sin sibilar efectivamente a la red. Estas empresas afirman que el RBF completo «rompe» su modelo comercial de usar RBF. Algunos incluso tienen criticado Los desarrolladores principales como «forzando» un cambio que afecta negativamente a estos negocios.
La simple realidad es que el doble gasto ha sido y siempre será posible, optar por RBF o RBF completo no hace nada para cambiar esto. Además, el simple hecho de crear una opción para cambiar su propia política de mempool local (que está desactivada de forma predeterminada) de ninguna manera dicta el cambio a nadie, es una opción que se les da a los usuarios para que elijan por sí mismos. Al final del día, cuando se trata de qué transacciones se incluirán realmente en el siguiente bloque, los únicos mempools que importan son los de los mineros. Los mempools de los nodos de usuarios individuales no son más que una cadena de almacenamiento de memoria con el objetivo final de propagar todas esas transacciones no confirmadas a los mineros para que eventualmente puedan incluirse en un bloque.
La política de Mempool se utiliza como una especie de mecanismo de seguridad suave para evitar ataques de denegación de servicio en los nodos y proteger a los usuarios de dispararse en el pie con transacciones y scripts complicados. Muchos tipos de transacciones son válidas por consenso, pueden incluirse en un bloque, pero no serán retransmitidas por la política de mempool predeterminada de los nodos. Sin embargo, esto no hace nada para evitar que un usuario determinado transmita una transacción que los nodos en la red ignorarían directamente a un minero.
Ese es el quid de la cuestión. Todo lo que se necesita es que los mineros configuren una API para enviarles transacciones directamente, lo que muchos ya tienen, y las restricciones de las políticas de mempool en toda la red no importan. Simplemente puede dar una transacción directamente a los mineros y omitir todas las reglas sobre cuándo se puede reemplazar algo en el mempool de otros nodos. Piense en los incentivos de eso: si se puede ganar dinero extrayendo cierta clase de transacciones, pero los mempools a través de la red no los transmiten, ¿qué haría usted como minero? Solo acéptalos directamente. Cuanto más se reduzca el subsidio y crezcan las tarifas de transacción como porcentaje de los ingresos de los mineros, más inevitable será que los mineros acepten directamente reemplazos que paguen tarifas más altas si los nodos de la red no los transmiten indirectamente. Es ineludible.
Este cambio no altera la política de mempool predeterminada para Bitcoin Core, simplemente presenta una opción para que un operador de nodo individual modifique su política de mempool local si así lo desea.
Y podría agregar, esta es una opción que siempre ha estado disponible si los usuarios eligieron modificar su cliente. Todo lo que hace es hacer que una elección que siempre ha estado disponible para los usuarios sea más sencilla de hacer. Los incentivos conducen inevitablemente al estado en el que todas las transacciones serán reemplazables si los mineros actúan de manera económicamente racional: es inevitable. La única cuestión es si el software debe reflejar esos incentivos, de manera que los usuarios individuales decidan por sí mismos qué política usar para su mempool, o si la gente simplemente se sienta y deja que la propagación de las transacciones se centralice en el envío directo a los mineros. ¿ellos mismos?
El resultado final es el mismo, pero esperar a que los mineros graviten hacia el envío directo de transacciones tendrá consecuencias muy negativas. Tendría implicaciones de privacidad para las personas que transmiten transacciones a la red y podría tener consecuencias muy negativas para la capacidad de los usuarios de decidir qué tarifa pagar por una transacción. Si una gran parte de las transacciones pendientes ya no se transmiten públicamente a través de la red, los usuarios tendrán una visión incompleta de contra quién están pujando para su inclusión en un bloque. Los mineros podrían incluso mentir sobre la distribución de tarifas para incentivar a los usuarios a pagar más de lo que deben.
El único inconveniente real de hacer que esta opción esté disponible es que el RBF completo podría no funcionar de manera consistente si solo una pequeña parte de la red, incluidos los mineros, eligen habilitar el RBF completo. Sin embargo, esto fundamentalmente no es diferente en términos de transición de lo que fue la actualización a SegWit. Durante ese período de transición, los nodos no actualizados no retransmitirían las transacciones de SegWit porque no podían validarlas, por lo que durante ese período hubo la misma dinámica de propagación inconsistente hasta que se actualizaron suficientes usuarios. Pero, en última instancia, eso no cambió el hecho de que la actualización era una decisión que debían tomar los usuarios individuales.
En última instancia, luchar contra el RBF completo es simplemente negar la realidad de los incentivos en la red. No se dicta nada a nadie, una opción de configuración simplemente presenta a los usuarios individuales una opción para que hagan por sí mismos. Me parece extraño que, al mismo tiempo, tantas personas ignoren la realidad de los incentivos para argumentar que un medio inseguro de recibir pagos puede mantenerse seguro desafiando los incentivos, al igual que las personas argumentan que a los usuarios de software no se les debe permitir elegir cómo hacerlo. para configurar su propio software.
Mi nodo, mis reglas, ¿verdad?
Esta es una publicación invitada de Shinobi. Las opiniones expresadas son totalmente propias y no reflejan necesariamente las de BTC Inc o Bitcoin Magazine.
