A research proposal called Shielded Bitcoin describes private, bitcoin-denominated transfers whose data would be published on Bitcoin without changing Bitcoin’s consensus rules. The design borrows the note, nullifier, and zero-knowledge proof model associated with shielded payment systems, but places its state machine above the base protocol.
What Bitcoin would record
In the proposed system, value is represented by encrypted notes. A transfer envelope contains encrypted outputs, public nullifiers that mark spent notes, and a proof covering conditions such as authorization, note membership, and conservation of value. The note amount and recipient data do not appear in plaintext.
Bitcoin would provide publication and ordering for those envelopes. The paper does not ask Bitcoin nodes to maintain the shielded note tree or nullifier set. Compatible implementations would reconstruct that state by replaying accepted envelopes in Bitcoin order. This division avoids a consensus change, but it also means ordinary Bitcoin validation and shielded-transfer validation remain distinct processes.
The paper specifies deterministic replay assumptions so correct implementations can derive the same state from the same deployment profile, initial state, and active Bitcoin history. A complete deployment still needs shared choices for parameters, serialization, proof systems, activation state, and other profile details.
Privacy has a defined boundary
The intended transfer hides the amount, sender, recipient, and direct position in the transfer graph. It does not hide every observable feature. Timing, the number of inputs and outputs, transaction grouping, Bitcoin fees, and carrier-transaction metadata remain public. Fee-wallet reuse or recognizable transaction patterns could create links outside the encrypted note system.
The key hierarchy separates spending authority from incoming viewing, outgoing recovery, and nullifier derivation. The paper also outlines selective disclosure tools. A holder could grant limited visibility or produce a report without handing over a spending key. The authors caution that read access alone does not prove ownership, completeness, or total balance.
The transfer layer is only part of the system
The paper calls the transfer layer non-custodial because users retain spending authority over their notes. It expressly limits that claim: the mechanisms for moving BTC into and out of the shielded system, known as peg-in and peg-out, fall outside the paper’s transfer-layer specification. Those boundary mechanisms determine how shielded units are backed and redeemed, so they are essential to evaluating any eventual implementation.
The design also uses a trusted setup for its current proof construction. Its security depends on the setup assumptions and on the correctness of wallets, indexers, replay logic, cryptography, and deployment parameters. Avoiding a soft fork removes one form of coordination; it does not remove software risk or the need for independent review.
A specification, not a launch
Shielded Bitcoin is best read as a technical specification for a metaprotocol rather than a privacy feature already enforced by Bitcoin. It maps out how encrypted notes could use Bitcoin as an ordering layer and states what would remain visible. The unresolved deployment profile and out-of-scope bridge components separate the paper’s transfer model from a production payment system.
Source: BTCUSA.