I'm not sure of the existing behavior is of when we issue a getdata request, but noting that there could be a privacy implication of this sort of change. Could you (or someone else) expand on why this is not a concern here? -- @JeremyRubin On Wed, Feb 10, 2021 at 6:29 AM Antoine Riard via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi, > > I'm proposing to stop the processing of unrequested transactions in > Bitcoin Core 22.0+ at TX message reception. An unrequested transaction is > one defined by which a "getdata" message for its specific identifier > (either txid or wtxid) has not been previously issued by the node [0]. > > This change is motivated by reducing the CPU DoS surface of Bitcoin Core > around mempool acceptance. Currently, an attacker can open multiple inbound > connections to a node and send expensive to validate, junk transactions. > Once the canonical INV/GETDATA sequence is enforced on the network, a > further protection would be to deprioritize bandwidth and validation > resources allocation, or even to wither connections with such DoSy peers. A > permissioned peer (PF_RELAY) will still be able to bypass such restrictions. > > Raw TX message processing has always been tolerated by Core and as such > some Bitcoin clients aren't bothering with an INV/GETDATA sequence. Such > change will break their tx-relay capabilities on the p2p network and > require adaptation from them. Given deployment time of any release, I hope > it provides a window time wide enough before the old tx-processing behavior > becomes the minority. > > Eager to gather feedback on this proposal, especially if such change is > deemed as too much constraining or fast on any Bitcoin software. > > Cheers, > Antoine > > [0] See https://github.com/bitcoin/bitcoin/pull/20277 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >