Shielded Bitcoin represents a new framework introduced by [[alloc] init] investigators Clara Shikhelman, Misha Komarov, and Aleksei Moskvin regarding a novel privacy metaprotocol on the foundational Bitcoin layer, designed to facilitate confidential Bitcoin transfers completely free of intermediaries, soft forks, or consensus adjustments. The official whitepaper is accessible here alongside the initial blog announcement here.
The specification outlines a structural format and indexing mechanism for robust confidentiality-focused transfers, leveraging Bitcoin PIPEs for moving capital into and out of the ecosystem. Additional details regarding the PIPEs framework appear toward the conclusion of this write-up.
Its structural blueprint heavily mirrors Bitcoin itself; it features an equivalent to the UTXO known as a note, transfers spend notes as inputs similar to standard Bitcoin transactions, a witness verifies that the utilized inputs possess proper authorization, while nodes—operating as indexers in the context of a metaprotocol—process transaction history to establish the current state of spent versus unspent coins, and so forth.
Nevertheless, all underlying specifics diverge significantly.
A Shielded Bitcoin transfer manifests simply as a data payload appended with a prefix such as “shbtc:” embedded within a Bitcoin transaction through OP_RETURN, the witness parameter, or alternative data-storage techniques. The Bitcoin network assigns zero meaning to it, performs no verification routines, and enforces no constraints whatsoever against it. Flawed Shielded Bitcoin transfers can successfully land on the blockchain, leaving it up to a Shielded Bitcoin Indexer monitoring the ledger passively—essentially acting as a node—to disregard those erroneous entries during validation and omit them from updating the network balance ledger.
Rather than eliminating notes from an unspent collection the way native Bitcoin handles UTXOs, an indexer utilizes a nullifier collection. This mechanism allows a participant to broadcast an encrypted proof and nullifier indicating that a specific note was spent without disclosing the identity of the note in question. Consequently, instead of verifying whether a note resides within the unspent note registry, the system checks whether a particular nullifier has previously been activated. Indexers construct an append-only Merkle tree that expands continuously, cataloging every created note output followed by the nullifier registry.
Interacting with this architecture requires only a standard Bitcoin node and a Shielded Bitcoin indexer. There is zero reliance on service providers, intermediaries, or off-chain state dependencies to recover assets. Operation mirrors standard on-chain Bitcoin, requiring solely your personal node, indexer, and cryptographic keys.
Every individual wallet derives a master secret key that serves as the root for all supplementary key hierarchies.
Consider this architecture similarly to hierarchical deterministic wallets in Bitcoin. Multiple address derivations stem from this foundational relationship. The sk_spend serves as your signing private key, sk_nf invalidates note outputs, vk_in decrypts and inspects incoming notes, vk_out reviews outbound activity, and sk_view establishes a valid deposit address.
Whenever a participant wishes to share an address to receive capital, they generate a diversifier parameter d comparable to a derivation index, and multiply that figure against their sk_view key. The resulting public key, designated as pk_d alongside d, constitutes the user’s receiving address.
The originator subsequently creates a randomized value, termed r_seed, which remains critical for both encrypting note outputs and generating nullifiers. Transaction outputs encapsulate precisely three encrypted components: the output value, the receiver-provided d parameter, and the sender’s r_seed data. The sender establishes a shared secret by combining an ephemeral secret key-pair with the recipient’s public key. Both participants independently derive an identical secret by multiplying their local private key with the counterpart’s public key. The note output undergoes encryption via this shared secret, while the ephemeral sk_eph is appended unencrypted so the recipient can successfully reconstruct the shared secret.
Regarding inputs, valid transactions necessitate two primary elements: a public nullifier for the consumed note outputs, and a zero-knowledge proof verifying that 1) the note output exists within the Merkle tree of notes, 2) the transaction holds authorization from the correct sk_spend key, 3) the nullifier was derived accurately, and 4) zero monetary inflation has transpired.
As observed in the visual above, the nullifier incorporates the sk_nf key, the ρ value computed from r_seed, and the index position of the note within the note output Merkle tree. Zero-knowledge proofs validate these parameters, explaining why tracking duplicate nullifiers suffices instead of deleting spent notes. Although the exact note output linked to a given nullifier remains masked, the zero-knowledge proofs embedded within every transaction guarantee that each added nullifier originates from a legitimate note output. Provided there are no duplicate occurrences, this mechanism yields identical double-spend protections.
Ultimately, the protocol successfully embeds encrypted metaprotocol transactions directly onto the Bitcoin ledger while preserving rigorous mathematical guarantees against double-spending and unauthorized currency creation from nothing.
This framework exhibits exceptional architectural quality regarding privacy characteristics, aligning closely with established models like Zcash shielded pools. Specific privacy considerations arise during entry and exit phases of the metaprotocol, which subsequent documentation will address comprehensively. Concerns regarding privacy metrics or scheduled mixing sessions inherent to coinjoins do not apply here.
Regarding the bridging mechanism, developers intend to construct a peg utilizing PIPEs v2, a specialized witness encryption architecture. PIPEs enable participants to encrypt a private key using a programmatic construct that withholds the key unless accompanied by a zero-knowledge proof verifying a specific precondition—such as the state of a particular UTXO or the confirmation status of a transaction. This design empowers a peg to operate entirely without central operators, federated committees, or third-party custodial entities.
This implementation demands zero soft forks or alterations to the core Bitcoin protocol, functioning strictly off-chain.
The roadmap for Shielded Bitcoin centers on a pegging mechanism enabling users to allocate funds into Shielded Bitcoin utilizing cryptographically secured keys managed by PIPEs, which subsequently unlock upon generating zero-knowledge proofs confirming legitimate peg-out transactions settled on-chain.
Active research continues on drafting the formal paper outlining this component of the ecosystem, anticipated for publication in the near future.
Originally published at https://bitcoinmagazine.com/technical/alloc-init-releases-shielded-bitcoin-proposal-for-private-bitcoin-transactions.
