-
Seguir los canales regulares de comunicación evita saturar la mempool de Bitcoin.
-
Los nodos podrán tener mayor selectividad al transmitir transacciones en la red.
Una propuesta plantea permitir a los nodos de Bitcoin poder rechazar la recepción de transacciones que no hayan solicitado o requerido, a partir de las próximas versiones del cliente Bitcoin Core.
La solución apunta a buscar mayor eficiencia en la gestión de transacciones de Bitcoin y su transmisión entre pares. La propuesta, hecha por el desarrollador Antoine Riard en la lista de correos de Bitcoin, fue reseñada a su vez por el boletín Bitcoin Optech.
El boletín publicado el pasado 17 de febrero explica que, en principio, antes de transmitir una transacción a otros nodos, un nodo puede enviar primero un mensaje inv o de inventario. Este mensaje liviano basta a los otros nodos para decidir si considerar o no guardar y retransmitir la transacción. La respuesta afirmativa de un nodo para recibir una transacción es el comando getdata.
Cuando el nodo reconoce la transacción, la guarda en su memoria. La mempool de la red es la suma de la memoria que cada nodo que la red usa para guardar las transacciones entrantes y no confirmadas, explicamos en el glosario de CriptoNoticias.
Sin embargo, señala la propuesta de Riard, el método inv/getdata ha sido obviado «por algunos clientes ligeros y otros softwares» por más de una década. Así ponen de ejemplo a bitcoinj, el cliente de Bitcoin Core en lenguaje Java, donde se visualiza a nivel de código cómo se envían las transacciones a los nodos, sin haber sido solicitadas por estos.
Sin que los nodos puedan evitar conocer una transacción no solicitada, un atacante podría enviar muchas transacciones pesadas o costosas de confirmar desde varios puntos de conexión hacia un nodo objetivo, saturando así la memoria del nodo.
La comunicación eficiente entre nodos protege a Bitcoin
La solución del desarrollador es la de obligar a cumplir el protocolo de intercambio de mensajes inv/getdata, de modo que se puedan ahorrar y distribuir mejor los recursos de procesamiento y validación de transacciones. Los nodos podrían también clausurar las conexiones contra pares identificados como maliciosos o que están boicoteando la red.
La única forma posible para evadir esta solución, y lograr transmitir un mensaje inv o transacción cruda (raw tx, transacción ligera en información) cuando esta se haga efectiva, es la de apoyarse en otro par que utilice un cliente de Bitcoin compatible e interactúe con la red.
Hacer relay (relevo) o apalancarse en otro usuario para transmitir transacciones, permitiría aún que este tipo de mensajes lleguen a los nodos, pero una vez se implemente la condición de cumplir con la secuencia inv/getdata en todos los clientes, estos softwares tendrían que ir actualizándose hasta que ya se les haga imposible transmitir transacciones crudas en la red P2P de Bitcoin.
En la discusión de GitHub entre desarrolladores, uno de los participantes confirma que con solo transmitir transacciones costosas de procesar a un nodo de escucha o nodo oyente (listening node), generaría lentitud en la transmisión y validación de transacciones.
Aunque el tamaño de este ataque tendría que ser enorme para generar graves efectos en la red, sí puede afectar a un nodo objetivo. Que sea teóricamente posible realizarlo amerita una solución práctica de parte de los desarrolladores y colaboradores de Bitcoin.
Se plantea implementar esta actualización en la versión 22.0 del cliente Bitcoin Core. Después de allí, todos los clientes de Bitcoin tendrán que actualizarse o no podrán enviar ningún tipo de transacción.
