Add bip-halt-unrequested-txn-processing

[ariard]

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

[ariard]

if a draft had matured a bit

Hey @murchandamus, sorry but running the following unix command yields nothing about draft bip "maturity".

curl -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.

[murchandamus]

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.

[ariard]

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:

• "has been submitted to the mailing list": the BIP has been submitted here on the mailing list on Sep 6 2024 (i.e 10 days ago, before you're opening comment)
• "clear and complete description": the BIP describe a behavior change about tx processing using IETF's RFC 2119 (you can precise what is not clear...)
• "proper motivation": the motivation is pointing out how this can constitute a deanonymization vector
• "explains design decisions": emerging from conversations on the historical PRs on bitcoin core, it sounds the most minimal change not disrupting other softwares
• "describes alternate designs": i'm not aware of any sound competing idea, with at least a bip draft + implem (if you know some, i'll add them...and this meet by very few existent bips)
• "addresses backwards compatibility": this is addressed by non-upgraded softwares to NODE_TXRELAYV2_V2
• "specification should be detailed enough to allow competing, interoperable implementations": here, i'll let a non bitcoin core contributor working on another inter-operable implemation comment what is not clear
• "high quality": you're free to do a technical review and point out what is not high quality in this BIP

If you wish to engage in a real technical review of this draft BIP, there are 2 TODOs open:

TODO: segment the protocol version by sub-categories of traffic class (e.g tx, addr, block ?)

and

TODO: add a policy rule to disconnect protocol violation ?

Looking forward if you have technical thoughts, beyond editorial remarks as a BIP maintainer.

[murchandamus]

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.

[ariard]

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.

[ariard]

Shared an email on the mailing list this day to give an update on this BIP.

Mainly recalling the 3 problems that it wish to improve on:

• transaction-relay as DoS vector
• transaction-propagation deanonymization vector
• transaction-relay throughput overflow attacks on contracting protocols

[murchandamus]

This pull request has had unaddressed review comments for over seven months and seems abandoned. Is this still being worked on?

[murchandamus]

This PR has had unaddressed review comments and no code changes for over nine months. The author has not replied in over six weeks to a request for an update. I’m closing this PR as work on it has stopped. Please request to reopen this PR or open a new pull request in case you decide to continuing work on this.