El CEO de Synonym, John Carvalho, acusó a varios desarrolladores de Bitcoin Core de intentar obligar a Bitcoin a aceptar transacciones de reemplazo por tarifa (RBF) de forma predeterminada. Su propuesta cambiaría los protocolos básicos de Bitcoin en lugar de permitir que los usuarios decidan si utilizar transacciones RBF o confirmación cero (0conf) a nivel de superficie.
Carvalho dice que los desarrolladores han usado tácticas como:
- Difundir mentiras y tácticas de cabildeo en la lista de correo de Bitcoin-Dev,
- introducir cambios en el código de nodo de Bitcoin Core, y
- sobornar a los mineros para que apoyen a RBF.
Las transacciones RBF podrían reemplazar los protocolos de transacción 0conf utilizados por la mayoría de los comerciantes. Carvalho dice que Synonym apoya los esfuerzos para hacer que las transacciones 0conf sean más resistentes a los ataques de doble gasto y acusó a los desarrolladores que valoran RBF de intentar proteger los diseños de nicho con casos de uso limitado.
Las transacciones 0conf también se denominan «transacciones no confirmadas» o «transacciones propuestas» y, por definición, no están incluidos en ningún bloque en la cadena de bloques de Bitcoin.
¿Qué hace que las transacciones RBF sean diferentes de las transacciones 0conf?
Reemplazar por tarifa puede acelerar la confirmación de una transacción al reemplazar una transacción no confirmada con una transacción de tarifa baja que incluye una tarifa más alta. Este tipo de transacción solo funciona cuando un minero aún no ha seleccionado la transacción de bajo costo para incluirla en un bloque. La tarifa más alta hace que sea más probable que un minero seleccione la transacción.
Las transacciones RBF vienen con un defecto. Los remitentes pueden reemplazar una transacción no confirmada con una que tenga una tarifa más alta y también reemplazar la dirección a la que se dirige la transacción. Este defecto hace posible que los remitentes de un pago criptográfico defrauden a los comerciantes enviando los fondos a otra dirección controlado por el remitente después de que el comerciante entrega su compra.
Las transacciones de confirmación cero permiten gastar activos digitales sin esperar 10 minutos para que una transacción comience a confirmarse. Un remitente puede transmitir una transacción y contar con que el comerciante acepte los fondos si parece válido de un vistazo. Los comerciantes favorecen las transacciones 0conf porque pueden hacer negocios tan rápido como si el comprador pasara una tarjeta de débito.
El creador de Bitcoin, Satoshi Nakamoto, pareció anticipar las transacciones 0conf en 2010 cuando postuló una «Máquina de refrigerios de Bitcoin», una máquina expendedora que podría aceptar transacciones en 10 segundos o menos con una «comprobación suficientemente buena».
Desde entonces, las transacciones 0conf han visto adopción con procesadores de pago como BitPaylo que ayudó a difundir su uso entre los comerciantes.
Los miembros de la comunidad de Bitcoin argumentaron que los remitentes aún podrían reemplazar las transacciones 0conf antes de que un minero las agregue a un bloque. Los intentos de resolver problemas con las transacciones 0conf incluyeron una propuesta para agregar un protocolo de pérdida de confirmación cero que los comerciantes podrían usar para desalentar el robo. Las transacciones de pérdida de confirmación cero habrían requerido la colocación de fondos que se perderían si el remitente intenta gastar dos veces los fondos en la transacción original.
Carvalho argumentó que la decisión sobre el uso de transacciones RBF o 0conf debe dejarse en un nivel superficial. Final los usuarios idealmente tomarían la decisión final en lugar de que los desarrolladores de Core se lo impongan. Los desarrolladores de billeteras como Synonym podrían agregar opciones para transacciones RBF y/o 0conf.
Leer más: Esta actualización de Bitcoin Core protegerá a los operadores de nodos completos de los ataques
En una publicación publicada en GitHub el día de hoy, Carvalho dijo: “Si entiendo correctamente, el metatema aquí parece ser la plantilla de preferencia/curación/censura de mempool txns, qué plantillas proporcionar y cuáles tener como predeterminadas.
“El reemplazo es solo una opción que un nodo podría preferir… Depende de cada nodo decidir.
“No deberíamos inyectar sesgos para ninguna preferencia en particular como opción predeterminada, pero probablemente debamos comenzar con algún tipo de política, por lo que esto debería establecerse en el consenso actual del statu quo, no en una nueva agenda para que RBF se convierta en una opción predeterminada de primera clase. escribe.
“Todo esto sin mencionar las muchas cosas que podría decir que son geniales acerca de que los comerciantes pueden optar por 0conf, y que los riesgos actualmente son muy manejables y la exposición se puede limitar fácilmente para brindar un gran valor a los comerciantes y consumidores. .
“Podemos tener RBF y 0conf coexistiendo, bueno, ¡ya lo hacemos! Así que seamos reflexivos y abordemos el diseño general de manera inteligente y sin agredir pasivamente ni decidir por los usuarios en conflicto con el consenso actual. ¡Gracias!»
Mientras tanto, mientras todo esto sucede, algunos en la comunidad de Bitcoin se preguntan si todo es parte de algún plan para distraer la atención del reciente error de LND en Lightning Network.
Protos se comunicó con Carvalho para hacer comentarios, pero al momento de la publicación no recibió respuesta.
Para noticias más informadas, síguenos en Gorjeo y noticias de Google o escucha nuestro podcast de investigación Innovado: Blockchain City.
