Following regular communication channels is a measure to avoid saturating the Bitcoin mempool. The nodes will now be able to improve their selectivity when it comes to transmitting transactions.
One proposal to allow Bitcoin nodes to reject the receipt of transactions that they have not requested or required, starting with the next versions of the Bitcoin Core client.
The solution aims to generate more efficiency in the management of Bitcoin transactions and their transmission between pairs. The developer Antoine Riard made this proposal on the Bitcoin mailing list.
The newsletter, published on February 17, explains that a node can first send an inv or inventory message before transmitting a transaction to other nodes. This light message is enough for the other nodes to consider saving and forwarding the transaction. The affirmative response from a node to receive marketing is the get data command.
When the node recognizes the transaction, it saves it in its memory. The network mempool is the sum of each node that the network uses to store incoming and unconfirmed transactions.
Riard’s proposal notes, the inv / getdata method has been bypassed “by some thin clients and other software” for more than a decade. These clients use the client of Bitcoin Core in Java language as an example. Bitcoin Core shows a visualization at the code level of how transactions went to the nodes without having been requested by them.
Without the nodes to avoid learning about an unsolicited transaction, an attacker could send many heavy or expensive to commit transactions from various connection points to a target node. This action ends up saturating the node’s memory.
More Effectiveness and Efficiency regarding Communication between Nodes
The developer’s solution is to enforce the inv / get data message exchange protocol, so that transaction processing and validation resources can find safety and better distribution. The nodes could also shut down connections against malicious peers or who are affecting the network.
The only possible way to evade this solution, and manage to transmit an inv message or raw transaction (raw tx, light marketing in information) when it becomes effective, is to rely on another pair that uses a compatible Bitcoin client.
Relay (relay) to transmit transactions would still allow this type of messages to reach the nodes, but once the condition of complying with the inv / get data sequence in all clients, this software would keep updating until the transmission of raw transactions becomes impossible on the Bitcoin P2P network.
In the GitHub discussion between developers, one of the participants confirms that only transmitting transactions that are expensive to process to a listening node or listening node would generate slowness in the transmission and validation of transactions.
Although this attack would have to be enormous to cause severe effects on the network, it can only affect a target node. That it is theoretically possible to do so requires a practical solution from Bitcoin developers and collaborators.
There are plans to implement this update in version 22.0 of the Bitcoin Core client. After there, all Bitcoin clients will have to upgrade, or they will not be able to send any transaction.
By: Jenson Nuñez
