Gap Limit indique au portefeuille après combien d’adresses inutilisées consécutives il doit arrêter de chercher. Lors d’une restauration depuis une sauvegarde, il recalcule les adresses et vérifie si elles ont un historique de transactions. Une règle d’arrêt lui évite de parcourir indéfiniment un immense ensemble de possibilités. Un paiement situé au-delà de cette limite peut manquer à l’affichage alors que son propriétaire possède les bonnes clés. Dépasser la limite n’efface pas les fonds et ne réduit pas le nombre de clés que l’on peut dériver.
Anna utilise un portefeuille, une application ou un appareil pour recevoir et envoyer des bitcoins. Elle a généré beaucoup d’adresses de réception à l’avance, les coordonnées nécessaires pour lui envoyer un paiement, sans toutes les utiliser. Après la restauration, certains paiements manquent. Imaginons une limite de 20 : l’adresse d’indice 0 a un historique, les indices suivants 1–20 n’en ont pas, et l’indice 21 a reçu un paiement. L’indice est simplement la position de l’adresse dans la suite ; la numérotation commence à zéro. La recherche s’arrête après la série vide, avant l’indice 21, et manque ce paiement. Si une adresse utilisée apparaissait dans la série examinée, le compteur d’adresses inutilisées repartirait de zéro. Cela ne signifie donc pas que le portefeuille entier est limité à vingt adresses. [1] [6]
Que veut dire inutilisée ici ? Ce n’est pas une adresse qui ne contient pas d’argent actuellement. Anna peut avoir reçu un paiement puis l’avoir dépensé entièrement. Le solde est nul, mais l’historique demeure et l’adresse compte toujours comme utilisée. BIP 44 s’appuie donc sur l’historique, pas seulement sur le solde courant. Assimiler toute adresse vide à une adresse jamais utilisée pourrait interrompre trop tôt la restauration. Même une ancienne rentrée déjà dépensée sert à vérifier un portefeuille restauré. [1]
BIP 44 décrit l’organisation des comptes et des adresses dans un portefeuille hiérarchique, qui organise les clés et les adresses en arbre, avec différentes branches. Sa règle Address gap limit fixe une limite de 20 pour la recherche sur la branche externe de réception, la suite d’adresses destinée aux paiements entrants. Le logiciel doit avertir lorsqu’une nouvelle adresse est générée au-delà. C’est une convention de restauration, pas une règle de consensus décidant si le réseau accepte une transaction. D’autres portefeuilles peuvent avoir d’autres réglages ou procédures. Cette règle ne recommande pas non plus de réutiliser indéfiniment la même adresse de réception. [1]
Le portefeuille initial peut connaître des adresses générées très loin dans la suite. En restaurant uniquement une sauvegarde des clés, le nouveau logiciel peut ignorer jusqu’où vous étiez allé. Electrum le signale expressément : les adresses au-delà du Gap Limit peuvent ne pas être retrouvées automatiquement lors d’une restauration ordinaire. Sa documentation propose d’augmenter la limite ou de dériver davantage d’adresses jusqu’à la position utilisée. Les réglages appropriés dépendent néanmoins du logiciel et du type de portefeuille. La valeur par défaut de 20 dans la FAQ concerne Electrum 2.0 ; elle n’est pas universelle pour les portefeuilles actuels. [2]
On peut imaginer le portefeuille comme un arbre organisé. Les comptes séparent des groupes de fonds, et chacun peut contenir différentes branches d’adresses. Dans BIP 44, change=0 désigne la branche de réception et change=1 celle de la monnaie rendue, la somme qui reste à l’expéditeur après un paiement. La recherche des comptes commence au compte 0 et examine sa branche externe. Si elle trouve un historique, elle passe au suivant ; le premier compte sans historique arrête cette recherche. Le standard demande donc de ne pas créer de nouveau compte si le précédent n’a pas d’historique. Un intervalle vide dans une branche et un compte vide sauté sont deux problèmes distincts. Augmenter une limite ne détermine pas à lui seul les autres comptes que le logiciel examinera. [1]
BIP 32 décrit une dérivation déterministe : les mêmes données de départ et le même chemin donnent les mêmes clés. Le terme Derivation Path désigne le chemin dans cet arbre. Avec le type de script, c’est-à-dire les règles de dépense, ce chemin détermine les adresses suivies. La bonne Seed Phrase, vos mots de sauvegarde, n’est donc qu’une partie des informations nécessaires. Avec BIP 39, une passphrase facultative intervient aussi dans le calcul de la seed, le secret de départ servant à dériver les clés. La passphrase est un texte secret supplémentaire, distinct du mot de passe de l’application. Une autre passphrase mène à un autre portefeuille ; augmenter Gap Limit ne corrige pas cela. Une clé privée est une valeur numérique secrète dont le portefeuille se sert pour créer une signature numérique autorisant une dépense. Pour aller plus loin, un xpub est une clé publique étendue permettant de dériver d’autres clés publiques. Il aide à suivre les adresses et les paiements, mais ne permet pas à lui seul d’autoriser une dépense. Il ne peut pas franchir seul une étape de dérivation hardened, qui exige la clé privée du parent. Élargir la recherche ne fournit pas cette capacité manquante. [4] [5] [6]
Bitcoin Core 29.0 propose importdescriptors via RPC, l’interface de programmation du nœud. Un descriptor décrit comment les clés définissent les conditions de dépense et les adresses à surveiller. range fixe la plage d’indices à dériver ; ce n’est pas une règle d’arrêt après un intervalle inutilisé. Pour un descriptor actif, next_index fixe le prochain indice servant à générer des adresses. timestamp détermine à partir de quand chercher les transactions. now est prévu pour des sorties dont on sait qu’elles n’ont jamais servi ; il ne remplace pas la récupération de paiements anciens. La documentation inclut aussi les blocs jusqu’à deux heures avant le timestamp le plus ancien parmi les descriptors importés et le Mempool, la réserve locale de transactions non confirmées. Même une adresse correctement dérivée peut donc manquer dans l’aperçu si la période pertinente n’a pas été examinée. [3]
Revenons à Anna. Une adresse de réception connue ou une trace de paiement conservée depuis l’ancien portefeuille lui permet de vérifier si le nouveau les a vraiment retrouvées. Il faut comparer aussi les fonds reçus puis dépensés, pas uniquement le solde final. Une recherche plus longue peut retrouver un historique omis, mais demande du temps et davantage de requêtes. Avec un serveur distant, elle peut révéler à celui-ci davantage d’adresses liées. La recherche seule ne transfère rien et ne modifie pas la blockchain. Si l’historique ne correspond toujours pas, vérifiez les informations de sauvegarde, le compte, le chemin, le type d’adresse et la disponibilité des données historiques, plutôt que d’augmenter seulement la limite. Retrouver une adresse ne prouve pas que toute la restauration est complète. [1] [2] [4]
Pour une vision complète, lisez aussi HD Wallet, Derivation Path, Extended Public Key (xpub), Output Descriptor, Change Address, Seed Phrase. Cette entrée est également citée par HD Wallet, Derivation Path.