Du kannst diesen Artikel auch auf Deutsch lesen.
We are proud to announce that the BitBox02 is the first hardware wallet that can safely perform Bitcoin silent payments. In this blog post series, we want to show you how silent payments work, and what the BitBox02 is doing under the hood to make sure these payments are performed securely.
Support for sending to silent payment addresses will be made available to all BitBox02 users in a future update.
- Part I explains how silent payments work in general
- Part II will show interesting insights into what your BitBox02 does under the hood in order to support silent payments in a secure manner
Silent payments is a BIP (Bitcoin improvement proposal) for a new Bitcoin address format. The main benefit of it is that it is a static address. It removes the need to manage multiple addresses, while still preserving privacy. If you want to learn more about the basics of this concept, check out our previous article on reusable payment codes.
Currently, to maintain privacy, a recipient must interact with a sender to give them a new fresh address for every transaction. This leads to a bad user experience or operational difficulties.
For example:
- Withdrawing from an exchange: for every withdrawal you should to get a new unused receive address from the BitBoxApp, register the new address at the exchange and verify it's the correct address on the BitBox and on a second device
- Depositing to an exchange: for every deposit, you should to create a fresh deposit address at the exchange and verify it on a second device and on your BitBox before sending the coins
- Collecting donations: you need to setup and operate a server like BTCPay Server to create new addresses for every donor
Many Bitcoin services and users avoid the above complexities by reusing a single address, compromising their privacy, as all transactions related to this address can easily be identified and analyzed.
Silent payments aim to solve these challenges. They use static addresses intended to be reused, while transactions made to them can only be identified by the sender and the recipient. Charities could post their donation address publicly on their website without anyone being able to tell who donated, or how much. Exchanges could register your single silent payment address for all withdrawals.
Transactions today
A Bitcoin transaction is made up of inputs and outputs.
The outputs create new UTXOs (unspent transaction outputs), and the inputs spend existing UTXOs. If you want to learn more about what UTXOs are, check out our blog post on the topic.
Most commonly, a UTXO is locked with a single public key, and spent by providing a signature created with the corresponding private key. When you send bitcoin to an address, traditionally the address encodes a public key (or the hash of a public key).
Silent payments use some interesting cryptographic techniques to derive a fresh, unused public key for each transaction that sends to a silent payment address. Now let's build up some knowledge and intuition for how this works. The below serves as a simplified, high level description of how silent payments work. For the full details, please refer to the official proposal.
A mini primer: private keys, public keys
A private key is simply a large number, large enough that it cannot be guessed, for example:
92193805913277071008055984303319191614197341949664602874511898854633635443214
For each private key, there is a corresponding public key. Knowing a public key alone does not reveal any information about its private key.
The public keys are technically part of a mathematical group, where addition has a special meaning. If you want to learn more about this, an excellent introduction to this topic can be found in the blog series “Elliptic Curve Cryptography: a gentle introduction”.
The formula to derive a public key from a private key is:
PublicKey = privateKey×G ,
where G is some predefined value called the generator. The generator is a special public key. Every other public key can be generated from it by addition.
For example, if your private key is 2, your public key is 2×G = G + G. If your private key is 3 your public key is 3×G = G + G + G, and so on. Of course, in practice, your private key would be a large number that cannot be guessed, like the example above.
Apart from division being impossible here (otherwise you could compute the private key from the public key!), most of the usual maths works the same way. Familiar laws like the distributive law hold:
(a + b)×G = a×G + b×G
In the remainder of this post, we use lowercase letters for private keys, and uppercase letters for public keys. For example: a×G = A.
Elliptic-Curve Diffie-Hellman
Elliptic-Curve Diffie-Hellman (ECDH) is a simple protocol to create a shared secret between two parties, Alice and Bob.
Let's say Alice wants to make a transaction to Bob.
- Alice has a private/public keypair:
a×G = A. - Bob has a private/public keypair:
b×G = B.
They can create a secret that only they know without communicating anything except their public keys.
- Alice computes the shared secret as
S = a×B. - Bob computes the shared secret as
S = b×A.
You can see that both values are the same by replacing B = b×G and A = a×G:
S = a×B = a×(b×G) = a×b×G = b×a×G = b×(a×G) = b*A = S.
S=(a×b)×G is technically a public key of the private key a×b and could be used in a transaction output to send bitcoin to it, but it would then be spendable only by combining both Alice's and Bob's private keys.
To avoid sharing private keys, it can however be interpreted as a new private key by hashing it:
s = hash(S). The coins sent to the silent payment address could then be locked by the public key P = hash(S)×G = hash(a×B)×G = hash(b×A)×G.
The coins locked by this public key would still be spendable by either sender Alice (using her private key a) or recipient Bob (using his private key b). How can we lock the coins so that only Bob can spend them? Let’s find out.
Silent payments
A silent payment address has the sp1 prefix (not the familiar bc1 prefix) and looks for example like this:
sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv
It is quite long, as it encodes not one but two public keys of the recipient: a public key B_scan for scanning, and a public key B_spend for spending. The additional public key is used to lock the coins in a way that only Bob can spend them.
Instead of using the public key P = hash(S)×G to lock the coins, Alice adds Bob's second public key: P = B_spend + hash(S)×G. She computes the shared secret S by using Bob’s scan public key and her private key: S=a×B_scan.
Alice can create this public key P as she knows B_spend and B_scan from Bob's silent payment address, and she knows her private key a.
The resulting public key P is added as a Taproot output to the transaction.
Only Bob can spend these coins by using his own two private keys b_spend and b_scan. To spend the coins, the private key p of the public key P must be known.
P = B_spend + hash(S)×G
Replace B_spend = b_spend×G:
P = b_spend×G + hash(S)×G
By the distributive law (a + b)×G = a×G + b×G, this is equivalent to:
P = (b_spend + hash(S))×G
So the resulting private key for Bob to spend the coins is:
p = b_spend + hash(S).
Bob can compute the hash of the shared secret S by using his scan private key:hash(S)=hash(b_scan×A), and produce the final private key by adding b_spend to it.
Which private key does Alice use? How does Bob know her public key?
Alice, who wants to send coins to Bob, knows Bob’s public keys as they are encoded in Bob’s silent payment address.
But what about Alice’s keys? How does Bob know Alice’s public key to re-create the shared secret, allowing him to detect payments made to his silent payment address and spend the coins? It would be inconvenient if the recipient needed to interact with each sender to receive their public keys. The solution is quite elegant: the relevant keys are all attached to the transaction itself!
Alice spends her own UTXOs in a transaction to Bob, which are already locked with a private/public keypair. She needs her private keys to spend her coins anyway, so why not use them to create the shared secret too?
Alice can compute the shared secret used in the silent payment by using the private keys of her existing UTXOs that she uses in the transaction as inputs.
Bob can compute the shared secret by using Alice’s public keys, which are attached to the transaction inputs.
A transaction can spend many inputs at once, so Alice uses a combined private key which is the sum of all the inputs’ private keys:
a = a_1 + a_2 + …
And Bob uses Alice’s combined public key by summing the public keys of the transaction inputs:
A = A_1 + A_2 + …
The sum of the private keys is the private key of the sum of the public keys, again due to the distributive law:
A = (a_1 + a_2 + …)×G = a_1×G + a_2×G + … = A_1 + A_2 + …
For silent payments to work, each input must be associated with exactly one public key. As a result, the only inputs allowed in silent payment transactions are the following: P2TR (key spends), P2WPKH, P2WPKH-P2SH and P2PKH, or in other words: the single-signature script types, which currently are the most common ones. Unfortunately, if Alice is using a native multisig account (ignoring MuSig2 and other aggregation schemes that result in a single public key) or some other account that uses advanced scripting, she cannot make silent payments. I consider this a large downside of silent payments and a big obstacle to their adoption.
Guaranteeing that addresses are not reused
The main goal of silent payments is to avoid reusing addresses / public keys. By the above scheme, the public key of the recipient is created dynamically from Alice’s keys in the transaction inputs and Bob’s silent payment address. If, however, Alice herself only ever reused one address, then multiple transactions she will make to Bob’s silent payment address could end up using the same input key and as a result produce the same output public key.
To fix this, instead of computing the output key like:
P = B_spend + hash(S)×G
Instead, it is computed as:
P = B_spend + hash(input_hash×S)×G
Where input_hash = hash(outpoint || A), the hash of the outpoint of one of the transaction’s inputs. An outpoint is a transaction ID together with an output index, uniquely identifying a UTXO from a previous transaction. Because UTXOs cannot be double-spent in Bitcoin, including the hash of a UTXO identifier is guaranteed to result in a unique output public key, as no two UTXOs can have the same identifier. A is included in the hash due to a technicality described in the BIP.
In an initial draft of the proposal, the input hash was computed over all the transaction inputs, sorted lexicographically. In my review of the draft, I commented that this is problematic for hardware wallets (click “Show resolved” to expand the thread):
This is problematic for hardware wallets. Hardware wallets are constrained in memory and may not be able to load all outpoints and sort them. As a result, they would have to restrict transactions to already have sorted inputs at signing time, which is not desirable and would lead to compatibility issues.
Maybe instead of using the hash of the sorted outpoints, we could use something like: [...]
In the resulting discussion involving many participants, a solution was found that satisfies the requirements and is feasible for hardware wallets to implement: hashing only one input, the smallest one when ordered lexicographically. This ended up in the final version of the BIP and enabled us to implement support for silent payments in the BitBox02 without friction.
Summary
We introduced the concept of silent payments, a Bitcoin improvement proposal for a new Bitcoin address format that allows for static addresses to be reused while maintaining privacy. We covered the basics of private keys, public keys, and discussed the process of creating a shared secret using elliptic-curve Diffie-Hellman (ECDH) and how this can be used to lock coins in a way that only the recipient can spend them.
In the next installment, we will take a look at how silent payments change the role of hardware wallets, and we will dive deep into what hardware wallets have to do in order to support silent payments securely.
Don’t own a BitBox yet?
Keeping your crypto secure doesn't have to be hard. The BitBox02 hardware wallet stores the private keys for your cryptocurrencies offline. So you can manage your coins safely.
The BitBox02 also comes in a Bitcoin-only version, featuring a radically focused firmware: less code means less attack surface, which further improves your security when only storing Bitcoin.
Frequently Asked Questions (FAQ)
What are silent payments?
Silent payments are a Bitcoin improvement proposal that introduces a static address format, allowing for reusable addresses while preserving privacy by deriving unique public keys for each transaction.
Why are silent payments beneficial?
Silent payments simplify the process of maintaining privacy in Bitcoin transactions by removing the need for recipients to generate fresh addresses for every transaction, thus improving the user experience and operational efficiency.
How do silent payments improve privacy?
Silent payments allow recipients to use static addresses without revealing transaction details, as only the sender and recipient can identify specific transactions, preserving privacy.
How does elliptic-curve Diffie-Hellman (ECDH) play a role in silent payments?
ECDH helps generate a shared secret between the sender and recipient, which is used to create a unique public key for each transaction, allowing for secure and private payments.
Can I reuse a silent payment address?
Yes, silent payment addresses are designed for reuse. Each transaction automatically generates a unique public key, so even though the address remains static, privacy is maintained.
What does BitBox02 do to support silent payments?
BitBox02 performs cryptographic operations securely under the hood, ensuring that silent payments are conducted safely, with unique public keys for each transaction, and support for this will be added in a future update.
Shift Crypto is a privately-held company based in Zurich, Switzerland. Our team of Bitcoin contributors, crypto experts, and security engineers builds products that enable customers to enjoy a stress-free journey from novice to mastery level of cryptocurrency management. The BitBox02, our second generation hardware wallet, lets users store, protect, and transact Bitcoin and other cryptocurrencies with ease - along with its software companion, the BitBoxApp.