Gap Limit

Anna korzysta z portfela, czyli aplikacji lub urządzenia do odbierania i wysyłania bitcoinów. Wygenerowała z wyprzedzeniem wiele adresów odbiorczych, czyli danych potrzebnych do wysłania jej płatności, ale części nigdy nie użyła. Po odzyskaniu portfela brakuje płatności. Wyobraźmy sobie limit 20: adres o indeksie 0 ma historię, kolejne indeksy 1–20 jej nie mają, a na indeks 21 przyszedł przelew. Indeks to tylko numer adresu w kolejności; numeracja zaczyna się od zera. Skanowanie zatrzymuje się po pustym ciągu, przed indeksem 21, i pomija płatność. Gdyby w sprawdzanym ciągu pojawił się użyty adres, licznik luki zacząłby liczyć od nowa. Limit nie oznacza więc najwyżej dwudziestu adresów w całym portfelu. [1] [6]

Co oznacza tutaj nieużywany? Nie chodzi o adres, na którym teraz nie ma pieniędzy. Anna mogła otrzymać płatność, a później wydać ją w całości. Saldo wynosi wtedy zero, ale historia pozostaje, więc przy wyszukiwaniu adres nadal jest użyty. Dlatego BIP 44 opiera się na historii, nie tylko na bieżącym saldzie. Traktowanie każdego pustego adresu jako nigdy nieużywanego mogłoby zbyt wcześnie zakończyć odzyskiwanie. Nawet dawno wydany wpływ pomaga sprawdzić odzyskany portfel. [1]

BIP 44 to standard opisujący organizację kont i adresów w portfelu hierarchicznym, który porządkuje klucze i adresy w drzewo z różnymi gałęziami. Jego reguła Address gap limit ustala granicę 20 dla wyszukiwania w zewnętrznej gałęzi odbiorczej, czyli ciągu adresów przeznaczonych do przyjmowania płatności. Program powinien ostrzegać przy tworzeniu adresu poza tą granicą. To umowa dotycząca odzyskiwania, nie reguła konsensusu decydująca, czy sieć przyjmie transakcję. Inne portfele mogą mieć inne ustawienia lub procedury wyszukiwania. Nie jest to też zalecenie ciągłego używania tego samego adresu odbiorczego. [1]

Pierwotny portfel może znać adresy wygenerowane daleko naprzód. Przy odzyskiwaniu jedynie z kopii kluczy nowy program może nie wiedzieć, dokąd wcześniej dotarłeś. Electrum wyraźnie o tym ostrzega: adresy poza Gap Limit nie zawsze zostaną automatycznie znalezione podczas zwykłego odzyskiwania. Dokumentacja opisuje zwiększenie limitu lub wyprowadzanie kolejnych adresów aż do użytej pozycji. Właściwe ustawienia zależą jednak od programu i typu portfela. Domyślne 20 w FAQ dotyczy Electrum 2.0, a nie wszystkich współczesnych portfeli. [2]

Portfel można wyobrazić sobie jako uporządkowane drzewo. Konta oddzielają grupy środków, a każde konto może zawierać różne gałęzie adresów. W BIP 44 change=0 oznacza gałąź odbiorczą, a change=1 gałąź własnej reszty, czyli kwoty pozostającej nadawcy po płatności. Wyszukiwanie kont zaczyna się od konta 0 i sprawdzenia jego zewnętrznej gałęzi. Jeśli znajdzie historię, przechodzi do kolejnego; pierwsze konto bez historii zatrzymuje wyszukiwanie kont. Dlatego standard zaleca nie tworzyć nowego konta, jeśli poprzednie nie ma historii. Luka w jednej gałęzi adresów i przeskoczone puste konto to różne problemy. Zwiększenie jednego limitu samo nie określa, jakie kolejne konta przeszuka program. [1]

BIP 32 opisuje deterministyczne wyprowadzanie kluczy: te same dane początkowe i ta sama ścieżka dają te same klucze. Derivation Path to droga przez to drzewo; wraz z typem skryptu, czyli regułami wydawania, określa adresy śledzone przez portfel. Właściwa Seed Phrase, słowa kopii zapasowej, jest więc tylko częścią potrzebnych informacji. W BIP 39 w obliczaniu seed, początkowego sekretu do wyprowadzania kluczy, uczestniczy też opcjonalna passphrase — dodatkowy tajny tekst, odrębny od hasła aplikacji. Inna passphrase prowadzi do innego portfela i większy Gap Limit tego nie poprawi. Klucz prywatny to tajna wartość liczbowa, której portfel używa do utworzenia podpisu cyfrowego zatwierdzającego wydanie środków. Dla zaawansowanych: xpub jest rozszerzonym kluczem publicznym do wyprowadzania kolejnych kluczy publicznych. Pomaga śledzić adresy i płatności, ale sam nie uprawnia do wydawania środków. Sam nie przejdzie jednak przez krok hardened, wymagający klucza prywatnego poziomu nadrzędnego. Szersze wyszukiwanie nie daje tej brakującej możliwości. [4] [5] [6]

Bitcoin Core 29.0 udostępnia importdescriptors przez RPC, interfejs programistyczny węzła. Descriptor opisuje, jak z kluczy powstają warunki wydawania i obserwowane adresy. range określa zakres indeksów do wyprowadzenia, a nie regułę zatrzymania po pustej luce. Gdy descriptor jest aktywny, next_index określa następny indeks używany przy tworzeniu adresów. timestamp określa natomiast, od kiedy szukać transakcji. Wartość now służy wyjściom, o których wiemy, że nigdy nie były używane; nie zastępuje odzyskiwania dawnych płatności. Dokumentacja obejmuje też bloki do dwóch godzin przed najwcześniejszym timestamp spośród importowanych opisów oraz Mempool, lokalny zbiór niepotwierdzonych transakcji. Nawet poprawnie wyprowadzony adres może więc nie pojawić się w przeglądzie, jeśli nie sprawdzono właściwego okresu. [3]

Wróćmy do Anny. Jeśli zachowała znany adres odbiorczy lub zapis płatności ze starego portfela, może sprawdzić, czy nowy rzeczywiście je znalazł. Warto porównać także wpływy już wydane, a nie tylko końcowe saldo. Dłuższe skanowanie może znaleźć pominiętą historię, ale wymaga czasu i większej liczby zapytań. Zdalnemu serwerowi może ujawnić kolejne powiązane adresy. Samo szukanie niczego nie przesyła i nie zmienia blockchaina. Jeśli historia nadal się nie zgadza, trzeba sprawdzić dane kopii, konto, ścieżkę, typ adresu i dostępność danych historycznych, zamiast wyłącznie zwiększać limit. Znalezienie jednego adresu nie dowodzi kompletności całego odzyskiwania. [1] [2] [4]