Adresse Bitcoin

Alice souhaite payer Bob. Bob ouvre Recevoir dans son portefeuille, vérifie l’adresse affichée et l’envoie sous forme de texte ou de code QR. Alice la charge dans son portefeuille et contrôle le destinataire ainsi que le montant avant l’envoi. Elle n’a pas besoin de comprendre chaque caractère : l’application s’en charge. À partir de l’adresse, le portefeuille construit la condition nécessaire pour dépenser ensuite cet argent, généralement une signature avec la bonne clé privée. La transaction enregistre cette condition dans un script nommé scriptPubKey. Elle contient le montant et le script, pas le texte habituel de l’adresse. L’adresse sert donc à communiquer des coordonnées de paiement ; ce n’est pas une boîte contenant des pièces. [1] [3]

Copiez la longue adresse ou scannez son QR plutôt que de la saisir à la main. La vérification ne s’arrête pas là : un logiciel malveillant peut remplacer une adresse dans le presse-papiers. Comparez l’adresse entière avec celle obtenue du destinataire par un canal fiable. Si vous utilisez une Hardware Wallet, contrôlez aussi son propre écran. Le début et la fin ne suffisent pas : une adresse frauduleuse peut les imiter. La somme de contrôle intégrée à l’adresse aide à détecter les fautes de saisie, mais ne confirme pas qu’une adresse correctement écrite appartient à la bonne personne. Le portefeuille doit également prendre en charge le format et le réseau. Un petit paiement d’essai peut aider, sans remplacer la vérification lors du transfert suivant. Le protocole ne permet pas d’annuler simplement un paiement confirmé vers une adresse erronée mais valide. [2] [7] [8] [18]

La prochaine fois que Bob ouvre Recevoir, une autre adresse peut apparaître. Son argent n’a pas disparu pour autant. Une nouvelle adresse protège mieux sa vie privée : connaître une adresse publiée permet de suivre les paiements qui y arrivent sur la blockchain, mais ne devrait pas révéler automatiquement toutes les sommes reçues par le portefeuille. Réutiliser la même adresse facilite ce rapprochement. Des adresses nouvelles ne garantissent toutefois pas l’anonymat : des transactions ultérieures peuvent révéler d’autres liens. Vous pouvez partager une adresse pour recevoir un paiement, mais mieux vaut réfléchir avant de la publier partout. Une adresse ne correspond pas non plus forcément à une personne : plusieurs personnes peuvent gérer des fonds ensemble, ou un service peut les gérer pour ses clients. [1] [14]

Le portefeuille gère des clés, retrouve les paiements qu’il peut dépenser et en affiche le total. Son solde peut ainsi provenir de nombreuses adresses. Une HD Wallet courante crée des familles de clés à partir d’une origine commune : une nouvelle adresse ne signifie donc pas un nouveau portefeuille. Lors d’un paiement, l’application peut aussi renvoyer le reliquat vers sa propre Change Address, une adresse de monnaie rendue. Les adresses seules ne suffisent cependant pas à restaurer le portefeuille. La sauvegarde doit permettre de retrouver les clés nécessaires et leurs règles d’utilisation. De nombreux portefeuilles utilisent une Seed Phrase, un ensemble de mots de récupération ; des configurations plus complexes peuvent exiger d’autres informations. Le payeur n’a jamais besoin de ces mots ni de vos clés privées. [10] [14]

Un code QR n’est qu’une représentation de données. Il peut contenir une adresse seule ou une demande commençant par bitcoin:, avec un montant, un libellé de destinataire ou un message. BIP21 décrivait ce mécanisme, que BIP321 étend. Vérifiez donc ce que le portefeuille a réellement lu avant de confirmer. Les demandes du Lightning Network, telles qu’une invoice pour un paiement unique ou un offer permettant de demander de nouvelles invoices à chaque paiement, suivent un autre parcours de paiement ; Lightning Address facilite la demande d’un tel paiement. Certaines demandes proposent plusieurs moyens de régler. De même, la signature numérique d’un message ne confirme pas automatiquement une identité : BIP322 permet de démontrer que les conditions d’un script peuvent être remplies, mais ne prouve à lui seul ni l’identité juridique ni l’approbation d’une facture quelconque. [15] [16] [17]

Base58Check associe un octet de version aux données appelées payload. Il ajoute les quatre premiers octets de SHA256(SHA256(version || payload)), puis encode le résultat en Base58. Sur mainnet, 0x00 désigne P2PKH et 0x05 P2SH, d’où les débuts habituels 1 ou 3. Les réseaux de test ont d’autres versions. L’alphabet exclut les caractères faciles à confondre 0, O, I et l. Ce checksum de 32 bits détecte beaucoup de fautes de saisie, sans authentifier le destinataire. [2] [3]

Une adresse SegWit native comprend le préfixe bc pour mainnet ou tb pour testnet, le séparateur 1, la version witness et des données regroupées par 5 bits. Elle se termine par 6 caractères de contrôle. BIP173 a introduit Bech32 ; après la découverte d’une faiblesse face à certaines insertions et suppressions, BIP350 a conservé Bech32 pour la version 0 et fixé Bech32m pour les versions 1–16. Les lettres peuvent être toutes minuscules ou toutes majuscules, jamais mélangées. L’encodage est limité à 90 caractères. Même valide, il peut viser un autre réseau ou une version non prise en charge. [7] [8]

P2PKH et P2WPKH renvoient au HASH160 de 20 octets d’une clé publique. P2SH utilise HASH160 du redeemScript, tandis que P2WSH utilise SHA256 du witnessScript. SegWit v0 reconnaît donc P2WPKH de 20 octets et P2WSH de 32 octets. P2TR selon BIP341 est différent : son programme de version 1 contient une clé de sortie Q ajustée, x-only, de 32 octets, pas le hash d’une clé de réception ordinaire. Q peut aussi intégrer la racine d’un arbre de scripts supplémentaires, ce qui lie cryptographiquement la clé à ces conditions de dépense. L’adresse seule ne révèle donc pas toutes les possibilités de dépense. [6] [9]

Les premières sorties Bitcoin payaient souvent directement une clé publique. P2PKH a retardé sa révélation jusqu’à la dépense. BIP13 et BIP16 ont permis avec P2SH de transmettre le hash d’un script plus complexe. BIP141 a ajouté les programmes witness versionnés, BIP173 Bech32, puis BIP341 avec BIP350 le format Taproot utilisant Bech32m. Ces différences visuelles correspondent à des conditions de vérification différentes. Ne « convertissez » pas une adresse en remplaçant son préfixe à la main : vous pourriez créer une sortie différente ou impossible à dépenser. Certains scripts non standard et les premières sorties pay-to-pubkey n’ont pas d’adresse canonique habituelle. [4] [5] [6] [7] [8] [9] [3]

Une HD Wallet selon BIP32 dérive de nombreuses clés d’une racine commune. Les chemins distinguent les types de sortie : BIP44 utilise le niveau purpose 44' pour P2PKH, BIP84 le niveau 84' pour P2WPKH et BIP86 le niveau 86' pour P2TR à clé unique. Viennent ensuite le type de monnaie (coin type), le compte, la branche de réception ou change, puis l’index de l’adresse. La Seed Phrase seule ne définit pas forcément tous les chemins, comptes et règles Multisig. Un Output Descriptor conserve aussi l’origine des clés et la construction du script. La restauration doit retrouver les fonds réels, pas simplement réafficher une adresse connue. [10] [11] [12] [13] [14]

P2PKH et P2WPKH montrent généralement d’abord un hash de clé ; la dépense révèle la clé publique. P2SH et P2WSH révèlent le redeemScript ou witnessScript utilisé. Taproot inclut déjà une clé publique ajustée dans la sortie. Une key-path spend ajoute normalement une Schnorr Signature, tandis qu’une script-path spend révèle le script choisi, le control block et le chemin Merkle ; les branches inutilisées peuvent rester cachées. Il est donc faux de dire que toute adresse masque la clé publique. [6] [9]