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 raises a real cryptographic risk related to the security of the private key itself. The issue concerns both old P2PKH addresses and recent 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 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 expenditure, 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 that moment on, the address no longer offers the same cryptographic protection: the public key is exposed to offensive analysis, and any reuse of that 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 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 always 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 ks.
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.