Mastering best practices to protect your privacy

Address reuse

Privacy on Bitcoin

Address reuse

What's a receiving address?
What is address reuse?
Why is address reuse a problem?
How to avoid address reuse?

Having studied the techniques that can compromise your confidentiality on Bitcoin, in this third part, we'll now examine the best practices to adopt for protection. The aim of this part is not to explore methods of improving confidentiality, a subject that will be addressed later, but rather to understand how to interact correctly with Bitcoin to retain the confidentiality it naturally offers, without resorting to additional techniques.

To begin this third part, we will discuss address reuse. This phenomenon is the main threat to user confidentiality. This chapter is surely the most important of the entire course.

What's a receiving address?

A Bitcoin receiving address is a string or identifier used to receive bitcoins in a wallet.

Technically, a Bitcoin receiving address does not "receive" bitcoins in the literal sense, but rather serves to define the conditions under which bitcoins can be spent. In concrete terms, when a payment is sent to you, the sender's transaction creates a new UTXO for you as an output from the UTXOs it has consumed as inputs. This output attaches a script that defines how this UTXO can be spent at a later date. This script is known as "ScriptPubKey" or "Locking Script". Your receiving address, or more precisely its payload, is integrated into this script. In layman's terms, this script basically states:

"To spend this new UTXO, you must provide a digital signature using the private key associated with this receiving address."

Bitcoin addresses come in different types, depending on the scripting model used. The first models, known as "Legacy", include the P2PKH (Pay-to-PubKey-Hash) and P2SH (Pay-to-Script-Hash) addresses. P2PKH addresses always begin with 1, and P2SH with 3. Although still secure, these formats are now obsolete, as they entail higher transaction costs and offer less confidentiality than the new standards.

SegWit V0 (P2WPKH and P2WSH) and Taproot / SegWit V1 (P2TR) addresses represent modern formats. SegWit addresses start with bc1q and Taproot addresses, introduced in 2021, start with bc1p.

For example, here is a Taproot reception address:

bc1ps5gd2ys8kllz9alpmcwxqegn7kl3elrpnnlegwkm3xpq2h8da07spxwtf5

How the ScriptPubKey is constructed will depend on the standard you are using:

ScriptPubKey	Script template
P2PKH	OP_DUP OP_HASH160 `<pubKeyHash>` OP_EQUALVERIFY OP_CHECKSIG
P2SH	OP_HASH160 `<scriptHash>` OP_EQUAL
P2WPKH	0 `<pubKeyHash>`
P2WSH	0 `<witnessScriptHash>`
P2SH - P2WPKH	OP_HASH160 `<redeemScriptHash>` OP_EQUAL
P2SH - P2WSH	OP_HASH160 `<redeemScriptHash>` OP_EQUAL
P2TR	1 `<pubKey>`

The construction of reception addresses also depends on the script model chosen:

For P2PKH and P2WPKH addresses, the payload, i.e., the core of the address, represents the hash of the public key;
For P2SH and P2WSH addresses, the payload represents the hash of a script;
As for P2TR addresses, the payload is a tweaked public key. P2TR outputs combine aspects of Pay-to-PubKey and Pay-to-Script. The tweaked public key is the result of adding a classic spending public key with a "tweak", derived from the Merkle root of a set of scripts that can also be used to spend bitcoins.

Addresses displayed on your wallet software also include an HRP (Human-Readable Part), typically bc for post-SegWit addresses, a 1 separator, and a version number q for SegWit V0 and p for Taproot/SegWit V1. A checksum is also added to guarantee the integrity and validity of the address during transmission.

Finally, the addresses are put into a standard format:

Base58check for old Legacy addresses;
Bech32 for SegWit addresses;
Bech32m for Taproot addresses.

Here is the addition matrix for bech32 and bech32m formats (SegWit and Taproot) from base 10:

+	0	1	2	3	4	5	6	7
0	q	p	z	r	y	9	x	8
8	g	f	2	t	v	d	w	0
16	s	3	j	n	5	4	k	h
24	c	e	6	m	u	a	7	l

What is address reuse?

Address reuse refers to the use of the same receiving address to block multiple different UTXOs.

As we saw in the previous section, each UTXO has its own ScriptPubKey, which locks it and must be satisfied for the UTXO to be consumed as input in a new transaction. It is within this ScriptPubKey that payload addresses are integrated.

When different ScriptPubKeys contain the same receiving address, this is referred to as address reuse. In practice, this means that a user has repeatedly provided the same address to senders in order to receive bitcoins via multiple payments. And it's precisely this practice that is disastrous for your privacy.

Why is address reuse a problem?

Since the blockchain is public, it's easy to see which addresses lock which UTXO and how many bitcoins are locked. If the same address is used for several transactions, it becomes possible to deduce that all the bitcoins associated with that address belong to the same person. This practice compromises user privacy by enabling deterministic links to be established between different transactions and bitcoins to be traced on the blockchain. Satoshi Nakamoto himself already highlighted this problem in Bitcoin's White Paper:

As an additional firewall, a new pair of keys could be used for each transaction to keep them unlinked to a common owner

Source: S. Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System", https://bitcoin.org/bitcoin.pdf, 2009.

Satoshi's intention in this sentence was to create an additional firewall in the event of an association between a user's identity and a key pair on Bitcoin, to prevent his entire activity from being publicly linked to his identity. Today, with the proliferation of blockchain analysis companies and KYC regulations, the use of unique addresses is no longer an "additional firewall," but an indispensable practice for anyone wishing to maintain a minimum level of privacy.

When you reuse an address, you make an almost undeniable link between all the transactions associated with that address. Although this doesn't directly jeopardize your funds, as elliptic curve cryptography guarantees the security of your private keys, it does make it easier to monitor your activities. Indeed, anyone with a node can observe the transactions and balances of the addresses, totally compromising your anonymity.

To illustrate this point, let's take the example of Bob, a user who regularly buys bitcoins in small amounts in DCA and always sends them to the same address. After two years, this address contains a substantial quantity of bitcoins. If Bob uses this address to make a payment to a local merchant, the latter will be able to see all the associated funds and deduce Bob's wealth. This can lead to personal security risks, such as attempted theft or extortion. If Bob had used a blank address to receive each periodic purchase, he would have revealed infinitely less information to his merchant.

In string analysis, there are 2 types of address reuse:

External reuse;
Internal reuse within a transaction.

The first is when an address is reused in several different Bitcoin transactions. This is what we talked about earlier: this heuristic deduces that all UTXOs passed through this address belong to a single entity.

Internal address reuse does not occur when it spans multiple transactions, but rather when it occurs within a single transaction. Indeed, if the same address used to lock an input is used as the output of a transaction, then we can deduce that this output still belongs to the same user (change), and that the second output represents the actual payment. This other heuristic enables the tracing of funds across several transactions.

Address reuse is a significant issue for Bitcoin. According to the OXT.me website (currently inaccessible), the overall rate of address reuse on Bitcoin was around 52% in 2022:

This rate is enormous, but it comes overwhelmingly from exchange platforms rather than individual users.

How to avoid address reuse?

Avoiding address reuse is quite simple: simply use a new, blank address for all new payments to your wallet.

Thanks to BIP32, modern wallets are now deterministic and hierarchical. This means that a user can generate a large number of addresses from a single initial piece of information: the seed. By saving this single piece of information, it is possible to restore all the private keys in the wallet, enabling access to the funds secured by the corresponding addresses.

This is why, when you press the "receive" button in your wallet software, an unused receiving address is suggested every time. After receiving bitcoins at this address, the software automatically suggests a new one.

PS: Recently, some wallet software programs have announced their intention to stop generating blank addresses, fearing that this will be perceived as a form of money laundering by the authorities. If your software is one of these, I strongly advise you to replace it immediately, as this is not acceptable to the user. If you need a static identifier to receive payments, such as donations, it's not advisable to use a classic Bitcoin address because of the risk of reuse. Instead, use a Lightning address or opt for a static on-chain payment identifier, such as BIP47 or Silent Payments. These protocols are explained in detail in part 6 of this course.

Quiz

btc2044.1

1/5

What is the main threat associated with address reuse?