Tu crois peut-être qu’une adresse Bitcoin, c’est “un numéro de compte”. C’est logique. C’est l’image la plus simple. Mais c’est aussi l’image qui te fait faire les pires erreurs. Parce qu’une adresse Bitcoin n’est pas un compte. C’est une règle. Une règle qui dit: “Voici comment tu peux dépenser ces unités.”
Et c’est là que ça devient étrange. Tu peux envoyer du bitcoin à une adresse. Mais tu n’envoies pas “à une personne”. Tu verrouilles des UTXO avec un script. Tu écris une condition. Si la condition est respectée plus tard, l’argent bouge. Sinon, il reste bloqué.
Tu vois la tension. Les wallets te cachent tout ça. Tu copies une chaîne de caractères, puis tu cliques “envoyer”. C’est simple. Mais si tu ne comprends pas les types d’adresses, tu ne comprends pas les frais. Tu ne comprends pas la compatibilité. Et tu ne comprends pas la vie privée.
Dans cet article, tu vas mettre de l’ordre. Tu vas comprendre P2PKH, P2SH et Bech32. Tu vas aussi comprendre ce que “bc1” change vraiment. Et tu vas apprendre les réflexes sécurité-first, sans tomber dans le jargon.
Cadre mental
Commence par une image utile. Une adresse Bitcoin n’est pas une “destination”. C’est un cadenas. Tu fermes un cadenas sur une somme. Ce cadenas a un type. Et selon le type, la clé qui ouvre n’est pas la même. Parfois, c’est une seule clé. Parfois, c’est un contrat. Parfois, c’est un chemin conditionnel.
Techniquement, une adresse est une représentation lisible d’un script, ou d’un hash de script. On parle souvent de “scriptPubKey”. C’est la condition de dépense. Quand tu payes, tu n’écris pas “à Kevin”. Tu écris “à cette condition”.
Ce cadre te donne un avantage concret. Tu comprends pourquoi deux adresses différentes peuvent appartenir au même wallet. Tu comprends aussi pourquoi une adresse peut changer à chaque réception. Ce n’est pas un bug. C’est une stratégie de vie privée. Réutiliser une adresse, c’est comme publier ton relevé bancaire.
Tu comprends aussi pourquoi les frais varient. Les frais ne dépendent pas du montant. Ils dépendent surtout de la taille de la transaction en octets virtuels. Et la taille dépend du type de script utilisé. Certaines adresses sont plus “compactes”. Elles coûtent moins cher à dépenser. C’est simple, mais souvent ignoré.
Dernier point du cadre. Une adresse n’est pas une preuve d’identité. Elle ne dit pas “qui”. Elle dit “comment”. Et si tu confonds les deux, tu te fais manipuler plus facilement. Un scammer peut te donner une adresse. Ça ne prouve rien sur lui. Ça prouve juste qu’il sait copier-coller.
Garde une idée en tête: dans Bitcoin, tout tourne autour de la preuve. Tu prouves que tu peux dépenser, sans révéler plus que nécessaire. C’est pour ça que les formats, les clés et les signatures comptent autant.
Un bon test mental est simple. Si tu changes d’outil, la règle de sécurité ne change pas. Tu dois toujours pouvoir reconstruire ton contrôle à partir d’une seed, et vérifier ce que tu signes.
Il existe plusieurs formats d’adresses sur Bitcoin. Les trois grandes familles que tu dois connaître sont P2PKH, P2SH, et Bech32. Derrière ces sigles, il y a surtout des scripts différents, et donc des compromis différents.
P2PKH : l’ancien standard “adresse en 1…”
P2PKH veut dire “Pay to Public Key Hash”. C’est l’ancien standard le plus connu. Ces adresses commencent souvent par “1”. Elles utilisent un encodage Base58Check. Tu y vois des lettres et des chiffres, sans caractères ambigus comme 0, O, I, l. L’objectif est de limiter les erreurs humaines.
Le principe est simple. L’adresse contient le hash de ta clé publique. Quand tu voudras dépenser, tu devras fournir deux choses. Ta clé publique, et une signature faite avec ta clé privée. Le script vérifie que la clé publique correspond au hash, puis vérifie la signature.
Pourquoi “hash de clé publique” et pas la clé directement ? Parce que ça réduit la taille et ça ajoute une couche de prudence. Ta clé publique n’apparaît on-chain qu’au moment où tu dépenses. Tant que tu reçois et que tu ne dépenses pas, la clé publique n’est pas exposée. Ce n’est pas une magie. C’est une réduction d’information.
P2SH : l’adresse “en 3…” pour scripts et multisig
P2SH veut dire “Pay to Script Hash”. Ces adresses commencent souvent par “3”. L’idée est très pratique. Au lieu de payer vers un hash de clé publique, tu payes vers un hash de script. Donc tu payes vers un contrat. Mais tu n’écris pas tout le contrat au moment de recevoir. Tu n’écris qu’un hash.
Le gros avantage, c’est la flexibilité. Les cas classiques sont le multisig et certains scripts plus complexes. Par exemple, “2 signatures sur 3” pour dépenser. Ou “une clé peut dépenser, sinon une autre clé après une date”. P2SH a rendu ces usages plus accessibles, sans forcer le payeur à gérer la complexité.
Le coût, c’est qu’au moment de dépenser, tu dois révéler le script et les données qui le satisfont. Donc la dépense peut être plus lourde que des scripts plus modernes. Et ce poids se reflète dans les frais. Tu le ressens surtout en période de mempool chargé.
Bech32 : les adresses “bc1…” et SegWit
Bech32 est d’abord un format d’encodage. Il a été introduit avec SegWit via le BIP173. Tu reconnais ces adresses car elles commencent par “bc1”. Elles sont conçues pour réduire les erreurs. Elles ont un checksum robuste. Elles évitent la confusion de casse. Elles sont aussi plus adaptées aux QR codes.
Le point important n’est pas esthétique. Le point important est lié à SegWit. Avec SegWit, une partie des données de signature est séparée. On appelle ça le “witness”. Cela règle des problèmes de malléabilité et, surtout pour toi, ça réduit le coût des signatures dans le calcul des frais. Résultat: dépenser depuis une adresse SegWit est souvent moins cher.
Tu as deux sous-familles utiles. “bc1q…” correspond souvent à P2WPKH (SegWit natif, clé publique hash). “bc1p…” correspond à Taproot (P2TR). Taproot améliore la confidentialité et l’efficacité de certains scripts. Et il simplifie la manière de représenter des conditions complexes.
À retenir: P2PKH est largement compatible, mais moins efficace. P2SH permet des scripts, mais coûte souvent plus cher à dépenser. Bech32, surtout en SegWit natif et Taproot, est souvent le meilleur compromis moderne, si tes outils le supportent.
Les types d’adresses te donnent un signal de format. P2PKH commence souvent par “1”. P2SH commence souvent par “3”. Bech32 commence par “bc1”. Taproot commence souvent par “bc1p”.
Ce n’est pas juste esthétique. Le format impacte les fees, car la taille de la transaction change. En général, SegWit et Bech32 réduisent la taille, donc réduisent les frais.
Exemple concret: si tu envoies souvent de petites sommes, une adresse SegWit te fait gagner sur le long terme. Si tu utilises une vieille adresse legacy, tu payes souvent plus cher pour la même action.
Dans la pratique, le type d’adresse impacte trois choses. D’abord, la compatibilité. Ensuite, les frais. Enfin, la vie privée. Et ces trois points se voient dans ton quotidien.
Commençons par la compatibilité. Aujourd’hui, la plupart des plateformes et wallets supportent Bech32. Mais tu peux encore tomber sur des services anciens. Ils acceptent “1” et “3”, mais pas “bc1”. Dans ce cas, tu n’as pas besoin de paniquer. Tu choisis un format compatible. Tu restes pragmatique. Mais tu sais ce que tu perds en frais et en modernité.
Ensuite, les frais. Beaucoup de débutants pensent que les frais dépendent du montant envoyé. Non. Les frais dépendent surtout de la taille de la transaction. Or la taille dépend des inputs et des scripts. Les scripts SegWit sont plus efficaces car une partie du witness est “pondérée” différemment. Résultat: à fees rate égal, tu payes souvent moins.
Tu peux voir ça comme une valise. Sur Bitcoin, tu payes surtout au kilo, pas à la valeur. Une transaction “petite” avec un gros montant peut coûter moins qu’une transaction “grosse” avec un petit montant. Les types d’adresses influencent ce “poids”.
Enfin, la vie privée. Réutiliser une adresse P2PKH ou Bech32 est une mauvaise habitude. Une adresse réutilisée lie tes réceptions entre elles. Elle facilite les analyses. Les wallets modernes utilisent des adresses dérivées. Ils changent l’adresse automatiquement. Ce n’est pas “pour faire joli”. C’est pour limiter les corrélations.
Il y a aussi un impact sur les usages avancés. Le multisig est souvent associé à P2SH ou à des variantes SegWit (comme P2WSH). Taproot ouvre d’autres possibilités. Certaines conditions peuvent rester privées si elles ne sont pas utilisées. C’est une amélioration importante. Mais ce n’est pas “invisible”. C’est une amélioration de fuite d’information.
Et n’oublie pas un point simple. Une adresse ne dit pas sur quelle “chaine” tu es. Tu peux avoir des formats qui se ressemblent sur d’autres réseaux. Le danger, c’est d’envoyer sur le mauvais réseau ou la mauvaise chaîne. Donc tu dois toujours vérifier le réseau choisi dans ton wallet et dans la plateforme. Et tu testes en petit d’abord.
Une implication pratique est l’optimisation des frais. En choisissant des formats modernes et en gérant tes UTXO, tu peux réduire tes coûts sur le long terme. C’est une discipline simple, mais souvent ignorée.
Un exemple concret: si tu reçois plein de petits dépôts, tu crées plein d’inputs futurs. Le jour où tu dépenses, tu payes plus de vB. Faire une consolidation quand les fees sont bas peut aider.
Autre implication: la congestion est cyclique. Il y a des périodes calmes et des périodes chargées. Apprendre à attendre, ou à utiliser RBF/CPFP, te donne un contrôle que beaucoup n’ont pas.
La meilleure pratique, c’est la vérification. Quand tu reçois une adresse, vérifie au moins trois choses. Le préfixe (“1”, “3”, “bc1”). Le réseau (Bitcoin, pas une autre chaîne). Et la correspondance, si tu as un appareil matériel, entre l’écran du device et l’adresse affichée sur l’ordinateur.
Ce dernier point est sous-estimé. Un malware peut remplacer l’adresse copiée dans le presse-papiers. Tu penses envoyer à ton adresse. Tu envoies à celle de l’attaquant. Un hardware wallet affiche l’adresse réelle. Et tu peux comparer. C’est un réflexe simple qui sauve des vies.
Deuxième point: évite la réutilisation. Si tu donnes une adresse fixe publiquement, tu crées une carte de visite financière. Parfois c’est volontaire, comme pour recevoir des dons. Mais si ce n’est pas volontaire, évite. Utilise une nouvelle adresse par paiement. Ou utilise des solutions adaptées à la réception répétée.
Troisième point: attention aux adresses “compatibilité”. Il existe des adresses SegWit encapsulées en P2SH. On les appelle souvent “nested SegWit”. Elles commencent par “3”, mais elles bénéficient d’une partie des gains SegWit. C’est utile si tu dois rester compatible avec des systèmes anciens. Mais si tu peux, privilégie le SegWit natif “bc1q”.
Enfin, mets le disclaimer clairement. Je ne te conseille pas d’acheter Bitcoin. Je t’explique les formats d’adresses. Les risques sont réels. Une erreur de réseau ou une adresse compromise peut faire perdre des fonds. Fais ton propre research (DYOR). Test en petit d’abord avant scaling. Les gains ne sont jamais garantis. Et les choses bougent vite, cet article peut dater.
Adopte une routine simple. Regarde l’état du mempool avant un envoi important. Si c’est chargé, soit tu payes plus, soit tu attends. Le pire choix est d’envoyer au hasard et stresser.
Apprends deux outils: RBF et CPFP. RBF te permet d’augmenter les frais d’une transaction non confirmée. CPFP te permet de “pousser” un parent en payant plus sur l’enfant. Ce sont des outils de contrôle.
Enfin, pense à la structure de tes UTXO. Évite d’accumuler trop de poussière. Si tu en as, consolide quand les fees sont bas. C’est une hygiène, pas une stratégie de profit.
Erreurs courantes
Première erreur: envoyer au hasard quand le mempool est saturé. Tu te retrouves bloqué, puis tu paniques. Deuxième erreur: ignorer RBF et CPFP. Tu perds un levier simple pour débloquer une situation. Troisième erreur: accumuler des dizaines de petits UTXO par habitude. Le jour où tu dépenses, tes frais explosent. Si tu veux éviter ça, regarde les fees avant d’envoyer, et consolide quand c’est calme.
Évolution
Avant, l’usage Bitcoin était très “legacy”. Beaucoup d’adresses commençaient par 1 ou 3, et les frais étaient souvent moins optimisés. Avec SegWit puis Taproot, l’écosystème a gagné en efficacité et en confidentialité potentielle, mais l’adoption dépend des wallets. Aujourd’hui, tu vois plus de Bech32, plus de gestion fine des frais, et plus de couches comme Lightning. La tendance, c’est une UX plus simple, avec de la complexité cachée. À toi de comprendre ce que ton outil fait vraiment.
Cas limites
Cas limite: deux outils peuvent te donner deux lectures différentes, même sans mensonge. Un nœud peut avoir une politique de mempool différente. Un wallet peut cacher un détail pour simplifier. Autre nuance: certains concepts ont des exceptions historiques, surtout sur de vieux scripts ou de vieux wallets. Si tu tombes sur un comportement étrange, ne saute pas à la conclusion “Bitcoin est cassé”. Cherche l’implémentation, le standard, et la version. Souvent, c’est là que se trouve l’explication.
Le presse-papiers est une cible classique. Un malware peut remplacer l’adresse copiée. Compare toujours l’adresse sur un écran de confiance.
Penser qu’une adresse est un identifiant personnel. Une adresse est un script. Et une adresse réutilisée réduit ta vie privée.
Si tu hésites, choisis “bc1q” pour recevoir. Puis envoie un micro-montant test. Tu valides compatibilité et process sans stress.
Conclusion avec action
Une adresse Bitcoin est un cadenas, pas un compte. P2PKH, P2SH et Bech32 représentent des scripts différents. Ils changent compatibilité, frais et vie privée.
Ta prochaine étape est simple. Regarde dans ton wallet les formats disponibles. Fais une réception en “bc1q”. Puis dépense une petite somme. Observe la taille et les frais. Fais ton propre research (DYOR). Et avance prudemment.
