Shielded Bitcoin is a proposal put forward by [[alloc] init] researchers Clara Shikhelman, Misha Komarov, and Aleksei Moskvin for a novel privacy metaprotocol on the Bitcoin base-layer to enable shielded Bitcoin transactions without requiring operators, soft forks or other changes to Bitcoin consensus. You can find the whitepaper here and blog announcement here.
The protocol defines a transactional structure and indexing protocol for strong privacy-preserving transactions, while relying on Bitcoin PIPEs for pegging funds into and out of the system. More on the PIPEs mechanism at the end of the article.
Its design is very much a mirror of Bitcoin’s; there is an equivalent to a UTXO (a note), transactions consume notes as inputs like a regular Bitcoin transaction, a witness proves that the inputs consumed are properly authorized, nodes (indexers in the case of a metaprotocol) parse the transaction history and build a current state of what coins are spent and unspent, etc.
All of the details however are quite different.
A Shielded Bitcoin transaction is just a blob of data with a prefix (something like “shbtc:”) included in a Bitcoin transaction using OP_RETURN, the witness field, or some other data carrying method. It has no meaning to Bitcoin, the Bitcoin network does nothing to verify it, or enforce any rules against it whatsoever. It is perfectly possible for invalid Shielded Bitcoin transactions to wind up on-chain, and it is the job of a Shielded Bitcoin Indexer, that passively watches the blockchain, (read: node) to ignore those transactions when they fail validation, and refuse to apply them to updating the state of network balances.
An indexer doesn’t delete notes from an unspent note set like Bitcoin does with UTXOs. It uses a nullifier set. This is a way for a user to publicly post an encrypted proof and nullifier that a note has been spent without revealing which note has been spent. The idea is that rather than seeing if a note is in the “unspent note set”, you check and see if a nullifier has already been used. Indexers build a merkle tree that grows forever, and can only be added to, of every note output created, and then the nullifier set.
To use this protocol, all you need is a Bitcoin node and a Shielded Bitcoin indexer. There is no need for a service provider, coordinator, or any off-chain state to recover funds. It works just like on-chain Bitcoin, all you need is your node/indexer and your keys.
Each user wallet derives a master secret key, from which every other set of keys involved is created.
Think of this in a very similar manner to an HD wallet in Bitcoin. You can generate many address sets with this relationship. Sk_spend is your private key, the sk_nf is used to nullify note outputs, the vk_in is used to decrypt and view incoming notes, the vk_out to view your outgoing transactions, and the sk_view is used to generate a receiving address.
When a user wants to give an address to someone to send them funds, they generate a diversifier value d similar to a derivation value, and then multiply the value against their sk_view key. That resulting public key, pk_d and d are the user’s address.
The sender then generates a random value, the r_seed, which is necessary for the note output encryption as well as nullifying (we’ll get there in a second). 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’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 of the picture, two things are needed to have a valid transaction: a public nullifier for the note outputs consumed, and a zero-knowledge proof proving 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.
If you notice in the image above the nullifier uses the sk_nf key, the ρ value derived from r_seed, and the position of the note in the merkle tree of note outputs. The zero-knowledge proof ensures all of this is why you can simply count nullifiers for repeats instead of deleting spent notes. Even though you never know what 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. As long as you have no repeats it provides the same double-spend guarantee.
So there it is, the protocol enables you to essentially embed encrypted metaprotocol transactions on the Bitcoin blockchain, but still provide a guarantee that nothing is being doublespent and that coins are not being inflated out of thin air.
This is actually a very well designed system in terms of privacy properties, and is on par with something like Zcash shielded pools. There are privacy considerations to take into account at the time of entering and exiting the metaprotocol, and these are to be detailed in an upcoming paper release. There isn’t any concern of measuring privacy or periodic remixing like with coinjoins.
So, the peg. The intent is to build a peg using PIPEs v2, a witness encryption scheme. PIPEs allow you to encrypt a private key with a program/mechanism that will not divulge the key unless you can provide a ZK-proof that a certain condition has been met (i.e. the state of some UTXO, that a transaction has been confirmed, etc.). This would allow a peg to function without an operator, federation, or any third party custodying funds.
This requires no softforks or protocol changes to Bitcoin, and occurs entirely off-chain.
The plan with Shielded Bitcoin, and the next part of their work, is a pegging mechanism allowing 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, and should be released in the near future.
