gistfile1.txt

For a transaction to be included in a block, it must be spread across the network in order to reach the maximum number of miners.

Example: you send your transaction to your node, and it will relay it to 4 or 5 peers, which will relay it to 4 or 5 peers, and so on. In a few seconds all nodes in the network will know about your transaction. 

Bitcoin have 2 sets of rules:

- Consensus rules: define what is a valid transaction to be included in a block
- Relay rules: define what is a valid transaction to be relayed across the network.

Glossary:

- Standard transaction: valid by both set of rules
- Non-standard transaction: valid only in consensus, not relayed

Relay rules are stricter than consensus rules and were implemented to protect the network against attacks.

Example: there’s no consensus rule saying transactions must pay fees, but there’s a relay rule saying transactions must pay at least 1 sat/vbyte to be relayed. This to prevent someone from flooding the network with transaction paying no fees (so no cost to attack).

Other forms of attack are memory and cpu exhaustion, so transaction that are too complex to process (i.e. take too much cpu/memory to be validated) are also considered non-standard and not relayed.

Relay rules are free, every node runner is free to choose what he wants to relay through his node.

Starting with Satoshi, relay rules were also used to protect block usage.

Example: the op_return size limit in relay rules was first introduced to 40 bytes in 2014, then upgraded to 83 bytes in 2015 to prevent blockchain bloat while enabling basic metadata. Core v30 removed this limit. There’s no limit in consensus rules.

Why did Core remove the op_return limit? Are they spammers? Are they being paid by some obscure organisation that wants to destroy Bitcoin? No.

What Core is pushing for is to make relay rules identical to consensus rules because, when they are not, three main problems arise:

P1: Mining centralisation
P2: Inaccurate fee estimation by nodes
P3: Increased network strain during block validation

Let’s imagine two scenarios, where nodes run a stricter set of relay rules to fight spam, called “filters”:

C1: All nodes run filters (Filters ON)
C2: No nodes run filters (Filters OFF)

Let’s analyse each problem across these scenarios.

P1: Mining Centralisation
—------------------------------

In Scenario 1 (Filters ON), mining pools have an economic incentive to create APIs where anyone can submit non-standard transactions, as these still pay fees.

Spammers will choose the 4 or 5 largest pools to submit their non-standard transactions. They don't need more than that, as 4 or 5 pools guarantee a 90% success rate or higher. Small miners will be at a disadvantage because they will be mining blocks that pay lower fees. Sooner or later, they will join one of the top 4 or 5 pools to avoid losing potential revenue, causing mining centralisation, which can bring censorship and MEV (Miner Extracted Value) to Bitcoin.

In Scenario 2 (Filters OFF), these economic incentives do not exist.

P2: Inaccurate Fee Estimation by Nodes
—--------------------------------------------------

In Scenario 1 (Filters ON), nodes are out of touch with reality because they only know about a subset of the transactions that will appear in the next block. In other words, nodes are blind to the non-standard transactions that will be included.

Consequently, they will underestimate fees. If you use the fees suggested by your node, your transaction will likely get stuck in the mempool, forcing an RBF (Replace-By-Fee). Besides causing mempool stress, it creates a poor experience for the end user.

In Scenario 2 (Filters OFF), nodes are aligned with reality, so this problem does not occur.

P3: Network Strain in Block Validation
—-----------------------------------------------

In Scenario 1 (Filters ON), when a block containing non-standard transactions appears, nodes must ask their peers for those transactions. In this scenario, the only node that knows about these transactions is the pool's node. This information must then propagate through the entire network, leading to delays in block validation and a significant increase in network traffic.

Validation delays also increase the likelihood of orphan blocks, which brings other issues to the network.

In Scenario 2 (Filters OFF), nodes have all transactions cached and do not need to request anything from anyone.

In summary:

- Spam is indeed a problem, but the attempt to mitigate it can lead to even greater problems;
- Knots is worried about what we put in the machine, Core is worried about having the machine running.

Just my 2 sats.