Sortie de monnaie

Bitcoin dépense tout l'UTXO ; seule une partie ne peut pas être soustraite d’une entrée. Si le portefeuille choisit des entrées de 120 000 sats pour un paiement de 100 000 sats et des frais de 2 000 sats, il doit mettre les 18 000 sats restants dans la sortie suivante ou les conserver comme frais. La sortie du destinataire et la modification ont la même position dans la sérialisation, et l'ordre n'a aucune signification consensuelle. Une fois confirmé, le changement est un nouvel UTXO avec son propre point de sortie, sa confirmation et son prix de dépense futur. [Guide du développeur Bitcoin – Transactions]

La sélection des pièces sélectionne ensemble les entrées, les frais et les modifications possibles. La combinaison exacte ne produira pas le résultat ; sinon, le portefeuille compare le solde au coût de sa création et de sa dépense ultérieure. Financement RPC Bitcoin Core peut remplir au plus une sortie de modification et renvoie sa position, alors que send-all n'en a aucune. Le contrôle des pièces modifie les entrées utilisées, donc change, mais chaque entrée sélectionnée manuellement est consommée dans son intégralité. Vérifiez les entrées finales, les montants des bénéficiaires, les frais et la monnaie. [Bitcoin Core – Implémentation de la sélection de pièces] [Bitcoin Core RPC – fundrawtransaction] [Bitcoin Optech – Sélection de pièces]

Les portefeuilles HD dérivent généralement des scripts d'acceptation sur la branche externe et des modifications sur la branche interne. BIP44 marque change=0 comme externe et change=1 comme interne : par exemple m/84'/0'/0'/0/i et m/84'/0'/0'/1/i pour un compte SegWit natif. Il s’agit d’une convention d’application et non d’un consensus ; Le portefeuille de descripteur peut avoir une politique différente. La nouvelle adresse interne restreint la réutilisation des adresses, tandis que le retour à l'adresse d'origine est valide mais lie l'historique. [BIP 32 — Portefeuilles déterministes hiérarchiques] [BIP 44 — Hiérarchie multi-comptes]

Le descripteur de sortie combine le type de script, les clés, les origines et un caractère générique de dérivation spécifiant la propriété. La paire wpkh([fingerprint/84h/0h/0h]xpub…/0/*) et …/1/* décrit recevoir un changement ; BIP389 permet l'écriture multivoie. L'indicateur interne sélectionne le descripteur à modifier, il ne modifie pas le script lui-même. Une graine sans informations de compte, type de script et stratégie de dérivation peut laisser les modifications valides invisibles après une actualisation, même si les clés existent. [BIP 380 — Descripteurs de script de sortie] [BIP 389 — Expressions clés de descripteur multipath] [Bitcoin Core — Descripteurs de sortie]

Le bloc contient des valeurs et des scriptPubKeys, et non des étiquettes de payeur, de bénéficiaire ou de modification. Le portefeuille reconnaît sa propre modification à partir des enregistrements dérivés, l'explorateur se contente de le deviner. L'ordre de sortie ou la règle de la « deuxième sortie » n'est pas fiable. Une transaction peut n'avoir aucun changement, une, plusieurs sorties autocontrôlées ou des sorties de plusieurs participants. Le changement est donc une classification relative au portefeuille, et non une propriété écrite par le protocole. [Guide du développeur Bitcoin – Transactions]

Les heuristiques courantes désignent comme changement une sortie du même type de script que les entrées, un montant arrondi peu flatteur, une nouvelle adresse ou une valeur correspondant à l'arithmétique des entrées. Ils travaillent souvent pour un paiement ordinaire avec deux résultats, mais chacun a des contre-exemples. BIP78 Payjoin brise intentionnellement les heuristiques d'entrée commune, de type script et de montant rond ; CoinJoin, le traitement par lots et l'auto-transfert ajoutent encore plus d'ambiguïté. Le résultat est censé avoir un certain degré de certitude et de soutien, et non un statut de preuve de protocole. [BIP 78 — Payjoin] [Meiklejohn et al. — Une poignée de Bitcoins]

La poussière est la politique de relais du nœud calculée à partir du type de production, de la taille estimée de ses dépenses futures et du taux de relais de poussière réglable ; ce n'est pas un décompte satoshi universel ou une interdiction consensuelle. Un portefeuille peut rejeter la monnaie bien au-dessus de la poussière lorsque la création et les dépenses ultérieures coûtent plus que sa valeur. La limite économique dépend du tarif actuel et à long terme et de la taille du scénario. Supprimer le changement augmentera les frais d'aujourd'hui, trop peu de changement peut rester bloqué. [Bitcoin Core – Politique de relais de transactions]

Dans PSBT, les dérivations de sortie BIP32 permettent à un signataire matériel ou hors ligne de dériver la sortie proposée et de vérifier le retour à la même politique de portefeuille. BIP174 décrit la détection à la fois pour une clé unique et pour plusieurs signatures ; pour le multisig, faire correspondre une seule clé locale ne suffit pas. Un coordinateur malveillant peut remplacer la modification par sa propre sortie ou cacher le reste moyennant des frais exorbitants. Le signataire doit vérifier le destinataire, le montant total des frais et chaque modification déclarée sur l'écran de confiance. [BIP 174 — Format de transaction Bitcoin partiellement signé]

Le remplacement par des frais modifie les aspects économiques de la transaction non confirmée. les frais supplémentaires dans Bitcoin Core peuvent payer des frais plus élevés en réduisant les changements, en ajoutant des entrées ou en créant des changements ; après être tombé en dessous du changement politique ou économique, il disparaît. Dépenser des modifications non confirmées crée un descendant dépendant du remplacement du parent, et CPFP utilise une sortie contrôlée par le portefeuille pour augmenter le tarif du package. Ne considérez pas un txid/outpoint final non confirmé avant que les remplacements ne soient réglés. [Bitcoin Core RPC – tarif majoré]

La récupération complète nécessite des clés de départ ou de signature ainsi que des descripteurs de réception/internes, des origines de clé, un compte, un réseau, une politique de script, des plages de dérivation et un démarrage d'analyse suffisamment ancien. Un /1/* manquant tronque généralement le solde car la modification n'est pas trouvée. Pour le multisig, conservez tous les xpubs cosignataires, le seuil et l'ordre sur les deux branches. Testez la récupération en faisant correspondre les scripts de réception/modification connus, en reconstruisant l'UTXO, en créant un PSBT et en vérifiant la modification sur chaque signataire. [BIP 32 — Portefeuilles déterministes hiérarchiques] [BIP 380 — Descripteurs de script de sortie] [BIP 389 — Expressions clés de descripteur multipath]