Thank you
Often it is said before sending a sizable transaction to send a small test transaction.
Doesn’t such advice require using the addrsss at least twice?
# What does a Bitcoin address reveal before and after a transaction?
Reusing a Bitcoin address is often presented as a privacy issue. However, it also poses a **real cryptographic risk** related to the security of the private key itself. This issue concerns both older P2PKH addresses and newer SegWit (bc1q...) or Taproot (bc1p...) formats: when an address is reused after having already been used to spend a UTXO, all funds associated with that same key now depend on cryptographic material that has been exposed multiple times on the blockchain. This article explains the structural reasons for this risk, the cryptographic mechanisms involved, and the practical way to observe the public key revealed during a transaction.
### Exposure of the public key: a critical moment
Before any transaction, a Bitcoin address **does not reveal the public key**, but only a hash:
```
HASH160(pubkey) = RIPEMD160(SHA-256(pubkey))
```
This hash offers no possibility of retrieving the public key. As long as a UTXO remains unspent, the associated key remains mathematically inaccessible.
As soon as a UTXO is spent:
- the **signature** is published,
- the **complete public key** is revealed,
- the validity of the signature is verified against this key.
From this point on, the address no longer offers the same cryptographic protection: the public key is exposed to offensive analysis, and any reuse of this same key multiplies the data that can be exploited by an attacker.
### Where is the public key located at the time of spending?
The exact location depends on the type of address:
### P2PKH (addresses beginning with 1 or 3)
In **P2PKH** transactions, the public key appears:
- **in the scriptSig**,
- immediately after the signature,
- in hexadecimal form, usually as a compressed key (33 bytes, prefix 02 or 03) or uncompressed (65 bytes, prefix 04).
### P2WPKH (SegWit v0, bc1q addresses, etc.)
In **P2WPKH** transactions, the public key appears in the **witness**:
- witness[0] → signature (DER format),
- witness[1] → **compressed public key** (33 bytes, starting with 02 or 03).
### Taproot (P2TR, bc1p addresses, etc.)
**Taproot** transactions use Schnorr signatures and **x-only** public keys. The public key appears:
- in the **witness script**,
- usually under the “key path spending” line,
- in **x-only** format: 32 bytes (64 hex) without the 02/03 prefix.
### On mempool.space
[mempool.space](http://mempool.space/) does **not display “Public Key” in plain text**. You have to read the raw hexadecimal fields and recognize the format:
- **33 bytes** → compressed pubkey: starts with 02 or 03.
- **65 bytes** → uncompressed pubkey: starts with 04.
- **32 bytes** → Taproot x-only pubkey.
The public key is therefore still visible, but in the form of a hexadecimal field in the Inputs.
### Why does reuse weaken security?
### Revealing the public key once is not critical
Security relies on the difficulty of the discrete logarithm problem (ECDLP). As long as an attacker only has a single signature produced by the key:
- they cannot reconstruct anything,
- they have no statistical material,
- ECDLP remains intact.
### Revealing the same key multiple times multiplies the attack surface
Each UTXO expenditure associated with the same address publishes:
- an identical public key,
- a new, distinct signature.
In ECDSA (P2PKH, P2WPKH), each signature requires a random number: the **nonce k**. k must be:
- unique,
- unpredictable,
- perfectly generated.
> A flaw in the generation of k — well-documented events — allows the private key to be recovered if two signatures use the same k or correlated k's.
Real-world examples:
- Android bug in 2013,
- Faulty hardware RNG,
- Old OpenSSL libraries,
- Entropy weakness when booting a device,
- Smartcards producing biased nonces.
Reusing addresses **multiplies the signatures produced** by the same key → increases the probability of a cryptographic incident.
### Taproot improves the situation but does not eliminate it
Taproot uses Schnorr:
- deterministically derived nonce → eliminates the “same k” risk,
- more resistant linear signature structure.
However:
- the x-only key remains unique and exposed,
- multiple signatures remain exploitable for statistical analysis,
- hardware risks remain,
- post-quantum cryptography will compromise any exposed public key.
### Risk concentration
An HD wallet (BIP32) allows each UTXO to be isolated behind a different derived key. Reusing addresses negates this advantage:
- a bug in a single signature → compromises all UTXOs dependent on that key.
This is the worst possible configuration in terms of compartmentalization.
### What about cryptographic advances (quantum or otherwise)?
If an attacker gained the ability to solve ECDLP:
- any public key **already exposed** would become vulnerable,
- all reused addresses would be particularly fragile,
- an address that has never been spent would remain protected by HASH160.
Address reuse thus concentrates a future risk that the ecosystem explicitly seeks to avoid.
### Concrete example: key revealed in a real transaction
For the transaction:
```
7ee6745718bec9db76390f3a4390b9e7daeeb401e8c666a7b261117a6af654a1
```
This is a P2WPKH input. In the witness:
- the signature is in witness[0],
- the compressed public key is in witness[1].
The revealed public key is:
```
02174ee672429ff94304321cdae1fc1e487edf658b34bd1d36da03761658a2bb09
```
> Before spending: only HASH160(pubkey) was visible.
> After spending: the actual public key is visible, permanently.
### Conclusion
Reusing Bitcoin addresses represents a tangible cryptographic risk. It is not just a matter of poor privacy hygiene, but a structural problem: **a public key should only be exposed once**, and a signature should never be multiplied on the same key if maximum robustness is desired.
Current cryptographic mechanisms are robust, but experience shows that:
- implementations are never perfect,
- nonces can be biased,
- devices can lack entropy,
- hardware attacks exist,
- cryptanalysis is advancing.
Minimizing the exposure of public keys remains a fundamental best practice, today and tomorrow, and this starts with a simple rule: **never reuse an address that has already spent a UTXO**.
#Bitcoin #Privacy #Cryptography #ECDSA #Schnorr #Taproot #SegWit #UTXO #Decentralized #BitcoinPrivacy #CryptoEducation #BIP32 #HDWallet #QuantumThreat
Discussion
no you can send a first small test transaction to one address, then the rest to a second addree generated from the same wallet. Have you used Sparrow Wallet or Electrum before?