<p>No, that’s not an accurate understanding. The sender uses the private keys associated with his own UTXOs and the public key provided by the receiver to generate a shared secret. They can do this with many different combinations of UTXOs and thereby generate many shared secrets, but even so, they do not learn anything about the receiver’s address body, because each address is a function of the sender’s private keys and the receiver’s single public key.</p>

CC BY-SA 4.0
2024-09-09T14:42:15.417Z
2024-09-11T14:56:40.243Z
2024-09-11T14:56:40.243Z
Murch
<p>Taking a few steps back, it's helpful to remember that a taproot &quot;address&quot; is just a bech32m encoding of a public key. The majority of wallets today generate these public keys using BIP32, where child keys are derived from a master key. This is likely where you're getting the number &quot;4 billion addresses.&quot; It's important to point out, however, all you need to create a taproot output is a valid public key.</p>
<p>BIP352 (Silent payments) is different in that there is no derivation or pre-generation of addresses by the recipient. The sender creates a public key for the recipient and encodes it as a taproot output. For details on how the sender creates this public key for the recipient, I'd recommend reading the <a href="https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki#overview" rel="nofollow noreferrer">overview section of BIP352</a>. At a high level, however, the important details are:</p>
<ul>
<li>The sender first creates a shared secret between them and the recipient by multiplying the sum of their private keys with the recipient's scan public key (i.e., Elliptic Curve Diffie-Hellman key exchange)</li>
<li>This shared secret is turned into a public key and added to the sender's spend public key, ensuring the resulting output is only spendable by the recipient</li>
<li>The resulting public key (shared secret + recipient's spend public key) is encoded as a taproot output in the transaction</li>
</ul>
<p>The resulting public key is unique to this transaction. If the sender sends again to the same recipient silent payment address, they will necessarily have to use different UTXOs, which in turn guarantees each silent payment output is unique to the transaction it is in.</p>

CC BY-SA 4.0
2024-09-09T17:43:51.630Z
2024-09-10T07:39:43.827Z
2024-09-10T07:39:43.827Z
josie
<p>As I understand Silent Payment address is a way for sender to brute force find an invoice (address) on Taproot.</p>
<p>Question: Can sender then generate all 4 billion addresses of the private key, destroying privacy?</p>

<address-generation><silent-payments>
Can a silent payment address body be brute forced?
John
# Can a silent payment address body be brute forced?

(Asked by: username_0 on 2024-09-09)

As I understand Silent Payment address is a way for sender to brute force find an invoice (address) on Taproot.

Question: Can sender then generate all 4 billion addresses of the private key, destroying privacy?

**Tags:** address-generation, silent-payments


---

## 2 answers

### Answer by username_1 on 2024-09-09. Score: 3

No, that’s not an accurate understanding. The sender uses the private keys associated with his own UTXOs and the public key provided by the receiver to generate a shared secret. They can do this with many different combinations of UTXOs and thereby generate many shared secrets, but even so, they do not learn anything about the receiver’s address body, because each address is a function of the sender’s private keys and the receiver’s single public key.


---

### Answer by username_2 on 2024-09-09. Score: 2

Taking a few steps back, it's helpful to remember that a taproot "address" is just a bech32m encoding of a public key. The majority of wallets today generate these public keys using BIP32, where child keys are derived from a master key. This is likely where you're getting the number "4 billion addresses." It's important to point out, however, all you need to create a taproot output is a valid public key.

BIP352 (Silent payments) is different in that there is no derivation or pre-generation of addresses by the recipient. The sender creates a public key for the recipient and encodes it as a taproot output. For details on how the sender creates this public key for the recipient, I'd recommend reading the [overview section of BIP352](https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki#overview). At a high level, however, the important details are:

* The sender first creates a shared secret between them and the recipient by multiplying the sum of their private keys with the recipient's scan public key (i.e., Elliptic Curve Diffie-Hellman key exchange)
* This shared secret is turned into a public key and added to the sender's spend public key, ensuring the resulting output is only spendable by the recipient
* The resulting public key (shared secret + recipient's spend public key) is encoded as a taproot output in the transaction

The resulting public key is unique to this transaction. If the sender sends again to the same recipient silent payment address, they will necessarily have to use different UTXOs, which in turn guarantees each silent payment output is unique to the transaction it is in.


---

