Gap Limit визначає, після скількох невикористаних адрес поспіль гаманець має припинити пошук наступних. Під час відновлення з резервної копії він знову обчислює адреси й перевіряє, чи були з ними транзакції. Правило зупинки не дає нескінченно перебирати величезну кількість можливостей. Платіж за цією межею може не відображатися, хоча власник має правильні ключі. Саме перевищення ліміту не видаляє кошти й не обмежує кількість ключів, які можна вивести.
Анна користується гаманцем — застосунком або пристроєм для отримання й надсилання біткоїнів. Вона заздалегідь створила багато адрес для отримання платежів, тобто реквізитів, за якими їй можна заплатити, але частину ніколи не використовувала. Після відновлення деяких платежів бракує. Уявімо ліміт 20: адреса з індексом 0 має історію, наступні індекси 1–20 — ні, а на індекс 21 надійшов платіж. Індекс — лише порядковий номер адреси; нумерація починається з нуля. Сканування зупиняється після порожньої низки, перед індексом 21, і пропускає цей платіж. Якби в перевіреній низці трапилася використана адреса, лічильник прогалини почав би відлік заново. Отже, це не обмеження всього гаманця двадцятьма адресами. [1] [6]
Що тут означає невикористана? Не те, що на адресі зараз немає грошей. Анна могла отримати платіж, а потім повністю його витратити. Баланс стане нульовим, проте історія залишиться, і для пошуку адреса все ще вважається використаною. Тому BIP 44 працює з історією, а не лише з поточним балансом. Якщо кожну порожню адресу вважати ніколи не використаною, відновлення може зупинитися зарано. Навіть давно витрачене надходження допомагає перевірити відновлений гаманець. [1]
BIP 44 — стандарт організації рахунків і адрес в ієрархічному гаманці, де ключі й адреси організовані у вигляді дерева з різними гілками. Його правило Address gap limit задає межу 20 для пошуку на зовнішній гілці отримання, тобто в послідовності адрес для вхідних платежів. Під час створення адреси за цією межею програма має попередити користувача. Це домовленість про відновлення, а не правило консенсусу, за яким мережа приймає транзакції. Інші гаманці можуть мати інші налаштування чи процедури пошуку. З цього також не випливає порада постійно використовувати одну й ту саму адресу. [1]
Початковий гаманець може знати адреси, створені далеко наперед. Якщо відновлювати лише резервну копію ключів, нова програма може не знати, як далеко ви дійшли раніше. Electrum прямо попереджає: адреси за Gap Limit можуть не знайтися автоматично під час звичайного відновлення. Документація пропонує збільшити ліміт або виводити наступні адреси до використаної позиції. Відповідні налаштування залежать від програми й типу гаманця. Типове значення 20 у FAQ стосується Electrum 2.0, а не всіх сучасних гаманців. [2]
Гаманець можна уявити як упорядковане дерево. Рахунки відокремлюють групи коштів, а кожен рахунок може містити різні гілки адрес. У BIP 44 change=0 позначає гілку отримання, а change=1 — гілку власної решти, тобто суми, що залишається відправникові після платежу. Пошук рахунків починається з рахунку 0 та перевірки його зовнішньої гілки. Якщо є історія, він переходить далі; перший рахунок без історії зупиняє пошук рахунків. Тому стандарт вимагає не створювати новий рахунок, доки попередній не має історії. Прогалина в одній гілці й пропущений порожній рахунок — різні проблеми. Збільшення одного ліміту саме не визначає, які наступні рахунки перевірить програма. [1]
BIP 32 описує детерміноване виведення ключів: однакові початкові дані та шлях дають однакові ключі. Derivation Path — маршрут цим деревом; разом із типом скрипту, тобто правилами витрачання, він визначає адреси, за якими стежить гаманець. Правильна Seed Phrase, резервні слова, є лише частиною потрібної інформації. У BIP 39 до обчислення seed, початкового секрету для виведення ключів, також входить необов’язкова passphrase — додатковий секретний текст, відмінний від пароля застосунку. Інша passphrase веде до іншого гаманця, і більший Gap Limit цього не виправить. Приватний ключ — секретне числове значення, за допомогою якого гаманець створює цифровий підпис, що дозволяє витратити кошти. Для досвідчених читачів: xpub — розширений публічний ключ для виведення інших публічних ключів. Він допомагає стежити за адресами й платежами, але сам по собі не дозволяє витрачати кошти. Сам по собі він не може пройти крок hardened, який потребує приватного ключа батьківського вузла. Розширення пошуку цієї можливості не додає. [4] [5] [6]
Bitcoin Core 29.0 має команду importdescriptors у RPC, програмному інтерфейсі вузла. Descriptor описує, як із ключів формуються умови витрачання та адреси для спостереження. range задає діапазон індексів для виведення, а не правило зупинки після невикористаної прогалини. Якщо descriptor активний, параметр next_index задає наступний індекс створення адрес. timestamp визначає, від якого часу шукати транзакції. Значення now призначене для виходів, про які відомо, що вони ніколи не використовувалися; воно не замінює відновлення давніх платежів. Документація також включає блоки до двох годин перед найранішим timestamp серед імпортованих описів і Mempool, локальний набір непідтверджених транзакцій. Навіть правильно виведена адреса може бути відсутня в огляді, якщо потрібний період не перевірено. [3]
Повернімося до Анни. Якщо в неї є відома адреса отримання або запис платежу зі старого гаманця, вона може перевірити, чи новий їх справді знайшов. Варто порівнювати і вже витрачені надходження, а не лише кінцевий баланс. Довший пошук може знайти пропущену історію, але потребує часу й більшої кількості запитів. Віддаленому серверу він може розкрити додаткові пов’язані адреси. Сам пошук нічого не переказує й не змінює блокчейн. Якщо історія досі не збігається, потрібно перевірити дані копії, рахунок, шлях, тип адрес і доступність історичних даних, а не лише збільшувати ліміт. Знайдена адреса ще не доводить повноти всього відновлення. [1] [2] [4]
Для повної картини прочитайте також HD Wallet, Derivation Path, Extended Public Key (xpub), Output Descriptor, Change Address, Seed Phrase. На цю статтю також посилаються HD Wallet, Derivation Path.