Адреса Bitcoin: чем отличаются Legacy, SegWit и Taproot

Legacy, SegWit и Taproot — это форматы адресов одной сети Bitcoin. Монеты между ними не разделены: технически BTC можно отправить с Legacy-адреса на SegWit или Taproot и в обратном направлении. Отличаются способы, которыми условия получения и последующей траты монет записываются в блокчейн, а вместе с ними — совместимость программ, вес транзакции, расчет комиссии и возможности сложных сценариев.

Для обычного перевода разумным базовым выбором остается Native SegWit с началом bc1q: формат эффективно использует место в блоке и широко поддерживается современными кошельками и сервисами. Taproot с началом bc1p особенно полезен кошелькам и приложениям, которые действительно задействуют его механизм подписей и сценариев. Legacy на 1 нужен главным образом ради совместимости со старым программным обеспечением. Адрес на 3 занимает промежуточное положение, но по одному префиксу нельзя заключить, что это обязательно SegWit.

Что на самом деле представляет собой адрес Bitcoin

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

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

Поэтому распространенные выражения «адрес хранит биткоины» и «адрес является публичным ключом» удобны лишь как упрощение. Точнее говорить так:

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

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

Почему кошелек создает новые адреса

Современные HD-кошельки получают последовательность адресов из одной seed-фразы. Новый адрес для очередного поступления не означает создание отдельного кошелька или новой учетной записи. Приложение продолжает учитывать связанные UTXO и показывает их в общем балансе.

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

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

Четыре распространенных вида адресов Bitcoin

Названия Legacy, SegWit и Taproot описывают поколения технологий, но практическая классификация включает как минимум четыре распространенных варианта:

Формат	Тип выхода	Начало адреса в основной сети	Кодировка	Практическая роль
Legacy	P2PKH	1	Base58Check	Старый формат для простой проверки подписи
P2SH, включая Nested SegWit	P2SH	3	Base58Check	Хеш скрипта; может использоваться как оболочка для SegWit
Native SegWit	P2WPKH или P2WSH	обычно bc1q	Bech32	Нативный SegWit версии 0
Taproot	P2TR	bc1p	Bech32m	SegWit версии 1, Schnorr-подписи и пути Taproot

Префикс помогает быстро распознать вероятный формат, но не заменяет проверку адреса программой. Кроме типа выхода, валидатор учитывает контрольную сумму, допустимые символы, длину witness-программы и сеть.

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

Legacy: классический адрес P2PKH

Legacy обычно означает P2PKH — Pay to Public Key Hash. Такой адрес основной сети начинается с 1 и кодируется в Base58Check. Полученный выход блокируется условием, которое требует предъявить публичный ключ с нужным хешем и действительную ECDSA-подпись.

P2PKH появился на раннем этапе развития Bitcoin и долго был стандартным вариантом для кошельков. Его главное практическое преимущество сегодня — совместимость с устаревшим программным обеспечением. Если приложение не умеет распознавать Bech32 или Bech32m, адрес на 1 может оказаться доступным запасным вариантом.

Цена этой совместимости — менее эффективная структура расходования. Подпись и публичный ключ передаются в обычной части входа, поэтому такая транзакция не получает весовую экономию SegWit. При одинаковых остальных условиях расходование P2PKH-выхода обычно весит больше, чем расходование P2WPKH или простого Taproot-выхода по ключевому пути.

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

Legacy уместен, когда:

• принимающая сторона явно требует адрес на 1;
• старое устройство или программа не распознает новые форматы;
• сначала проводится совместимый миграционный перевод, после которого средства будут перемещены в современный кошелек.

Создавать новые Legacy-адреса только потому, что они «проверены временем», обычно нет необходимости. Криптографическая сохранность средств зависит не от визуального возраста формата, а от корректной реализации кошелька, защиты ключей и соблюдения условий расходования.

Адреса на 3: P2SH и Nested SegWit — не одно и то же

P2SH расшифровывается как Pay to Script Hash. Такой адрес основной сети начинается с 3 и представляет хеш скрипта погашения. Отправителю не требуется знать полное условие будущей траты: он создает выход на компактный хеш, а получатель раскрывает соответствующий redeemScript, когда расходует средства.

Механизм P2SH был стандартизирован для переноса ответственности за описание сложного условия с отправителя на получателя. Он подходит не только для SegWit. За адресом на 3 могут стоять мультиподпись, другой допустимый скрипт или witness-программа в P2SH-оболочке. Это следует из спецификаций BIP 16 и BIP 13.

Nested SegWit — частный случай P2SH. В варианте P2SH-P2WPKH скрипт внутри оболочки указывает на SegWit-программу для одного ключа, а в P2SH-P2WSH — на хеш witness-скрипта. Такая конструкция позволила получать часть преимуществ SegWit, сохраняя адрес старого типа, который уже умели обрабатывать многие сервисы.

Адрес на 3 поэтому нельзя без дополнительной информации называть «SegWit-адресом». По строке видно только P2SH. Что находится за хешем, становится известно при расходовании выхода.

Nested SegWit был важным переходным решением, когда нативные адреса bc1q поддерживались не везде. Сейчас его стоит выбирать, если контрагент или конкретный сервис принимает P2SH, но не принимает Native SegWit. При полной поддержке bc1q дополнительная оболочка обычно не дает преимущества и добавляет данные по сравнению с нативным SegWit.

SegWit: почему появился формат bc1q

Segregated Witness изменил структуру транзакции: данные, необходимые для проверки подписи, были вынесены в отдельную область witness. Для транзакций появились традиционный идентификатор txid и идентификатор полной сериализации wtxid. В расчетах размера используется вес, а комиссия на практике сопоставляется с виртуальным размером транзакции.

По правилам BIP 141 базовые данные учитываются с большим весом, чем witness-данные. Поэтому расходование SegWit-выходов может быть компактнее в виртуальных байтах, хотя подписи никуда не исчезают и по-прежнему проверяются узлами.

SegWit также устранил изменяемость идентификатора транзакции, вызванную модификацией данных подписи в старой структуре. Это не сделало любые транзакции вообще неизменяемыми во всех возможных смыслах, но отделение witness от расчета традиционного txid устранило проблему для обычных SegWit-входов и упростило построение протоколов поверх Bitcoin.

Нативные адреса SegWit версии 0 кодируются в Bech32 и в основной сети обычно начинаются с bc1q. Есть два основных типа:

• P2WPKH — Pay to Witness Public Key Hash, распространенный вариант для траты одним ключом;
• P2WSH — Pay to Witness Script Hash, вариант для скриптовых условий.

Их префикс может совпадать, а длина различаться, поскольку witness-программы имеют разный размер. Поэтому bc1q сообщает о SegWit версии 0, но сам по себе не всегда дает полную пользовательскую классификацию сценария.

Что дает кодировка Bech32

Bech32 была разработана специально для нативных witness-адресов. У нее есть несколько практических особенностей:

• адрес не использует визуально неоднозначные символы 1, b, i и o в наборе данных;
• строка не смешивает верхний и нижний регистр;
• контрольная сумма предназначена для обнаружения ошибок;
• набор символов удобнее кодируется в QR-кодах, чем Base58;
• префикс bc указывает на основную сеть Bitcoin, а символ 1 отделяет его от данных.

Адрес Bech32 может быть записан целиком строчными или целиком прописными буквами, но смешивать регистры нельзя. На практике кошельки почти всегда показывают строчный вариант. Спецификация формата и тестовые векторы приведены в BIP 173.

Контрольная сумма снижает риск принять поврежденный адрес, но не подтверждает личность получателя. Правильно закодированная строка может принадлежать злоумышленнику, оказаться подмененной вредоносным ПО или относиться не к тому платежу.

Почему bc1q часто выбирают по умолчанию

Для стандартного перевода P2WPKH дает удачный баланс между эффективностью и совместимостью. Формат нативно использует SegWit и не требует P2SH-оболочки. Если отправляющий сервис принимает bc1q, а кошелек получателя умеет управлять соответствующими ключами, технической причины предпочитать Legacy обычно нет.

Однако формулировка «Native SegWit всегда устанавливает минимальную комиссию» неверна. Адрес не задает комиссию сам по себе, а получатель вообще не контролирует набор входов транзакции отправителя. Один перевод может объединять много мелких UTXO, другой — тратить один выход; разница в весе окажется важнее выбранного выходного адреса.

Taproot: что изменилось в адресах bc1p

Taproot — это правила расходования для SegWit версии 1. Выход P2TR содержит 32-байтовую witness-программу, представляющую Taproot output key. Адрес основной сети начинается с bc1p и использует кодировку Bech32m, а не исходную контрольную сумму Bech32.

Bech32m была введена для witness-версий от 1 до 16. Программа, которая проверяет bc1q, но не реализует BIP 350, не обязательно сможет корректно обработать Taproot-адрес. Внешнее сходство bc1q и bc1p не означает одинаковой поддержки.

Taproot допускает два способа потратить выход:

1. Key path — ключевой путь. Предоставляется Schnorr-подпись для выходного ключа. Наблюдатель не узнает, были ли дополнительно предусмотрены скриптовые условия.
2. Script path — скриптовый путь. Раскрываются исполненный скрипт и данные, доказывающие, что он был включен в дерево условий.

Если участники сложной схемы сотрудничают и используют ключевой путь, операция в блокчейне может выглядеть как обычное расходование одним ключом. При скриптовой трате открывается выбранная ветвь и путь в дереве, но не все альтернативные условия. Именно это, а не «полная анонимность транзакций», является преимуществом Taproot для конфиденциальности сценариев.

Правила и ограничения механизма описаны в BIP 341. Для подписей Taproot применяется схема Schnorr из BIP 340.

Где Taproot действительно эффективнее

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

• совместное распоряжение средствами несколькими участниками;
• основной кооперативный путь и резервные условия;
• скриптовые политики с несколькими альтернативами;
• протоколы, которые используют агрегирование ключей или возможности Tapscript.

Для простого перевода одному получателю P2TR тоже может дать компактное расходование по ключевому пути. Но утверждение «bc1p всегда дешевле bc1q» слишком грубо. Taproot-выход занимает больше места, чем P2WPKH-выход, тогда как его ключевой вход может быть компактнее. Итог зависит от того, создается выход или расходуется, сколько в транзакции входов и выходов и какой путь траты используется.

Taproot не скрывает:

• сумму и время транзакции;
• связи между входами и выходами;
• сам факт скриптовой траты, если выбран script path;
• историю адреса и UTXO;
• данные, которые пользователь раскрыл бирже, обменному сервису или контрагенту.

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

Чем Legacy, SegWit и Taproot отличаются на практике

Совместимость

Legacy распознает самое широкое множество старого программного обеспечения. P2SH также давно поддерживается и позволил внедрять новые сценарии за знакомым адресом на 3. Native SegWit требует поддержки Bech32, а Taproot — SegWit версии 1 и Bech32m.

Совместимость имеет две стороны:

• кошелек получателя должен уметь создать адрес и впоследствии потратить полученный выход;
• кошелек или сервис отправителя должен уметь проверить адрес и сформировать на него корректный выход.

Приложение может поддерживать хранение и расходование собственных Taproot-выходов, но не предлагать вывод на bc1p, либо наоборот. Надпись «поддерживает Bitcoin» недостаточна: перед переводом важна поддержка конкретного формата на конкретной операции.

Комиссия

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

На итог влияют:

• типы расходуемых UTXO;
• количество входов;
• количество и типы выходов;
• наличие выхода сдачи;
• сложность скрипта и путь расходования;
• ставка комиссии;
• правила самого сервиса, если вывод производится не из самостоятельного кошелька.

Когда пользователь дает сервису bc1q вместо адреса на 1, это не гарантирует немедленное снижение удержания за вывод. Сервис может использовать собственную фиксированную или динамическую тарифную модель, объединять переводы в пакет и тратить входы других типов. Сетевая эффективность и комиссия, показанная в интерфейсе платформы, — связанные, но не тождественные величины.

Скорость подтверждения

Тип адреса не создает отдельную очередь и не меняет целевое время блока. Майнеры выбирают транзакции преимущественно по ставке комиссии относительно их веса. Компактная транзакция позволяет достичь той же ставки при меньшей абсолютной комиссии, но сама надпись SegWit или Taproot не дает приоритета.

Если Legacy-транзакция и SegWit-транзакция имеют одинаковую ставку в sat/vB и обе приняты узлами, формат адреса не гарантирует, какая из них первой попадет в блок. Ожидание зависит от загрузки мемпула, политики распространения и выбранной ставки.

Безопасность

Все перечисленные форматы используют правила консенсуса Bitcoin, но реализуют разные условия и схемы подписей. Нельзя выстроить их в простую шкалу «Legacy небезопасен, Taproot безопасен».

Для пользователя чаще критичнее другие факторы:

• подлинность приложения и устройства;
• качество генерации случайных данных;
• хранение seed-фразы и резервной копии;
• проверка адреса на доверенном экране;
• корректная реализация подписания;
• отсутствие вредоносного ПО;
• понимание политики мультиподписи и восстановления.

SegWit исправляет конкретную проблему изменяемости txid и эффективнее учитывает witness-данные. Taproot добавляет Schnorr-подписи и новую модель скриптов. Но ни один формат не защищает от отправки на адрес злоумышленника, раскрытия seed-фразы или выбора неправильной сети.

Конфиденциальность

Повторное использование адреса объединяет поступления вокруг одного публичного идентификатора независимо от того, начинается он с 1, bc1q или bc1p. Taproot может скрыть неиспользованные условия сложной политики, но не отменяет базовую прозрачность UTXO-модели.

Для повседневной приватности полезнее получать каждое новое поступление на новый адрес, не публиковать без необходимости весь набор своих адресов и понимать, что объединение нескольких UTXO в одной транзакции может указать на общий контроль над ними. Это вероятностные эвристики анализа, а не записанная в блокчейн личность владельца.

Сравнение форматов без маркетинговых упрощений

Критерий	Legacy P2PKH	Nested SegWit в P2SH	Native SegWit	Taproot
Начало адреса	1	3	bc1q	bc1p
Версия witness	Не используется	Обычно v0 внутри P2SH	v0	v1
Схема подписи для типичного пути	ECDSA	ECDSA	ECDSA	Schnorr
Совместимость со старым ПО	Наиболее широкая	Высокая благодаря P2SH	Требуется Bech32	Требуется Bech32m и Taproot
Эффективность простой траты	Ниже современных форматов	Лучше P2PKH, но есть оболочка	Эффективная нативная структура	Эффективный key-path, но результат зависит от состава транзакции
Сложные условия	Не основная задача P2PKH	Возможны через P2SH	Возможны через P2WSH	Ключевой и скриптовые пути, раскрытие выбранной ветви
Что видно по префиксу	P2PKH	Только P2SH, не внутренний сценарий	Witness v0	Witness v1 P2TR
Типичный выбор	Ради старой совместимости	Переходная совместимость	Обычные переводы	Совместимые современные кошельки и специальные сценарии

Таблица не заменяет документацию конкретного кошелька. Например, приложение может показывать bc1q, но поддерживать только P2WPKH, а не произвольные P2WSH-политики. Аналогично наличие адреса bc1p еще не раскрывает, какие возможности Taproot реализованы внутри программы.

От чего зависит комиссия: адрес получения или адрес отправления

Выбор адреса получения влияет сразу на два разных этапа.

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

Из этого следуют несколько неочевидных ситуаций:

• получение на современный формат может сократить расходы при будущей отправке, даже если текущую комиссию платит другая сторона;
• перевод всех средств на новый адрес сам по себе является транзакцией и требует комиссии;
• миграция множества мелких UTXO может оказаться дорогой во время высокой загрузки сети;
• объединение UTXO уменьшает их количество, но способно связать адреса и платежи с точки зрения анализа блокчейна;
• Taproot особенно выгоден не по одной букве p, а когда кошелек использует подходящий путь расходования.

Оценивать экономию следует по виртуальному размеру конкретной транзакции и ставке комиссии. Процентные обещания без описания состава входов, выходов и сценария расходования не универсальны.

Как выбрать адрес для получения BTC

Для обычного самостоятельного кошелька последовательность решения может быть простой.

1. Убедиться, что речь идет об основной сети Bitcoin. Название актива в интерфейсе недостаточно: нужно проверить выбранную сеть вывода и формат адреса.
2. Выбрать Native SegWit, если обе стороны поддерживают bc1q. Это практичный стандарт для обычных платежей.
3. Использовать Taproot, если отправитель принимает bc1p, а кошелек полноценно управляет таким адресом. Особенно это оправдано для приложений, использующих возможности Taproot.
4. Перейти к адресу на 3, если старый отправитель не работает с Bech32, но принимает P2SH. Нужно заранее знать, что адрес создан вашим кошельком и относится к нужному аккаунту.
5. Использовать Legacy, если это требуется для совместимости. Он остается валидным форматом, но обычно не является предпочтительным для нового рабочего процесса.

Если сервис отклоняет bc1p, не следует вручную заменять символы или пытаться «конвертировать» адрес. Нужно получить в кошельке другой поддерживаемый тип либо выбрать совместимый сервис отправки. Разные адреса одного HD-кошелька могут вести к ключам из общей seed-фразы, однако эту связь должен корректно создать сам кошелек.

Можно ли переводить между разными форматами

Да. P2PKH, P2SH, SegWit и Taproot работают в одном блокчейне. Входы одной транзакции также могут тратить UTXO разных типов, если кошелек умеет их подписывать.

Ограничение обычно возникает не в сети, а в интерфейсе отправителя. Старое приложение может считать новый адрес невалидным, потому что не знает его кодировку или witness-версию. Отказ формы вывода не доказывает несовместимость форматов на уровне Bitcoin.

Нужно ли переводить старые монеты на новый адрес

Обязательной миграции нет. UTXO на Legacy-адресе не становится недействительным из-за появления SegWit или Taproot. Перевод имеет смысл, если пользователь переходит на современный кошелек, планирует будущие траты и считает комиссию миграции приемлемой.

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

Как проверить Bitcoin-адрес перед отправкой

Проверка должна отвечать не только на вопрос «правильно ли скопированы символы», но и на вопрос «тот ли это получатель и та ли сеть».

Практический порядок выглядит так:

1. Выбрать в приложении именно Bitcoin и требуемую сеть вывода.
2. Получить адрес непосредственно в кошельке получателя, а не из старой переписки.
3. По возможности использовать QR-код, не полагаясь на ручной ввод.
4. Сверить адрес после вставки: вредоносная программа может заменить содержимое буфера обмена.
5. Проверить начало и несколько групп символов в середине и конце на экране доверенного устройства.
6. Убедиться, что сервис принимает этот формат: 1, 3, bc1q или bc1p.
7. Посмотреть сумму, сетевую комиссию, адрес и выход сдачи на аппаратном кошельке перед подтверждением.
8. Для нового маршрута или значительной суммы сначала отправить небольшой тест, если дополнительная комиссия оправдана риском.

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

Чем адрес отличается от TXID

Адрес указывает условие получения выхода. TXID идентифицирует конкретную транзакцию. После отправки сервис может показать оба значения, но они отвечают на разные вопросы:

• по адресу можно изучать связанные с ним выходы и историю, которую индексирует обозреватель;
• по TXID находят одну транзакцию, ее входы, выходы, комиссию и подтверждения;
• адрес нельзя использовать вместо TXID для однозначного обращения к одной операции, особенно если он применялся несколько раз.

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

Типичные ошибки при работе с форматами адресов

Выбирать сеть только по названию BTC

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

Считать любой адрес на 3 SegWit

Префикс 3 означает P2SH. Внутри действительно может находиться P2WPKH или P2WSH, но может быть и другой скрипт. Для пользователя надежным источником типа является кошелек, который создал адрес, а не догадка по префиксу.

Называть bc1 одним форматом

bc1q обычно обозначает нативный SegWit версии 0 с Bech32. bc1p — Taproot версии 1 с Bech32m. Приложение может принимать первый и отклонять второй. Фраза «сервис поддерживает адреса bc1» требует уточнения.

Ожидать снижения комиссии только от адреса получателя

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

Путать адрес с seed-фразой и приватным ключом

Адрес предназначен для передачи отправителю. Seed-фраза, приватные ключи и резервные данные не нужны для получения платежа и не должны передаваться поддержке, обменному сервису или «проверяющему» сайту.

Принимать успешную валидацию за подтверждение владельца

Кошелек может определить, что строка математически корректна, но не знает, кому она принадлежит. Проверка получателя остается отдельной задачей: адрес нужно получить по доверенному каналу и сверить перед подписью.

Какой формат использовать в разных ситуациях

Для регулярного получения BTC в современный самостоятельный кошелек оптимальным отправным вариантом обычно является bc1q. Он понятен большинству актуального ПО и не несет дополнительной P2SH-оболочки.

bc1p подходит, если оба приложения поддерживают Taproot и пользователь понимает, для чего кошелек его предлагает. Выбор оправдан не обещанием абстрактной «максимальной приватности», а реальной поддержкой Bech32m, Schnorr-подписей и нужного пути расходования.

Адрес на 3 полезен как совместимый мост для систем, которым недоступен нативный Bech32. Legacy на 1 остается рабочим вариантом для старого оборудования и сервисов, но это скорее средство совместимости, чем предпочтительный формат нового кошелька.

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

FAQ

Можно ли отправить BTC с Legacy-адреса на Taproot?

Да. Если кошелек отправителя распознает bc1p и умеет сформировать Taproot-выход, источником средств могут быть Legacy-UTXO. Комиссия будет зависеть в том числе от веса расходуемых Legacy-входов.

Почему сервис считает корректный адрес bc1p недействительным?

Вероятная причина — отсутствие поддержки Taproot или кодировки Bech32m в форме вывода. Это ограничение сервиса, а не доказательство ошибочности адреса. Нужно использовать предлагаемый кошельком адрес совместимого типа или другой поддерживаемый маршрут.

Все ли адреса bc1q имеют одинаковую длину?

Нет. SegWit версии 0 включает P2WPKH с 20-байтовой witness-программой и P2WSH с 32-байтовой. Их Bech32-адреса различаются по длине.

Можно ли определить баланс кошелька по одному адресу?

Можно увидеть связанные с адресом данные в публичном блокчейне, но это не обязательно полный баланс кошелька. HD-кошелек может управлять множеством внешних адресов и адресов сдачи, не связанных между собой очевидным публичным идентификатором.

Нужен ли новый адрес после каждого входящего платежа?

Для получения средств старый адрес может оставаться действительным, пока кошелек контролирует ключи. Новый адрес предпочтительнее для приватности: он не объединяет все поступления под одной публичной строкой.

Изменится ли адрес, если восстановить кошелек по seed-фразе?

Совместимый кошелек с теми же правилами получения ключей способен восстановить адреса. Если приложение использует другой тип адреса или derivation path, на первом экране может появиться другая последовательность. Перед внесением средств нужно проверить документацию и убедиться, что восстановлен нужный аккаунт.