This introducing a BIP for the unrequested transaction processing for the mechanism itself.
This is building on top of bip-txrelayv2 proposal.
Bitcoin Core conceptual discussion: https://github.com/bitcoin/bitcoin/pull/30572 Partially related ML post: https://groups.google.com/g/bitcoindev/c/nWUcXBQbLGU
Hey @ariard, as I pointed out already a few days ago on #1663, it would be preferable if a draft had matured a bit before a pull request is opened to this repository. This document appears to be more of a sketch than a draft.
The document should both elaborate on the perceived issue that is being addressed, as well as on convincing the audience that this approach is viable and effects a significant improvement of the situation. Overall, this proposal needs more substance for further review to be warranted.
12+</pre>
13+
14+==Abstract==
15+
16+This BIP proposes a new mechanism to halt the processing of unrequested transations
17+received by a node from its bitcoin networks peers.
0received by a node from its bitcoin network peers.
11+ License: GPLv2
12+</pre>
13+
14+==Abstract==
15+
16+This BIP proposes a new mechanism to halt the processing of unrequested transations
0This BIP proposes a new mechanism to halt the processing of unrequested transactions
17+received by a node from its bitcoin networks peers.
18+
19+==Motivation==
20+
21+Historically, nodes have been exchanging transactions on the Bitcoin peer-to-peer
22+network by sending an inv, and if the transaction has not been discovered and processed
Suggest wrapping p2p message types throughout this draft either in double quotes (i.e. “inv” in BIPs 33, 35, 130, 133, 330, 331), or in code blocks (i.e. inv in BIPs 37, 140, 157), and appending “message” when it helps clarity.
0network by sending an inv message, and if the transaction has not been discovered and processed
21+Historically, nodes have been exchanging transactions on the Bitcoin peer-to-peer
22+network by sending an inv, and if the transaction has not been discovered and processed
23+yet by the other peer, sending a dedicated tx message.
24+
25+Sending an unnannounced tx message has always been considered in conformity with
26+the protocol, however this behavior creates a denanonymization vector if leveraged
0the protocol; however, this behavior can create a de-anonymization vector if leveraged
A conceptual discussion is taking place in https://github.com/bitcoin/bitcoin/pull/30572.
Agree with @murchandamus that this pull ought to be in draft in its current state.
if a draft had matured a bit
Hey @murchandamus, sorry but running the following unix command yields nothing about draft bip “maturity”.
0curl -L https://raw.githubusercontent.com/bitcoin/bips/master/bip-0002.mediawiki > bip-process && cat bip-process | grep "mature"
The document should both elaborate on the perceived issue that is being addressed, as well as on convincing the audience that this approach is viable and effects a significant improvement of the situation. Overall, this proposal needs more substance for further review to be warranted.
The perceived issued addressed is already marked in the bip by mentionning the deanoynimization vector. On convincing the audience, this is a non-sense, a BIP author cannot take responsibility of convincing an undefined audience, especially in a decentralized ecosystem like bitcoin, where there is no formally defined domain experts.
I’ll let potential reviewers judge by themselves if this proposal needs more substance to be already reviewed or not. If they wish more context there is a already an email on the list and an open PR on bitcoin core, as pointed out by Jon.
You may read “matured a bit” as me trying to convey that this proposal seems to fall short of several requirements stated in BIP 2, including “has been submitted to the mailing list”, “clear and complete description”, “proper motivation”, “explains design decisions”, “describes alternate designs”, “addresses backwards compatibility”, “specification should be detailed enough to allow competing, interoperable implementations”, and “high quality”.
I’m happy to agree to disagree on this, but it seems obvious to me that this PR will not make significant progress until some effort goes towards addressing these shortcomings.
You may read “matured a bit” as me trying to convey that this proposal seems to fall short of several requirements stated in BIP 2, including “has been submitted to the mailing list”, “clear and complete description”, “proper motivation”, “explains design decisions”, “describes alternate designs”, “addresses backwards compatibility”, “specification should be detailed enough to allow competing, interoperable implementations”, and “high quality”. I’m happy to agree to disagree on this, but it seems obvious to me that this PR will not make significant progress until some effort goes towards addressing these shortcomings.
Thanks for the intent clarification.
About the requirements you’re listing as stated in BIP2:
If you wish to engage in a real technical review of this draft BIP, there are 2 TODOs open:
0TODO: segment the protocol version by sub-categories of traffic class (e.g tx, addr, block ?)
and
0TODO: add a policy rule to disconnect protocol violation ?
Looking forward if you have technical thoughts, beyond editorial remarks as a BIP maintainer.
Looking forward if you have technical thoughts, beyond editorial remarks as a BIP maintainer.
I’m not sure I see a benefit in an opt-in mechanism for not-processing unrequested transactions. Perhaps you could elaborate how it would improve the situation.
As I said, I’m happy to agree to disagree on the quality of this proposal, but given that you appear keener on rejecting my feedback than improving the quality of your proposal, providing feedback does not seem to be a good use of my time.
I’m not sure I see a benefit in an opt-in mechanism for not-processing unrequested transactions. Perhaps you could elaborate how it would improve the situation.
Adding an opt-in mechanism allows for gradual deployment of the not-processing unrequested transactions among all the classes of transaction-relay bitcoin softwares and clients. How many inbound slots are reserved for non-upgraded peers is a matter leave to the clients, as not all clients are similarly exposed in face of DoS or deanonymization risks.
For more of the technical rational, I can invite you to have a look on the arguments raised by many contributors on the PR (bitcoin core 30572). So far no other proposal has been brought to discussion, with the same trade-offs. Adding an opt-in mechanism is also compounding on some learnings from the mempoolfullrbf deployment option.