What are Confidential Transactions (CT)?

The first version of the concept, dubbed “bitcoins with homomorphic value,” was proposed in 2013 by Hashcash inventor and Blockstream co-founder Adam Back.

In 2015 the technology was first implemented in Blockstream’s sidechain Elements.

The concept was later developed by Bitcoin Core developer Gregory Maxwell.

Bitcoin does not provide full confidentiality. Because the blockchain is public, transaction-analysis tools can trace movements of funds and, in many cases, identify who is transacting.

This lack of privacy undermines fungibility and increases the risk of censorship. Exchanges and other services may block users because their coins were previously involved in illegal activity, even if the current owner is unaware of that history. Confidential Transactions can, in principle, mitigate these problems.

The technology introduces new address and transaction formats. A transaction format comprises a scriptPubKey, a Pedersen commitment scheme, and an ECDH (Elliptic-Curve Diffie–Hellman) nonce.

The scriptPubKey contains a Confidential Transaction Address (CTA) and a spending condition under which bitcoin may be spent only if ownership of the address’s private key is proven with a signature.

A Confidential Transaction Address is a hash of a blinding key plus a conventional bitcoin address.

The blinding key hides both the bitcoin address and the transaction amount in the public ledger. Possession of the blinding key also lets one see the bitcoin address and the amount within the confidential transaction.

A Pedersen commitment is a hash of the entire bitcoin output plus the blinding key.

The ECDH nonce is a key that allows the entire confidential transaction to be revealed. It is used to transmit encrypted data to the transaction’s recipient, who learns the bitcoin transaction output and the confidential transaction’s blinding factor.

Example of CTs in action.

Alice has two bitcoins and wants to send one to Bob.

After receiving Bob’s address, Alice creates a blinding key and combines it with the address into a single hash. This produces a confidential address. Although it is recorded on the public ledger, no one besides Alice and Bob knows that the confidential transaction address corresponds to Bob’s address.

Example of a confidential address:

CTEwQjyErENrxo8dSQ6pq5atss7Ym9S7P6GGK4PiGAgQRgoh1iPUkLQ168Kqptfnwmpxr2Bf7ipQsagi

Alice then creates a confidential transaction. Using the same blinding key and a one-bitcoin output, she forms a Pedersen commitment. The amount Alice sends to Bob is hidden from the public, yet both of them can see it because they each possess the public blinding key. Alice has it as the creator; Bob can derive it with the private key of his bitcoin address.

Next, Alice creates a scriptPubKey with the confidential transaction address she derived from Bob’s bitcoin address, together with a spending condition stating that one bitcoin can be spent if Bob proves control of the address’s private key with a signature.

The transaction is then recorded on the public ledger.

One key principle in Bitcoin is conservation of value: the amount of bitcoin credited to an address must equal the amount debited from it.

Because Confidential Transactions hide amounts, two issues arise:

• The usual way of computing fees by subtraction becomes impossible.
• The network cannot tell whether an output matches an input, making conservation of value unverifiable.

The first issue is easy to solve by making transaction fees publicly visible.

The second is addressed with Pedersen commitments.

Pedersen commitments have the distinctive mathematical property of homomorphism. A homomorphism preserves structure between two algebraic systems. This is effective for cryptography because it lets one commit to data and verify relations about it using simple algebraic operations such as addition—without revealing the underlying data itself.

Example:

Take a simple algebraic structure and “hash” values by multiplying by 2.

(a + b)*2 = a*2 + b*2

Assume a=1 and b=3.

(1+3)*2 = 1*2 + 3*2

4*2 = 2+6

If we replace the value of “a” on the left-hand side with another number, say 4, the algebraic structure no longer holds:

(a + b)*2 = a*2 + b*2

(4 + 3)*2 ≠ 1*2 + 3*2

Using the homomorphic property of Pedersen commitments, Confidential Transactions enforce conservation of value for bitcoin addresses.

Now apply this to Alice sending Bob one bitcoin. For simplicity, ignore fees.

Alice has a two-bitcoin Pedersen commitment for her confidential transaction. When Alice sends Bob one bitcoin, she uses a specific formula to create the commitment. She uses the same formula to send one bitcoin to a change address. We add the two commitments to check whether the result equals Alice’s original two-bitcoin Pedersen commitment. If it does, the commitment is a valid confidential transaction.

The protocol improves bitcoin’s privacy. Blinding keys mask bitcoin addresses and amounts, enhancing fungibility.

Blinding keys can also be shared for auditing: a payer or payee may grant a third party access to the blinding key for audit purposes.

While CTs hide transaction amounts, observers can still see sender and recipient addresses.

A potential workaround is to create false negatives by sending zero-amount outputs to multiple addresses to obscure the true destination.

CTs can also be combined with CoinJoin, which aggregates transaction outputs into one large transaction, hiding relationships between users from outside observers.

Another limitation is that CT hides the amount only for a specific transaction. If a subsequent transaction is not confidential, its data can be used to infer the amount of the earlier confidential transaction.

For example, if Alice sends Bob an unknown amount, and Bob later sends five bitcoins to Carol and two to himself as change, one can deduce that Alice sent Bob seven bitcoins.

Confidential Transactions are effective only if the technology is widely adopted.

• A confidential transaction’s data volume is roughly 20 times that of a regular transaction, tripling computational load. Fees for CTs will therefore be significantly higher, limiting the pool of potential users.
• The size of CTs conflicts with either scalability (the network processes fewer transactions), decentralisation (fewer users can run full nodes and verify everything), or both.
• It is unclear whether all users would accept making bitcoin more private and fungible. Lack of consensus could complicate the soft forks needed to implement the technology.

CTs are deployed in the commercial sidechain Liquid, developed by Blockstream. The technology lets Liquid users verify that received amounts do not exceed sent amounts.

In Liquid, among other things, this means funds can move between exchanges without revealing the amounts. Competitors cannot see exchange balances, and traders cannot exploit such information in markets, as they often can today: blockchain transparency enables those with knowledge of a large impending transaction to trade ahead of it.

A variant of CTs—Ring Confidential Transactions (Ring CT)—is used in Monero. Other adaptations appear in Bitshares and in the MimbleWimble protocol, which underpins Grin and Beam.

CTs could also be implemented in Bitcoin’s base layer. Several ideas exist for doing so via a backward-compatible soft fork, though such upgrades would still hurt scalability and are likely some way off.

Confidential Assets were invented by Blockstream developers Andrew Poelstra, Adam Back, Mark Friedenbach, Gregory Maxwell and Pieter Wuille.

The white paper on Confidential Assets was published on Blockstream’s website on April 3, 2017. The company announced Confidential Assets as a new option for the Sidechain Elements technology.

CTs use a Pedersen commitment that replaces the original transaction amount on-chain:

commitment = xG + a(H + rG)

Where a is the transaction amount, G and H are elliptic-curve generators. G is a constant. H represents the asset type and takes different values for different confidential assets. X and r are blinding factors.

They are set to different random values in each UTXO (unspent transaction output) to hide both the transaction amount and the asset type.

This model allows verification that inputs and outputs balance for each asset in every transaction. The verifier sees the commitment but not the amount or the asset type.

The sender transmits the amount and asset type to the recipient encrypted, either on-chain or off-chain in a p2p format, so that only the two parties know the details.

During asset issuance, transfer and burning, Zero-Knowledge Proofs (ZKP) are also required to prove that the amount and asset type are within acceptable ranges without revealing them. The proof for the asset type is called a Surjection Proof.

Implementation is possible only in a new blockchain or via a hard fork of an existing one.

Smart contracts cannot be added to this scheme, so one cannot customise the logic of Confidential Assets or build on-chain applications atop them. Developers can implement only limited logic via techniques such as Scriptless Script.

Technologies such as AZTEC, Zether, Anonymous Zether, PGC and Nightfall address this issue. In all of these, existing blockchain privacy schemes (zk-SNARK, MimbleWimble, etc.) are implemented with smart contracts. This model provides:

• Programmability: smart contracts modify the logic of issuance, burning, transfer and exchange, expanding the functions and attributes of Confidential Assets.
• Interoperability: Confidential Assets can interact with other contracts (tokens, auctions, voting), enabling more applications.

In the Elements project, Confidential Assets are applied to the Bitcoin network.

In Bitcoin-based implementations the transaction process is non-interactive—the recipient need not be online to receive a transaction. In MimbleWimble-based systems the process is interactive.

In Bitcoin-based Confidential Assets implementations, both parties’ addresses are visible, unlike in MimbleWimble-based systems.

The technology can also be implemented in systems based on the MimbleWimble protocol—Grin and Beam. Beam’s developers enabled this via the Eager Electron 5.0 hard fork in June 2020.