Bitcoin right now is not really anonymous. While Bitcoin addresses aren’t necessarily linked to real-world identities, they can be. Monitoring the unencrypted peer-to-peer network, analysis of the public blockchain, and Know Your Customer (KYC) policy or Anti-Money Laundering (AML) regulation can reveal a lot about who’s using Bitcoin, and for what.

This is not great from a privacy perspective. Bitcoin users might not necessarily want the world to know where they spend their money, what they earn or how much they own, while businesses may not want to leak transaction details to competitors – to name some examples.

Additionally, bitcoins being traceable, possibly “tainted,” and potentially worth less than other bitcoins is at odds with fungibility. This could even challenge Bitcoin’s value proposition as money.

But there are potential solutions to increase privacy, and improve fungibility.

One of these solutions is “Confidential Transactions.”

Background

As opposed to most digital financial infrastructure, all typical Bitcoin transactions are recorded on the public blockchain, visible for anyone to see. This is required to validate transactions without any centralized authority, but also makes it trivial to trace how many bitcoins are sent from which addresses to which addresses.

To enhance privacy, it is possible to hide the amount of bitcoins transacted. An early version of this concept, then referred to as “bitcoins with homomorphic value,” was first proposed in 2013 by hashcash inventor and current Blockstream president Dr. Adam Back. The idea was later picked up by Bitcoin Core and Blockstream developers Gregory Maxwell and Dr. Pieter Wuille and Blockstream mathematician Andrew Poelstra. This eventually led to the implementation of Confidential Transactions in Blockstream’s testnet-sidechain, Alpha.

How It Works

Confidential Transactions combine and utilize several cryptographic tricks, most notably Borromean ring signatures and Pedersen commitment schemes.

Without diving too deep into the cryptographic specifics, these tricks are applied so that only the sender and the receiver of a transaction are aware of the amount transacted. Everyone else would see only that bitcoins are transacted, but not know how many.

The clever thing is that, while some or all amounts are masked for “onlookers,” these onlookers can still use the masked amounts for certain types of calculations. Specifically, all inputs of a transaction can be added up, all outputs can be added up, and the two sums can be compared to ensure they’re equal ‒ all while never revealing any of the masked amounts, nor the sums. As such, nodes can verify that no bitcoins were created out of thin air, without knowing how many bitcoins were actually sent.

(On a side note, one of the amounts is always visible: the mining fee. That’s to ensure miners can’t award themselves too many fees, and has no further consequences from a privacy perspective. Other amounts can be made visible as well, if the sender or receiver so chooses.)

Soft Fork

Perhaps surprisingly, Confidential Transactions would be more or less compatible with the current Bitcoin-protocol. While the specifics need to be fleshed out, the solution can be rolled out as a soft fork ‒ though it might be a bit “hacky.”

Here’s how.

To ensure that “old” (non-upgraded) and “new” (upgraded) nodes would remain in sync, bitcoins used in a Confidential Transaction would first have to be “pass through” an “anyone-can-spend” address. This is a Bitcoin address that anyone can spend from, even without the corresponding private key or signature.

Or so it seems to old nodes.

New nodes would recognize the address as the first step in a Confidential Transaction, and would accept only transactions from that address that do include the correct signature. As long as a majority of hash power applies these rules, the bitcoins on the anyone-can-spend address cannot be stolen by anyone who doesn’t control the corresponding private key. (Old nodes might wonder why no one is spending the freely available bitcoins. But they also wouldn’t mind that no one does; from their perspective, no protocol rules are being broken.)

Here’s where it gets interesting.

If a Confidential Transaction is made from the anyone-can-spend address, both old nodes and new nodes see that transaction. But they see something different. New nodes would recognize the transaction as a Confidential Transaction, and, for example, check that there are no bitcoins created from thin air. Old nodes, meanwhile, would be tricked into thinking it’s a zero-bitcoin transaction: they would believe no bitcoins left the anyone-can-spend address at all.

This logic holds for each subsequent transaction. New nodes would see new transactions, and know that some amount of bitcoin is probably moved from address to address – though they’d have no idea how many. Old nodes, all the while, see “zero-bitcoin transactions,” and believe all the bitcoins are still sitting in the anyone-can-spend address. (Old nodes might wonder why people are sending empty transactions to each other. But again, they wouldn’t mind.)

The reason this won’t cause havoc (specifically due to incompatible UTXO-sets) is that bitcoins received through a Confidential Transaction can initially be spent only as a Confidential Transaction. They are “locked up” in the anyone-can-spend address for now, and cannot visibly move over the Bitcoin blockchain at all.

In order to be able to spend these bitcoins in a normal transaction again, they must first “pass through” the original anyone-can-spend address. The receiver of a Confidential Transaction would have to send them back to the anyone-can-spend address, and from there start moving the coins in clear sight on the blockchain again.

Once they start moving in clear sight again, new nodes would check that not too many coins are being moved, while old nodes would simply assume the coins are moving for the first time since they were “locked up.”

As such, the anyone-can-spend address effectively functions as a cloaking device. Passing through the anyone-can-spend address makes the amounts of subsequent transactions invisible to all nodes. The bitcoins would “re-appear” only after they’ve made it back to the original anyone-can-spend address.

Downsides and Trade-offs

Unfortunately, Confidential Transactions are no silver bullet for privacy.

Most obviously, while Confidential Transactions mask amounts, onlookers can still see which address is paying which address.

But there are potential solutions to solve this as well.

For one, it’s trivial to create false negatives and pay zero bitcoins to several addresses to obfuscate where the bitcoins really went. Additionally, Confidential Transactions could be particularly useful in combination with CoinJoin, which combines sending and receiving addresses from several transactions into a single, large transaction.

Another potential weakness of Confidential Transactions is that masked amounts are really only masked for that particular transaction. This can be rather pointless if a subsequent transaction is not a Confidential Transaction. The information from later transactions can sometimes be used to retroactively calculate how many bitcoins must have been involved in the Confidential Transaction.

(For example: If Alice sends an unknown amount of bitcoins to Bob, and Bob subsequently sends 5 bitcoins to Carol and 2 to himself as change, it obviously means Alice sent 7 bitcoins to Bob.)

This means that Confidential Transactions are really useful only if such use is widespread. But that brings us to a perhaps even bigger problem: Confidential Transactions are quite resource-heavy. A Confidential Transaction is about 20 times bigger than a normal transaction, while it even increases computation thirtyfold. As such, the cost of each Confidential Transaction would be significantly higher compared to typical transactions, which provides a disincentive to people actually using them – diminishing their usefulness for everyone else as well.

On top of that, the sheer size of Confidential Transactions puts them at odds with either scalability (as the Bitcoin network would be able to handle fewer transactions), or decentralization (as fewer users would be able to run a full node and verify all transactions), or both.

And last but not least: It’s not clear that everyone agrees Bitcoin should be more private or fungible, which might further complicate rolling out potential soft forks like these.

Thanks to Pieter Wuille, Adam Back and Monero lead developer Riccardo Spagni for information and added feedback.