Fondamentaux du Bitcoin

Types d'adresses Bitcoin expliqués

Comparez les formats d'adresses legacy, SegWit imbriqué, SegWit natif et Taproot, leurs préfixes, compatibilité et limites de sécurité.

Réponse directe

Comparez les formats d'adresses legacy, SegWit imbriqué, SegWit natif et Taproot, leurs préfixes, compatibilité et limites de sécurité.

Deux adresses Bitcoin peuvent toutes deux recevoir des BTC et créer néanmoins des structures de transaction différentes en dessous. Une adresse de réseau principal commençant par 1, une commençant par 3, une adresse bc1q et une adresse bc1p peuvent toutes être des destinations valides, mais elles ne représentent pas nécessairement le même script, le même encodage ou la même condition de dépense future.

Cette différence est facile à manquer car le portefeuille présente une adresse comme une simple chaîne de caractères. En dessous, l'adresse indique au logiciel comment construire une sortie de transaction. Une fois cette sortie confirmée, elle devient un UTXO qui devra plus tard être dépensé selon les règles de script encodées par cette sortie.

La question pratique n'est donc pas simplement “ Quel préfixe est le plus récent ? ” Il s'agit de savoir si l'adresse appartient au réseau Bitcoin prévu, quel type de sortie elle représente, si le logiciel d'envoi prend en charge ce format, et ce que l'adresse peut—et ne peut pas—vous dire avant d'autoriser un paiement.

Ce que représente une adresse Bitcoin

Une adresse Bitcoin n'est pas un compte au sens bancaire. Elle ne contient pas de bitcoin, ne détient pas de clé privée et ne fournit pas une vue complète du solde d'un portefeuille. C'est un encodage lisible par l'homme qui aide un portefeuille à construire une sortie de transaction particulière.

La relation simplifiée est :

Adresse Bitcoin
        ↓
Décodage de l'adresse
        ↓
scriptPubKey
        ↓
Sortie de transaction
        ↓
UTXO confirmé
        ↓
Condition de dépense future

Lorsque vous envoyez du bitcoin, le portefeuille ne déplace pas un objet d'une chaîne d'adresse à une autre. Il consomme des UTXO existants comme entrées de transaction et crée de nouvelles sorties. L'adresse de destination fournit les informations nécessaires pour construire l'une de ces sorties.

C'est pourquoi un format d'adresse compte techniquement. Une adresse P2PKH conduit à un script de sortie différent d'une adresse P2WPKH. Une sortie Taproot P2TR est encore différente. Ces sorties peuvent toutes représenter des bitcoins dépensables, mais les conditions et la sérialisation utilisées lors de leur dépense ne sont pas identiques.

L'adresse n'est pas la clé privée

La clé privée reste distincte de l'adresse. Un portefeuille utilise le matériel de clé privée pour créer la signature ou les données de témoin requises par la condition de dépense. Publier une adresse de réception ne publie pas la clé privée.

L'inverse est également important : voir une adresse ne prouve pas qu'une personne particulière contrôle la clé correspondante. L'analyse de la blockchain peut observer les transactions et les sorties, mais une chaîne d'adresse seule n'est pas une preuve d'identité.

Pourquoi plusieurs formats existent

Bitcoin a plusieurs formats d'adresse parce que le système de transaction a évolué tout en maintenant la compatibilité avec les sorties plus anciennes. Les nouveaux formats n'ont pas remplacé les anciennes sorties sur la blockchain. Au lieu de cela, ils ont introduit des moyens supplémentaires d'exprimer les conditions de dépense.

Les quatre formats que la plupart des utilisateurs rencontrent sur le mainnet Bitcoin sont :

Legacy P2PKH, généralement affiché avec une adresse commençant par 1.
P2SH, commençant généralement par 3; SegWit imbriqué est une utilisation importante de P2SH, mais pas la seule.
Native SegWit, encodé avec Bech32 et commençant généralement par bc1q pour la version de témoin 0.
Taproot, encodé avec Bech32m et commençant par bc1p pour les sorties P2TR de version de témoin 1.

Le changement important n'est pas l'apparence de la chaîne. C'est ce que la destination décodée dit au portefeuille de placer dans la nouvelle sortie.

Types d'adresses Bitcoin comparés

Nom commun	Préfixe du réseau principal	Encodage	Sortie typique	Ce que le préfixe vous indique
Legacy	`1`	Base58Check	P2PKH	Famille d'octets de version pour une adresse de hachage de clé publique du réseau principal
P2SH (y compris SegWit imbriqué)	`3`	Base58Check	P2SH ; le SegWit imbriqué est une construction possible de script de remboursement	La destination est P2SH, pas le script de remboursement exact qu'il contient
Native SegWit	`bc1q`	Bech32	Témoin v0, généralement P2WPKH ou P2WSH	Destination Bech32 de version de témoin 0 sur le réseau principal
Taproot	`bc1p`	Bech32m	P2TR	Destination Taproot de version de témoin 1 sur le réseau principal

Ce tableau est utile pour l'identification, mais le préfixe n'est pas une description complète du comportement de dépense futur. L'exemple le plus clair est une 3... adresse : elle identifie P2SH, mais P2SH peut s'engager sur de nombreux scripts de remboursement. Le SegWit imbriqué n'est qu'une possibilité.

Adresses P2PKH héritées

Le paiement à clé publique hachée hérité, ou P2PKH, est le format d'adresse le plus associé aux premiers logiciels de portefeuille Bitcoin. Sur le réseau principal, ces adresses Base58Check commencent normalement par 1.

L'adresse représente un hachage d'une clé publique. Lorsqu'un portefeuille paie vers cette destination, il crée un script de verrouillage P2PKH qui exige une signature valide et la clé publique correspondante lorsque la sortie est dépensée.

OP_DUP
OP_HASH160
<20-byte public-key hash>
OP_EQUALVERIFY
OP_CHECKSIG

L'adresse visible n'est donc pas le script lui-même. Le portefeuille décode l'adresse Base58Check, extrait la version et la charge utile, et construit le scriptPubKey approprié.

Les sorties P2PKH restent des sorties Bitcoin valides. “ Legacy ” ne signifie pas invalide ou automatiquement dangereux. La distinction devient pertinente lorsqu'on compare la structure des transactions : dépenser une sortie P2PKH traditionnelle place les données de déverrouillage dans le script d'entrée plutôt que d'utiliser la sérialisation du témoin SegWit.

Cette différence peut augmenter le poids de la transaction par rapport aux dépenses de clé SegWit courantes. Cela ne signifie pas qu'un paiement P2PKH a automatiquement des frais particuliers. Le nombre d'entrées, le nombre de sorties, le taux de frais sélectionné et le reste de la transaction signée déterminent toujours le coût final.

P2SH et SegWit imbriqué

Le paiement à hachage de script, ou P2SH, a déplacé une partie de la logique de dépense derrière un hachage. Les adresses P2SH du réseau principal utilisent Base58Check et commencent normalement par 3.

Une sortie P2SH standard place le hachage du script de remboursement dans le script de verrouillage :

OP_HASH160
<20-byte script hash>
OP_EQUAL

Le script de rachat complet n'est fourni que lorsque la sortie est dépensée. Cela a créé un outil de compatibilité important lors de l'introduction de SegWit : un programme témoin SegWit pouvait être placé dans un script de rachat P2SH, permettant à un expéditeur comprenant les adresses P2SH ordinaires de payer une sortie qui serait ensuite dépensée en utilisant les règles SegWit.

Une construction courante à clé unique est appelée P2SH-P2WPKH :

Adresse P2SH
    ↓
hash du redeemScript
    ↓
le redeemScript contient un programme témoin P2WPKH
    ↓
la signature et la clé publique sont fournies via les données témoins lors de la dépense

Un préfixe 3 ne prouve pas SegWit

C'est l'une des limites les plus importantes de l'identification visuelle des adresses. Une adresse commençant par 3 vous indique que la destination utilise la version d'adresse P2SH du réseau principal. Cela ne révèle pas le script de rachat complet avant que la sortie ne soit dépensée.

P2SH existait avant SegWit et peut encapsuler d'autres scripts. Considérer chaque 3... adresse comme “ une adresse SegWit ” est donc trop large.

Limite technique : le préfixe identifie le format d'adresse externe. Il ne prouve pas le script exact caché derrière un hash P2SH.

SegWit natif et bc1q

SegWit natif supprime le wrapper de compatibilité P2SH et représente le programme témoin directement. BIP 173 a introduit l'encodage Bech32 pour les adresses SegWit natives.

Sur le réseau principal Bitcoin, la partie lisible par l'homme est bc. La version 0 du témoin produit des adresses communément reconnaissables par le début bc1q.

Deux sorties courantes de version 0 du témoin sont :

P2WPKH: un programme témoin de 20 octets couramment utilisé pour les paiements de portefeuille à clé unique.
P2WSH: un programme témoin de 32 octets qui s'engage sur un script témoin.

L'adresse elle-même donne au portefeuille la version du témoin et le programme. Pour la version 0 du témoin, les scripts de sortie courants ont ces formes :

P2WPKH : OP_0 
P2WSH : OP_0

La sortie contient directement le programme témoin au lieu d'un wrapper P2SH. Lorsque l'UTXO est dépensé, la signature ou les données de script requises par le programme témoin sont fournies dans le témoin de la transaction plutôt que dans un scriptSig traditionnel de style P2PKH.

Bech32 modifie également la détection d'erreurs

Bech32 n'est pas simplement un alphabet différent. Il inclut une somme de contrôle conçue pour cette famille d'adresses et sépare la partie réseau lisible par l'homme des données de programme témoin encodées.

Les chaînes Bech32 ne doivent pas mélanger les caractères majuscules et minuscules. Les portefeuilles affichent normalement les adresses Bech32 du réseau principal Bitcoin en minuscules. Un encodage entièrement en majuscules peut être valide selon la spécification, mais un mélange de casse est invalide.

Taproot et bc1p

Taproot a introduit les sorties pay-to-Taproot, ou P2TR. P2TR utilise la version de témoin 1 avec un programme témoin de 32 octets. Sur le réseau principal Bitcoin, l'adresse résultante commence par bc1p.

La version de témoin 1 et les versions ultérieures utilisent Bech32m plutôt que la somme de contrôle Bech32 d'origine. BIP 350 a introduit ce changement après qu'une faiblesse a été identifiée dans l'utilisation du comportement de la somme de contrôle Bech32 d'origine pour les versions de témoin plus récentes.

Cela donne une règle d'identification pratique :

bc1q... → version de témoin 0 → Bech32
bc1p... → version de témoin 1 P2TR → Bech32m

Le script de verrouillage P2TR correspondant utilise la version de témoin 1 et une clé de sortie Taproot de 32 octets :

OP_1 <32-byte Taproot output key>

Une sortie P2TR s'engage sur cette clé de sortie Taproot. Elle peut ensuite être dépensée via le chemin de clé ou, si un arbre de script a été engagé, via un chemin de script révélé valide.

L'adresse ne révèle pas quel chemin sera finalement utilisé. Voir bc1p vous indique que la sortie est P2TR. Cela ne vous dit pas si le futur dépensier utilisera une signature de chemin de clé ou révélera un chemin de script.

Ce que les préfixes Bitcoin vous disent vraiment

Les préfixes sont utiles car ils permettent à un humain d'identifier rapidement la famille d'adresses et le réseau probables. Ils doivent être traités comme une vérification initiale, et non comme une validation complète.

Exemple de début	Signification probable pour le mainnet	Ce que cela ne prouve pas
`1...`	Adresse mainnet P2PKH	Propriétaire, solde ou identité du destinataire
`3...`	Adresse mainnet P2SH	Que le script de remboursement est imbriqué SegWit
`bc1q...`	Adresse native de témoin version 0	S'il s'agit de P2WPKH ou P2WSH par le préfixe seul
`bc1p...`	Adresse P2TR de témoin version 1	Quel chemin de dépense Taproot sera utilisé plus tard

Le préfixe ne peut pas non plus authentifier la personne qui vous a donné l'adresse. Une adresse parfaitement encodée et valide selon la somme de contrôle peut toujours appartenir au mauvais destinataire.

Le réseau vient avant le type d'adresse

Avant de choisir entre Legacy, SegWit ou Taproot, confirmez que l'adresse appartient au réseau Bitcoin que vous avez l'intention d'utiliser.

Les adresses de la famille Bech32 rendent cela visible via leur partie lisible par l'homme. BIP 173 définit bc pour le mainnet Bitcoin et tb pour les adresses de testnet Bitcoin. La partie lisible par l'homme fait donc partie de la validation du réseau, et non de la décoration.

Les familles d'adresses Base58Check utilisent également des octets de version différents entre le réseau principal et les réseaux de test, même si la différence est moins évidente pour un utilisateur qui ne regarde que la chaîne.

Un portefeuille doit rejeter une combinaison réseau/adresse non prise en charge, mais la responsabilité finale reste de confirmer le réseau affiché par l'application d'envoi. La reconnaissance du format d'adresse ne remplace pas la vérification du réseau.

Pour le contexte plus large de la transaction—entrées, sorties, confirmations et la couche de base Bitcoin—utilisez le réseau Bitcoin.

Type d'adresse et frais de transaction

Il est courant d'entendre qu'une adresse Bitcoin plus récente est “ moins chère ”. Cette affirmation est utile dans certaines comparaisons, mais trop simple pour être utilisée comme règle de frais.

L'adresse choisie par un destinataire affecte le type et la taille sérialisée de la sortie créée aujourd'hui. Plus important encore, lorsque cette sortie est dépensée plus tard, son type de script affecte la structure de l'entrée de transaction correspondante.

SegWit modifie également la comptabilité Weight de la transaction car les octets de témoin sont pondérés différemment des octets non témoins. Une dépense de clé Native SegWit courante a donc un profil Weight différent d'une dépense Legacy P2PKH comparable. Cela affecte la taille virtuelle lorsque le UTXO est dépensé, mais cela ne fixe toujours pas le frais total à l'avance.

Le même montant BTC peut entraîner des coûts futurs différents

Considérez deux utilisateurs qui reçoivent chacun la même quantité de bitcoin. L'un reçoit une sortie P2PKH et l'autre reçoit une sortie P2WPKH. La valeur est identique. La structure d'entrée future ne l'est pas.

Lorsque ces UTXO sont dépensés plus tard, leurs données de déverrouillage sont sérialisées différemment. Cela modifie le Weight de la transaction et donc la taille virtuelle. Au même taux sat/vB, un vSize différent signifie un frais total différent.

Il s'agit d'un scénario technique illustratif, et non d'un enregistrement de transaction utilisateur ou d'une affirmation concernant un portefeuille spécifique.

Le type d'adresse ne détermine pas le frais final par lui-même. Une transaction avec de nombreuses entrées SegWit efficaces peut être plus grande qu'une transaction avec une seule entrée Legacy. Le nombre de sorties, les signatures, les chemins de script et le taux de frais choisi comptent également.

Pour la relation complète entre Weight, la taille virtuelle et sat/vB, lisez comment fonctionnent les frais de transaction Bitcoin. Lorsque vous avez besoin d'une estimation spécifique à une transaction plutôt que d'une comparaison conceptuelle, utilisez le Calculateur de frais de transaction Bitcoin.

La compatibilité est une vérification de l'expéditeur

Une adresse Bitcoin valide n'est pas utile à un flux de paiement si le portefeuille d'envoi ou le service de retrait ne comprend pas le format.

Cette distinction était particulièrement importante lors de l'adoption de SegWit natif et plus tard de Taproot. Le réseau Bitcoin pouvait reconnaître le type de sortie tandis que les applications plus anciennes ne prenaient pas en charge la création de cette destination.

Lorsqu'un service rejette une bc1q ou bc1p adresse, ne modifiez pas l'adresse manuellement. Ne supprimez pas de caractères, ne changez pas le préfixe et ne le convertissez pas via un site Web arbitraire. Utilisez un format d'adresse que votre portefeuille de réception a réellement généré et que l'expéditeur prend explicitement en charge.

Envoyer entre les formats n'est pas une conversion

Vous n'avez pas besoin d'un portefeuille Legacy pour payer une adresse Legacy ni d'un portefeuille Taproot pour payer une adresse Taproot dans le sens où les formats source et destination doivent correspondre. La transaction d'envoi consomme les UTXOs pris en charge que le portefeuille sélectionne et crée une nouvelle sortie pour le script de destination.

La question pertinente est de savoir si le logiciel d'envoi peut décoder et construire la sortie de destination demandée.

Une adresse valide peut toujours être incorrecte

Les sommes de contrôle détectent certaines erreurs de transcription. Elles n'authentifient pas le destinataire prévu.

Si un logiciel malveillant remplace une adresse copiée par une autre adresse Bitcoin valide, le remplacement peut passer parfaitement la validation de la somme de contrôle. Le format technique est valide ; la destination est incorrecte.

C'est pourquoi “ le portefeuille a accepté l'adresse ” n'est pas le contrôle de sécurité final. L'acceptation vous indique que le logiciel a reconnu une destination valide ou prise en charge. Elle ne prouve pas d'où vient l'adresse.

Vérifiez avant d'envoyer

Un processus de vérification utile sépare la validation du format de la validation du destinataire.

Confirmez le réseau. Assurez-vous que le portefeuille ou le service envoie Bitcoin sur le réseau Bitcoin prévu plutôt qu'un autre actif ou un environnement de test.
Lisez la famille d'adresses. A 1, 3, bc1q ou bc1p Le préfixe vous donne un premier indice sur le format.
Confirmez la prise en charge par l'expéditeur. Le service de retrait ou le portefeuille doit accepter explicitement le format de destination.
Vérifiez la destination via un canal de confiance. Comparez l'adresse complète sur un écran de confiance lorsque cela est pratique plutôt que de vous fier uniquement à quelques caractères de début et de fin.
Examinez l'écran de transaction final du portefeuille. Confirmez le destinataire, le montant, les frais de réseau et tout changement avant de signer.
Protégez les éléments privés. La vérification de l'adresse de réception ne vous oblige jamais à saisir une phrase de récupération ou une clé privée sur un site Web.

Pour les transferts importants ou sensibles sur le plan opérationnel, les organisations ajoutent souvent des procédures indépendantes de vérification de destination. Ces procédures sont un contrôle opérationnel, et non une propriété d'un format d'adresse Bitcoin spécifique.

La réutilisation d'adresse est un problème distinct

Une adresse Bitcoin n'expire pas au niveau du protocole simplement parce qu'elle a été utilisée une fois. Si la condition de dépense correspondante reste contrôlable, les paiements futurs vers la même adresse peuvent toujours créer des sorties valides.

Cela ne rend pas la réutilisation d'adresse souhaitable. Réutiliser une adresse de réception peut rendre les transactions plus faciles à associer sur la blockchain publique et peut réduire la confidentialité.

Cette question de confidentialité est distincte de la question de savoir si l'adresse est P2PKH, P2SH, P2WPKH ou P2TR. Un format d'adresse moderne ne rend pas privé l'usage répété de la même destination visible.

Les limites de la validation d'adresse

La validation du format répond à une question étroite : si la chaîne peut être décodée comme le type attendu de destination Bitcoin selon les règles d'adresse pertinentes. Elle n'authentifie pas la personne qui l'a fournie, ne prouve pas la propriété d'une clé privée, ne prouve pas le solde total d'un portefeuille, ne garantit pas qu'un service prend en charge le format et ne détermine pas les frais de transaction finaux.

Elle ne peut pas non plus révéler des informations délibérément cachées par la construction de la sortie. Une adresse P2SH n'expose pas le script de rachat complet avant la dépense, et une adresse P2TR ne vous dit pas à l'avance si la dépense future utilisera le chemin de clé ou révélera un chemin de script. Traitez le décodage réussi comme un contrôle dans le processus de paiement, pas comme une preuve que toutes les hypothèses environnantes sont correctes.

Choisir un format de réception

Le défaut le plus sûr est d'utiliser une adresse générée par le portefeuille que vous contrôlez réellement plutôt que de construire ou de convertir une adresse manuellement.

Si le portefeuille récepteur propose plus d'un type d'adresse, utilisez le type qui correspond à la politique de script prévue par le portefeuille et que l'expéditeur peut décoder. Une adresse P2WPKH est appropriée lorsque le portefeuille génère intentionnellement une destination de hachage de clé de version de témoin 0. Une adresse P2TR est appropriée lorsque le portefeuille génère intentionnellement une destination Taproot et que l'expéditeur la prend en charge. Les destinations plus anciennes P2PKH ou P2SH restent valides lorsqu'un flux de travail exige ces formats.

Ne choisissez pas un format uniquement parce que quelqu'un prétend qu'il est “ le moins cher ”. La sortie que vous créez aujourd'hui devient une entrée uniquement lorsqu'elle est dépensée plus tard, et le coût final de cette transaction future dépend de la structure complète de la transaction et du taux de frais.

L'adresse doit provenir du portefeuille récepteur. L'expéditeur doit la prendre en charge. Le réseau doit correspondre. Ces trois vérifications comptent plus que de rechercher un préfixe en soi.

FAQ sur les adresses Bitcoin

Quelle est la différence entre bc1q et bc1p ?

bc1q est généralement le début d'une adresse Bitcoin de version de témoin 0 du réseau principal encodée avec Bech32, telle que P2WPKH ou P2WSH. bc1p identifie une adresse P2TR de version de témoin 1 du réseau principal encodée avec Bech32m.

Chaque adresse Bitcoin commençant par 3 utilise-t-elle SegWit ?

Non. Une adresse du réseau principal commençant par 3 est une adresse P2SH. Le SegWit imbriqué peut utiliser P2SH, mais P2SH peut s'engager sur d'autres scripts de rachat, donc le préfixe seul ne prouve pas que la sortie est un SegWit imbriqué.

Les adresses Bitcoin sont-elles sensibles à la casse ?

Les adresses Base58Check utilisent un alphabet sensible à la casse. Les encodages Bech32 et Bech32m ne doivent pas mélanger les caractères majuscules et minuscules ; les portefeuilles Bitcoin les affichent normalement en minuscules. Ne modifiez pas manuellement la casse d'une adresse.

Puis-je envoyer Bitcoin d'un type d'adresse à un autre ?

Oui, lorsque le portefeuille expéditeur prend en charge le format de destination. Une transaction peut dépenser un type d'entrée pris en charge et créer un type de sortie différent pris en charge. Les préfixes de source et de destination n'ont pas à correspondre.

Une adresse Bitcoin expire-t-elle ?

Aucune règle de protocole ne fait expirer une adresse Bitcoin normale après une date définie ou après un paiement. Les portefeuilles génèrent souvent de nouvelles adresses de réception parce que la réutilisation d'adresse peut réduire la confidentialité, et non parce que les adresses précédemment générées deviennent automatiquement invalides.

Quel type d'adresse Bitcoin dois-je utiliser ?

Utilisez une adresse générée par le portefeuille récepteur pour le réseau Bitcoin et le type de script que vous avez l'intention d'utiliser, puis confirmez que l'expéditeur prend en charge ce format. Le SegWit natif est courant pour les paiements modernes, tandis que Taproot est approprié lorsque les deux parties prennent en charge P2TR. Ne transformez pas manuellement un format d'adresse en un autre.

Sources techniques

Les descriptions de formats d'adresse ci-dessus sont basées sur les propositions d'amélioration Bitcoin et la documentation Bitcoin Core. Ces références définissent les encodages d'adresses, les programmes de témoin et le comportement des scripts ; elles ne prouvent pas l'identité ou la sécurité d'une adresse de réception spécifique. L'approche plus large de sourcing de BitcoinToolkit est décrite sur la Sources de données page.

BIP 13 : Format d'adresse pour pay-to-script-hash — spécifie le format d'adresse P2SH Base58Check.
BIP 16 : Pay to Script Hash — définit le modèle de dépense P2SH et l'évaluation du script de rachat.
BIP 49 : Schéma de dérivation pour P2WPKH imbriqué dans P2SH — documente la construction courante de SegWit imbriqué à clé unique discutée dans ce guide.
BIP 141 : Segregated Witness — définit les programmes de témoin, la transaction Weight et la sémantique de sortie SegWit.
BIP 173 : Format d'adresse Base32 pour les sorties de témoin natives v0-16 — a introduit l'encodage d'adresse Bech32 native SegWit.
BIP 350 : Format Bech32m pour les adresses de témoin v1+ — définit Bech32m et la règle de somme de contrôle pour les versions de témoin plus récentes.
BIP 341 : Taproot — définit les règles de sortie et de dépense Taproot, y compris la version de témoin 1 P2TR.
Descripteurs de sortie Bitcoin Core — documente les descriptions structurées des scripts de sortie Bitcoin courants et des expressions de clés.

Sources

Vous avez trouvé une erreur ? Signaler un problème de contenu ou lisez notre Politique de corrections.