<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">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?</div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">--<br><a href="https://twitter.com/JeremyRubin" target="_blank">@JeremyRubin</a><a href="https://twitter.com/JeremyRubin" target="_blank"></a></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 10, 2021 at 6:29 AM Antoine Riard via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,<br><br>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].<br><br>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.<br><br>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.<br><br>Eager to gather feedback on this proposal, especially if such change is deemed as too much constraining or fast on any Bitcoin software.<br><br>Cheers,<br>Antoine<br><br>[0] See <a href="https://github.com/bitcoin/bitcoin/pull/20277" target="_blank">https://github.com/bitcoin/bitcoin/pull/20277</a><br></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>