Proposal: A Trustless, Content-Redacting Bitcoin Full Node
Status: Discussion draft / research proposal
Purpose: Solicit technical review, criticism, alternative designs, and implementation ideas.
Scope: This document proposes an architecture, not a finished protocol specification.
Forum note: Diagrams use fixed-width ASCII so this version renders on standard Discourse installations without Mermaid support.
Short description
This proposal explores a Bitcoin node architecture that can independently verify the valid Bitcoin chain without receiving, processing, storing, or relaying selected arbitrary-data regions embedded in otherwise valid Bitcoin transactions.
The core idea is to separate:
- Bitcoin consensus — which blocks and transactions are valid;
- deterministic redaction rules — which byte regions a safe node refuses to possess;
- cryptographic validity proofs — proving that the hidden bytes existed in the committed Bitcoin block and that the complete, unredacted block was consensus-valid; and
- peer-to-peer distribution — allowing safe representations and proofs to be generated by anyone and relayed by anyone without trusting the sender.
The proposed system does not require a trusted sanitizer, a federation, a blacklist operator, a voting system among provers, or a second blockchain. Ideally it also requires no Bitcoin consensus change.
The guiding principle is:
Hide bytes, not economic information, whenever possible. Every hidden byte must be hidden because a deterministic public rule requires it—not because a prover chose to hide it.
1. Motivation
A conventional Bitcoin full node downloads and validates the complete serialized contents of every block it processes. Even when a node operator has no interest in arbitrary non-financial data embedded in transactions, the node normally must receive that data in order to independently validate the chain.
This creates a potential problem if arbitrary blockchain data contains material that an operator does not want to possess for legal, ethical, religious, organizational, or other reasons.
The desired node should therefore have two properties that normally appear to conflict:
Property A — Independent validation
The node should not have to trust a block explorer, API, centralized server, federation, or designated “clean copy” of Bitcoin.
Property B — Data avoidance
The node should be able to categorically refuse to receive selected byte regions that match deterministic structural rules.
The objective is not to determine whether data is morally acceptable, legal, offensive, copyrighted, artistic, or otherwise subjectively classified.
Instead, the software would identify structural mechanisms used to carry arbitrary data, according to a deterministic public policy.
Examples worth researching include rules conceptually similar to:
- data-bearing
OP_RETURNconstructions above a defined threshold; - known non-executed script-envelope patterns;
- data pushes within statically non-executed branches such as
OP_FALSE OP_IF ... OP_ENDIF; - other script or witness regions that can be proven unnecessary to the executed spending condition and match explicit protocol rules.
The exact rules are intentionally left open for review.
2. Non-goals
This proposal is not intended to:
- change which Bitcoin transactions are consensus-valid;
- prevent miners from mining arbitrary data;
- make transactions disappear from Bitcoin;
- create a new blockchain;
- create a committee that decides what Bitcoin contains;
- establish subjective content moderation;
- require safe nodes to trust a regulatory authority;
- require safe nodes to trust proof generators;
- introduce a second consensus mechanism;
- redefine Bitcoin Core relay policy as Bitcoin consensus;
- conceal ordinary financial transactions merely because somebody dislikes them.
A transaction may be completely valid Bitcoin while parts of its serialization qualify for redaction by the safe-node protocol.
3. Important Bitcoin property: the block header already commits to every transaction
A Bitcoin block header contains the transaction Merkle root. The block hash and proof of work are calculated from the block header, while the Merkle root cryptographically commits the header to the transactions in the block.
Conceptually:
Bitcoin block header
┌─────────────────────┐
│ previous block hash │
│ merkle root │
│ time │
│ target │
│ nonce │
└──────────┬──────────┘
│
▼
transaction Merkle root
│
┌─────────┴─────────┐
│ │
▼ ▼
branch branch
/ \ / \
txid txid txid txid
Changing any committed transaction changes its transaction ID and therefore changes the Merkle root.
This means a safe node can independently:
- obtain the Bitcoin header chain;
- verify proof of work and chain selection;
- know the transaction Merkle root selected by that proof of work;
without first receiving all transaction bytes.
However, a Merkle commitment by itself is not enough.
Knowing that a hidden transaction hash belongs in a block does not prove that the hidden transaction was consensus-valid.
That is the role of a validity proof.
4. Core architecture
The system has two broad node capabilities:
Full-data nodes
These are ordinary systems capable of receiving complete Bitcoin blocks.
Some full-data nodes may additionally generate cryptographic proofs.
Safe nodes
These deliberately refuse to receive byte regions classified for redaction.
They verify Bitcoin headers, safe block representations, cryptographic commitments, validity proofs, and state continuity.
There is no privileged prover.
Bitcoin P2P Network
complete blocks
/ | \
/ | \
v v v
+---------------+ +---------------+ +---------------+
| Full-data / | | Full-data / | | Full-data / |
| Prover A | | Prover B | | Prover C |
+-------+-------+ +-------+-------+ +-------+-------+
| | |
v v v
+-----------+ +-----------+ +-----------+
| Safe Node |<--->| Safe Node |<--->| Safe Node |
| 1 | | 2 | | 3 |
+-----+-----+ +-----------+ +-----+-----+
^ |
| v
+-----------------------------+-----------+
| Safe Node |
| 4 |
+-----------+
A safe node does not need to know whether the peer supplying a proof actually generated it.
A proof package may come from:
- a proof generator;
- another safe node;
- an archive;
- a cache;
- removable media;
- an untrusted mirror;
- any other transport.
The sender is untrusted.
The proof is verified locally.
5. Why prover consensus should not be required
A tempting design would have multiple provers vote on the correct safe representation.
For example:
67% of registered provers agree that SafeBlock X is correct.
This proposal explicitly avoids that design.
A prover quorum creates an additional consensus problem:
- Who qualifies as a prover?
- How are votes weighted?
- Can identities be Sybil-attacked?
- What happens if a majority colludes?
- What happens during a network partition?
- Why should safe nodes trust this consensus rather than Bitcoin consensus?
Instead:
Bitcoin determines the canonical chain. Deterministic rules determine the canonical redaction. Cryptographic proofs determine whether those rules were applied correctly.
A single valid proof should be sufficient.
Correct provers do not need to agree with one another by communication; they independently evaluate the same deterministic function.
Bitcoin block B
│
┌───────────────┼───────────────┐
▼ ▼ ▼
Prover A Prover B Prover C
│ │ │
▼ ▼ ▼
Transform(B) Transform(B) Transform(B)
│ │ │
└───────────────┼───────────────┘
▼
same canonical result
Multiple provers improve availability and censorship resistance, not truth.
6. Deterministic redaction
The protocol should define a pure deterministic operation such as:
CanonicalRedact(transaction) -> SafeTransaction
For a particular protocol version, the same transaction must always result in the same safe representation.
No prover discretion should exist.
Conceptually:
if region_matches_redaction_rule(region):
replace region with canonical commitment
else:
preserve exact bytes
The protocol should strongly prefer partial redaction over hiding an entire transaction.
For example:
Original transaction
├── version RETAIN
├── inputs
│ ├── previous output RETAIN
│ ├── sequence RETAIN
│ └── witness
│ ├── signature RETAIN
│ ├── executed script logic RETAIN
│ ├── arbitrary data region REDACT
│ └── control information RETAIN
├── outputs RETAIN
└── locktime RETAIN
This allows the safe node to retain as much directly useful Bitcoin information as possible.
7. Canonical redaction representation
A conceptual safe representation might look like:
SafeTransaction {
protocol_version
retained_regions[]
redacted_regions[] {
position
original_length
commitment
rule_id
}
txid_commitment
wtxid_commitment_if_applicable
}
This is illustrative only.
For example, an arbitrary-data envelope might be transformed conceptually from:
OP_FALSE
OP_IF
<large arbitrary byte sequence>
OP_ENDIF
<executed spending condition>
into something like:
OP_FALSE
OP_IF
REDACTED_REGION {
length: 347221
commitment: 9e81...
rule: NON_EXECUTED_DATA_ENVELOPE
}
OP_ENDIF
<executed spending condition>
The safe representation is not a Bitcoin transaction and must not be confused with one.
It is a separate representation whose relationship to the real transaction is cryptographically proven.
8. Structural rules, not content classification
The redaction rules should avoid interpreting the human meaning of bytes.
Bad rule:
Redact material that appears offensive.
Bad rule:
Redact illegal imagery.
Bad rule:
Redact gibberish.
These require subjective interpretation or content inspection.
Instead, rules should be defined in machine-verifiable terms.
Conceptual examples:
RULE_001:
A qualifying OP_RETURN construction whose serialized data-bearing
region exceeds threshold X.
RULE_002:
A qualifying statically non-executed data envelope matching an
exact script structure.
RULE_003:
A qualifying region of witness/script data that is provably outside
the executed validation path and satisfies precisely specified size
and structural requirements.
The terms qualifying, threshold, and exact script semantics would need rigorous specification.
An especially relevant known construction is the Ordinals inscription envelope, in which inscription content is serialized as data pushes inside an unexecuted OP_FALSE OP_IF ... OP_ENDIF conditional.
The proposal should not special-case a brand, protocol, political viewpoint, MIME type, or human-readable content. It should describe byte-level structures.
9. The anti-censorship property
A critical requirement is that a malicious prover must not be able to hide arbitrary transactions or arbitrary fields.
Suppose a transaction contains an ordinary payment and no region qualifies for redaction.
A malicious prover sends:
[HIDDEN TRANSACTION]
The proof must fail because:
CanonicalRedact(real_transaction) != supplied_safe_representation
Likewise, suppose only one region qualifies but the prover attempts to conceal the recipient and amount.
Again:
CanonicalRedact(real_transaction) != supplied_safe_representation
The proof fails.
This gives the system an important property:
A prover cannot decide what to censor. It can only prove the deterministic transformation defined by the protocol.
Changing what gets redacted therefore requires changing the safe-node software/protocol rules, not convincing a sanitizer or federation.
10. The validity proof
For a safe representation S, the prover possesses the original transaction or block B.
At a high level, the proof should establish a statement resembling:
There exists a complete Bitcoin block B such that:
1. B corresponds to the advertised Bitcoin block header.
2. The transaction Merkle root of B equals the Merkle root
committed to by that header.
3. B satisfies Bitcoin consensus rules relative to the valid
previous chain state.
4. Applying every transaction in B produces the claimed next
chain state.
5. Applying CanonicalRedact() to B produces exactly the supplied
SafeBlock representation S.
6. Every omitted byte is therefore omitted only where the
public redaction rules permit omission.
The hidden portions are private witness data to the proof system.
The safe representation, block header, state commitments, protocol version, and other required values are public inputs.
Complete Bitcoin Block
(private to prover)
|
+-------------------+-------------------+
| | |
v v v
+------------------+ +----------------+ +------------------+
| Bitcoin consensus| | CanonicalRedact| | Bitcoin Merkle |
| validation | | () | | commitment |
+---------+--------+ +-------+--------+ +---------+--------+
\ | /
\ | /
\ v /
\ +---------------+ /
+------>| State |<------+
| transition |
+-------+-------+
|
v
+---------------+
| Validity proof|
+-------+-------+
|
v
+-----------+
| Safe Node |
+-----------+
The exact proof circuit may organize these checks differently; the important point is that the proof binds all of them to the same complete block.
The safe node learns that the claims are true without receiving the redacted bytes.
11. Merkle proofs versus zero-knowledge validity proofs
These solve different problems.
Merkle commitment
Bitcoin’s existing transaction Merkle root allows a verifier to establish that transaction hashes are committed to by the proof-of-work-secured block header.
It does not establish that an unseen transaction:
- spent existing UTXOs;
- had valid signatures;
- satisfied Bitcoin Script;
- obeyed locktime and sequence rules;
- avoided double spending;
- obeyed block-level consensus constraints;
- caused the claimed UTXO state transition.
Validity proof
The validity proof can establish those properties while keeping designated bytes private.
Therefore, this proposal likely needs both:
Bitcoin PoW
↓
Block header
↓
Transaction Merkle commitment
↓
Validity proof over complete hidden/visible block data
↓
Verified safe representation
12. State validation and the UTXO problem
Hiding transaction bytes introduces an important state problem.
Suppose a redacted transaction creates an output that is spent years later.
The safe node must still know that:
- the output really existed;
- its value and spending conditions were what the later transaction requires;
- it had not already been spent.
A conventional node learns this by processing the complete transaction and maintaining the UTXO set.
A safe node therefore needs a cryptographically committed chain state.
Conceptually:
State commitment N
│
│ + Bitcoin block N+1
│ + validity proof
▼
State commitment N+1
│
│ + Bitcoin block N+2
│ + validity proof
▼
State commitment N+2
Utreexo is especially relevant research here because it defines a dynamic hash accumulator for Bitcoin’s UTXO set and mechanisms for validation against that committed state.
The final design need not necessarily use Utreexo unchanged, but it should study and reuse established work wherever practical.
13. Recursive proofs and trustless bootstrapping
A new safe node should ideally not need a trusted UTXO snapshot or checkpoint.
A long-term architecture could use recursive proofs so that a current proof cryptographically attests to the validity of prior state transitions.
Conceptually:
Genesis-defined Proof 1 State 1 Proof 2 State 2
initial state ---> | ---> | ---> | ---> |
... |
v
+-------------------+
| Recursive proof |
| through height N |
+---------+---------+
|
v
State N
A newly installed node could then bootstrap from:
- Bitcoin consensus rules;
- the proof-of-work header chain or a proof that correctly commits to it;
- a succinct recursive validity proof;
- the current safe state representation.
No trusted prover identity is required.
Projects such as ZeroSync and Raito demonstrate related research directions involving STARK proofs for Bitcoin chain state. They should be treated as research references rather than assumed production-ready components.
14. SafeBlock: a possible transport object
A useful protocol abstraction may be a deterministic object such as:
SafeBlock {
safe_protocol_version
bitcoin_block_header
bitcoin_block_hash
previous_safe_state_commitment
resulting_safe_state_commitment
safe_transactions[]
redaction_summary
canonical_representation_root
validity_proof
}
The exact structure is open for design.
A key goal is:
same Bitcoin block
+ same Safe protocol version
= same canonical SafeBlock representation
Proof bytes themselves may differ depending on proof-system properties, but the committed semantic representation should not.
15. Merkleizing the safe representation
SafeBlock data could itself be represented by a Merkle tree or other content-addressed structure.
SafeBlockRoot
/ \
/ \
MetadataRoot DataRoot
/ \
/ \
retained redaction
data commitments
Potential benefits:
- integrity checking;
- parallel downloads;
- deduplication;
- caching;
- resumable synchronization;
- selective retrieval;
- content-addressed P2P distribution;
- efficient proof-package sharing.
Safe nodes could request pieces by hash without trusting the peer serving them.
16. P2P distribution
The safe network should behave as a peer-to-peer network rather than a hierarchy under prover infrastructure.
Prover A Prover B Prover C
| | |
v v v
+--------+ +--------+ +--------+
| Safe 1 |<---------->| Safe 2 |<---------->| Safe 3 |
+---+----+ +---+----+ +---+----+
| | |
| | |
| +---v----+ |
+---------------->| Safe 5 |<---------------+
+---+----+
|
v
+--------+
| Safe 4 |
+--------+
Any safe peer may relay a valid proof package. The receiving node verifies
it locally; the relay peer does not become trusted merely by forwarding it.
Once one valid proof package exists, any safe node can verify, cache, and relay it.
A safe node receiving a package from another peer asks only:
Does this verify?
not:
Do I trust this peer?
This makes proof generation permissionless and proof distribution fully decentralized.
17. Availability versus trust
Multiple provers remain useful, but not because the safe node takes a majority vote.
Safety
Cryptographic verification protects the safe node from incorrect prover output.
Availability
Many independent proof generators make it difficult for one organization or jurisdiction to prevent safe nodes from obtaining proofs.
Therefore:
1 valid proof = sufficient for correctness
many independent provers = better availability
A malicious prover can:
- waste bandwidth;
- refuse to respond;
- delay generating a proof;
- send an invalid proof.
It should not be able to make a valid safe node accept an invalid Bitcoin state or unauthorized redaction.
18. No encrypted copy of redacted payloads
The preferred design should avoid sending an encrypted or reversibly encoded copy of excluded bytes to safe nodes.
Instead, safe nodes should receive only information necessary for cryptographic verification, such as:
- cryptographic commitments;
- original byte length where required;
- location/structural metadata;
- rule identifier;
- proof data.
For example:
RedactedRegion {
offset: ...
length: ...
commitment: SHA256(... or protocol-defined commitment)
rule_id: ...
}
The underlying bytes should never cross the safe node’s trust boundary.
The legal significance of hashes, commitments, ciphertext, metadata, or other derived information will vary by jurisdiction and requires separate legal analysis. The technical design should nevertheless minimize exposure by construction.
19. Suggested classifications
A useful protocol may distinguish three outcomes:
RETAIN
The exact original bytes are delivered to the safe node.
REDACT
A particular byte region is replaced with a cryptographic commitment and associated proof metadata.
OPAQUE
The protocol cannot safely expose a useful partial representation, so a larger structure must remain hidden.
The design goal should be:
Minimize OPAQUE. Prefer precise REDACT. Preserve RETAIN wherever possible.
This allows the safe node to directly inspect and validate as much conventional Bitcoin data as possible.
20. Relationship to Bitcoin relay policy
Safe-node redaction rules must not be confused with:
- Bitcoin consensus rules;
- Bitcoin Core standardness rules;
- mempool policy;
- miner transaction-selection policy;
- historical defaults such as data-carrier limits.
For example, it may be perfectly coherent for:
Bitcoin consensus: VALID
Safe protocol: REDACT REGION
The Safe protocol is determining what its nodes are willing to possess, not whether Bitcoin accepts the transaction.
Terminology such as RETAIN and REDACT is preferable to VALID, INVALID, STANDARD, or NONSTANDARD.
21. Mempool behavior
This proposal primarily addresses data that has already been mined into blocks.
Mempool behavior can be treated separately.
A safe node could have a conservative mempool policy that simply declines to request or relay transaction forms likely to contain qualifying arbitrary-data regions.
That does not affect consensus validation of mined blocks.
Possible future work could explore proof-carrying sanitized unconfirmed transactions, but that should not complicate the initial design.
22. Compatibility with ordinary Bitcoin peers
A safe node cannot be a perfect archival substitute for an ordinary full-data node.
If it deliberately does not possess redacted bytes, it cannot later serve those bytes to another peer.
It can, however, potentially participate in many normal node activities:
- validating proof of work;
- following the most-work valid Bitcoin chain;
- wallet transaction verification;
- maintaining or verifying UTXO state;
- relaying retained transactions;
- relaying safe representations;
- serving safe proof packages;
- monitoring chain reorganizations;
- exposing Bitcoin RPC functionality that does not require the omitted content.
A separate service bit and/or P2P protocol extension would likely be appropriate so peers know which data the node can serve.
(continued in next post)