Unlike other similar vulnerabilities that have been ignored by the Bitcoin Core team, this specific vulnerability could be mitigated by enabling full Replace-By-Fee (RBF) by default, a solution that was proposed but subsequently disregarded due to what appears to be political reasons within the Core development team. This refusal to address the problem is indicative of a broader disregard for free relay attack concerns, further exemplified by the rejection of a pull request aimed at integrating full RBF, despite its potential to correct multiple issues including transaction pinning and facilitating TRUC/V3 transactions.

TRUC/V3 transactions, as outlined in BIP-431, are criticized for their flawed rationale. The proposal's authors seem to acknowledge the inevitability of free relay attacks yet proceed with recommendations that do not mitigate such risks, suggesting a misallocation of engineering resources towards an ineffective solution. This stance is contradicted by the existence of numerous disclosed attacks that demonstrate the practicality of free relay, thereby challenging the assumptions underlying TRUC/V3 transactions and the broader reluctance to enable full-RBF, which ironically, would align with the objectives of TRUC/V3 by enforcing a full-RBF policy for these transactions.

The mechanics of the described vulnerability rely on exploiting discrepancies between miners' policies and those of Bitcoin Core nodes, specifically through broadcasting low fee-rate transactions that are unlikely to be mined but will nevertheless consume bandwidth as Core nodes attempt to propagate them. This stratagem involves several steps: initiating a low fee-rate transaction without opt-in RBF, followed by a double-spend with higher fees, and then engaging in behaviour that forces Core nodes to waste resources on relaying transactions that miners will ignore due to the transactions spending outputs not present in their mempools. The economic impact of this attack is minimal for the attacker, especially when transactions are broadcasted at fee-rates below the threshold likely to be included in a block, thus highlighting a significant inefficiency within the current protocol that could be exploited for various purposes, including facilitating low-cost transaction consolidation for attackers.

This disclosure underscores a concerning apathy towards security vulnerabilities within the Bitcoin Core development community, particularly those that challenge the prevailing political and technical narratives. The detailed documentation of the attack, along with references to discussions and previous disclosures (Mar 18th disclosure, Mar 31st disclosure), serves as a compelling argument for revisiting the decision-making processes and technical priorities of the Bitcoin Core project, especially in light of the potential for relatively simple fixes to mitigate significant vulnerabilities.