Policy and consensus answer different questions
Consensus determines whether a transaction may appear in a valid block. Mempool and relay policy determines whether a particular node will hold or forward that transaction before confirmation. A consensus-valid transaction can therefore be rejected from a local mempool.
Policy can change between Bitcoin Core releases without a consensus change. Wallet design must qualify assumptions by the node software, version and configuration actually used rather than describing one policy snapshot as a permanent network rule.
Unconfirmed dependencies form packages
A child transaction may spend an output created by an unconfirmed parent. Nodes evaluate dependency order, ancestor and descendant relationships, fees and resource limits when deciding whether the transactions can enter the mempool.
Package submission lets related transactions be considered together in supported workflows. It does not guarantee network-wide relay, shared mempools or future confirmation; peers can run different versions and policies.
Package economics enable CPFP
A high-fee child can raise the combined fee rate of itself and a low-fee parent, giving a miner an incentive to include both. This child-pays-for-parent logic depends on the transactions forming an acceptable package and on the relevant node or miner policy.
The combined fee rate is not a magic override. Missing inputs, consensus failures, conflicting transactions or package-policy limits can still prevent acceptance.
Replacement and pinning interact
Replacement policies decide when a conflicting transaction may displace mempool entries. A protocol that depends on fee bumping must understand which party can create descendants, conflicts or resource usage that makes the preferred replacement difficult or expensive to relay.
Pinning is the use of policy constraints to obstruct another participant's transaction or fee-bump path. Designs should limit untrusted parties' ability to attach problematic transactions and should test replacement behaviour under adversarial states.
Design against a documented version
Current Bitcoin Core package and replacement documentation describes the behaviour implemented by that release family. BIP431 describes version-3 transaction policy and topology restrictions intended to make some pinning-resistant protocols easier to reason about.
Use the RPCs and test framework of the deployment version to reproduce each state: original transaction, child, conflict, replacement and confirmation. Monitor release notes because policy engineering is active and operational behaviour can improve without changing block validity.
Visual recap
From one transaction to a relay package
Fees, dependencies and conflicts are evaluated under local policy before miners consider inclusion.
Create parent
Attach child
Order dependencies
Evaluate package fees
Check conflicts and limits
Accept, reject or replace
Key vocabulary
Terms worth knowing
- Package
- A related set of unconfirmed transactions considered with their dependency relationships.
- Replacement
- A policy-governed process where a conflicting transaction displaces one or more mempool entries.
- Pinning
- Using relay or replacement constraints to obstruct another party's preferred transaction or fee bump.
Worked example
A fee-bump path works locally but not at a peer
A wallet submits a low-fee parent and high-fee child. Its own current node accepts the package, while an older peer rejects it.
- 1Confirm both transactions are consensus valid
- 2Record software versions and configuration
- 3Inspect ancestor, descendant and fee rules
- 4Test direct submission to the intended broadcaster or miner interface
- 5Avoid claiming network-wide acceptance
Package relay is local and version-dependent. Protocols need documented assumptions and fallback paths rather than a global-mempool model.
Common misconceptions
What learners often get wrong
Misconception
A high enough child fee overrides every rejection.
More accurate
Fees cannot repair missing inputs, consensus failures, conflicts or unsupported package topology.
Misconception
All Bitcoin nodes implement identical mempool policy.
More accurate
Consensus must align for blocks, while relay policy and software versions can differ.
Try it yourself
Build an adversarial package test matrix.
- Create parent and child cases
- Add one conflicting replacement
- Vary software version and policy
- Record local acceptance and relay separately
- State which result is consensus and which is policy
Use fictional values and public information only. Never enter seed words, private keys or other wallet secrets into a learning exercise.
Key takeaways
- Consensus validity does not guarantee mempool acceptance or relay.
- Unconfirmed parents and children form dependency packages.
- CPFP relies on combined package economics and applicable policy.
- Pinning exploits relay or replacement constraints to obstruct a preferred spend.
- Package and replacement behaviour must be tested against a named software version.
Lesson recap
Check what you learned
Reveal each model answer, then honestly mark whether you understood it or need another review.
1 of 3
Recall
If a node rejects a transaction package from its mempool, does that prove the transactions could never appear in a valid block?
References
