To mitigate mempool divergence between nodes and miners, node operators should have the ability to submit non-standard transactions to their local mempools. One of the reasons to do so is to improve the quality of fee estimates.
Acceptance via the p2p network has been discussed in #27578 and is deemed to be problematic. This issue is for enabling non-standard transaction submission for the sendrawtransaction rpc only.
Your question is already answered in the thread you link to. You are even answering this yourself in your reply from #27578 (comment):
if a restriction can be lifted safely and benefit a specific group of users, why not?
So if something that benefits someone can be safely lifted, it should be done. Though, doing it as a non-standard transaction submitted manually and locally only doesn’t make sense, as explained in the thread you link to.
I assume you refer to the following explanation why enabling it locally only doesn’t make sense:
Its direct peers will simply discard these when your node broadcasts them, and they will eventually be purged from your mempool as any other non-confirmed transaction.
The scenario that I have in mind though is alternative transport mechanisms for bitcoin transactions that exist outside the p2p network and that are publicly accessible. Miners are incentivised to pull out of that source, and therefore regular nodes should do that too to keep their mempool as much in sync as possible?
How can I then keep my mempool in sync with said public alternative sources of non-standard transactions that will also appear in blocks and impact the fees that I should pay?
Enabling it for all transport mechanisms appears to be difficult, and local submission only would do the job.
The scenario that I have in mind though is alternative transport mechanisms for bitcoin transactions that exist outside the p2p network and that are publicly accessible. Miners are incentivised to pull out of that source, and therefore regular nodes should do that too to keep their mempool as much in sync as possible?
Miner’s incentives are more complex than simply put into blockchain anything that pays a satoshi. One may end up in a situation where mempool is filled up with a type of non-standard transactions that miners rarely pick up.
@sdaftuar wrote in #27772 (comment):
Are you unaware that some of the DoS attacks that are prevented by our standardness checks include situations where a block might be mined that would take a very long time to validate, a cost that would be felt by the whole network? See for instance [https://bitcointalk.org/?topic=140078%7CCVE-2013-2292]]](https://bitcointalk.org/?topic=140078%7CCVE-2013-2292%5D%5D). It is absurd that this issue would be ignored in a PR seeking to change mainnet behavior.
I wasn’t aware of this class of DoS attacks. And indeed, I can’t think of a reason to disable this check. I am not sure if there are no better ways to address this than through policy, but that seems to be another topic.
Even putting aside the network-wide risks, I think it would be inappropriate for this project to bless a configuration that could lead to our users allowing themselves to be DoS’ed, which seems like the obvious outcome (I have no idea how we would provide documentation to our users to do these risk assessments themselves).
I see what your saying, but I also want to add that the risk of users DoS’ing themselves depends on the source of the transactions they submit through RPC. The user might be sourcing transactions from a trusted and secure source that has robust (but different) DoS protection measures in place already.
Generally speaking though, it strikes me as odd that there is no way for me to submit a transaction via rpc to my own local mempool that will later be mined by someone and happily show up in the chain. Thinking for example of >400kw txes. Perhaps there is a subset of standardness that is insufficient on the p2p interface, but safe for rpc?
In the most recent PR that tried to do something similar to this (which you also commented on), I asked for the particular rules that seem to be problematic (for whatever use case is motivating these PRs) to be spelled out, so that we can discuss – and perhaps there are indeed modifications to our rules that would be fine and beneficial to the network if we adopted. If you’d care to do that here, perhaps progress could be made. Treating our standardness rules as a black box to be worked around, without any consideration for why any of these rules exist, is not helpful and not going to lead anywhere. Concept NACK.
The reason that I am interested in non-standard transactions is the taproot annex. There seem to be many ways to benefit from this field, and it might also reduce chain space requirements for certain applications.
The reason that I am interested in non-standard transactions is the taproot annex. There seem to be many ways to benefit from this field, and it might also reduce chain space requirements for certain applications.
The way to fix that is to standardise uses of the annex, not to change the node to accept anything into the mempool / relay anything. See also https://github.com/bitcoin/bips/pull/1381 and https://github.com/bitcoin-inquisition/bitcoin/pull/22 (EDIT: replace “isn’t” with “is”, geez)