One proposal raises allowing Bitcoin nodes to power reject the receipt of transactions that have not requested or required, starting with the next versions of the Bitcoin Core client.
The solution aims to seek greater efficiency in the management of Bitcoin transactions and their transmission between pairs. The proposal, made by developer Antoine Riard on the Bitcoin mailing list, was in turn reviewed by the Bitcoin Optech newsletter.
The newsletter published on February 17th explains that, in principle, before transmitting a transaction to other nodes, a node can first send an inv or inventory message. This light message is enough for the other nodes to decide whether or not to consider saving and forwarding the transaction. The affirmative response from a node to receive a transaction is the getdata command.
When the node recognizes the transaction, it saves it in its memory. The network mempool is the sum of the memory that each node that the network uses to store incoming and unconfirmed transactions, We explain in the CriptoNoticias glossary.
The mempool.space portal allows you to view data about the Bitcoin mempool. Source: Mempool Space.
However, Riard’s proposal notes, the inv / getdata method has been overlooked “by some thin clients and other software” for more than a decade. Thus they give an example of bitcoinj, the client of Bitcoin Core in Java language, where it is visualized at the code level how transactions are sent to the nodes, without having been requested by them.
Without the nodes being able 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, thus saturating the node’s memory.
Efficient communication between nodes protects Bitcoin
The developer’s solution is to enforce the inv / getdata message exchange protocol, so that transaction processing and validation resources can be saved and better distributed. The nodes could also shut down connections against peers identified as malicious or who are boycotting the network.
The only possible way to evade this solution, and manage to transmit an inv message or raw transaction (raw tx, light transaction in information) when it becomes effective, It is to rely on another pair that uses a compatible Bitcoin client and interacts with the network.
Relay (relay) or leverage another user to transmit transactions, would still allow this type of messages to reach the nodes, but once the condition of complying with the inv / getdata sequence is implemented in all clients, these software would have to keep updating until it becomes impossible for them to transmit raw transactions on the Bitcoin P2P network.
In the GitHub discussion between developers, one of the participants confirms that just by transmitting costly transactions to process to a listening node or listening node, it would generate slowness in the transmission and validation of transactions.
Although the size of this attack would have to be enormous to have serious effects on the network, it can affect a target node. That it is theoretically possible to do so requires a practical solution from Bitcoin developers and collaborators.
It is planned 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 type of transaction.