Skip to content
Satnam SatoshiIn service of humanityFind your place ↗
Menu

Sikh Bitcoin · Advanced · Lesson 9 of 21

Mempools and policy are not consensus

Understand why nodes can disagree about pending transactions.

About 14 minutes with practice. You only need something to take notes with. No real wallet details or payments are part of this lesson.

Course contents · Lesson 9 of 21
  1. Read the whitepaper as an argument
  2. Hashes and Merkle commitments
  3. UTXOs, change and accounting
  4. Scripts describe spending conditions
  5. Signatures and what they authorize
  6. Block headers and the chain of work
  7. Difficulty, hashrate and noisy observations
  8. Issuance, fees and incentives
  9. Mempools and policy are not consensus
  10. Fee changes: RBF and CPFP
  11. SegWit and transaction weight
  12. Taproot and Schnorr: useful, not magical
  13. HD wallets and derivation paths
  14. PSBT: separate construction from signing
  15. Descriptors make a wallet policy portable
  16. Full nodes, pruning and verification
  17. Reorganizations and lightweight evidence
  18. Lightning channels and HTLCs
  19. Lightning liquidity has direction
  20. Soft forks, proposals and human coordination
  21. Capstone: trace a payment end to end

What you will learn

  • Distinguish local relay policy from block validity.
  • Explain why a transaction can be absent from one explorer.

There is no single global waiting room

A node’s mempool is its local collection of accepted unconfirmed transactions. Nodes can receive information at different times, apply different policies and evict transactions under resource constraints. An explorer showing no result does not prove that nobody else has seen the transaction. Conversely, visibility in one mempool does not ensure eventual confirmation.

Policy helps manage limited resources

Relay and mempool policy restrict what a node is willing to handle before confirmation. Consensus rules determine what blocks it accepts as valid. These layers overlap in purpose but are not identical. A transaction can fail a local policy check without proving that every possible block containing it would violate consensus. Exact behavior depends on implementation and version.

Diagnose with identifiers and context

For a fictional pending donation, collect the network, transaction identifier, observing node’s synchronization state and relevant policy response. Avoid exposing an entire wallet history when one transaction is sufficient. Compare observations with their timestamps. A responsible interface distinguishes not observed, rejected by this node, pending and confirmed instead of turning every missing lookup into failed payment.

When comparing two nodes, also record when each observation was made; their views can change while the comparison is underway.

Practice on paper

Explorer A shows a transaction pending; Explorer B has no record. List two explanations that do not require fraud.

Reveal the worked answer

They may have different propagation timing or local policies, or one may be out of sync. The disagreement needs investigation of the same network and transaction, not an automatic resend.

Check your understanding

Choose an answer in your head or on paper, then reveal the explanation. Retry whenever you like. Answers are not submitted or scored; completion marks are your own learning notes.

1. Is there one universal mempool shared identically by every node?

  • Yes
  • No
Reveal answer 1

No. Mempools are local views.

2. Is relay policy always identical to consensus validity?

  • Yes
  • No
Reveal answer 2

No. They answer different operational questions.

Take this with you

Describe a node’s observation without calling it the whole network.

Your learning, at your pace

Read every lesson freely. Optional progress tracking needs JavaScript and browser storage; it does not require an account or wallet.