Watch-only Wallet

Alice conserve ses clés dans un portefeuille matériel et veut vérifier un paiement depuis son téléphone. Elle y transfère la configuration publique du portefeuille, pas ses mots de sauvegarde. L’application reconnaît alors les adresses concernées et recherche leurs paiements sur le réseau. Alice voit un versement de 20 000 sat, les plus petites unités du bitcoin, et ses confirmations alors que l’appareil de signature reste éteint chez elle. Le téléphone n’a pas pour autant obtenu le droit de dépenser cet argent. De même, un commerçant peut donner à sa comptable une vue des paiements sans lui confier les clés. Tout dépend de ce qui a été importé : saisir une Seed Phrase, les mots permettant de retrouver les clés, supprimerait cette séparation. [12]

On peut ajouter l’adresse publique de quelqu’un d’autre à une application de suivi. Le montant affiché ne prouve donc pas que son utilisateur peut le dépenser, encore moins régler toutes ses dettes. L’application additionne les UTXO qu’elle trouve, c’est-à-dire les sorties de paiements antérieurs encore disponibles. Elle ne voit que ce qui correspond aux données importées et à l’historique accessible. Des adresses manquantes, une recherche inachevée ou un serveur peu fiable peuvent donner une vue incomplète. Un zéro à l’écran ne signifie pas à lui seul que les bitcoins sont perdus ; il faut d’abord vérifier le périmètre du suivi et la source des données. [8] [9]

Lorsqu’Alice veut payer, l’application choisit les UTXO disponibles et prépare destinataire, montant et frais. Elle peut renvoyer à son propre portefeuille la partie inutilisée d’une entrée : c’est la monnaie rendue, ou change. Ces informations peuvent être transmises dans une PSBT, le format de transaction Bitcoin partiellement signée défini par BIP174. L’appareil distinct reçoit ainsi ce qu’il lui faut pour signer sans avoir sa propre base UTXO. Alice doit vérifier sur son écran fiable le véritable destinataire, le montant, les frais et la monnaie rendue. Une application compromise pourrait préparer un autre paiement que celui prévu. Le réglage sighash compte aussi : il définit les parties de la transaction couvertes par la signature. Après vérification et signature seulement, la transaction finale, conforme à la proposition approuvée et aux règles du portefeuille, est diffusée. [2] [10]

Une clé publique étendue, ou xpub, permet de dériver d’autres clés publiques dans une branche du portefeuille ; elle ne signe pas de paiement à elle seule. Mais une personne qui l’obtient avec les règles du portefeuille peut relier les adresses accessibles, les paiements passés et futurs et les soldes. Cela révèle bien plus qu’une adresse pour un seul versement. Un serveur tiers peut reconstituer une vue similaire à partir des requêtes répétées de l’application. Votre propre Full Node, qui vérifie lui-même la blockchain, limite ce partage ; une connexion chiffrée ou privée ne cache pas les requêtes au serveur destinataire. N’exportez que le compte nécessaire, limitez les copies et protégez les étiquettes associant adresses, noms et motifs de paiement. [1] [13] [14]

Les sections suivantes constituent une référence technique pour la configuration et la récupération. Un script fixe les conditions de dépense ; un Output Descriptor décrit ces règles et les données nécessaires pour dériver les adresses. Un HD Wallet construit un arbre de clés à partir d’un seed, les données secrètes de départ utilisées pour dériver ces clés. La dérivation non-hardened produit d’autres clés publiques depuis un xpub, tandis que la dérivation hardened nécessite une clé privée. Multisig ajoute un nombre défini de signatures requises. Importer une adresse ne surveille que son script, pas les futures adresses de réception ou de monnaie rendue. Une clé publique ne couvre différents types de scripts que si le logiciel les dérive explicitement. Un xpub de compte permet des dérivations non-hardened, mais ne précise ni P2PKH, SegWit, Taproot, la branche interne, ni le seuil de signatures Multisig. Le descripteur complète ces informations. Exportez-le depuis le bon compte de l’appareil de signature, avec le réseau et le type de script corrects ; ne devinez pas le chemin de dérivation, la suite d’étapes depuis la clé de départ. [1] [4] [7]

Les portefeuilles HD séparent généralement la réception /0/* de la branche interne /1/* pour le change, la monnaie rendue. Sans la branche interne, des fonds peuvent sembler disparaître après une dépense. Un range trop petit, c’est-à-dire une plage trop étroite d’adresses dérivées, peut masquer des recettes. next_index définit la prochaine adresse à générer ; un décalage entre deux logiciels peut entraîner la réutilisation d’adresses. Gardez les descripteurs actifs, plages et index cohérents. Vérifiez l’adresse de réception sur l’appareil de signature : un logiciel malveillant peut la remplacer tout en affichant un solde plausible. [6] [9]

Dans Bitcoin Core, importdescriptors utilise timestamp pour définir le début du nouveau parcours de la chaîne. now ignore l’ancien historique, tandis que 0 demande une recherche depuis le Genesis Block. La plage range et la disponibilité des anciens blocs comptent aussi. active indique si le descripteur sert à produire de nouvelles adresses ; internal désigne les sorties internes au portefeuille, comme la monnaie rendue. Un nœud élagué, qui a supprimé les anciens blocs pour économiser de la place, peut ne plus disposer des blocs nécessaires. Un rescan ne fait que retrouver des transactions existantes. Conservez la date ou la hauteur de première utilisation et comparez la restauration à des adresses et transactions connues, pas seulement à un zéro affiché. [9] [10]

BIP380 définit un langage décrivant des ensembles de scripts de sortie. L’exemple wpkh([d34db33f/84h/0h/0h]xpub…/0/*)#checksum indique le type de script, l’empreinte de la clé maîtresse, le chemin d’origine, la clé publique du compte, la branche, l’index variable et la somme de contrôle. Ce n’est pas une donnée valide à importer. Taproot utilise tr() selon BIP386 ; BIP389 autorise plusieurs chemins dans une expression. La somme de contrôle détecte les erreurs de copie, pas l’identité de l’auteur. Un descripteur contenant xprv détient une clé secrète et n’a pas sa place dans un coordinateur d’observation. [4] [5] [6] [7]

BIP32 décrit une exception importante : le xpub d’un parent associé à la clé privée d’un descendant obtenu uniquement par des étapes non-hardened permet de calculer la clé privée du parent. Le xpub seul ne suffit pas ; c’est cette combinaison qui est dangereuse. Une étape hardened au-dessus du compte exporté empêche l’attaque de franchir cette limite. N’introduisez jamais xprv, seed ou clés privées dans le portefeuille d’observation, sa base ou les fichiers PSBT qui l’accompagnent. [1]

Observer un portefeuille Multisig exige le seuil de signatures, le type de script, le xpub de chaque cosignataire, l’origine et l’ordre des clés et les deux branches d’adresses. Un seul xpub ne suffit pas. Perdre le descripteur complique la restauration même avec des seeds intacts ; changer l’ordre ou l’enveloppe du script peut produire d’autres adresses. Vérifiez les règles et une adresse témoin sur tous les appareils de signature. Sauvegardez un descripteur avec somme de contrôle ou une configuration standard, en sachant qu’il révèle les liens entre cosignataires. [4] [11]

Conservez séparément des clés privées les deux descripteurs, l’origine des clés, le réseau, la date ou hauteur de création, les plages, index, étiquettes et règles Multisig. BIP329 transporte les étiquettes, sans remplacer le descripteur ni l’historique. Testez la restauration dans un profil distinct ou un réseau de test : importez la configuration publique, reparcourez l’historique, comparez les anciennes adresses des deux branches et les UTXO attendus, préparez une PSBT et signez avec l’appareil prévu. Vérifiez le résultat avant diffusion. Watch-only sert à observer et préparer, sans donner le droit de dépenser. [3] [9] [12]