Gap Limit обмежує кількість послідовних невикористаних адрес під час пошуку в детермінованій гілці. Він обмежує пошук історії, а не кількість похідних ключів; перевищення саме по собі не означає криптографічної втрати коштів.
Використана адреса перериває невикористану послідовність і скидає лічильник. Приклад із лімітом 20: індекс 0 має історію, індекси 1–20 — ні, тому сканування зупиняється перед індексом 21 і може пропустити платіж там. Це не максимум двадцяти адрес у всьому гаманці. [BIP 44 — Account discovery and address gap limit]
BIP 44 задає Address gap limit 20 для пошуку на зовнішній гілці отримання. Під час генерації адреси за цією межею програма має попереджати. Це конкретна домовленість щодо відновлення, а не правило консенсусу чи обов’язкове налаштування кожного гаманця; інші системи можуть мати інші діапазони. [BIP 44 — Account discovery and address gap limit]
BIP 44 шукає історію транзакцій, а не додатний баланс. Адреса, яка отримала кошти й потім витратила все, залишається використаною. Ототожнення нульового балансу з невикористаною адресою могло б передчасно зупинити пошук і пропустити наступні платежі. [BIP 44 — Account discovery and address gap limit]
BIP 44 починає з рахунку 0 та перевіряє його зовнішню гілку; якщо знайдено історію, переходить до наступного рахунку. change=0 отримує платежі, change=1 повертає власну решту. Перший рахунок без історії зупиняє пошук рахунків, тому стандарт обмежує створення пропущених порожніх рахунків. Ліміт однієї гілки не є спільним лічильником усіх рахунків. [BIP 44 — Account discovery and address gap limit]
Electrum FAQ прямо попереджає, що адреси, згенеровані за Gap Limit, можуть не знайтися автоматично під час звичайного відновлення із seed. Документовані способи виправлення — більший ліміт або виведення додаткових адрес до використаного місця. Значення 20 за замовчуванням у FAQ стосується Electrum 2.0; тут воно не видається за налаштування всіх сучасних гаманців. [Electrum FAQ — Gap limit and generated addresses]
RPC importdescriptors у Bitcoin Core 29.0 розрізняє range, next_index і timestamp. Діапазон похідних індексів не є правилом зупинки після невикористаних адрес; next_index задає наступний генерований індекс. timestamp задає початок сканування. now не замінює повного відновлення історії; документація також включає блоки до двох годин перед найранішим timestamp і Mempool. Отже, правильного діапазону без відповідної історії сканування недостатньо. [Bitcoin Core 29.0 — importdescriptors RPC]
BIP 32 виводить ключі детерміновано, але пошук має починатися з правильного гаманця, рахунку, шляху деривації та типу скрипту. Більший Gap Limit не виправить інший seed чи відмінну passphrase. Сам xpub також не виводить нащадків hardened; розширення сканування не замінить відсутньої можливості деривації. [BIP 32 — Hierarchical Deterministic Wallets] [BIP 39 — From mnemonic to seed]
Ширший пошук означає більше похідних адрес і запитів та може розкрити віддаленому серверу додаткові зв’язки гаманця. Відновлення перевіряють за відомими адресами й транзакціями, зокрема вже витраченими надходженнями. Розширений пошук не змінює блокчейн і не переміщує монети; успіх залежить також від правильних початкових даних і доступної історії. [BIP 44 — Account discovery and address gap limit] [Electrum FAQ — Gap limit and generated addresses] [BIP 32 — Hierarchical Deterministic Wallets]
Для повної картини прочитайте також HD Wallet, Derivation Path, Extended Public Key (xpub), Output Descriptor, Вихід решти. На цю статтю також посилаються HD Wallet, Derivation Path.