#Туториал. Почему Bitcoin-адрес меняется после перевода

Почему Bitcoin-адрес меняется после перевода? Ситуация типичная: вы получили биткоин на свой кошелёк, всё дошло. Через неделю заходите пополнить его ещё раз и видите уже совсем другой адрес. Старый исчез с экрана. Первая реакция у многих одинаковая: что-то сломалось или деньги уйдут не туда.

Ничего не сломалось. Для современных HD-кошельков смена адресов — нормальное поведение, заложенное в стандартах Bitcoin. Но ответ «не переживайте, это нормально» ничего не объясняет. Ниже разберём тему до уровня протокола: как адреса связаны с ключами, почему их может быть очень много, куда возвращается сдача, как это анализируют блокчейн-аналитики, что такое gap limit и что делать, если вам действительно нужен один постоянный адрес.

Гайд не привязан к конкретному кошельку или производителю. Базовая механика определяется стандартами Bitcoin, хотя конкретный момент, когда приложение показывает новый адрес, зависит от реализации кошелька.

Короткий ответ

Если вы пришли из поиска и хотите лишь убедиться, что с деньгами всё в порядке:

• HD-кошелёк работает не с одним адресом, а с детерминированным деревом ключей, которое выводится из seed. Из одного seed можно получить практически неограниченное количество адресов.
• После использования адреса для получения средств кошелёк обычно предлагает следующий свободный адрес. Некоторые кошельки могут сгенерировать новый адрес и раньше — например, по отдельной команде пользователя.
• Все предыдущие адреса, выведенные из того же seed и того же пути деривации, остаются под контролем вашего кошелька. У Bitcoin-адресов нет срока действия, поэтому монеты, отправленные на старый адрес, не исчезнут.
• Баланс, который вы видите, — это сумма монет на всех адресах аккаунта, а не на одном.
• Если после собственной отправки в эксплорере виден второй выход на незнакомый адрес, очень часто это адрес сдачи вашего же кошелька.

Дальше — механика. Здесь полезно разобраться один раз, потому что на этом знании держится половина практических вопросов о приватности, восстановлении кошелька и работе с биржами.

Что такое Bitcoin-адрес технически

Самое важное для понимания всей темы: в самом протоколе Bitcoin понятия «адрес» не существует. В блоках находятся не адреса, а скрипты условий расходования (scriptPubKey). Адрес — это человекочитаемое представление такого скрипта, удобная оболочка на уровне кошелька. В сети нет никакого реестра адресов: о вашем адресе там не появится никакой записи, пока на него не придёт первая транзакция.

Отсюда следует важный вывод: адрес не нужно «создавать» или «регистрировать». Его можно вычислять офлайн, миллионами, без интернета и без чьего-либо разрешения.

От приватного ключа к адресу

Цепочка преобразований выглядит так:

1. Приватный ключ — это секретное число в допустимом диапазоне кривой secp256k1, которое обычно представляют 256 битами.
2. Публичный ключ вычисляется из приватного по правилам эллиптической кривой secp256k1. Обратное восстановление приватного ключа из публичного считается вычислительно неосуществимым для классических компьютеров.
3. Дальше всё зависит от типа выхода. В P2PKH и P2WPKH используется HASH160 публичного ключа — RIPEMD-160(SHA-256(pubkey)). В P2SH и P2WSH хешируется скрипт, а в P2TR используется tweaked x-only публичный ключ.
4. После этого данные кодируются в человекочитаемый адрес с контрольной суммой: Base58Check для старых форматов, Bech32 для SegWit v0 и Bech32m для witness-версий 1 и выше, включая Taproot.

Ключевая деталь: не все Bitcoin-адреса скрывают один и тот же объект. P2PKH и P2WPKH содержат хеш публичного ключа, P2SH — хеш redeem script, а P2TR напрямую коммитится к x-only output key. Это важно для раздела ниже о повторном использовании адресов и раскрытии публичного ключа.

Зачем адресу контрольная сумма

Адрес — это строка, которую человек копирует, иногда переписывает вручную или считывает из QR-кода. Без проверки ошибка могла бы привести к неправильному адресу, поэтому форматы Bitcoin имеют встроенную контрольную сумму: большинство случайных опечаток кошелёк отклоняет ещё до создания или подписания транзакции.

Base58Check, в том числе адреса, начинающиеся с 1 и 3, использует контрольную сумму на основе двойного SHA-256 и сокращённый алфавит без символов 0, O, I и l, которые легко перепутать.

Bech32 (BIP173) использует BCH-код и обеспечивает сильные гарантии обнаружения типичных ошибок. Bitcoin-адреса этого формата обычно записываются в нижнем регистре, а смешанный регистр недопустим. Код также позволяет реализациям указывать, где могла возникнуть ошибка, но автоматически «исправлять» адрес небезопасно.

Важно не смешивать две вещи. Префикс bc1q соответствует witness-версии 0, а bc1p — witness-версии 1, которую использует Taproot. Отдельно в оригинальном Bech32 обнаружили слабость: если последний символ строки — «p», вставка или удаление определённого количества «q» непосредственно перед ним может не нарушить контрольную сумму. Для SegWit v0 это не создавало практической проблемы из-за ограничений длины, но для будущих witness-версий недостаток нужно было устранить.

Поэтому BIP350 ввёл Bech32m — схему с другой константой в финальном вычислении контрольной суммы. Witness-версия 0 осталась на Bech32, а версии 1 и выше используют Bech32m. Старое ПО, которое знает только Bech32, должно отклонить такой адрес как некорректный, а не молча трактовать его как обычный адрес SegWit v0.

Один seed и практически неограниченное число адресов: BIP32

Ранние кошельки хранили просто набор не связанных между собой приватных ключей. Это означало, что резервная копия устаревала каждый раз, когда кошелёк генерировал новый ключ. Люди действительно теряли монеты из-за этого: бэкап есть, но он сделан до появления адреса, на который пришли средства.

В 2012 году Pieter Wuille предложил BIP32 — стандарт иерархически-детерминированных кошельков (HD wallets), который решил эту проблему.

Как строится дерево

Если вы используете BIP39 seed-фразу, сначала из неё получают бинарный seed, а уже BIP32 с помощью HMAC-SHA512 формирует master private key и chain code. Затем функция вывода дочернего ключа берёт родительский ключ, chain code и индекс и создаёт следующий узел дерева.

Дерево детерминированное: одинаковый seed при одинаковых правилах деривации даёт одинаковые ключи в одном и том же порядке. Для обычного single-sig HD-кошелька seed-фраза служит основой восстановления, но важно знать правильный тип скрипта и derivation path; в более сложных схемах, например multisig, могут понадобиться и дополнительные данные.

Hardened и non-hardened деривация: два режима вывода ключей

Здесь находится деталь, без которой сложно понять xpub — расширенный публичный ключ, из которого выводятся адреса аккаунта, — а также watch-only кошельки и связанные с ними риски.

Существует два режима вывода дочерних ключей. В обычном (non-hardened) режиме дочерний публичный ключ можно вычислить из родительского расширенного публичного ключа без приватного ключа. В hardened-режиме используются индексы от 2³¹ и выше, которые обычно обозначают апострофом или буквой h, и для вывода нужен родительский приватный ключ.

Практический смысл у них разный. Non-hardened деривация позволяет создать watch-only кошелёк: приложение с расширенным публичным ключом видит производные адреса и баланс, но не может подписывать транзакции. Hardened-деривация не позволяет восстановить родительский или соседние приватные ключи только из одного hardened дочернего приватного ключа.

Derivation path: как кошелёк находит нужную ветку

Само дерево BIP32 не задаёт, где именно находятся «ваши» адреса. Это определяет BIP44 и BIP43, который ввёл поле purpose. Путь выглядит так:

m / purpose' / coin_type' / account' / change / address_index

Первые три уровня hardened, последние два — нет. Это сделано намеренно: именно поэтому расширенный публичный ключ уровня аккаунта способен вывести все адреса получения и все адреса сдачи этого аккаунта, не имея ни одного приватного ключа.

Разбор уровней

• purpose: какой стандарт адресов используется. 44 — legacy (BIP44), 49 — вложенный SegWit (BIP49), 84 — Native SegWit (BIP84), 86 — Taproot (BIP86).
• coin_type: монета по реестру SLIP-44. Для Bitcoin это 0, для тестовой сети — 1. Разные монеты находятся в полностью независимых ветках, чтобы ключи не пересекались между сетями.
• account: номер аккаунта внутри монеты. Это логический «подкошелёк» со своей историей и своим балансом.
• change: 0 для внешней цепочки — адресов, которые вы даёте другим, и 1 для внутренней — адресов сдачи. Это ключевой уровень для нашей темы.
• address_index: порядковый номер адреса в цепочке, начиная с 0.

Например, m/84’/0’/0’/0/5 — это шестой по счёту, с индексом 5, адрес получения первого Native SegWit-аккаунта Bitcoin.

Один seed и несколько отдельных типов аккаунтов

Поскольку purpose входит в derivation path, один и тот же seed может давать отдельные наборы адресов для legacy, вложенного SegWit, Native SegWit и Taproot. Это не «разные варианты записи одного адреса», а разные ветки с разными ключами и отдельными UTXO. При этом они не независимы с точки зрения резервного копирования: компрометация основного seed ставит под угрозу все эти ветки.

UTXO: почему сдача возвращается на новый адрес

Это вторая и гораздо менее очевидная причина появления новых адресов. Она пугает сильнее первой, потому что в блокчейн-эксплорере выглядит как исчезновение части денег.

Что такое UTXO

В Bitcoin нет счетов с балансами. Есть набор неизрасходованных выходов транзакций — UTXO (Unspent Transaction Output). UTXO — это неделимый фрагмент монет с привязанными условиями расходования. Ваш «баланс» — это сумма всех UTXO, которые ваш кошелёк умеет разблокировать.

Ближайшая бытовая аналогия — наличные купюры. У вас не «сумма на счёте», а конкретные купюры в кармане. Купюру нельзя разрезать пополам.

Выбор монет (coin selection) и выход сдачи

Когда вы отправляете платёж, кошелёк выполняет coin selection: подбирает набор своих UTXO, суммарной стоимости которых хватает на сумму платежа плюс комиссию. Потратить UTXO частично нельзя — только целиком.

Если кошелёк тратит UTXO на 0.1 BTC, а отправить нужно 0.03 BTC, транзакция расходует весь UTXO и обычно создаёт как минимум два выхода: 0.03 BTC получателю и остаток за вычетом комиссии обратно себе. Этот остаток и есть сдача. Современный HD-кошелёк обычно возвращает её на свежий адрес внутренней цепочки.

На примере Taproot-аккаунта: получение идёт на m/86’/0’/0’/0/0, /0/1, /0/2, а сдача возвращается на m/86’/0’/0’/1/0, затем /1/1, /1/2. Одно дерево, две разные ветки.

Выходов не всегда два. Если потенциальная сдача слишком мала, кошелёк может вообще не создавать отдельный change-выход, и разница фактически увеличит комиссию. Некоторые алгоритмы coin selection, в том числе Branch and Bound в Bitcoin Core, специально ищут вариант без сдачи — это может быть полезно и для приватности, и для будущих комиссий.

Итак, адрес меняется по трём разным причинам

Путаница возникает потому, что три разных механизма часто сводят к одному:

1. Вы получили монеты, после чего кошелёк может предложить следующий адрес внешней цепочки (change = 0). Точный момент зависит от конкретного ПО: одни интерфейсы сохраняют текущий неиспользованный адрес, другие позволяют вручную сгенерировать новый ещё до поступления средств.
2. Вы отправили монеты, и сдача вернулась на адрес внутренней цепочки (change = 1), который обычный интерфейс «Получить» чаще всего не показывает.
3. Вы смотрите на аккаунт другого типа: legacy, вложенный SegWit, Native SegWit или Taproot. У каждого типа своя ветка деривации и свой набор UTXO.

Работают ли старые адреса

Да. У Bitcoin-адреса нет встроенного срока действия или механизма отзыва. Если приватный ключ или скрипт, контролирующий соответствующий выход, по-прежнему доступен вашему кошельку, средства на старом адресе остаются доступными для расходования так же, как и раньше.

Реальная проблема может возникнуть не из-за «старения» адреса, а из-за того, как конкретный кошелёк ищет производные адреса при восстановлении seed.

Gap limit: сколько адресов кошелёк проверяет при восстановлении

Когда вы восстанавливаете seed в новом кошельке, программа не знает, сколько адресов вы успели использовать. Она перебирает их последовательно и должна где-то остановиться, потому что адресов может быть практически неограниченное количество.

BIP44 описывает address gap limit: если во время поиска встречаются 20 последовательных неиспользованных адресов внешней цепочки, стандартный алгоритм discovery может прекратить сканирование. Использованность определяется по истории транзакций, а не по текущему балансу.

Похожий принцип BIP44 применяет и к аккаунтам: во время account discovery поиск следующего аккаунта прекращается, если предыдущий не имеет истории транзакций. Сам стандарт также рекомендует ПО не создавать новый аккаунт, пока предыдущий ещё не использовался.

В процедуре account discovery BIP44 сканирует внешнюю цепочку, потому что внутренняя предназначена для сдачи, связанной с активностью того же аккаунта. Конкретная реализация восстановления и размер keypool могут отличаться между кошельками.

Проблемный сценарий выглядит так: вы сгенерировали много адресов получения подряд, не используя первые из них, а затем получили средства на адрес далеко за пределами стандартного gap limit. При восстановлении некоторые кошельки могут остановить поиск раньше и временно не показать эти средства.

Монеты при этом не потеряны. Они остаются в блокчейне и могут появиться после увеличения gap limit или корректного рескана в кошельке, который это поддерживает. Практическое правило простое: не генерируйте десятки адресов получения «про запас» без необходимости.

Почему одного xpub недостаточно: дескрипторы вывода (output descriptors)

Расширенный публичный ключ (xpub) сам по себе не всегда описывает полный контекст кошелька: важно знать его origin/derivation path и тип скрипта. Один и тот же набор производных публичных ключей можно обернуть, например, в разные типы выходов, поэтому одной строки xpub для надёжного восстановления метаданных в будущем может быть недостаточно.

Разработчики кошельков сначала решили проблему обходным путём: в SLIP-132 появились префиксы ypub и zpub, которые указывают на тип адресов. Это не стандарт Bitcoin, поддержка у него неравномерная, и именно отсюда возникают вопросы в духе «мой кошелёк выдаёт zpub, а сервис просит xpub».

Нормальное решение — output descriptors, дескрипторы вывода, описанные в BIP380 и соседних стандартах. Дескриптор — это строка, которая однозначно задаёт тип скрипта, отпечаток мастер-ключа, путь деривации, сам расширенный ключ и собственную контрольную сумму. Выглядит примерно так:

wpkh([d34db33f/84h/0h/0h]xpub6.../0/*)#checksum

Поддержка output descriptors появилась в Bitcoin Core 0.17, а начиная с версии 23.0 descriptor wallets стали типом кошелька по умолчанию. Если ваш кошелёк умеет экспортировать дескриптор, его полезно сохранять как дополнительное описание структуры кошелька. Но дескриптор с xpub не заменяет seed или приватные ключи и сам по себе не позволяет тратить средства.

Зачем нужна смена адресов: приватность

Смена адресов существует не ради красоты интерфейса. Bitcoin публичен: каждую транзакцию навсегда может увидеть любой человек. Вопрос лишь в том, насколько легко связать эти транзакции между собой и с вами.

Что раскрывает повторное использование адреса

Если вы используете один адрес для всех поступлений, любой, кто его знает, может напрямую увидеть в эксплорере все UTXO и транзакции, связанные именно с этим адресом. То есть вместо одного платежа вы раскрываете гораздо большую часть своей финансовой истории.

Свежий адрес не имеет собственной предыдущей истории, поэтому напрямую не раскрывает остальные поступления. Это повышает приватность, хотя блокчейн-аналитика всё равно может связывать разные адреса по поведенческим и транзакционным эвристикам.

Общее владение входами (common-input-ownership heuristic)

Это один из основных инструментов аналитических компаний. Если несколько адресов выступают входами в одной транзакции, аналитик предполагает, что все они принадлежат одному владельцу: чтобы подписать транзакцию, нужно иметь приватные ключи ко всем входам.

Это предположение вероятностное, а не гарантированное. Его могут нарушать CoinJoin и другие совместные транзакции, где входы принадлежат разным людям. Но для обычных single-user транзакций эвристика часто остаётся полезной.

Как определяют адрес сдачи

Это ещё одна важная техника блокчейн-форензики, то есть анализа транзакций в блокчейне. В транзакции с двумя выходами протокол никак не отмечает, какой из них является платежом, а какой — сдачей. Оба выглядят одинаково. Аналитики определяют это по набору эвристик:

• Совпадение типа скрипта. Кошельки обычно отправляют сдачу на тот же тип адресов, с которого расходуют средства. Если все входы P2WPKH и один выход P2WPKH, а второй P2TR (Taproot), то первый с большей вероятностью является сдачей.
• Круглые суммы. Платёж ровно на 0.05 BTC при остатке 0.03847291 BTC делает круглый выход очевидным кандидатом на платёж, а некруглый — на сдачу.
• Свежий адрес. Выход на адрес без какой-либо предыдущей истории с большей вероятностью является сдачей, сгенерированной HD-кошельком отправителя.
• Лишний вход. Если транзакцию можно было собрать из меньшего количества входов, «лишний» вход может подсказать, какой из выходов является сдачей.
• Замена транзакции через RBF. RBF (Replace-by-Fee) позволяет перевыпустить транзакцию с более высокой комиссией. Во многих кошельках дополнительная комиссия берётся из change-выхода, поэтому наблюдение за несколькими версиями транзакции может помочь определить, какой выход является сдачей. Но это не универсальное правило для всех реализаций.
• Цифровой отпечаток кошелька. Разные кошельки по-разному сортируют выходы, устанавливают nLockTime — поле, которое запрещает включать транзакцию в блок раньше заданного времени, — и выбирают типы адресов. По этим признакам определяют ПО, а затем распознают следующие транзакции того же пользователя.

Каждая эвристика по отдельности вероятностная, но вместе они дают высокую уверенность. Результат — так называемый peeling chain: длинная цепочка, в которой от крупной суммы последовательно «отщипываются» платежи, а остаток уходит дальше по адресам сдачи. Такой паттерн хорошо заметен после крупных транзакций бирж, маркетплейсов и майнинг-пулов.

Смена адресов усложняет анализ, но не делает вас анонимным. При наличии дополнительных данных — например, информации от биржи или повторного объединения UTXO — аналитик может снова связать часть адресов между собой.

Расширенный публичный ключ сводит ротацию на нет

Account-level xpub в стандартной HD-схеме позволяет выводить все non-hardened адреса получения и сдачи соответствующего аккаунта. Поэтому тот, кто получил такой xpub вместе с правильным контекстом деривации, может отслеживать всю историю и баланс этого аккаунта.

Сам по себе xpub не позволяет тратить монеты, потому что не содержит приватных ключей. Опасный сценарий возникает, если вместе с соответствующим xpub утечёт хотя бы один non-hardened дочерний приватный ключ: тогда по BIP32 можно восстановить родительский приватный ключ.

xpub иногда запрашивают сторонние сервисы для watch-only мониторинга или бухгалтерского учёта. Это легитимный сценарий, но передавать ключ стоит только тем, кому вы готовы показать полную историю этого аккаунта. Лучше завести для такой задачи отдельный аккаунт.

Раскрытие публичного ключа и исключение Taproot

Это более технический аргумент, который в популярных статьях часто объясняют неправильно.

В P2PKH (1…) и P2WPKH (bc1q…) выход коммитится к хешу публичного ключа, поэтому сам публичный ключ становится виден только при расходовании — в scriptSig или witness рядом с подписью. P2SH (3…) вместо этого коммитится к хешу redeem script, поэтому конкретное поведение зависит от того, какой скрипт скрыт внутри.

Для P2PKH/P2WPKH повторное получение на уже использованный для расходования адрес означает, что новые средства снова привязаны к публичному ключу, который уже был раскрыт в блокчейне. Сегодня это не создаёт практической возможности украсть монеты, но убирает один слой «скрытия ключа за хешем».

Стойкость таких выходов опирается на сложность задачи дискретного логарифмирования на secp256k1. Для классических компьютеров практического способа восстановить приватный ключ из публичного не существует. Квантовый риск остаётся теоретическим: достаточно мощного квантового компьютера, способного атаковать эти ключи на практике, сегодня нет.

Для обычного пользователя это не повод избегать Taproot: ротация адресов помогает от кластеризации в обоих случаях, а у Taproot есть собственные преимущества. Но использовать раскрытие публичного ключа как универсальный аргумент против повторного использования адресов некорректно.

Модель аккаунтов: почему в Ethereum один адрес на аккаунт

Bitcoin и монеты его семейства — Litecoin, Bitcoin Cash, Dogecoin, Dash — работают на UTXO-модели. На родственной модели, хотя и не являясь родственниками Bitcoin, работают Cardano (eUTXO) и прозрачные транзакции Zcash. Ethereum, Solana, Tron, Cosmos и Polkadot используют модель аккаунтов.

В модели аккаунтов один конкретный адрес соответствует одному аккаунту, отдельного change-выхода нет, а баланс хранится как часть состояния сети. При этом один seed, конечно, может выводить множество разных аккаунтов и адресов — просто автоматической ротации по UTXO-модели Bitcoin здесь нет.

Последствие для приватности неприятное и необратимое. Если вы два года получаете USDT на один адрес, любой, кто знает этот адрес, сразу видит всю историю поступлений и расходов вместе с текущим балансом. Никакие эвристики не нужны — всё находится в открытом доступе.

В Bitcoin смена адресов по умолчанию усложняет такой анализ. В модели аккаунтов разделять потоки приходится вручную, создавая отдельные аккаунты под разные задачи: один для бирж, второй для получения оплат, третий для хранения. Это один из практических аргументов против того, чтобы держать основной запас стейблкоинов на том же адресе, который вы публикуете в чатах и открытых профилях.

Что делать, если нужен один постоянный адрес

Иногда ротация объективно мешает: адрес добавлен в белый список биржи, используется для выплат майнинг-пула или опубликован для донатов в профиле. Варианты есть, но они отличаются по зрелости и поддержке.

Осознанное повторное использование

Самый простой вариант, и он не всегда плох. Если речь о выводе с биржи, которая уже провела ваш KYC, приватности от этой конкретной биржи у вас всё равно нет. Использовать один адрес из белого списка для регулярных выводов с неё — вполне разумный компромисс.

Минимальная гигиена: для такого потока заведите отдельный аккаунт — не просто адрес, а именно аккаунт со своим xpub — и никогда не тратьте эти монеты вместе с остальными в одной транзакции.

BIP47: многоразовые платёжные коды

Идея такая: вы публикуете статический платёжный код, а отправитель с помощью одноразовой notification-транзакции договаривается с вами об общем секрете и затем выводит из него новые адреса для каждого платежа. В блокчейне такие платежи выглядят как обычные выходы на разные адреса.

Широкой поддержки BIP47 не получил. Самая заметная реализация работала под брендом PayNym в Samourai Wallet, а после остановки этого проекта в 2024 году часть инфраструктуры PayNym стала недоступна. Прежде чем рассчитывать на этот вариант, проверьте актуальную поддержку в своём кошельке. Ещё один минус схемы — необходимость notification-транзакции перед первым платежом, то есть дополнительные расходы и след в блокчейне.

Silent Payments (BIP352)

Silent Payments позволяют опубликовать один многоразовый платёжный адрес с префиксом sp1. Каждый платёж на него создаёт уникальный Taproot-выход, а сам протокол не оставляет прямой on-chain связи между опубликованным Silent Payment address и конкретными полученными выходами. Отдельная notification-транзакция перед первым платежом не нужна.

Работает это так: отправитель вычисляет общий секрет из суммарных публичных ключей входов своей транзакции и ключа сканирования из вашего адреса. Получатель находит свои платежи, сканируя транзакции и выполняя то же вычисление по протоколу ECDH — обмену ключами Диффи — Хеллмана на эллиптической кривой, при котором две стороны получают общий секрет, не передавая его по сети.

Компромисс — сканирование. Получатель должен проверять подходящие транзакции и выполнять вычисления, необходимые для обнаружения своих платежей. Для full node это практичнее, а эффективная поддержка лёгких клиентов остаётся отдельной инженерной задачей. Полученные Silent Payment outputs имеют формат P2TR.

По состоянию на август 2026 года BIP352 имеет версию 1.1.1 от 16 апреля 2026 года. Sparrow Wallet поддерживает отправку на Silent Payment addresses начиная с версии 2.3.0, а с 2.5.0 — также получение, включая работу с air-gapped hardware signers. В Bitcoin Core интеграция BIP352 всё ещё ведётся как отдельная работа: полноценная send/receive-функциональность кошелька пока не является завершённой частью релизной версии.

Lightning

Если задача — принимать повторяющиеся платежи, а не хранить их непосредственно on-chain, часть проблемы снимает Lightning. BOLT12 описывает многоразовые offers: получатель может опубликовать одно предложение, на основе которого для конкретного платежа формируется invoice. Это другой уровень со своими компромиссами по ликвидности, доступности и резервному копированию, поэтому как замена холодному on-chain хранению он не подходит.

Когда смена Bitcoin-адреса создаёт неудобства

Белый список биржи и верификация кошелька

Многие биржи требуют добавить адрес вывода в белый список, после чего может действовать задержка перед первым выводом. Если кошелёк уже предлагает новый адрес получения, возникает соблазн каждый раз обновлять whitelist. В таком сценарии допустимо осознанно использовать один проверенный адрес для конкретной биржи, понимая компромисс с приватностью.

Отдельно существуют процедуры подтверждения владения кошельком, привязанные к конкретному адресу. Смена адреса между верификацией и транзакцией ломает процесс. Лучше проходить верификацию и выполнять транзакцию за один раз, не делая паузу на неделю.

Майнинг-пул и сервисы с фиксированным адресом выплат

Пулы, стейкинг-сервисы и часть платёжных процессоров позволяют указать только один адрес выплат. Выбора здесь нет. Решение то же: отдельный аккаунт под этот поток, чтобы повторное использование адреса не тянуло за собой остальную историю.

Донаты и публичные платежи

Опубликованный адрес для донатов по определению будет использоваться повторно, и с точки зрения приватности это худший сценарий: адрес публично связан с вашим именем. Для сборов и волонтёрских кошельков это типичная ситуация: адрес публикуют в соцсетях, после чего он навсегда остаётся связан с тем, кто собирает средства. Именно здесь Silent Payments или BIP47 дают наибольший выигрыш. Если использовать их не получается, минимум — отдельный аккаунт и никакой консолидации этих монет с основными.

Бухгалтерия и watch-only

Если нужно дать кому-то доступ к просмотру баланса, не передавайте адреса по одному. Заведите отдельный аккаунт и передайте дескриптор или xpub именно этого аккаунта. Так человек будет видеть полную и всегда актуальную картину по нужному потоку и не получит информации об остальных средствах.

Типичные ошибки

• Сверять адрес только на экране компьютера. Вредоносное ПО может подменять адрес в буфере обмена. Если вы используете аппаратный кошелёк, одно из его ключевых преимуществ — возможность проверить адрес получения на доверенном экране самого устройства перед использованием.
• Путать ротацию с отравлением истории (address poisoning). Это отдельная атака: вам отправляют микроскопическую сумму с адреса, визуально похожего на ваш — с теми же первыми и последними символами, — рассчитывая, что в следующий раз вы скопируете адрес из истории транзакций. В списке операций это может выглядеть похоже на обычное появление новых адресов. Никогда не копируйте адрес получателя из истории.
• Генерировать адреса пачками «про запас». Это типичный способ создать большой разрыв между использованными адресами и упереться в стандартный gap limit при восстановлении.
• Хранить в качестве бэкапа только xpub. Без типа скрипта и пути деривации он неоднозначен. Сохраняйте дескриптор, если кошелёк умеет его экспортировать.
• Считать ротацию полноценной анонимностью. Она лишь повышает стоимость анализа. Консолидация UTXO, круглые суммы и повторное использование в другом месте сводят эффект на нет.
• Паниковать, увидев второй выход в собственной транзакции. Это может быть ваша сдача.

Итог

Bitcoin-адрес работает не как постоянный номер банковского счёта. В HD-кошельке адреса выводятся из детерминированного дерева ключей, а адреса получения можно регулярно менять без создания нового seed.

У старых адресов нет срока действия. Баланс кошелька формируется из всех контролируемых им UTXO, а сдача обычно возвращается во внутреннюю ветку. Legacy, nested SegWit, Native SegWit и Taproot могут использовать разные derivation paths, поэтому при восстановлении важно выбрать правильный тип аккаунта.

Одна из практических ловушек — gap limit: если создать большой промежуток неиспользованных адресов получения, некоторые кошельки при стандартном сканировании могут не дойти до адреса, на который уже поступили средства.

Если ваш кошелёк постоянно показывает один и тот же BTC-адрес, это само по себе ещё не означает неисправность. Проверьте документацию конкретного кошелька: это может быть особенностью интерфейса, импортом одного ключа или другой схемой управления адресами.

Что почитать дальше

• Потеряли seed-фразу, но кошелёк всё ещё работает: что делать
• Хранение seed-фразы: 5 безопасных способов в 2026 году
• Аппаратный кошелёк vs биржа: где действительно безопаснее хранить крипту
• Вывод крипты на карту с Binance, OKX и Bybit в 2026 году

Источники

Стандарты:

• BIP32: Hierarchical Deterministic Wallets
• BIP39: Mnemonic code for generating deterministic keys
• BIP43: Purpose Field for Deterministic Wallets
• BIP44: Multi-Account Hierarchy for Deterministic Wallets — алгоритм обнаружения аккаунтов и gap limit.
• BIP49 / BIP84 / BIP86: деривация для вложенного SegWit, Native SegWit и Taproot.
• BIP173: Base32 address format for native v0-16 witness outputs (Bech32)
• BIP350: Bech32m format for v1+ witness addresses
• BIP352: Silent Payments
• BIP380: Output Script Descriptors General Operation
• SLIP-44 и SLIP-132

Другое:

• Bitcoin Optech: Bech32 / Bech32m и Silent Payments.
• Bitcoin Wiki: Privacy
• M. Möser, A. Narayanan. Resurrecting Address Clustering in Bitcoin. Financial Cryptography 2022
• Learn Me A Bitcoin: HD Wallets и Derivation Paths.
• Wallets Recovery: таблица путей деривации и форматов экспорта по кошелькам.
• Silent Payments: спецификация и трекер поддержки BIP352.