Un portefeuille est une application ou un appareil permettant de recevoir et d’envoyer des bitcoins. Transaction Labeling consiste à ajouter des descriptions et des notes aux transactions, adresses ou autres enregistrements du portefeuille. Elles peuvent préciser le motif d’un paiement ou la provenance de fonds reçus. Ces métadonnées restent dans l’application, hors de la transaction Bitcoin, et ne prouvent pas à elles seules l’identité de l’autre partie.
Vous ouvrez l’historique du portefeuille et retrouvez un ancien paiement. Était-ce un acompte, un cadeau ou un transfert vers votre autre compte ? Une note « acompte réparation vélo » peut vous rappeler le but du paiement longtemps après. La renommer modifie une note de l’application, pas la transaction ni son identifiant txid. Aucun nouvel enregistrement dans la blockchain, l’historique public des transactions confirmées, n’est nécessaire. La même distinction compte lors d’une restauration : la Seed Phrase, les mots servant à retrouver les clés du portefeuille, ne contient pas vos notes personnelles. Retrouver la possibilité de dépenser et retrouver le contexte sont deux tâches différentes. [1] [3] [5]
Une note utile décrit ce que vous savez : numéro de facture, motif du paiement ou origine des fonds. Votre note n’est toutefois pas équivalente à une association automatique de l’application ou à une affirmation reprise d’un analyste. BTCPay Server utilise par exemple invoice pour un règlement de facture et payout pour un versement ou remboursement, et permet des étiquettes personnalisées. Ce contexte aide à utiliser Coin Control, la sélection manuelle des UTXO, sorties encore non dépensées. Chaque sortie indique un montant et les conditions à remplir pour le dépenser. Mais écrire « ne pas regrouper » ne suffit pas : ce sont les entrées effectivement choisies qui relient les sommes lors du prochain paiement. [1] [2]
Certains portefeuilles peuvent geler une sortie pour ne pas la sélectionner lors d’une dépense. BIP 329 transmet cet état local par spendable, seulement pour le type output. spendable:false utilise la valeur booléenne false ; la chaîne de texte "false" est différente. L’essentiel est simple : le gel évite une sélection involontaire dans cette application, pas toute dépense possible. Ce n’est pas un Timelock, une condition temporelle imposée par les règles Bitcoin. Un autre portefeuille disposant des bonnes clés peut dépenser la sortie si ses véritables conditions sont remplies. [1] [3]
En changeant d’application, prévoyez donc aussi un export séparé des notes. Il peut relier noms, factures et historique à des adresses ou à un XPUB, une clé publique étendue. Elle permet de calculer d’autres adresses pour la partie correspondante du portefeuille, mais un XPUB seul ne permet pas de signer des paiements. Si l’export comporte un enregistrement de type spscan, celui-ci contient une clé privée de détection des Silent Payments entrants. Elle n’autorise pas seule la dépense, mais sa divulgation nuit à la confidentialité. L’absence de clé privée de dépense ne rend donc pas le fichier anodin. Chiffrez les copies conservées et leur transfert, puis testez la restauration dans le bon compte. [1] [4] [5]
BIP 329 distingue tx, addr, pubkey, input, output, xpub et spscan : transaction, adresse, clé publique, entrée, sortie, clé publique étendue et expression de détection des Silent Payments. Le type détermine le sens de ref. Pour input, il s’agit de l’identifiant de la transaction et de l’indice de son entrée ; pour output, de la transaction créatrice et de l’indice de la sortie. txid:1 ne suffit donc pas sans type. Il pourrait désigner une entrée ou une sortie, objets différents. Assimiler toutes ces références à une « adresse de paiement » est dangereux. [1] [4]
BIP 329 échange les données en JSON Lines : un fichier texte UTF-8 avec un enregistrement structuré par ligne. Vous n’avez pas à l’écrire vous-même ; les deux applications doivent le comprendre. Les champs obligatoires type et ref indiquent l’objet. label, origin et spendable sont facultatifs. L’absence de label ou spendable ne devrait pas remplacer une valeur existante à l’import. Un importateur conforme doit ignorer les types inconnus. Ouvrir le fichier avec succès ne signifie donc pas avoir conservé toutes les notes et tous les réglages. [1]
Une transaction peut apparaître dans plusieurs comptes ou portefeuilles avec une description différente dans chacun. origin distingue ces points de vue. Il contient un Output Descriptor abrégé, description du portefeuille lisible par logiciel, avec les informations d’origine des clés mais sans clés réelles, chemins de dérivation enfants ni somme de contrôle. Il indique le portefeuille concerné par l’étiquette. Il ne signe pas le fichier et ne certifie pas la sincérité du motif saisi. Identifier le bon compte et faire confiance au contenu de la note sont deux choses différentes. [1]
Avant de quitter l’ancienne application, essayez le transfert sur une copie de test séparée. Choisissez des paiements connus et comparez l’objet, ref, le texte et un éventuel gel spendable. Vérifiez accents, comptes multiples, types inconnus et champs facultatifs absents. L’importateur peut ignorer des enregistrements non pris en charge ou raccourcir les étiquettes. Les 255 caractères suggérés sont une limite par défaut, pas une garantie universelle. Conservez l’ancienne sauvegarde jusqu’à avoir vérifié le contexte important. Le message « import terminé » ne le confirme pas à lui seul. [1]
Pour une vision complète, lisez aussi Coin Control, UTXO, Confidentialité de Bitcoin, Address Clustering, Seed Phrase, Output Descriptor. Cette entrée est également citée par Chain Surveillance.