Un pseudonyme est un identifiant reconnaissable sans identité civile intégrée. Dans Bitcoin, il peut s’agir d’une adresse, public key, xpub, wallet cluster, Lightning node ID ou compte de service ; sa force dépend des liens possibles entre ces traces et le monde réel.
Le whitepaper Bitcoin sépare public keys et identité publique, tout en signalant que le flux des transactions reste visible. Le pseudonyme masque le nom jusqu’à ce qu’une autre donnée crée un lien. L’activité passée et future peut alors être réanalysée ; l’anonymat n’est pas acquis définitivement.
Une adresse est une instruction de paiement dérivée d’une clé ou d’un Script, ni nom d’utilisateur ni preuve fiable d’une personne. Un utilisateur contrôle plusieurs adresses et une condition de dépense peut impliquer plusieurs personnes ou appareils. La signature prouve l’autorisation Script, pas l’identité légale.
Chaque transfert on-chain dépense des UTXO antérieurs et crée de nouveaux outputs. Montants, types de Script et filiation sont publics : l’observateur construit un graphe probabiliste. Il est généralement sans noms, mais exchange, facture ou adresse publiée peuvent en étiqueter une partie.
Address reuse transforme une instruction ponctuelle en identifiant public persistant. Les contreparties voient l’historique commun et suivent les recettes ou dépenses ultérieures. Une nouvelle receive address par paiement réduit ce lien direct sans empêcher les autres heuristiques.
La wallet rend souvent l’excédent comme change. Détection du change et common-input-ownership heuristic peuvent réunir les inputs en wallet cluster sans preuve cryptographique. CoinJoin, PayJoin, coin control et dépenses suivantes peuvent affaiblir ou renforcer l’inférence.
Un exchange KYC connaît le compte et souvent l’adresse de retrait ; le marchand connaît commande, heure et montant ; un paiement physique peut révéler la présence. L’identité est attribuée hors consensus mais ajoutée au graphe public. Changer d’adresse n’annule pas un lien divulgué.
BIP 32 dérive de nombreuses clés depuis un arbre déterministe. Une fuite de xpub ne permet normalement pas de dépenser, mais révèle potentiellement l’historique passé et futur de la branche. xpub est donc un pseudonyme puissant et durable.
IP, heure de broadcast, wallet backend, block explorer, cookies, notifications push, cloud backup et SDK analytics peuvent relier un pseudonyme on-chain à un appareil ou compte. Un full node personnel limite certaines requêtes tierces, pas toutes les fuites réseau ou endpoint.
Lightning ajoute des identifiants : node ID public et channels peuvent persister ; invoice, offer, route hint ou payment hash créent d’autres liens. Le paiement off-chain n’est normalement pas inscrit dans blockchain, mais participants, nœuds de routage et services voient des métadonnées différentes.
Lors d’un audit, distinguez ‘l’adresse ne contient pas de nom’ de ‘personne ne connaît le propriétaire’. Vérifiez address reuse, origine UTXO, change, inputs communs, adresses publiées, xpub, KYC, backend et Lightning. Décrivez la linkability face à un observateur précis, pas un anonymat absolu. Sources: Bitcoin whitepaper — Privacy; Bitcoin.org — Protect Your Privacy; BIP 32 — Hierarchical Deterministic Wallets; Bitcoin Developer Guide — Transactions; Lightning BOLT #7 — Routing Gossip.
Pour une vision complète, lisez aussi Confidentialité de Bitcoin, Adresse Bitcoin, KYC, Address Clustering, Bitcoin, UTXO. Cette entrée est également citée par Confidentialité de Bitcoin, KYC, Nostr.