Gap Limit ogranicza liczbę kolejnych nieużywanych adresów podczas przeszukiwania deterministycznej gałęzi. Ogranicza wyszukiwanie historii, a nie liczbę możliwych do wyprowadzenia kluczy; przekroczenie samo nie oznacza kryptograficznej utraty środków.
Użyty adres przerywa nieużywany ciąg i zeruje licznik luki. Przykład z limitem 20: indeks 0 ma historię, indeksy 1–20 jej nie mają, więc skan zatrzyma się przed indeksem 21 i może pominąć tam płatność. To nie limit dwudziestu adresów w całym portfelu. [BIP 44 — Account discovery and address gap limit]
BIP 44 ustala Address gap limit 20 dla wyszukiwania w zewnętrznej gałęzi odbiorczej. Program powinien ostrzegać przy generowaniu adresu poza tą granicą. Jest to konkretna konwencja odzyskiwania, nie reguła konsensusu ani obowiązkowe ustawienie każdego portfela; inne systemy mogą stosować inne zakresy. [BIP 44 — Account discovery and address gap limit]
BIP 44 szuka historii transakcji, a nie dodatniego salda. Adres, który otrzymał środki, a potem wydał wszystko, nadal jest użyty. Uznanie pustego salda za nieużywany adres mogłoby przedwcześnie zatrzymać skan i pominąć kolejne płatności. [BIP 44 — Account discovery and address gap limit]
BIP 44 zaczyna od konta 0 i sprawdza jego zewnętrzną gałąź; po znalezieniu historii przechodzi do kolejnego konta. change=0 odbiera płatności, change=1 własną resztę. Pierwsze konto bez historii zatrzymuje odkrywanie kont, dlatego standard ogranicza tworzenie pominiętych pustych kont. Limit jednej gałęzi nie jest wspólnym licznikiem wszystkich kont. [BIP 44 — Account discovery and address gap limit]
Electrum FAQ wyraźnie ostrzega, że adresy wygenerowane poza Gap Limit mogą nie zostać automatycznie odnalezione podczas zwykłego odzyskiwania z seed. Udokumentowaną naprawą jest większy limit lub wyprowadzanie kolejnych adresów aż do użytej pozycji. Domyślne 20 w FAQ odnosi się do Electrum 2.0; nie jest tu przedstawiane jako ustawienie wszystkich obecnych portfeli. [Electrum FAQ — Gap limit and generated addresses]
RPC importdescriptors w Bitcoin Core 29.0 rozróżnia range, next_index i timestamp. Zakres wyprowadzanych indeksów nie jest regułą zatrzymania po nieużywanych adresach; next_index wyznacza następny generowany indeks. timestamp określa początek skanu. now nie zastępuje pełnego odzyskiwania historii; dokumentacja uwzględnia też bloki do dwóch godzin przed najwcześniejszym timestamp i Mempool. Poprawny zakres bez odpowiedniej skanowanej historii zatem nie wystarcza. [Bitcoin Core 29.0 — importdescriptors RPC]
BIP 32 wyprowadza klucze deterministycznie, ale szukanie musi zacząć się od właściwego portfela, konta, ścieżki derywacji i typu skryptu. Większy Gap Limit nie naprawi innego seed ani odmiennej passphrase. Sam xpub nie pozwala też wyprowadzać potomków hardened; rozszerzenie skanu nie zastąpi brakującej możliwości derywacji. [BIP 32 — Hierarchical Deterministic Wallets] [BIP 39 — From mnemonic to seed]
Szersze szukanie to więcej wyprowadzonych adresów i zapytań; może ujawnić zdalnemu serwerowi dodatkowe powiązania portfela. Odzyskiwanie sprawdza się względem znanych adresów i transakcji, także już wydanych wpływów. Rozszerzony skan nie zmienia blockchaina ani nie przenosi monet; sukces zależy też od właściwych danych początkowych i dostępnej historii. [BIP 44 — Account discovery and address gap limit] [Electrum FAQ — Gap limit and generated addresses] [BIP 32 — Hierarchical Deterministic Wallets]
Pełniejszy obraz uzyskasz, czytając to hasło razem z HD Wallet, Derivation Path, Extended Public Key (xpub), Output Descriptor, Wyjście reszty. Do tego hasła prowadzą również odsyłacze z HD Wallet, Derivation Path.