* [bitcoin-dev] Proposal to stop processing of unrequested transactions in Bitcoin Core
@ 2021-02-10 13:13 Antoine Riard
2021-02-11 18:29 ` Jeremy
0 siblings, 1 reply; 4+ messages in thread
From: Antoine Riard @ 2021-02-10 13:13 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1400 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 1554 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Proposal to stop processing of unrequested transactions in Bitcoin Core
2021-02-10 13:13 [bitcoin-dev] Proposal to stop processing of unrequested transactions in Bitcoin Core Antoine Riard
@ 2021-02-11 18:29 ` Jeremy
2021-02-11 21:15 ` Pieter Wuille
0 siblings, 1 reply; 4+ messages in thread
From: Jeremy @ 2021-02-11 18:29 UTC (permalink / raw)
To: Antoine Riard, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2057 bytes --]
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 <https://twitter.com/JeremyRubin>
<https://twitter.com/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
>
[-- Attachment #2: Type: text/html, Size: 2951 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Proposal to stop processing of unrequested transactions in Bitcoin Core
2021-02-11 18:29 ` Jeremy
@ 2021-02-11 21:15 ` Pieter Wuille
2021-02-12 11:49 ` Antoine Riard
0 siblings, 1 reply; 4+ messages in thread
From: Pieter Wuille @ 2021-02-11 21:15 UTC (permalink / raw)
To: Jeremy, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 340 bytes --]
> 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?
What kind of privacy concern are you talking about? I'm not sure I see how this could matter.
Cheers,
--
Pieter
[-- Attachment #2: Type: text/html, Size: 642 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Proposal to stop processing of unrequested transactions in Bitcoin Core
2021-02-11 21:15 ` Pieter Wuille
@ 2021-02-12 11:49 ` Antoine Riard
0 siblings, 0 replies; 4+ messages in thread
From: Antoine Riard @ 2021-02-12 11:49 UTC (permalink / raw)
To: Pieter Wuille; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1859 bytes --]
Hi Jeremy,
If I understand correctly your concern, you're worried that change would
ease discovery of the node's tx-relay topology ? I don't scope transaction
origin inference, if you suppose the
unrequested-tx peer sending is the attacker it must have learnt the
transaction from somewhere else which is more likely to be the tx owner
rather than the probed node.
As far I can think of this change, a peer might send an unrequested
transaction to this node and observe that it's either a) processed, the
node has learnt about the txid from another peer or b) rejected, the node
has never learnt about the txid. The outcome can be queried by sending a
GETDATA for the "is-unrequested" txid.
I think the same result can already be achieved by sending an INV and
observing if a GETDATA is replied back to guess the presence of another
peer with already the knowledge of the txid. Or alternatively, just connect
to this other peer and wait for an announcement.
What else can we think of ?
From my side, compared to the already-existing heuristics, I don't see how
this change is easing attackers' work. That said, I don't deny our
transaction announcements/requests logic is worthy of more study about its
privacy properties, especially when you acknowledge the recent overhaul of
the transaction request and the upcoming Erlay changes.
Cheers,
Antoine
Le jeu. 11 févr. 2021 à 16:15, Pieter Wuille <bitcoin-dev@wuille•net> a
écrit :
>
> 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?
>
>
> What kind of privacy concern are you talking about? I'm not sure I see how
> this could matter.
>
> Cheers,
>
> --
> Pieter
>
>
[-- Attachment #2: Type: text/html, Size: 2482 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-02-12 11:49 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-10 13:13 [bitcoin-dev] Proposal to stop processing of unrequested transactions in Bitcoin Core Antoine Riard
2021-02-11 18:29 ` Jeremy
2021-02-11 21:15 ` Pieter Wuille
2021-02-12 11:49 ` Antoine Riard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox