Change Address

Alice a reçu 120 000 sat, les plus petites unités du bitcoin, et veut payer 100 000 sat. Dans cet exemple, ses fonds forment un UTXO : une sortie d’une transaction antérieure encore non dépensée. Elle devient une entrée du paiement et est dépensée en entier. Avec 2 000 sat de frais, le destinataire reçoit 100 000 sat et les 18 000 sat restants vont dans une nouvelle sortie du portefeuille d’Alice. Cela ressemble à un paiement avec un gros billet dont on rend la monnaie, mais les deux montants sont répartis dans une seule transaction. Alice n’attend pas que le destinataire lui rembourse quoi que ce soit. Le portefeuille choisit normalement l’adresse de change lui-même. Un explorateur peut donc afficher deux adresses de destination, alors qu’Alice a payé une seule personne. Après confirmation, le change est un nouvel UTXO avec sa propre référence de sortie, l’outpoint ; ce n’est pas un morceau inutilisé de l’ancienne sortie. Un outpoint associe l’identifiant de la transaction, txid, à la position de la sortie dans cette transaction. Alice pourra le dépenser comme ses autres fonds. [1]

Le script scriptPubKey fixe les conditions à respecter pour dépenser une sortie. Il n’indique pas pourquoi vous avez envoyé l’argent. Un bloc contient des montants et des scripts scriptPubKey, pas des étiquettes désignant le payeur, le destinataire ou la monnaie rendue. Le portefeuille reconnaît ses propres sorties de monnaie rendue à partir de ses enregistrements de dérivation ; un explorateur de blocs ou un analyste en estime la fonction. Ni l’ordre des sorties ni la règle selon laquelle la deuxième serait la monnaie rendue ne sont fiables. Une transaction peut ne rendre aucune monnaie, avoir une sortie de monnaie rendue, plusieurs sorties contrôlées par l’expéditeur ou des sorties appartenant à plusieurs participants. La désignation change exprime donc la relation d’une sortie avec un portefeuille. Ce n’est pas une propriété distincte inscrite dans le protocole. [1]

Une heuristique est une déduction à partir d’indices indirects. Payjoin et CoinJoin permettent à plusieurs participants de construire une transaction ensemble : les déductions simples peuvent donc échouer. Un BIP est un document de proposition technique ou de standard. Les heuristiques courantes repèrent la monnaie rendue à partir d’indices : une sortie du même type de script que les entrées, un montant non rond, une nouvelle adresse ou un montant correspondant au calcul du reliquat. Pour un paiement ordinaire à deux sorties, ces estimations peuvent fonctionner et relier des dépenses ultérieures, mais chacune admet des contre-exemples. BIP78 Payjoin remet délibérément en cause l’hypothèse d’un propriétaire commun des entrées et la reconnaissance de la monnaie rendue par le type de script ou les montants ronds. CoinJoin, les paiements groupés et les transferts entre ses propres adresses ajoutent d’autres ambiguïtés. Une estimation doit préciser son incertitude et les éléments qui l’étayent ; une heuristique seule ne constitue ni une preuve du protocole ni une preuve de propriété juridique. [4] [14]

Une PSBT est un ensemble contenant une proposition de transaction et des informations complémentaires, échangeable entre portefeuille et appareil de signature. Multisig impose une autorisation selon une règle impliquant plusieurs clés. Les données de dérivation des clés selon BIP32 dans les sorties d’une PSBT permettent à un appareil de signature matériel ou hors ligne de vérifier la monnaie rendue proposée. L’appareil doit dériver lui-même la sortie et contrôler qu’elle respecte les mêmes règles du portefeuille. BIP174 décrit la vérification pour une clé unique et pour Multisig ; avec plusieurs signatures, la présence d’une seule clé locale dans la sortie ne suffit pas. Un coordinateur malveillant qui assemble la transaction peut remplacer la monnaie rendue par sa propre sortie ou dissimuler le reliquat dans des frais excessifs. Avant de signer, vérifiez donc les sorties des destinataires, le total des frais et chaque sortie présentée comme de la monnaie rendue sur un écran de confiance. [5]

Pour le calcul, I désigne les fonds choisis, R les paiements aux destinataires, F les frais et C le change : C = I − R − F. RPC est une interface de programmation permettant d’envoyer des commandes au nœud. Coin Selection, la sélection des UTXO, détermine ensemble les entrées, les frais et l’éventuelle monnaie rendue. Une combinaison d’entrées exactement adaptée n’a pas besoin de sortie de monnaie rendue. Sinon, le portefeuille compare le reliquat au coût de création de cette sortie et de sa dépense ultérieure. Le RPC fundrawtransaction de Bitcoin Core peut ajouter au maximum une sortie de monnaie rendue et indique sa position. L’envoi de tous les fonds sélectionnés aux destinataires ne crée délibérément aucune monnaie rendue. La sélection manuelle avec Coin Control modifie les entrées et donc le montant rendu, mais chaque entrée sélectionnée est consommée intégralement. Vérifiez donc les entrées finales, les montants destinés aux bénéficiaires, les frais et la monnaie rendue, pas seulement le montant du paiement. [9] [10] [13]

Une HD Wallet dérive de nombreuses clés et adresses à partir d’un secret initial. Le chemin de dérivation précise quelle adresse calculer ; BIP désigne un document de proposition technique ou de standard. Une HD Wallet dérive généralement les adresses de réception sur une branche externe et les adresses de monnaie rendue sur une branche interne. BIP44 désigne change=0 comme la branche externe et change=1 comme la branche interne. Pour un compte SegWit natif, les chemins m/84'/0'/0'/0/i et m/84'/0'/0'/1/i en sont des exemples. C’est une convention des portefeuilles, pas une règle de consensus ; un portefeuille utilisant des descripteurs peut suivre d’autres règles. Une nouvelle adresse interne limite la réutilisation des adresses. Restituer le reliquat à l’adresse initiale est valide, mais relie l’historique des paiements et peut faciliter son attribution à une personne précise. [2] [3]

La notation xpub ci-dessous représente une clé publique étendue : elle permet de dériver des données publiques descendantes, mais pas de signer elle-même un paiement. Le seed est la valeur secrète initiale servant à dériver les clés. Un descripteur de sortie décrit le type de script, les clés, les informations sur leur origine et la règle de dérivation des adresses suivantes. La paire wpkh([fingerprint/84h/0h/0h]xpub…/0/*) et …/1/* peut ainsi décrire les branches de réception et de monnaie rendue ; BIP389 permet d’exprimer plusieurs branches dans une même notation. L’indicateur internal précise au portefeuille quel descripteur utiliser pour la monnaie rendue, sans modifier le script obtenu. Lors d’une restauration, le seed seul peut ne pas suffire à retrouver tous les fonds. Sans les informations sur le compte, le type de script et la méthode de dérivation, le portefeuille peut manquer des sorties de monnaie rendue valides alors que les clés nécessaires existent toujours. [6] [7] [8]

Dust désigne une sortie de très faible valeur évaluée selon les règles de relais des transactions d’un nœud. Le seuil applicable dépend du type de sortie, de la taille estimée des données nécessaires à sa dépense ultérieure et du taux de frais configurable dust relay feerate. Il ne s’agit ni d’un nombre universel de satoshis ni d’une interdiction imposée par le consensus. Un portefeuille peut refuser aussi une monnaie rendue supérieure à ce seuil si créer la sortie puis la dépenser coûte davantage que le montant restitué. Ce seuil économique dépend du taux de frais actuel, de l’estimation du taux futur et de la taille du script. Ne pas créer de monnaie rendue augmente les frais immédiats ; une sortie trop petite peut, à l’inverse, devenir excessivement coûteuse à dépenser plus tard. [12]

Replace-by-fee (RBF) remplace une transaction non confirmée par une autre dont les frais sont plus élevés. Le RPC bumpfee de Bitcoin Core peut couvrir la différence en réduisant la monnaie rendue, en ajoutant des entrées ou en créant une nouvelle sortie de monnaie rendue. Celle-ci peut disparaître si elle passe sous le seuil fixé par les règles du nœud ou la rentabilité économique. Dépenser une monnaie rendue non confirmée crée une transaction suivante qui dépend de la transaction initiale ; remplacer cette dernière peut invalider cette relation. La commande bumpfee refuse toutefois le remplacement si le portefeuille ou le mempool du nœud, sa réserve de transactions non confirmées, contient déjà une transaction qui dépense une sortie du paiement initial. CPFP (Child Pays for Parent) crée une transaction suivante au lieu de remplacer la première. Elle dépense une sortie du paiement initial contrôlée par le portefeuille et paie des frais plus élevés. Le taux de frais des deux transactions prises ensemble augmente ainsi, ce qui incite les mineurs à les confirmer ensemble. Tant que les remplacements ne sont pas réglés, ne considérez pas un txid non confirmé ni la référence de sortie outpoint comme définitifs. [11] [15]

La restauration doit retrouver les adresses de réception et de change. Pour un portefeuille classique à signature unique, la bonne Seed Phrase (mots de récupération), l’éventuelle passphrase utilisée et des réglages compatibles suffisent généralement. Le seed est la valeur secrète initiale servant à dériver les clés ; la passphrase est un mot de passe supplémentaire si vous aviez choisi d’en utiliser un. Tout utilisateur n’a donc pas besoin de noter des descripteurs manuellement. Avec des réglages personnalisés ou Multisig, où plusieurs clés encadrent l’autorisation, les mots seuls peuvent toutefois ne pas suffire. Conservez aussi la description du portefeuille : réseau, compte, type de script, règles de dérivation et, pour Multisig, les clés publiques étendues xpub de tous les participants, leur ordre et le nombre de signatures requis. Si la branche /1/* manque, la restauration peut ignorer le change et afficher un solde inférieur. Vérifiez les adresses et sorties connues des deux branches, la plage de dérivation et le début du parcours de l’historique. Le test doit aussi confirmer que vous pouvez préparer et signer correctement un paiement. [2] [6] [7]