[alloc] init Releases a Proposal for Private, Shielded Bitcoin Transactions

[[alloc] init] Releases Shielded Bitcoin Proposal for Private Bitcoin Transactions

Researchers at [[alloc] init], Clara Shikhelman, Misha Komarov, and Aleksei Moskvin, have released a proposal for Shielded Bitcoin, a privacy metaprotocol on the Bitcoin base-layer. The proposal describes shielded Bitcoin transactions without requiring operators, soft forks, or other changes to Bitcoin consensus. It was published with a whitepaper and a blog announcement, and the report first appeared on Bitcoin Magazine, written by Shinobi.

A Bitcoin-like structure carried by Bitcoin transactions

Shielded Bitcoin defines a transactional structure and indexing protocol for strong privacy-preserving transactions. It relies on Bitcoin PIPEs for pegging funds into and out of the system.

The design mirrors Bitcoin in several ways. It has an equivalent to a UTXO, called a note. Transactions consume notes as inputs, like a regular Bitcoin transaction. A witness proves that the consumed inputs are properly authorized. Nodes, in the case of a metaprotocol indexers, parse the transaction history and build a current state of what coins are spent and unspent.

The details differ substantially. A Shielded Bitcoin transaction is a blob of data with a prefix, something like shbtc:, included in a Bitcoin transaction using OP_RETURN, the witness field, or another data carrying method. It has no meaning to Bitcoin. The Bitcoin network does nothing to verify it or enforce any rules against it. Invalid Shielded Bitcoin transactions can wind up on-chain. A Shielded Bitcoin indexer passively watches the blockchain, ignores those transactions when they fail validation, and refuses to apply them to updating the state of network balances.

Tracking notes without deleting them

An indexer does not delete notes from an unspent note set the way Bitcoin deletes UTXOs. Instead, it uses a nullifier set. A user can publicly post an encrypted proof and nullifier showing that a note has been spent without revealing which note was spent. Rather than checking whether a note remains in the unspent note set, the system checks whether a nullifier has already been used.

Indexers build a merkle tree that grows forever, can only be added to, and contains every note output created. They also build the nullifier set.

Keys, addresses, and recovery

To use the protocol, a user needs a Bitcoin node and a Shielded Bitcoin indexer. There is no need for a service provider, coordinator, or off-chain state to recover funds. It works like on-chain Bitcoin: the user needs the node or indexer and the keys.

Each user wallet derives a master secret key, from which every other set of keys involved is created. This is similar to a Bitcoin hierarchical deterministic wallet. Many address sets can be generated through this relationship.

The private spending key is Sk_spend. The sk_nf key is used to nullify note outputs. The vk_in key is used to decrypt and view incoming notes. The vk_out key is used to view outgoing transactions. The sk_view key is used to generate a receiving address.

When a user wants to give an address to someone for a payment, the user generates a diversifier value, d, similar to a derivation value, and multiplies that value against the sk_view key. The resulting public key, pk_d, and d together form the user’s address.

Encrypted outputs and zero-knowledge input proofs

When a sender creates a transaction, the sender generates a random value, r_seed, which is needed for note output encryption and for nullifying. Transaction outputs contain only three encrypted things: the value of the output, the d value the receiver gave the sender, and the sender’s r_seed value.

The sender uses a secret ephemeral key-pair and the receiver’s public key to create a shared secret. Both parties can generate the same secret by multiplying their private key by the other party’s public key. The note output is encrypted using this shared secret, and the ephemeral sk_eph is included unencrypted so the receiver can generate the shared secret.

On the input side, a valid transaction needs two things: a public nullifier for the consumed note outputs, and a zero-knowledge proof. The proof must show four things. First, the note output is included in the merkle tree of notes. Second, the transaction is authorized by the appropriate sk_spend key. Third, the nullifier is correctly derived. Fourth, no inflation has occurred.

The nullifier uses the sk_nf key, a rho value derived from r_seed, and the position of the note in the merkle tree of note outputs. The zero-knowledge proof is what allows the system to count nullifiers for repeats instead of deleting spent notes. A user never knows what note output a nullifier corresponds to, but the proofs in every transaction guarantee that each nullifier added to the set came from a valid note output. As long as there are no repeated nullifiers, the system provides the same double-spend guarantee.

Privacy properties and remaining questions

The protocol embeds encrypted metaprotocol transactions on the Bitcoin blockchain while still providing a guarantee that nothing is being double-spent and that coins are not being inflated out of thin air.

The design is strong in terms of privacy properties and is on par with something like Zcash shielded pools. There are privacy considerations at the time of entering and exiting the metaprotocol. These are to be detailed in an upcoming paper release. There is no concern of measuring privacy or periodic remixing like with coinjoins.

Pegging funds through Bitcoin PIPEs

The peg is intended to use 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 zero-knowledge proof shows a certain condition has been met. The condition could be the state of some UTXO or that a transaction has been confirmed.

This would allow a peg to function without an operator, federation, or any third party custodying funds. It requires no softforks or protocol changes to Bitcoin and occurs entirely off-chain.

The next part of the work is a pegging mechanism allowing users to deposit funds into Shielded Bitcoin using PIPEs cryptographically-controlled keys. Those funds would then be unlocked by generating a zero-knowledge proof of legitimate peg out transactions confirmed on-chain.

Work is currently ongoing on the paper defining this aspect of the system, and it should be released in the near future.