Quick answer: A Bitcoin transaction can be refused by a wallet or service, rejected from a node’s mempool, withheld from peer relay, omitted from a block template, delayed by the share of work using that template policy, or removed from the active chain by a reorganization. Bitcoin has no consensus rule that guarantees a particular transaction will be broadcast, selected, confirmed, or remain confirmed. Censorship resistance comes from alternative paths and independent decision makers; it is not a promise of inclusion.
Define the layer before calling an event censorship
- Consensus validity
- Whether a transaction may appear in a block accepted under a node’s current consensus rules.
- Standardness and mempool policy
- Local conditions for retaining an unconfirmed transaction. A transaction can be consensus-valid yet fail a node’s local policy.
- Relay
- A node’s decision to announce or deliver transaction data to peers. Relay is not a global broadcast receipt.
- Template selection
- The template builder’s choice of transactions and packages for a candidate block.
- Job distribution
- The work derived from a template and sent to hashing devices. A payout coordinator and template builder may be different actors.
- Block inclusion
- A valid found block contains the transaction and is accepted into a node’s active chain.
- Reorganization
- A different valid branch accumulates more work and replaces active-chain blocks, potentially disconnecting a confirmation.
- Service or legal restriction
- A wallet, custodian, counterparty, network operator, template builder, or other person refuses action because of contract, policy, coercion, or law. That is distinct from protocol invalidity.
Transaction lifecycle: every arrow is conditional
- Wallet and signing: software constructs a transaction and satisfies the selected inputs’ spending conditions.
- Local submission: a node checks consensus-related conditions and its current local mempool policy.
- Peer announcement: the node may announce inventory to connected peers; peers independently decide what to request, accept, store, and relay.
- Template construction: a template builder selects transactions and packages it knows and accepts.
- Job distribution and hashing: work derived from the candidate block reaches hashing devices, which search for proof of work.
- Block publication and validation: a found block is published; each node independently validates it under its current rules.
- Chain selection: nodes consider valid candidates and attempt to activate the branch with the most accumulated work.
- Confirmation depth: later blocks add work, reducing some reorganization risk under stated assumptions without creating absolute finality.
Broadcast and local mempool acceptance
Submitting a transaction is not a network-wide operation. Bitcoin Core’s pinned broadcast path checks whether the transaction is already confirmed or local, tests or submits it to the local mempool according to the chosen broadcast method, and then initiates peer announcement. A successful call is evidence about that node and path, not every peer or miner.
Local rejection can be caused by invalidity, non-final conditions, missing parents, conflicts, replacement rules, insufficient fee, package or ancestor/descendant limits, or other policy. Record the exact error, software version, configuration, mempool state, transaction and parent data, and observation time before assigning motive.
Bitcoin Core’s revision-pinned package-policy documentation explicitly notes that operators can configure mempool policies differently and describes capacity-sensitive minimum feerates. There is no single canonical mempool shared by the network.
Peer relay is selective and topology-dependent
Connected peers can decline transaction relay, apply fee filters, lack required parents, know a conflict, or receive the announcement later. Bitcoin Core’s pinned inventory-relay logic skips transactions below a peer’s fee filter and respects whether a peer relays transactions.
Multiple controlled peers or network paths can improve reach and help diagnose an isolated failure. They cannot prove receipt by a non-filtering template builder. Broadcasting through third parties can also reveal transaction or origin metadata. Network path changes are not legal-evasion advice and should not be represented as anonymity or inclusion guarantees.
Template builders, coordinators, and hashing devices
Transaction selection occurs in template construction, not inside an ASIC searching header values. A pool can coordinate shares and payouts while also building templates, or compatible systems can separate those functions. A solo-labelled payout arrangement does not prove that the hardware operator constructs the candidate block.
Bitcoin Core’s default template builder begins from its configured mempool, and its pinned selection logic evaluates transaction chunks against block constraints and mining score. This is one implementation and policy, not a consensus requirement to include every fee-paying transaction.
BIP 22 and BIP 23 specify template interfaces. To claim local selection, verify which component obtains chain and mempool data, constructs the coinbase and transaction set, produces jobs, receives a found solution, and publishes the block. For the broader role distinction, see Bitcoin Nodes vs Miners.
Fees, packages, replacement, and non-inclusion
A transaction fee creates a potential opportunity only for a template builder that received the transaction, accepts its transaction and package policy, considers its effective feerate competitive, and chooses to include it. Capacity, conflicts, package relationships, private arrangements, risk policy, or legal constraints can change that decision. “Leaving a fee on the table” is not proof of irrationality or censorship.
Replacement and child-pays-for-parent can improve package economics in compatible circumstances. They do not compel peers or template builders. Modern Bitcoin Core replacement behavior has evolved beyond the original opt-in description, so use the pinned current replacement-policy documentation, exact wallet behavior, and receiving-node result rather than assuming one historical policy.
Failure-stage and evidence matrix
| Stage | Controller | Observable evidence | Common non-censorship explanation | Evidence consistent with targeted filtering | Conditional mitigation | Residual limitation |
|---|---|---|---|---|---|---|
| Wallet creation | Wallet/service and signer | Unsigned/signed transaction, error, policy, selected inputs | Insufficient funds, wallet policy, non-final construction, missing key | Documented refusal based on identified party or destination | Use controlled signing software where lawful and compatible | Does not establish relay or inclusion |
| Local acceptance | Submitting node | Exact test/submit result, version, configuration, mempool state | Invalidity, conflict, fee floor, missing parent, limits | Selective local rule reproducible against comparable transactions | Correct transaction/package or test another controlled policy | Other nodes may still differ |
| Peer relay | Each peer and network path | Connections, inventory/request logs, peer filters, timing | Relay disabled, fee filter, topology, missing data, propagation delay | Repeated selective withholding across controlled comparisons | Additional lawful controlled peers or direct paths | Reach and privacy remain uncertain |
| Template selection | Template author | Observed templates/jobs, mempool knowledge, included comparators | Package priority, late arrival, block constraints, differing mempool | Persistent omission despite known acceptance and comparable priority | Use another verified template path where lawful | Block discovery remains stochastic |
| Job distribution | Coordinator/proxy | Authenticated jobs, endpoints, configuration, template commitments | Stale job, connectivity, proxy failure, configuration drift | Jobs systematically exclude an otherwise-observed template choice | Verify or change approved job path | Payout and publication controls may remain shared |
| Block publication | Solution recipient/publisher | Share/solution logs, block receipt and peer propagation | Stale solution, invalid candidate, network failure | Valid solutions selectively withheld under a stated policy | Independent authenticated publication path | Does not prevent a competing branch |
| Block validation | Each validating node | Validation result and active rule set | Invalid proof, script, value, structure, or contextual rule | No censorship inference when the block is objectively invalid under those rules | Correct the invalid block/transaction | Validity is distinct from active-chain selection |
| Active chain | Distribution of valid accumulated work | Competing branches, chainwork, reorg depth, timestamps | Natural race or propagation difference near the tip | Repeated attempts to orphan otherwise-valid inclusive blocks | Wait for depth and monitor work distribution | No fixed depth creates absolute finality |
| Custodial access | Wallet, exchange, custodian, counterparty | Terms, account notice, withdrawal/deposit state | Risk, fraud, technical, or account controls | Explicit party/destination restriction | Use self-custody prospectively where lawful and suitable | Cannot change past custody or force counterparties |
| Legal restriction | Persons subject to a jurisdiction/order | Official source, order, designation, ownership, licence, counsel | Misidentification or inapplicable jurisdiction | Verified obligation affecting a participant’s conduct | Qualified legal analysis and authorized process | Technical workarounds do not resolve legal duties |
Partial filtering changes delay before a majority threshold
If a fraction of found blocks uses a filtering policy, that fraction omits the transaction from its own opportunities. Inclusion by others remains probabilistic and also depends on relay, mempool acceptance, fee/package priority, and template knowledge. A short run of filtering blocks can occur by chance, while a short run of inclusive blocks does not prove the policy ended.
Do not translate a static attributed block share into a guaranteed delay. Attribution labels can be wrong, physical ownership can differ from coordination, and template authority can differ from payout identity. The peer-reviewed paper Monitoring the Transaction Selection Policy of Bitcoin Mining Pools is useful for measurement method, not a current entity ranking. The ASIC mining topology guide explains these control layers.
Majority work, orphan threats, and valid-chain limits
A sustained majority-work actor can omit a transaction while attempting to extend its valid branch faster than inclusive alternatives. It can attempt to reorganize otherwise-valid blocks containing the transaction. A smaller coalition can still omit from its own blocks or threaten short reorganizations; effects depend on work share, duration, visibility, propagation, incentives, and participant response.
Hashpower does not let an actor forge signatures, spend arbitrary third-party outputs, create invalid inflation accepted by unchanged nodes, or make those nodes accept a block violating their current rules. Avoid durable hardware counts, currency costs, or “impossible today” claims. The relevant work distribution and operating conditions change.
Confirmation depth and probabilistic finality
A block header commits to its predecessor and transaction merkle root, but the active chain is not an append-only database with absolute finality. Bitcoin Core considers valid candidates and attempts to activate the most-work chain using its pinned chain-selection logic.
When a block disconnects, transactions may be reconsidered for a local mempool subject to current policy and conflicts; return is not guaranteed. See the pinned reorg mempool handling. The Bitcoin whitepaper, especially sections 5 and 11, frames catch-up as a probability. Confirmation requirements must match value, threat model, counterparty, and observed conditions.
Capability matrix: who can affect which layer?
| Actor | Refuse service | Withhold relay | Omit own templates | Attempt to orphan an inclusive block | Make current-rule nodes accept invalid data | Primary limitation |
|---|---|---|---|---|---|---|
| Custodial service | Yes, within its service | Can withhold its submission | Only if it also controls templates | Only with controlled work | No | Does not control self-custodied keys or all network paths |
| Non-custodial wallet software | Can refuse construction or broadcast | Can limit configured paths | No by itself | No by itself | No | User may use other compatible software, subject to law and keys |
| Relay node | Can refuse peer requests | Yes, for its peers | Only if also a builder | Only if also controls work | No | Alternative peers may exist |
| Network administrator or ISP | Can block its access path | Can disrupt or observe its path | No direct template authority | No without work control | No | Scope is its networks, law, and technical reach |
| Pool/accounting coordinator | Can refuse accounts/work | Can control its job path | Only if it authors templates | Only through coordinated work | No | Hardware owners, templates, custody, and publication may differ |
| Template builder | Can refuse candidate transactions | Can choose its input paths | Yes, for its templates | Only with supporting work | No | Cannot compel independent builders or nodes |
| Minority hashing coalition | Can refuse work | Can withhold its own data | Can support filtering templates | Can attempt, with lower sustained-work expectation | No | Others may extend inclusive valid branches |
| Sustained majority-work actor | Can refuse work | Can isolate its infrastructure | Can filter its candidates | Can attempt to outpace inclusive valid branches | No | Must retain work advantage and produce valid blocks |
| Validating node | Can refuse peers/data locally | Can set local relay policy | No unless also a builder | No without work | Applies its own configured rules only | Does not force other nodes to adopt its rules |
| Government, regulator, or court | Can compel persons in scope | Can regulate or order network actors in scope | Can pressure or compel builders in scope | Only through controlled/coerced work | Cannot alter unchanged node validation directly | Authority, jurisdiction, ownership, licences, and enforcement vary |
Legal coercion is not consensus invalidity
A transaction can satisfy Bitcoin’s rules while a particular person is prohibited from dealing with a party or property. Legal duties depend on jurisdiction, ownership, control, designation, licence, and facts. An address identifier is evidence used in a legal/compliance process; it is not a consensus blacklist embedded in Bitcoin Core.
The official OFAC virtual-currency FAQ topic explains that obligations apply to persons subject to its jurisdiction and that there is no single compliance solution for every circumstance. OFAC FAQ 559 defines a digital-currency address. Canadian readers can consult the official Consolidated Canadian Autonomous Sanctions List as a source, not as a substitute for counsel.
Do not infer that every miner, node, wallet, or user has the same obligation. Do not treat a technical path change as resolution of a legal duty. Preserve the official source, effective date, jurisdiction, order or designation, ownership analysis, licence, advice, and decision record.
Diagnostic decision tree for a stalled transaction
- Preserve evidence. Record raw transaction, txid/wtxid, parents, wallet result, node version/configuration, fee and size, timestamps, peers, and any service notice.
- Check transaction and chain state. Is it well-formed, final for the current tip/time rules, already confirmed, conflicted, replaced, or spending unavailable inputs?
- Test local acceptance. Capture the exact result. If rejected, classify consensus-related failure, policy, missing data, conflict, fee, or package limits.
- Check local mempool presence. Absence after earlier acceptance can reflect eviction, conflict, expiry policy, reorg effects, restart, or configuration.
- Inspect relay evidence. Are peers connected and transaction relay enabled? Do peer fee filters, missing parents, topology, or privacy settings explain limited announcement?
- Evaluate package competitiveness. Compare the transaction/package with the current local mempool and actual blockspace without assuming every builder has the same data or policy.
- Verify template exposure. Did an identified builder receive and accept it? Are observed jobs/templates available? A payout label is not enough.
- Use controlled comparisons. Compare similarly timed transactions with similar effective priority while controlling for parents, conflicts, arrival, and policy.
- Check active-chain events. Was an inclusive block found, rejected as invalid, or disconnected by a reorganization?
- Escalate legal/service issues. If a restriction, designation, freeze, or order may apply, stop technical experimentation that could worsen exposure and obtain qualified advice.
Lawful conditional mitigations
| Action | Potential benefit | Prerequisite/evidence | Residual limitation |
|---|---|---|---|
| Run a full node | Independent validation, local acceptance evidence, controlled broadcast path | Secure, synchronized, connected node and understood policy | Does not control peers or templates and can be isolated |
| Correct transaction/package | Resolves a specific validity, parent, conflict, fee, or policy failure | Exact error and wallet capability | Other policies and selection remain independent |
| Replacement | May improve priority or correct outputs under current policy | Spend authority, current replacement rules, recipient implications | Not universally accepted and can create conflicts |
| Child-pays-for-parent | May improve package economics | Spendable output, compatible package structure and policy | Package limits and template policy still apply |
| Additional controlled peers | Improves reach and diagnoses topology | Privacy review, authenticated configuration, lawful use | Does not prove template receipt; can leak metadata |
| Verified alternate template path | Changes one transaction-selection authority | Evidence of who builds templates, jobs, publishes, and pays | Block discovery and reorg risk remain stochastic |
| Lightning for a new payment | May use an existing off-chain route | Channels, liquidity, compatible recipient, route and fee | Routing can fail; opening/closing and disputes depend on-chain |
| Wait for confirmation depth | Reduces some post-inclusion reorg risk | Transaction already included; threat/value-based policy | Does not cause initial inclusion or create absolute finality |
| Qualified legal advice | Clarifies obligations, licences, authorized options, and records | Relevant facts, parties, ownership, jurisdiction and official sources | Does not create a protocol or economic outcome |
Lightning and privacy boundaries
Lightning can route a payment through existing channels without recording each hop as an on-chain payment. Onion routing limits what an intermediate hop learns, but nodes still control channel availability, liquidity, fees, minimums, forwarding, and connections. Counterparties can refuse service, routes can fail, and channel opening, unilateral close, and dispute transactions depend on base-layer inclusion.
The pinned BOLT specification describes onion routing. Research on congestion attacks in payment-channel networks shows why route redundancy is not an impossibility proof. See the Bitcoin and Lightning settlement-layer guide for scope.
Privacy tools can reduce some graph inferences but can introduce coordinator denial, distinctive transaction structure, wallet risk, data leakage, or legal concerns. They do not guarantee anonymity, relay acceptance, template selection, legality, or confirmation. Privacy and censorship resistance overlap without being the same property.
How to study suspected filtering without a false accusation
Define the transaction set and hypothesis before observing blocks. Preserve raw transactions and parents, effective package priority, first-seen evidence from multiple controlled nodes, local policy results, conflicts, block and template data, chain reorganizations, observation window, clock basis, and unknowns. Separate “not observed” from “known and omitted.”
Use enough observations for the claimed effect and publish uncertainty. Control for late propagation, different mempools, package relationships, block weight, fee changes, private transactions, and builder identity. A coinbase or payout label can be heuristic and does not establish the template author. Do not publish current rankings or allegations in an evergreen explainer.
Related protocol guides
- Bitcoin decentralized consensus for agreement and validation concepts.
- Nakamoto consensus for work-based chain selection.
- Hashrate measurement for why network work estimates are not a machine census.
- Difficulty retarget mechanics for liveness under changing work.
Sources and revision record
Reviewed 2026-08-29 against the Bitcoin whitepaper; BIP 22 and BIP 23; Bitcoin Core commit ca7162cde58e69214a3309c17fac6d666b5f055a; Lightning BOLT commit 152897261850d93c4f4597f39cf22d7d22d6ede6; the cited peer-reviewed transaction-selection and payment-channel research; and the linked official sanctions sources. Legal sources are jurisdiction- and date-specific. This page embeds no current pool share, network hashrate, difficulty, fee estimate, confirmation forecast, attack cost, commercial incident, or product/service recommendation.
Frequently asked questions
Can a valid Bitcoin transaction be permanently censored?
Bitcoin provides no rule that guarantees a particular transaction will be relayed, retained, selected, mined, or remain in the active chain. Independent relay and template paths make coordinated exclusion harder, but a transaction can be delayed or omitted for policy, fee, conflict, capacity, legal, network, or targeted reasons. Describe the stage and evidence instead of promising eventual inclusion.
What is the difference between broadcast, relay, mempool acceptance, and confirmation?
Broadcast submits a transaction to one or more nodes. Each node independently decides whether to accept it into its local mempool and announce it to peers. A template builder separately decides what to include in a candidate block. Confirmation occurs only when a valid block containing it enters the active chain, and later reorganizations remain possible.
Why might one node reject a transaction that another node accepts?
Nodes can use different fee floors, capacity, replacement settings, package limits, relay permissions, and other policy. They can also have different parents or conflicts. Consensus validity for inclusion in a block is not identical to local mempool standardness or relay policy. Check the exact rejection reason and node configuration rather than inferring censorship from one result.
Can one pool or template builder delay a transaction?
Yes. A template builder can omit a transaction from its own candidate blocks, and a coordinator can withhold jobs or relay. The resulting delay is stochastic and depends on that actor's share of found blocks, whether other template builders received and accept the transaction, fee and package priority, and whether inclusive blocks remain in the active chain.
What can sustained majority hashpower do to transaction inclusion?
A sustained majority-work actor can omit a transaction while attempting to build faster than inclusive branches, and can attempt reorganizations of otherwise-valid blocks. It still must produce blocks accepted by current-rule nodes and cannot forge another user's signature or make those nodes accept invalid inflation. Feasibility and duration are conditional, not guaranteed.
Do higher fees, replacement, or child-pays-for-parent guarantee confirmation?
No. They may improve relay or template priority when the transaction and package meet the receiving node's current policy and the wallet can construct the required transaction. They do not compel a peer or template builder, resolve every conflict or legal restriction, or prevent a later reorganization. Preserve the original and replacement evidence when diagnosing.
Do a full node, alternate network path, privacy tool, solo mining, or Lightning make a payment uncensorable?
No. A full node improves independent validation and a controlled broadcast path. Other network paths can improve reach but may introduce privacy or legal risk. Privacy tools do not guarantee anonymity or inclusion. Solo mining controls templates only with a verified local template path and still has block-discovery risk. Lightning depends on routes, liquidity, counterparties, and on-chain settlement.
What should a user do when sanctions or another legal restriction may apply?
Pause and obtain advice from a qualified lawyer for the relevant person, jurisdiction, ownership, licence, and transaction. A protocol-valid transaction can still create legal obligations for particular participants. This guide does not provide sanctions-evasion steps, and changing wallet, relay, network, privacy, mining, or payment paths is not a substitute for legal analysis.
