Policy Rules in Bitcoin: Setting Standards for Transactions and Ensuring Network Resilience
In this upcoming blog post, we will delve into the fascinating world of Bitcoin and its rule sets. We’ll explore consensus and policy rules, the mempool, and vulnerabilities in the network. We’ll examine how policy rules address attacks on the network, as well as a type of attack that occurs on Layer 2 of Bitcoin — the Lightning Network. The community has proposed solutions to these attacks, and we’ll explore these proposals together. So fasten your seatbelts, it’s going to be an interesting ride. But before we dive in, let’s first gain a clear understanding of what consensus rules are.
Consensus Rules
Consensus rules are compulsory rules that every bitcoin implementation must follow, the consensus rules govern the bitcoin network transaction and block format, mining, and coinbase transaction creation.
If a bitcoin software implementation does not follow a consensus rule, it might mine an invalid block, create an invalid transaction, or perform some other behaviour that will lead to disconnection by other peers in the bitcoin network, depending on the consensus rules they violate. These rules are termed consensus because every bitcoin node in the decentralized network adheres to those rules.
Policy rules
Apart from the consensus rules bitcoin core (one of the implementations of the bitcoin node software) has another set of rules that were added, these rules do not contradict the consensus rules, but are additional strictness to the bitcoin consensus rules.
Policy rules are optional not all bitcoin implementations have policy rules, libbitcoin a widely used bitcoin node implementation does not have policy rules but works well, it works yeah! but we will see as we continue why policy rules are added, how they help mitigate some attacks and the tradeoffs of adding policy rules.
The Transaction Mempool.
The transaction mempool is the list of unconfirmed transactions that a bitcoin node has.
New unconfirmed transactions are propagated to the bitcoin network from peer to peer and hence the mempool might differ from one node to another which means there is no one universal mempool in the bitcoin network. Miners pick transactions from their mempool and include them in the block they are mining.
The mempool without policy rules will accept any consensus valid transaction that has been received and will keep it there.
This poses some attacks that can be launched on the bitcoin network.
- Denial Of Service Attack
An attacker might publish thousands of transactions to peers causing them to be only collecting his transaction and validating it, which might take some CPU time for the network, and pause the network for a bit which gives the attacker the advantage of being the only one mining at the time.
2. Fill the mempool with garbage
An attacker might decide to fill the mempool with garbage, with a bunch of transactions with low fees that might never be mined into a block.
How do we fix this?
Well by using Policy rules to set standards transactions. Bitcoin core has isStandard policy rules for transactions they will accept from a peer, if a transaction is not standard it will be rejected by the peer.
These isStandard (https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp) rules fix the denial of service attack that can be launched to peers. Some examples of policy rules are found below:
Reject transactions with size > 100,000 vB,
Reject transactions with scriptPubkeys that have too many sigOps,
Setting an unconfirmed transaction descendent limit.
Any non-standard transaction that makes it to a block will be accepted by all nodes because the transaction is consensus valid and must be accepted by all nodes.
It is crucial to transmit transactions that comply with consensus and policy standards. Publishing non-standard transactions will impact the transaction’s propagation in the network, as nodes that enforce policy rules will reject the transaction and not share it with their peers. Consequently, the transaction might not reach miners and will not get mined.
Although policy rules are important and mitigate critical attacks, they still have their own drawbacks, they are not consensus rules and some implementations will not enforce them, which could inadvertently censor transactions that are not malicious, and are valid, but violate policy rules.
There is no global mempool in the Bitcoin network. Each node has its own view of the mempool, which can vary due to factors such as uptime, delays in transaction propagation, and node connectivity. The primary concern in this scenario is the potential for censorship of transactions that do not pose any malicious intent but violate policy rules.
Non-standard transactions will not be propagated in the network. There are two ways in which non-standard transactions can be mined:
- If you are a miner, you can include the transaction in the block that you are mining.
- You can send the transaction directly to a miner for them to mine in a block
Low fee transactions and the mempool.
When it comes to selecting which transactions to include in a block, miners prioritize those with the highest fee-rates. Transactions with low fee-rates may not be selected by miners and will remain stuck in the mempool until the transaction fee per vByte for the block template is lowered or they are evicted by higher fee-rate transactions.
To avoid the frustration of having a transaction stuck in the mempool, there are two similar ways to increase the likelihood of its inclusion in a block. This process is commonly referred to as “fee bumping”.
- Replace by fee (RBF)
BIP125, authored by David A. Harding and Peter Todd, is also known as RBF (Replace-By-Fee). It defines how to opt-in to RBF using two methods:
- Explicit signaling: A transaction is considered to have opted in to allowing replacement of itself if any of its inputs have an nSequence number less than (0xffffffff — 1).
- Inherited signaling: Transactions that don’t explicitly signal replaceability are replaceable under this policy for as long as any one of their ancestors signals replaceability and remains unconfirmed.
If a transaction that has opted-in to RBF becomes stuck with a low fee, you can publish another identical transaction with a higher fee. All nodes that enforce BIP125 will accept the second transaction and discard the first one with the lower fee.
2. Child pays for parent (CPFP)
In this fee bumping technique, you spend one or more outputs of the low fee transaction as inputs to a child transaction, which should have a high fee. This will incentivise miners to pick both transactions and include them in a block by adding the low fee-rate ancestor transaction first as they cannot include the child without first including the parent.
Layer two interactions with mempool policy
There is a current policy rule that limits the size of unconfirmed transaction descendants to be less than or equal to 101,000 vBytes.
RBF has an added requirement that the fee that will be paid by the replacement transaction must be greater than the sum of the fees of the transaction being replaced , and all its children if it has any.
In the lightning network commitment transaction, a channel partner might decide to launch an attack on his partner by publishing a commitment with a low fee, together with descendants that are up to the maximum size 101,000 vbytes, this attack will stuck the commitment transaction cluster in the mempool, and make the channel partner pay a high fee if they want to RBF that published commitment transaction cluster
This attack is known as transaction pinning attack. https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md
Package RBF also known as v3 transaction.
There is a proposal currently by a bitcoin core developer Gloria Zhao, to mitigate the pinning attack and improve the mempool policy fee bumping.
Transactions with nVersion = 3 are nonstandard, hence the policy proposal introduces a new standard of transactions with nversion = 3 and includes some rules that solve some of the underlying problems in fee bumping.
The v3 transactions rules are;
- All existing isStandard rules apply to v3 transactions as well,
- A v3 transaction signals replaceability, even if it does not signal BIP125 replaceability.
- Any descendant of an unconfirmed V3 transaction must also be V3.
- A V3 transaction’s unconfirmed ancestors must all be V3.
- A V3 transaction cannot have more than 1 unconfirmed descendant.
- A V3 transaction that has an unconfirmed V3 ancestor cannot be larger than 1,000 virtual bytes.
- A V3 transaction cannot have more than 1 unconfirmed ancestor.
This rule mitigates pinning attacks and sets some strict rules on unconfirmed transaction clusters.
Conclusion
We have discovered that mempool policy rules serve to prevent certain types of attacks on Bitcoin, but they do not conflict with consensus rules. Rather, they simply enforce stricter standards. It’s important to note that there is no global mempool, and even without policy rules, the contents of mempools will vary. However, it’s worth noting that any valid non-standard transaction that makes it into a block will ultimately be accepted by all Bitcoin nodes.
