Researchers at [[alloc] init] — Clara Shikhelman, Misha Komarov, and Aleksei Moskvin — have released Shielded Bitcoin, a whitepaper describing a novel privacy metaprotocol built on the Bitcoin base layer. The design enables shielded Bitcoin transactions without requiring operators, soft forks, or any other changes to Bitcoin consensus. The whitepaper and an accompanying blog announcement are available, and the team shared the news on X.

The protocol defines a transactional structure and an indexing protocol for strongly privacy-preserving transactions, while relying on Bitcoin PIPEs to peg funds into and out of the system. The PIPEs mechanism is examined in detail at the end of this article.

That no-consensus-change property matters: Bitcoin's ledger records amounts and addresses in public view, and changes to its rules have historically required broad network-wide coordination. A design that operates entirely within the existing rule set does not depend on that process to move forward.

A Bitcoin-Like Design With Very Different Details

The architecture deliberately mirrors Bitcoin's own. There is an equivalent to the UTXO, called a note. Transactions consume notes as inputs, just as a regular Bitcoin transaction spends UTXOs. A witness proves that the consumed inputs are properly authorized, and nodes — indexers, in the case of a metaprotocol — parse the transaction history and build a running state of which coins are spent and unspent.

Every underlying detail, however, is quite different.

Transactions Bitcoin Itself Ignores

A Shielded Bitcoin transaction is simply a blob of data carrying a prefix — something like "shbtc:" — embedded in a Bitcoin transaction via OP_RETURN, the witness field, or some other data-carrying method. This is the metaprotocol pattern: the protocol's rules are enforced by its own indexers rather than by Bitcoin, so the base chain sees nothing beyond ordinary data. The blob has no meaning to Bitcoin: the network does nothing to verify it and enforces no rules against it whatsoever.

As a result, it is perfectly possible for invalid Shielded Bitcoin transactions to wind up on-chain. It falls to a Shielded Bitcoin Indexer, which passively watches the blockchain, to ignore transactions that fail validation and refuse to apply them when updating the state of network balances.

Nullifiers Instead of a Spent Set

An indexer does not delete notes from an unspent note set the way Bitcoin removes spent UTXOs. Instead, it maintains a nullifier set. This mechanism lets a user publicly post an encrypted proof and a nullifier showing that a note has been spent without revealing which note was spent. Rather than checking whether a note sits in an "unspent note set," participants check whether a given nullifier has already been used.

Indexers build a merkle tree that grows forever and can only be added to, containing every note output ever created, alongside the nullifier set.

Running the Protocol Requires Only a Node

Using the protocol requires nothing more than a Bitcoin node and a Shielded Bitcoin indexer. No service, coordinator, or off-chain state is needed to recover funds. It works just like on-chain Bitcoin: all a user needs is their node/indexer and their keys.

Each user wallet derives a master secret key, from which every other set of keys involved is created — a design closely resembling an HD wallet in Bitcoin, from which many address sets can be generated. sk_spend serves as the spending private key, sk_nf is used to nullify note outputs, vk_in decrypts and views incoming notes, vk_out views outgoing transactions, and sk_view generates a receiving address.

When a user wants to hand someone an address for receiving funds, they generate a diversifier value d, similar to a derivation value, and multiply it against their sk_view key. The resulting public key pk_d, together with d, constitutes the user's address.

The sender then generates a random value, the r_seed, which is needed both for encrypting the note output and for nullification. Transaction outputs contain only three encrypted items: the value of the output, the d value the receiver gave the sender, and the sender's r_seed value. To encrypt, the sender uses a secret ephemeral key pair and the receiver's public key to create a shared secret — both parties can compute the same secret by multiplying their private key by the other party's public key. The note output is encrypted with this shared secret, and the ephemeral sk_eph is included unencrypted so the receiver can generate the shared secret themselves.

Zero-Knowledge Proofs Guarantee Validity

On the input side, two things are required for a transaction to be valid: a public nullifier for each note output consumed, and a zero-knowledge proof demonstrating that (1) the note output is included in the merkle tree of notes, (2) the transaction is authorized by the appropriate sk_spend key, (3) the nullifier is correctly derived, and (4) no inflation has occurred.

The nullifier incorporates the sk_nf key, a ρ value derived from the r_seed, and the position of the note in the merkle tree of note outputs. Although no one can tell which note output a nullifier corresponds to, the zero-knowledge proofs in every transaction guarantee that each nullifier added to the set came from a valid note output. Indexers can therefore simply reject repeated nullifiers rather than deleting spent notes, and as long as there are no repeats, the system provides the same double-spend guarantee.

The net effect is that encrypted metaprotocol transactions can be embedded on the Bitcoin blockchain still guaranteeing that nothing is being double-spent and that coins are not being inflated out of thin air.

Privacy Properties

According to the analysis, the system is well designed in terms of privacy properties and is on par with something like Zcash's shielded pools. The comparison sketches the broader landscape: Zcash delivers shielded transactions through rules built into its own protocol, whereas this design pursues comparable properties on Bitcoin's base layer without touching consensus. Privacy considerations that arise at the time of entering and exiting the metaprotocol are to be detailed in an upcoming paper release, leaving the system's entry and exit points among the details to watch as the work progresses. Unlike coinjoins, there is no concern about measuring privacy or the need for periodic remixing.

Pegging Funds With PIPEs v2

The intended peg relies on PIPEs v2, a witness encryption scheme. PIPEs allow a private key to be encrypted with a program or mechanism that will not divulge the key unless a ZK-proof is provided showing that a certain condition has been met — for example, the state of some UTXO, or that a transaction has been confirmed. This would let a peg function without an operator, a federation, or any third party custodying funds — a notable property, since peg designs extending Bitcoin have typically leaned on such custodians. It requires no soft forks or protocol changes to Bitcoin and occurs entirely off-chain.

The next phase of the team's work is a pegging mechanism that would allow users to deposit funds into Shielded Bitcoin using PIPEs cryptographically-controlled keys, which would then be "unlocked" by generating a ZK-proof of legitimate peg-out transactions confirmed on-chain. Work is currently ongoing on the paper defining this aspect of the system, which should be released in the near future; together with the entry/exit privacy paper, it will fill in the pieces the whitepaper leaves open.

---

This article, written by Shinobi, first appeared on Bitcoin Magazine.