Восстановление Bitcoin-кошелька: диапазон адресов
Ключи сохранены, но восстановленный кошелёк не показывает оплату последнего счёта. Такое возможно без потери секретов: инструмент ищет другой диапазон адресов или начинает историю слишком поздно. В уроке построим восстановительную опись, которая учитывает уже выданные назначения и обе ветви кошелька.
Пусть библиотека выдала 2 500 счетов, а оплачены лишь некоторые. Пример относится к модели данных. Мы не выполняем rescan, не импортируем дескрипторы и не измеряем время восстановления.
Выданный адрес и использованный адрес
Сайт показал адрес счёта, но читатель мог не отправить перевод. Следующий счёт получил следующий индекс. После тысяч таких операций множество выданных назначений может содержать длинные промежутки без поступлений. Алгоритм восстановления, который останавливается после короткой последовательности пустых адресов, способен пропустить более поздние оплаты.
Для библиотеки нужны два счётчика: максимальный выданный индекс и известные использованные индексы. Первый относится к приложению и процессу выдачи; второй — к наблюдаемой истории. Подмена первого вторым опасна, потому что ранее показанные пустые адреса остаются потенциальными получателями поздних переводов.
Сохраним опись:
{
"account": "library-sales",
"receiveIssuedThrough": 2499,
"changeIssuedThrough": 42,
"scanStartHeight": 120,
"network": "regtest"
}Это собственная структура досье, не формат команды импорта. Индексы нулевые: значение 2499 означает, что показано 2 500 назначений данной ветви. Высота 120 относится к известному началу учебной истории и должна сверяться с реальной конфигурацией, когда она появится.
Диапазон дескриптора
Выражение со звёздочкой описывает семейство, но инструменту нужен конечный диапазон обработки. В importdescriptors предусмотрены параметры диапазона и дополнительные признаки. Точные формы аргументов зависят от справочника версии. При восстановлении нельзя считать, что наличие символа * заставит узел бесконечно искать все возможные индексы.
Если импортировали 0–999, адрес индекса 2400 останется вне этого поиска. Расширение диапазона возвращает способность наблюдать назначение, но ещё требуется сканирование подходящей истории. Полезно фиксировать диапазон как часть восстановительного результата, а не только как вход команды.
Запас диапазона может облегчать дальнейшую выдачу, однако не отменяет контроль предела. Сайт должен замечать приближение к нему и не выдавать адреса из неизвестной конфигурации. При параллельном создании счетов индексы распределяются согласованно, чтобы два запроса не получили одно назначение по ошибке приложения.
Откуда сканировать
Параметр начала поиска позволяет ограничить работу известной историей. Слишком поздняя точка пропускает старые платежи, слишком ранняя увеличивает обработку. Начало должно опираться на достоверное время или высоту создания соответствующей политики, с достаточным запасом для её фактического использования.
Не берём время сегодняшнего импорта как время возникновения всех адресов. Выражение можно импортировать спустя годы после первого получения. Аналогично дата резервного файла не доказывает, что кошелёк начал работать в этот день. Досье сохраняет происхождение и начальный период отдельно.
Если узел хранит сокращённую историю блоков, старых данных для полного сканирования может не быть локально. Тогда восстановление требует другого источника или повторного получения нужной истории по возможностям инструмента. Текущий UTXO-набор и полный журнал оплат — разные цели; наличие известных текущих выходов не восстанавливает все уже израсходованные поступления.
Ветвь сдачи и старые формы
Библиотека могла расходовать выручку и получать сдачу. Если восстановить только внешнее получение, её собственные средства окажутся в невидимой ветви. Поэтому опись включает приём и сдачу, а также прежние формы условий, если кошелёк менял адресные типы.
Изменение одного профиля не переписывает старые выходы. Переход от исторических адресов к SegWit означает, что старые условия продолжают существовать до расходования. Новый активный дескриптор полезен для новых счетов, но не заменяет историческую политику.
Для нескольких подписантов нужно восстановить также весь состав и порог. Три сохранившихся публичных ключа без порядка и формы скрипта могут приводить к иному назначению. Поэтому восстановительная запись содержит полное выражение и сведения о ключевом происхождении.
Сверка с приложением
После сетевого поиска сопоставляем выходы с базой счетов. Если наблюдение нашло адрес, которого нет в восстановленной таблице, запись не теряется. Создаём внутреннюю категорию несопоставленного поступления и выясняем, какая часть журнала выдачи отсутствует.
Если таблица содержит счёт, но поступлений нет, это также не обязательно потеря. Читатель мог не оплатить, перевод мог идти в другой сети, адрес мог быть подменён или наблюдение ещё неполно. Вывод должен содержать основание, а не общий статус «не найдено» без свежести и диапазона.
Дубликаты идентифицируются по сети и outpoint. Повторный rescan не должен создать вторую оплату за тот же выход. История включения обновляется отдельно от идентичности платежа. Это делает восстановление повторяемым без повторной выдачи материалов.
Договор готовности
Успешное восстановление для библиотеки означает: все согласованные дескрипторы загружены, диапазоны покрывают журнал выдачи, история обработана от достаточной точки, известные поступления сопоставлены, а невидимые категории явно перечислены. Общий баланс является одним результатом, но не единственным критерием.
Несопоставленный поздний перевод
Представим, что после восстановления поступило 30 000 на адрес индекса 2400. Если журнал выдачи сохранил этот индекс, сервис находит старый счёт и применяет правило поздней оплаты. Если связь потеряна, назначение всё равно относится к кошельковой политике, но номер заказа неизвестен. Сумма не позволяет надёжно выбрать один из множества счетов с той же ценой. Внутренний разбор сохраняет выход отдельно и восстанавливает журнал из доступных источников.
Этот сценарий показывает, почему максимальный диапазон и коммерческое сопоставление имеют самостоятельные результаты. Можно полностью увидеть деньги и одновременно неполно восстановить приложение. Отчёт должен выразить обе степени готовности, чтобы оператор не возобновил автоматическую выдачу по случайным совпадениям.
Параметры описаны в importdescriptors и rescanblockchain. В этом уроке подготовлена опись, а не проведённое восстановление. Она позволяет заранее увидеть, почему сохранённый секрет и корректно найденная история должны проверяться отдельно.