El desarrollador de Bitcoin Core, Amiti Uttarwar, está trabajando en la revisión de la lógica de retransmisión de la red para introducir más privacidad en el proceso de retransmisión de transacciones.
Una adición relativamente nueva al equipo de Bitcoin Core, Uttarwar fue empleado por primera vez como desarrollador de Bitcoin Core en crypto startup Xapo en octubre de 2019. Su enfoque principal en este momento se refiere a un cambio propuesto a la lógica de retransmisión de Bitcoin, que Pieter Wuille destacó previamente como uno de varios proyectos prometedores de implementación entre pares.
Cuando los usuarios inician una transacción de bitcoin, como Uttarwar explicó en un septiembre. Presentación de 2019 necesitan transmitir la transacción, lo que significa que deben enviar un mensaje INV a sus pares y asegurarse de que la transacción esté en el grupo de memoria de otras personas, o en el mempool.
Sin embargo, la transmisión inicial no siempre ve a través. Por ejemplo, podría haber problemas con la retransmisión o la transacción podría ser desalojada del mempool cuando otras transacciones tienen tasas de tarifas más altas. Si surgen tales problemas, que, según Uttarwar, es bastante frecuente, los usuarios tendrían que enviar otro mensaje INV y retransmitirlo a sus pares.
"La lógica actual de retransmisión es terrible para la privacidad", dijo Uttarwar, explicando su motivación para el cambio propuesto .
Cómo funciona
Con el sistema actual, dijo, solo la billetera fuente retransmitirá las transacciones. Como resultado, si un nodo espía ve dos mensajes INV para la misma transacción proveniente de un nodo, puede inferir que el nodo es la billetera fuente, "haciendo que la privacidad sea un regalo muerto".
"Esto deja espacio para una vulnerabilidad llamado un ataque de polvo ", argumentó. Un ataque de polvo ocurre cuando un atacante envía una pequeña cantidad de BTC a varias direcciones diferentes y observa los comportamientos de retransmisión de varias billeteras, lo que socava la función de privacidad de la red.
El mecanismo propuesto por Uttarwar tiene como objetivo resolver esta vulnerabilidad. Si se implementa su diseño alternativo, en lugar de que solo la billetera fuente envíe la señal de retransmisión, todos los nodos retransmitirán las transiciones que creen que "deberían haberse confirmado".
"Extraigo la lógica de la billetera en el nodo y yo use el ensamblador de bloques para que podamos identificar la parte superior del mempool de una manera comparable a cómo lo verá mi nodo ”, dijo, analizando algunas de las funcionalidades que incluye su propuesta. “Actualizo la lógica de la billetera para volver a enviar transacciones no confirmadas al nodo en lugar de enviarla directamente a sus pares. Agrego un filtro de antigüedad en la lógica de creación de bloques para que podamos ignorar las nuevas transacciones recientes ”.
Ruta de desarrollo
La solicitud de extracción (PR) se abrió por primera vez en agosto de 2019, y Uttarwar le dijo a The Block que ella ha hecho cambios considerables a la propuesta desde entonces.
"Una de las grandes piezas de cambio es que he podido romper una funcionalidad del gran PR en un cambio independiente", dijo. “Así que actualmente estoy trabajando para tratar de ver ese cambio. Y una vez que se fusionen, volveré a este proyecto de retransmisión más grande ”.
Otro cambio significativo se refiere a un mecanismo para realizar un seguimiento de la cantidad máxima de veces que se puede retransmitir una transición. Si bien Uttarware previamente planeó incluirlo como un seguimiento de su propuesta de retransmisión, recientemente decidió construirlo después de que un crítico destacó cómo la ausencia de este cambio podría ser un vector de ataque.
Uttarwar también señaló el uso excesivo de ancho de banda como una de sus preocupaciones subyacentes detrás de sus elecciones de diseño.
"Creo que el ancho de banda es algo que deberíamos considerar cuidadosamente y, si se hace mal, podría ser problemático", dijo. Para evitar picos extremos de ancho de banda en toda la red, Uttarwar ha incorporado algunos mecanismos preventivos, incluida la distribución poisson de los tiempos de retransmisión por nodo y la lógica de filtrado para los candidatos de retransmisión.
Si bien el RP ha estado en vigencia durante siete meses, dijo que no tiene prisa por impulsar la propuesta.
"Estoy menos preocupada por la línea de tiempo y estoy más preocupada por la robustez en cada paso del camino", dijo. "No quisiera que nada se fusionara prematuramente".
[DISPLAY_ULTIMATE_PLUS]
Referencia: https://www.theblockcrypto.com/post/58620/bitcoin-core-developer-reworks-the-networks-rebroadcast-logic-to-improve-privacy?utm_source=rss&utm_medium=rss