Gap Limit borne le nombre d’adresses inutilisées consécutives rencontrées dans une branche déterministe. Il limite la recherche de l’historique, pas le nombre de clés dérivables ; le dépasser ne signifie pas à lui seul une perte cryptographique des fonds.
Une adresse utilisée interrompt la série inutilisée et remet le compteur à zéro. Exemple avec une limite de 20 : l’indice 0 possède un historique, les indices 1–20 n’en ont pas ; la recherche s’arrête donc avant l’indice 21 et peut y manquer un paiement. Ce n’est pas un maximum de vingt adresses pour tout le portefeuille. [BIP 44 — Account discovery and address gap limit]
BIP 44 fixe un Address gap limit de 20 pour la recherche sur la branche externe de réception. Le logiciel doit avertir lors de la génération d’une adresse au-delà de cette limite. C’est une convention précise de restauration, pas une règle de consensus ni un réglage obligatoire de tous les portefeuilles ; d’autres systèmes peuvent utiliser d’autres plages. [BIP 44 — Account discovery and address gap limit]
BIP 44 recherche l’historique des transactions, pas un solde positif. Une adresse ayant reçu puis dépensé tous ses fonds reste utilisée. Confondre solde vide et adresse inutilisée pourrait arrêter la recherche prématurément et omettre des paiements ultérieurs. [BIP 44 — Account discovery and address gap limit]
BIP 44 commence au compte 0 et vérifie sa branche externe ; il poursuit au compte suivant s’il trouve un historique. change=0 reçoit les paiements, change=1 reçoit sa propre monnaie rendue. Le premier compte sans historique arrête la découverte des comptes ; le standard limite donc la création de comptes vides sautés. La limite d’une branche n’est pas un compteur commun à tous les comptes. [BIP 44 — Account discovery and address gap limit]
La FAQ Electrum avertit explicitement que les adresses générées au-delà du Gap Limit peuvent ne pas être retrouvées automatiquement lors d’une restauration habituelle depuis la seed. Les remèdes documentés sont une limite supérieure ou la dérivation d’autres adresses jusqu’à la position utilisée. La valeur par défaut de 20 y concerne Electrum 2.0 ; elle n’est pas présentée ici comme le réglage de tous les portefeuilles actuels. [Electrum FAQ — Gap limit and generated addresses]
Le RPC importdescriptors de Bitcoin Core 29.0 distingue range, next_index et timestamp. Une plage d’indices dérivés n’est pas une règle d’arrêt après des adresses inutilisées ; next_index fixe le prochain indice généré. timestamp fixe le début du balayage. now ne remplace pas une restauration historique complète ; la documentation inclut aussi les blocs jusqu’à deux heures avant le timestamp le plus ancien et le Mempool. Une plage correcte sans historique balayé adéquat ne suffit donc pas. [Bitcoin Core 29.0 — importdescriptors RPC]
BIP 32 dérive les clés de façon déterministe, mais la recherche doit partir du bon portefeuille, compte, chemin de dérivation et type de script. Un Gap Limit supérieur ne corrige ni une autre seed ni une passphrase différente. Un xpub seul ne peut pas non plus dériver des descendants hardened ; élargir la recherche ne remplace pas une capacité de dérivation manquante. [BIP 32 — Hierarchical Deterministic Wallets] [BIP 39 — From mnemonic to seed]
Une recherche élargie implique davantage d’adresses dérivées et de requêtes ; elle peut révéler des liens supplémentaires du portefeuille à un serveur distant. La restauration se vérifie avec des adresses et transactions connues, y compris des recettes déjà dépensées. Élargir la recherche ne modifie pas la blockchain et ne déplace pas les coins ; sa réussite dépend aussi de données initiales correctes et d’un historique disponible. [BIP 44 — Account discovery and address gap limit] [Electrum FAQ — Gap limit and generated addresses] [BIP 32 — Hierarchical Deterministic Wallets]
Pour une vision complète, lisez aussi HD Wallet, Derivation Path, Extended Public Key (xpub), Output Descriptor, Sortie de monnaie. Cette entrée est également citée par HD Wallet, Derivation Path.