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]