Private Bitcoin Transactions Enabled by [[alloc] init]'s Shielded Bitcoin Proposal

This article was first published by Bitcoin Magazine.

Researchers Clara Shikhelman, Misha Komarov, and Aleksei Moskvin from [[alloc] init]] have introduced Shielded Bitcoin, a privacy metaprotocol designed for the Bitcoin base-layer. It enables shielded transactions without requiring operators, soft forks, or other consensus changes. The whitepaper is available at this link and the blog announcement at this link.

The protocol defines a transactional structure and an indexing protocol for strong privacy-preserving transactions. It leverages Bitcoin PIPEs to peg funds into and out of the system. More details on the PIPEs mechanism appear later in this article.

The system's design closely mirrors Bitcoin's: it has an equivalent to a UTXO called a note, transactions consume notes as inputs like standard Bitcoin transactions, a witness verifies that inputs are properly authorized, and nodes (acting as indexers for this metaprotocol) parse the transaction history to build a current state of spent and unspent coins.

The specifics, however, differ substantially.

A Shielded Bitcoin transaction is a data blob with a prefix (e.g., “shbtc:”) embedded in a Bitcoin transaction via OP_RETURN, the witness field, or another data-carrying method. The Bitcoin network does not verify or enforce any rules for these transactions. Invalid Shielded Bitcoin transactions can appear on-chain; a Shielded Bitcoin Indexer—a passive blockchain watcher—ignores those that fail validation and does not apply them to the network balance state.

An indexer does not delete notes from an unspent note set as Bitcoin does with UTXOs; instead it uses a nullifier set. This allows a user to publicly post an encrypted proof and nullifier that a note has been spent without revealing which note. Rather than checking an unspent note set, the system checks whether a nullifier has been used before. Indexers build an ever-growing merkle tree—append-only—of every note output created, along with the nullifier set.

Using the protocol requires only a Bitcoin node and a Shielded Bitcoin indexer. No service provider, coordinator, or off-chain state is needed for fund recovery. It operates similarly to on-chain Bitcoin, needing only the node/indexer and the user's keys.

A user's wallet derives a master secret key, from which all other key sets are generated.

This works much like an HD wallet in Bitcoin, enabling generation of multiple address sets. The sk_spend is the private key, sk_nf nullifies note outputs, vk_in decrypts and views incoming notes, vk_out views outgoing transactions, and sk_view generates a receiving address.

To provide an address for receiving funds, a user generates a diversifier value d (similar to a derivation value) and multiplies it with their sk_view key. The resulting public key pk_d, along with d, forms the user's address.

The sender generates a random r_seed value, needed for note output encryption and nullification. Transaction outputs contain only three encrypted components: the output value, the receiver's d value, and the sender's r_seed. The sender uses a secret ephemeral key pair and the receiver's public key to derive a shared secret. Both parties can compute the same secret by multiplying their private key with the other's public key. The note output is encrypted with this shared secret, and the ephemeral sk_eph is included unencrypted so the receiver can recreate the shared secret.

For a valid transaction on the input side, two elements are required: a public nullifier for the consumed note outputs, and a zero-knowledge proof demonstrating that (1) the note output is part of the merkle tree of notes, (2) the transaction is authorized by the correct sk_spend key, (3) the nullifier is properly derived, and (4) no inflation has occurred.

The nullifier uses the sk_nf key, the ρ value derived from r_seed, and the note's position in the merkle tree of outputs. The zero-knowledge proof covers all these elements, which is why counting nullifiers for duplicates can substitute for deleting spent notes. Although the specific note output tied to a nullifier remains unknown, the proofs in every transaction ensure each added nullifier stems from a valid note output. As long as there are no repeats, the system offers the same double-spend guarantee.

In essence, the protocol allows encrypted metaprotocol transactions to be embedded on the Bitcoin blockchain while ensuring no double-spending and preventing inflation.

The system is well-designed for privacy, comparable to Zcash's shielded pools. Privacy considerations exist when entering and exiting the metaprotocol, which will be detailed in a forthcoming paper. Unlike coinjoins, there is no need for periodic remixing or measuring privacy.

The peg is intended to be built using PIPEs v2, a witness encryption scheme. PIPEs enables encrypting a private key with a mechanism that only reveals the key upon provision of a ZK-proof that a condition has been satisfied (e.g., a UTXO state or transaction confirmation). This would allow the peg to operate without an operator, federation, or third-party custody.

This system requires no soft forks or changes to Bitcoin's protocol and operates entirely off-chain.

The next step for Shielded Bitcoin is a pegging mechanism that lets users deposit funds via PIPEs cryptographically-controlled keys. These funds would be "unlocked" by generating a ZK-proof of legitimate on-chain peg-out transactions.

Work on the paper detailing this aspect is ongoing and expected to be released soon.