Du kannst diesen Artikel auch auf Deutsch lesen.
In the first installment, we learned about the technical underpinnings of silent payments in general. Now it is time to take a closer look at silent payments in hardware wallets such as the BitBox.
We highly recommend reading the first part first, as this post builds upon the knowledge we built there, specifically about what private and public keys are and how silent payments work. As in the first part, we use lowercase letters for private keys, and uppercase letters for public keys. For example: A = a × G.
To re-cap, when Alice makes a silent payment to Bob, the transaction output to Bob is dynamically derived from Bob’s silent payment address and Alice’s private keys:
P = B_spend + hash(input_hash × S) × G
...where S is the shared secret. Alice’s hardware wallet can compute it with her private key a and Bob’s public key B_scan:
S = a × B_scan
Here, Alice takes B_spend and B_scan from Bob’s silent payment address, while a is the sum of the private keys she uses in the transaction.
Creating vs. signing transactions
The first thing to realize is how silent payments significantly change the role of hardware wallets when it comes to processing Bitcoin transactions.
In traditional payments, the host wallet (the software on your computer or phone such as the BitBoxApp) creates the transaction, and the hardware wallet (such as your BitBox02) simply verifies and signs it to approve.
With silent payments, this changes. The hardware wallet is now responsible not only for signing the transaction but also for generating part of it, specifically the transaction output to Bob. This is because Alice’s private keys are needed to generate Bob’s transaction output, and only her hardware wallet knows those private keys.
This shift introduces some new risks:
- Memory corruption: If the hardware wallet has a bug or memory issue, it could derive an incorrect output, which might send funds to an unusable address, effectively losing them.
- Malicious behavior: If the hardware wallet is compromised, it could create an output that directs funds to an attacker instead of Bob, without the host wallet noticing.
This problem can be elegantly solved by having the host wallet verify the correctness of the silent payment output generated by the hardware wallet.
This is conceptually similar to anti-klepto, which is another instance where the host wallet verifies that the hardware wallet does not misbehave.
Discrete-log equality proofs
How would the host wallet verify that the silent payment output generated by the hardware wallet is correct?
The host wallet cannot directly verify it, as it has no way of re-creating it by itself. It would need either Alice's private key a or Bob’s private key b_scan in order to be able to compute the shared secret S, but it doesn’t have access to either of those.
Instead, we make use of a cryptographic tool to allow the host to verify that the hardware wallet created the silent payment output correctly. The tool is called a Discrete-log equality (DLEQ) proof.
A Discrete Logarithm Equality (DLEQ) proof lets you show that the same private key a was used to generate two different public keys, even when using different "starting points" (known as base points).
The first public key is A1 = a × G, where G is a common base point (generator). The second public key is A2 = a × P2, where P2 is another base point. The proof ensures that both public keys come from the same private key a, without revealing the private key itself.
In simple terms, you're proving that the same secret (private key a) was used in both cases, even though different base points (G and P2) were used.
In technical terms, it is a proof that the discrete log of A to the base G is the same as the discrete log of A2 to the base P2.
Verifying correctness
The protocol to enable the host to verify the correctness of the generated silent payment output is then as follows:
The hardware wallet creates the silent payment output, and along with it a DLEQ proof that its private key a is the same secret in both A = a × G and in the shared secret S = a × B_scan.
Since both A and S are derived from the same private key a, the DLEQ proof ensures that the shared secret S is correctly generated using Alice’s private key.
The hardware wallet sends the generated silent payment output P, along with the DLEQ proof and the shared secret S, to the host wallet.
The host verifies the DLEQ proof using three things:
- The public key
Aas the sum of the public keys in the transaction inputs Alice is spending, B_scanfrom the silent payment address, andS, which is provided by the hardware wallet
If the proof checks out, the host can be confident that S is correctly calculated as a × B_scan, even without knowing the private key a.
The host wallet can now verify the silent payment output by independently re-computing it:
P = B_spend + hash(input_hash × S) × G
For this, the host wallet takes B_spend from the silent payment address, computes the input_hash independently from the transaction inputs, and uses the provided S, which was verified to be correct in the previous step.
If the re-computed silent payment output matches the one returned by the hardware wallet, the host wallet can safely proceed to finalize and broadcast the transaction knowing that the silent payment output is correct and hasn’t been corrupted.
Summary of the flow
- Alice’s hardware wallet creates the silent payment output and proves it used the correct private key using a DLEQ proof.
- The host wallet verifies the proof to ensure the shared secret was calculated correctly.
- The host wallet recomputes and verifies the silent payment output using the shared secret and known values from the transaction, and finalizes the transaction if everything checks out.
This approach ensures that the hardware wallet does not misbehave, either due to corruption or malicious activity.
Rollout
The feature to securely make silent payments, including the correctness check in the BitBoxApp as described in this article, will be released soon in the next BitBoxApp version 4.45 with BitBox02 firmware version 9.21.
The BitBox02 is the first hardware wallet to support making silent payments. It’s difficult for other wallets, exchanges, services, etc. to justify the effort of adding support for silent payment accounts if the broader ecosystem does not support sending to them. It’s a chicken & egg problem. We hope we can aid adoption of silent payments in this way.
Shoutout and a word on open source collaboration
We first learned about silent payments in a talk from the BIP authors josibake and Ruben Somsen at the BTC Azores unconference in 2023. The BIP itself has received an impressive amount of high quality reviews.
When we first drafted the implementation for the BitBox02, I started thinking about the risks mentioned above, and put out a tweet outlining my concerns. Josie, Ruben and Andrew Toth quickly pointed out DLEQ as a potential solution and linked me to some very useful reading material on the topic. The only missing piece was having a good and reviewed implementation of DLEQ.
When Andrew Toth started writing a draft BIP for specifying DLEQ, cryptographer Tim Ruffing recalled that an implementation already existed in the secp256k1-zkp code library, which the BitBox02 already relies on. It was provided by jesseposner in a different context, but luckily it turned out that this implementation was a good fit for silent payments as well.
Armed with test vectors from the BIP, the above DLEQ implementation, and a useful reference implementation (which we could not use directly as hardware wallets have different requirements), we were able to smoothly integrate support for this feature in the BitBox.
It is always a great feeling when so many people volunteer their time and effort to build something in the open, and it all comes together in the end.
Many thanks to Josie, Ruben, Andrew and many others for helping us complete this feature.
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.
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.