BIP352: The Present and Future of Silent Payments

Author: Anony

"Silent Payments" is a solution proposed to achieve static payment identifiers while taking into account privacy requirements. Using it, the payment recipient only needs to disclose a stable and unchanging identifier (which can be regarded as a special address), and the sender will create a new non-repeating Bitcoin address for the recipient during the payment sending process.

This article attempts to explain its basic concepts, the first Bitcoin enhancement proposal for silent payments, BIP352 ^[5] , and looks forward to the adoption of silent payments based on the specifications of BIP352.

Basic Concepts of Silent Payment

To understand the concept of silent payment, let’s first review the payment process of Bitcoin “on-chain” (that is, using blockchain as the transaction confirmation method):

1. Alice tries to pay Bob, so she asks Bob for a Bitcoin script that Bob can use (an address is a compact, error-proof representation of such a script ^[1] );
2. Bob replies to Alice with an address;
3. Alice copies the address into her Bitcoin wallet software, adds other transaction details, and broadcasts the transaction to get blockchain confirmation.
4. When Bob's software receives a new block, it scans for matching transactions based on the information stored by Bob (such as addresses); if there is a match, it stores the transaction information and marks the related transaction output as funds that it can use.

This process is related to the following points:

1. Privacy. If Bob gives an address that has already been used, it increases the risk of the address being "deanonymized" - the real owner of the address can be detected by a third party. This habit of compromising privacy is called "address reuse", and the more it is reused, the greater the risk of deanonymization.
2. Interactivity. In the above process, Bob interacts with Alice and provides her with an address. It can be seen that this interaction is a hassle to a certain extent, but considering privacy, its value is obvious: Bob can use this opportunity to provide a new address and avoid address reuse.
3. Backup convenience. As long as Bob does not spend the payment immediately after receiving it, the bitcoin will stay in his address, which creates the need to back up the key information of the address. Considering privacy, Bob should generate a new address for each new payment, but how to back it up conveniently?

In the current Bitcoin custody scheme, the BIP-32 hierarchical deterministic wallet scheme solves the above-mentioned contradiction between privacy and backup convenience ^[2] : the keys used by Bob are all derived from the same seed through certain steps; since these keys have the same source, Bob only needs to back up the seed (at most a very small amount of derivation step information needs to be backed up additionally); and since the derivation step is one-way, a third party cannot infer from the public keys of these keys that they belong to the same source, which also well guarantees privacy.

The only unsatisfactory part is that the interaction requirement still exists. Each payer must first establish communication with Bob and obtain a new address before initiating payment. Is there a way to achieve a static payment identifier (address) without sacrificing privacy?

Ruben Somsen, the originator of the silent payment concept, once discussed possible solutions in a speech ^[3] . Silent payment is one of them and shows a special (somewhat radical) trade-off: eliminating the need for interaction by increasing the scanning burden on the recipient Bob (that is, the complexity of the fourth step of the payment process mentioned above).

Silent payments use a concept called “Diffie–Hellman key exchange” (which is the same age as the concept of “public key cryptography”! ^[4] ): if Alice and Bob each have a public-private key pair, then they only need to know the other’s public key to obtain a shared secret that only they know with a simple operation: multiplying their own private key by the other’s public key.

Because of the mathematical relationship between private and public keys, when Alice multiplies her private key by Bob's public key, the resulting value will be the same as the value obtained by Bob multiplying his private key by Alice's public key.

Let's take the public and private keys based on elliptic curves as an example. Alice's public key A is obtained by performing point multiplication on private key a and elliptic curve point G; Bob's key pair is similar. Then: aB = a*bG = b*aG = bA . This is called "ECDH (DH key exchange on elliptic curves)".

By definition, only someone who knows one of the private keys can get this secret value, so no one else knows it, only them and each other.

Imagine that if Bob discloses one of his public keys in advance, Alice can use her private key to derive a new secret value without interacting with him, and then derive a new public key (and then the corresponding address) from this secret value. For example, this new public key is the elliptic curve point of the hash value of Bob's public key plus the shared secret value: New PK = B + H(aB).G ; the private key behind this public key is: New sk = b + H(bA) . Obviously, only Alice and Bob can know how this public key is constructed, because it uses a shared secret value that only they know; and only Bob can spend the funds in this address (because only he knows his private key b, not Alice).

This method meets the above three requirements: (1) As long as Alice does not reuse the private key, she will not get the same address; (2) Alice no longer needs to interact with Bob and can directly construct an address that only Bob can spend; (3) Bob does not need to back up the key material for each new address, because in a sense, they are all derived from the same seed (key pair).

However, the question is, how does Alice tell Bob which key pair she used? If Bob doesn't know Alice's public key, then this trick won't work.

This is where silent payments are more radical than similar concepts in the past: they require Alice to use the public keys used in the transaction inputs, without conveying this information by other means (such as additional OP_RETURN transaction outputs), so that transactions using the key exchange techniques described above look exactly the same as transactions without such techniques! This maximizes privacy requirements, and the task of discovering the secret information is completely left to Bob.

The above is the basic concept of silent payment. Next, let’s see how BIP352 adds flesh and blood to the skeleton of silent payment and makes it a usable technology, and how its various specifications affect the scanning burden of payment recipient Bob.

BIP352: The first silent payment BIP

BIP352 is well written, following a step-by-step process in the overview and being quite rigorous in the details. To balance the need to introduce the content and the purpose of this article, its main design goals and choices are restated as follows:

• Ecological compatibility
  • BIP352 uses Bech32m encoding ^[6] to encode the recipient address of silent payments.
    • This design means that Bitcoin software that supports P2TR outputs does not need to implement new encoding and decoding methods, and only needs to be fine-tuned to decode the required information from the silent payment address.
    • This design also allows us to define multiple versions of the Silent Payment Protocol. BIP352 is defined as "v0 of the Silent Payment Protocol".
• Storage security
  • The BIP352 silent payment address contains not one public key, but two public keys, called the "scanning public key" and the "spending public key". To scan payments related to yourself, you need to know the "scanning private key", but you do not need to know the "spending private key".
    • Therefore, users can store spending private keys in more secure devices (such as well-designed signers).
• Privacy
  • The "outpoint" of the transaction input is also included in the derivation of the shared secret value. The output point is a unique identifier of a UTXO, consisting of the id of the transaction that created the UTXO and the sequence number of the UTXO among the transaction outputs.
    • This design avoids the impact of Alice (the payment initiator) reusing the address/public key on Bob (the payment receiver). As long as the transaction IDs do not overlap ^[7] , the output points of each UTXO are unique. Even if the same public key is used, the derived shared secret value will be different, so the same address will not be generated for Bob.
  • All inputs participate in the derivation of the shared secret value. The shared secret value is derived by taking the smallest output point of all transaction inputs. In addition, Alice also uses the private key used by all qualified inputs to derive the shared secret value.
    • This design also helps prevent Bob from being able to tell which input came from Alice.
  • Compatible with as many input types as possible. BIP352 defines "P2PKH", "P2WPKH", "P2SH-P2WPKH" and "P2TR" as qualified inputs, which means that payers can use funds on these address types to initiate silent payments.
    • Readers who are familiar with Bitcoin input types can see that this includes almost all standardized scripts controlled by a single public key. The fewer the requirements for input types, the larger the user group that may initiate silent payments, and the smaller the difference between it and regular payments, the less likely it is to be identified.
    • At the same time, because of the requirements of the previous point, when constructing a silent payment transaction, the payer must ensure that the private key of each transaction input that meets the requirements can participate in the derivation of the shared secret value.
  • Using an additional sequence number in the derivation of the recipient's Bitcoin address allows the payer to spread the actual payment amount across multiple different addresses in a single transaction.
    • This can be used to counter speculation based on the amount of money.
• Scanning convenience/management convenience
  • The above “use all input” design also makes it easier for Bob to scan and pay.
  • Only allow P2TR output to be scheduled for Bob.
  • Allow Bob to generate multiple silent payment addresses using the same set of scan keys and spend keys by generating multiple spend public keys through additional tags.
    • Bob can generate multiple silent payment addresses and arrange different addresses for different payees/payment purposes without additional backup.

The above is the general content of BIP352.

Based on the above design, the process for payment recipient Bob to scan silent payment transactions related to himself on the blockchain is roughly as follows:

1. First, Bob needs to find out the potential silent payment transactions in a block (called “eligible transactions” in BIP352);
   • There are three criteria for judging potential transactions: (1) having P2TR outputs; (2) containing at least one input of the above permitted types; and (3) not containing inputs of a higher version than Segregated Witness v1. Here, only the application of the first criterion requires only information about the transaction itself; the latter two criteria require us to obtain the script public key of the preceding output of the input in order to perform the judgment, and this information is implicit and will not be reflected in the transaction.
2. Then, Bob needs to traverse all the inputs of a potential transaction, on the one hand to find the smallest output point, and on the other hand to extract the public keys from the above usable inputs and add them up;
   • This process will produce two key information required to derive the shared secret value. One is the hash value containing the minimum output point information, called "input_hash" in BIP352; the other is the sum of the public keys of all qualified inputs, denoted as "A" in BIP352.
3. Finally, Bob uses input_hash, A and his own scanned private key to derive a shared secret value, and then derives a public key and the corresponding P2TR script based on his spending public key; then he checks whether there is such a P2TR output in the output of the transaction. If so, he saves such a transaction and output and marks it as funds that he can spend. If not, it means that the transaction is not related to him.

Astute readers can find that the above two steps 1 and 2 are the direct consequences of two key designs made by BIP352 on the basic concept of "silent payment": (1) use all transaction input information when deriving the shared secret value of the payment sender and receiver; (2) support as many input types as possible. Such a scanning burden will obviously affect the adoption of silent payment (or, this cost will limit its application scenarios).

Next, we discuss the possible working mode of the BIP352 silent payment wallet and use a comparative approach to understand its scanning burden.

Two working modes and scanning burden

Analyzing the above recipient scanning process, we can find that no matter whether the scanner is Bob or Carol, they have to run the first two steps of the scan, and the results obtained at the end of the two steps are the same. In other words, because BIP352 silent payment "uses all inputs", whether a transaction is a potential silent payment transaction, and (if so) its input_hash and A, is a kind of information that is equally useful to all silent payment recipients, a kind of information that can be reused (in fact, the recipient only needs to obtain the product of the two). Therefore, a working mode that can be imagined is the "server-client mode": the server runs the first two steps of the scan and provides the client with the results; the client only runs the last step based on the local key information. This mode is similar to the "full node-light node" mode in a regular wallet, which can greatly reduce the workload of the client.

In contrast, the "integrated mode" does not split the workload, and all three steps are completed by the same computer.

However, if you consider the above scanning steps more carefully and connect them with the working mode of the full node, you will have further discoveries:

Scanning steps 1 and 2 require obtaining the script public keys of all inputs of a transaction to determine the input script type and perform the corresponding public key extraction steps according to the script type. The information exposed in the transaction, including "script signature (ScriptSig)" and "witness (txinwitness)", is not enough. However, when verifying transactions in newly arrived blocks, full nodes also require this information, and obtaining this information only requires searching in the UTXO set, without accessing historical blocks and historical transactions (without triggering deeper hard disk reads).

That is to say, if the above scanning steps are performed while verifying the transactions in the new block, it is incidental, and the additional overhead comes entirely from the calculation (input and output type checking, public key extraction, shared secret value derivation, ECDH, etc.), and objectively speaking, the amount of these calculations will not be too large; however, if we use a separate process to run the scan, not only will we have to pay additional computing overhead, but we will also need additional, deeper hard disk reads, because once the new block is verified, the script public key of the transaction input can no longer be obtained from the UTXO set, but can only be obtained by accessing historical transactions (and there is an additional storage space overhead here: indexing all transactions on the blockchain. If such an index does not exist, historical transactions cannot actually be read, and the synchronous verification-scanning mode does not require indexing historical transactions).

Due to this significant difference in overhead ^[8] , we add the definition of “integrated mode”: the scanning step is a subsidiary step of block verification and is completed synchronously with block verification.

Please note that after adding the definition, the combination of "integrated mode" and "server-client mode" does not constitute a complete set: it is possible that the scanning workload is not split, but the scanning work is still completed in a separate process.

The definitions of these two modes are constructed only to facilitate our understanding of the scanning burden of BIP352 silent payment recipients through comparison: due to the accuracy of the definitions, they both have appropriate comparison objects. The integrated mode can be compared with a regular wallet based on a full node; the server-client mode can be compared with a regular wallet based on a light node of the BIP158 block filter ^[9] .

To do this, we make the following assumptions about the number and proportion of transactions occurring in the network, and the number of addresses controlled by wallets:

• On average, each block contains n transactions, which have a total of m transaction inputs and o transaction outputs;
• The percentage of transactions that contain at least one P2TR output is p , and the percentage of P2TR outputs to all outputs in a single block is q ;
• The silent payment wallet only discloses 1 silent payment address;
• The regular wallet contains 20 P2TR addresses;
• Only consider the case where this wallet address appears in the transaction output (the case of receiving payment).

Under the above assumptions, the scanning burden of a regular wallet based on a full node is: 20 * o * q , that is, 20 address matching checks are run for each P2TR output in the block. The scanning burden of a silent payment wallet in integrated mode is: n * p * I + o * q * 1 The first item is the overhead caused by the first two steps of the silent payment scan, which is in units of transactions. Here, I is the amount of computation required to perform type checks, public key extraction, ECDH and other operations on a transaction, which is assumed to be a constant; the second item is the amount of computation required to perform address matching checks on each P2TR output of these potential transactions. Given that the wallet owner has only disclosed 1 silent payment address, it only needs to be executed 1 .

As for the conventional wallet based on light nodes, we know that its working mode is to verify the block filter first; if the filter shows that there are no inputs and outputs of interest in the block, the complete block will not be downloaded; if the block filter shows that there are (there is a very small possibility of misjudgment here), then download and check the address match. We regard the burden of verifying the block filter as a constant (this does not affect the comparison), then its scanning burden is: 1/x * 20 * o * q , where 1/x is the probability of the filter hitting, which must be greater than the misjudgment probability of the BIP158 block filter, but the actual size depends on the distribution of transactions received by this wallet among blocks.

The scanning burden of the silent payment wallet based on the server-client model is: n * p * I_1 + o * q * 1 The reason why this formula is so similar to the integrated model is that the server only completes part of the scanning work, and for each possible transaction, the client still needs to perform part of the work (specifically ECDH) (it is only part of I , so it is recorded as I_1 ), and the address matching check of the P2TR output cannot benefit from the work of the server at all, so it remains as it is.

Summarizing the above analysis:

1. The scanning burden of regular wallets is largely determined by the number of outputs of the same type, but the scanning burden of silent payment wallets is partly (or even mainly) related to the number of eligible transactions. The two are not easy to compare directly; but from the perspective of computational complexity, the scanning burden of silent payment is most likely greater. Specifically, this burden is related to the proportion of transactions containing P2TR outputs; the greater the proportion, the greater the scanning burden of silent payment wallets;
2. Both regular wallets and silent payment wallets can benefit significantly from moving to a light node/client model;
3. The difference in scanning burden between silent payment wallets and regular wallets will be greater in client mode, which means it is easier for users to feel the performance difference. Silent payment wallets may be more suitable for stable desktop terminals rather than daily mobile terminals.

The present and future of silent payments

Performance/cost will undoubtedly affect the adoption of a technology. From the above analysis, we can see that no matter which working mode, silent payment wallets have to pay a higher price than regular wallets. It can be said that this is also within our expectations, because this is the inherent characteristic of "silent payment". At least, in the application scenarios envisioned by people (accepting donations, accepting payments as an institution), the benefits of static payment methods should outweigh their additional costs. Moreover, given the possibility of server-client, part of the workload can be reused.

Currently, multiple projects are trying to implement BIP352 silent payment wallets, such as:

• Implement BIP352 in Bitcoin Core: https://github.com/bitcoin/bitcoin/issues/28536
• Dana Wallet Mobile Silent Payment Wallet: https://github.com/cygnet3/danawallet

In addition, developers are also adding multiple specifications to make silent payments compatible with coinjoin transactions. In a coinjoin transaction, multiple participants will each provide inputs and specify outputs for the transaction; according to BIP352, in order for such a transaction to carry silent payments, the payer must allow the private key of each qualified input to participate in the derivation of the shared secret value; at the same time, this cannot cause the leakage of the real private key; in addition, tools are needed to be able to pass information about the constructed transaction between parties (the recipient's script must be calculated after every participant participates in the calculation). The relevant specifications are:

• BIP374 discrete logarithm equality proof: https://github.com/bitcoin/bips/pull/1689
  • Discrete logarithm equality proofs allow a private key holder to prove that they know a private key without revealing what the private key is.
• BIP375 uses PSBT to send silent payments: https://github.com/bitcoin/bips/blob/master/bip-0375.mediawiki
  • Defines the "PSBT (Pending Signed Bitcoin Transaction)" data format that can be used to convey information in a multi-party signed silent payment transaction collaboration.

The protocol design space related to silent payments is also being explored.

(over)

footnote

1. https://www.btcstudy.org/2024/11/22/bitcoin-address-types-its-essentials-and-its-economics/ ↩

2. https://www.btcstudy.org/2023/10/25/a-guide-for-recovering-your-bitcoin-wallets/ ↩

3. https://www.btcstudy.org/2022/10/19/on-various-non-interactive-payments/ ↩

4. https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange ↩

5. https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki ↩

6. https://www.btcstudy.org/2024/11/22/bitcoin-address-types-its-essentials-and-its-economics/#Bech32m ↩

7. https://www.btcstudy.org/2024/04/17/transaction-security-improvement-from-soft-forks/#BIP30% EF%BC%9A%E7%A6%81%E6%AD%A2%E5%87%BA%E7%8E%B0%E7%9B%B8%E5%90%8C%E7%9A%84%E4%BA%A4%E6%98%93-ID ↩

8. This significant difference in cost may explain why some developers are determined to implement BIP352 in Bitcoin Core. See: https://github.com/bitcoin/bitcoin/issues/28536 ↩

9. https://www.btcstudy.org/2022/04/18/how-neutrino-works-by-Suredbits/ ↩