4

Is it a bad idea to give the nodes optionality to disallow certain list of transaction types(like P2TR_V1 which contain inscription spam, i.e. the previous output for those) from relaying? By default, it can be set to allow everything.

1

2 Answers 2

3

Very good question. There are important reasons to have the relay options, e.g. to filter or limit certain types of transactions and spam.

Bitcoin Core already offers a few filters configuration options, e.g.: bytespersigop, datacarrier, datacarriersize, permitbaremultisig.

Miners run their own, custom ones.

Bitcoin Knots adds spam filter against certain type of spam, e.g. so-called "ordinals".

1
  • 2
    Can you expand your first paragraph a little? Right now it's basically saying "it's good to have filtering options so that we can filter", i.e. a tautology. And it's the only paragraph that actually addresses the question. Commented Feb 5 at 15:33
5

Optionality is not bad per se, but there are arguments for why it may be harmful, and why having optionality would be bad for node operators and also not have the effects that people think it would.


We first need to understand what the purpose of transaction relay and mempool policy are. Transaction relay over the P2P network is a mechanism to inform miners about a transaction so that it can be included in a block. It does not require the sender to know who miners are, and the sender can be reasonably sure that their transaction will reach anyone who is trying to mine. Mempool policy serves as a way for miners to accept transactions that maximize their fee revenue while also ensuring that there is not too much volume of transactions that could cause their node to have performance issues. Policy rules such as RBF and CPFP allow miners to maximize their fee revenue, while policy limits like ancestor and descendant limits exist in order to reduce the computation required to accept incoming transactions and to build new block templates.

In order for a transaction sender to be reasonably sure that their tranasction will go into a block, they need to know the mempool policies of the miners and the mempool policies of the nodes that will relay the transaction to the miners. Thus it is beneficial to the individual sender if they are able to assume that mempool policy is homogeneous - non-mining nodes and mining nodes share the same mempool policy. Furthermore, if the sender runs their own node that runs a policy that they think miners will run, then the sender only needs to see if their transaction will be accepted by their own node to be reasonably sure that the transaction will reach miners and be included in a block.

It's also important that the best mempool policy (i.e. the one that maximizes miner revenue) is publicly available as free and open source software as that allows for smaller miners and mining pools to exist. If the best policy and block assemblers were all proprietary and private software that only some mining pools have, then the hashrate would go to those pools since they are able to pay more, and we would have increased miner centralization. It is therefore in the entire network's best interest to have mempool policy and block assembler be FOSS.


As it is now, the mempool policy of nodes in the Bitcoin network is fairly homogeneous. The vast majority of nodes run some version of Bitcoin Core, and most other node implementations have also implemented the same or very similar mempool policies as Bitcoin Core. In addition to the selfish reasons that one would want homogeneous mempool policy, there are also other network-wide benefits of every node having the same mempool policy.

First and foremost is compact blocks. The principal idea of compact blocks is that miners will choose to include transactions that were relayed throughout the network and therefore available in most nodes' mempools. This allows the actual blocks to consume less bandwidth when being relayed as instead of having to relay a block containing transaction data that has already been sent, the block can just contain a list of the txids that were included in the block and the receiving node can reconstruct it by pulling those transactions from its mempool. By sending less data for the block, it can be relayed much faster.

Since one of the assumptions of compact block is that one node's mempool should be very similar to another node's, the sending node will assume that a transaction in a block that it had in its mempool does not need to be sent. However, if the receiving node does not have that transaction, it will need to request that transaction, and this obviously slows down the relay of that block.

The biggest effect that this can have is an increase in the rate of stale blocks. This is obviously bad - it reduces the confidence that a low number of confirmations is actually safe, and for the losing miner, hashrate was wasted on the losing block. From past experience, we know that when blocks take longer to propagate, the stale block rate increases. Since compact blocks was first introduced, there was a measurable decrease in the rate of stale blocks.

But this is only a problem for the network if a significant proportion of it is running these filters and miners are not accepting transactions originating from outside of the P2P network. If they are not, then the effect is just that the individual node running the filter will end up using more bandwidth and time in order to receive and validate a new block.

Another benefit is fee estimation. Fee estimation algorithms typically consider the feerates of transactions in the mempool, and how long it takes for transactions to be included in blocks. For example, a somewhat naive algorithm might construct a block template from the transactions in a node's mempool and then give a feerate estimate based on the feerates of the transactions included in that block. This obviously assumes that the node's mempool is very similar to miners' mempools. If the node were excluding many high paying transactions, it could underestimate the feerate actually needed to get into blocks.

In Bitcoin Core's fee estimation algorithm, one of the things it considers is how many blocks were found in the time between a transaction appearing in the node's mempool and that transaction being included in a block. This is used to give an estimate of how long it will take for a transaction at a particular feerate to confirm. If the mempool does not closely match miner mempools, then this algorithm is less effective as it will be unable to account for the transactions in blocks that it did not find in its own mempool.


There is also a philosophical and possibly legal reason to not want to filter transactions. The filtering of transactions can also lead down the road of censorship. If nodes can exclude transactions that match a particular script pattern for inscriptions, why can't they also exclude transactions that match the scripts in the OFAC compliance list? I think it's clear that censorship is against the ethos of Bitcoin, so anything that leads further down the path of allowing or encouraging censorship should be considered with skepticism.

Now it has been argued that nodes today already implement filters and exclude some transactions. While mempool policy does indeed make many transactions non-standard, many of these were put in place a long time ago. They were implemented when Bitcoin was less prominent and when developers had less scrutiny. These days, with lawsuits having been brought against Bitcoin developers and with regulators paying much more attention to Bitcoin, introducing filters could make developers seem to be a central authority and possibly have regulators call for similar filters that implement actually dangerous censorship.


A final and somewhat tangential point is that such filters are not guaranteed to even be effective. Although inscriptions use a particular pattern that is easy to spot, it's also just as easy for inscriptions to move to a different pattern and bypasses the filter. In fact, they could even go to a script construction that would require significantly more compute power to filter as the construction is one that monetary transactions would actually use.

Furthermore, it does not take many nodes that have a relaxed policy to allow filtered transactions to still make it to miners willing to accept them. Estimates place this at around just 10% of the network required for transactions to still be relayed to miners. With an option that is default off, and with the slow uptake of new software versions, having such a filtering option likely would not meaningfully affect the prevalence of such transactions in blocks, while also adversely affecting the nodes that have enabled it by resulting in poorer performance of compact block relay and fee estimation algorithms.

And lastly, we have observed that miners will accept transactions that were not relayed through the P2P network. They have, and presumably will continue to, accept transactions received out-of-band and include them in their blocks. As mentioned above, this hurts compact block relay and fee estimation, especially if the fee was also paid out-of-band. This also worsens miner centralization as pools that are able to advertise and thus accept transactions out-of-band would be able to pay their miners more, so more hashrate is likely to go to those pools. So even if the entire network turned on a filtering option, it's not clear that that would make all of the undesired transactions go away.

2
  • Dust transactions are either an error or spam, there is no other way. How about better/dynamic dust transaction filters then?
    – WhoIsNinja
    Commented Feb 5 at 17:43
  • The effects that I described in my answer apply to any and all filters that could be introduced, including those pertaining to dust.
    – Ava Chow
    Commented Feb 5 at 18:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.