Типы биткоин-адресов: объяснение

Прямой ответ

Сравните форматы адресов legacy, nested SegWit, native SegWit и Taproot, их префиксы, совместимость и пределы безопасности.

Два биткоин-адреса могут оба получать BTC и при этом создавать разные структуры транзакций. Адрес основной сети, начинающийся с 1, один, начинающийся с 3, адрес bc1q и адрес bc1p — все могут быть действительными назначениями, но они не обязательно представляют один и тот же скрипт, кодировку или будущее условие траты.

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

Поэтому практический вопрос не просто “Какой префикс новее?” Это вопрос о том, принадлежит ли адрес предполагаемой сети биткоина, какой тип выхода он представляет, поддерживает ли отправляющее программное обеспечение этот формат и что адрес может — и не может — сказать вам перед авторизацией платежа.

Что представляет собой биткоин-адрес

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

Упрощенная взаимосвязь такова:

Биткоин-адрес
        ↓
Декодирование адреса
        ↓
scriptPubKey
        ↓
Выход транзакции
        ↓
Подтвержденный UTXO
        ↓
Будущее условие траты

Когда вы отправляете биткоины, кошелек не перемещает объект из одной строки адреса в другую. Он потребляет существующие UTXO как входы транзакции и создает новые выходы. Адрес назначения предоставляет информацию, необходимую для создания одного из этих выходов.

Вот почему формат адреса имеет техническое значение. Адрес P2PKH приводит к другому выходному скрипту, чем адрес P2WPKH. Выход Taproot P2TR снова отличается. Эти выходы могут представлять расходуемые биткоины, но условия и сериализация, используемые при их трате, не идентичны.

Адрес не является приватным ключом

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

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

Почему существует несколько форматов

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

Четыре формата, с которыми большинство пользователей сталкиваются в основной сети Биткоина:

• Legacy P2PKH, обычно отображается с адресом, начинающимся с 1.
• P2SH, обычно начинается с 3; вложенный SegWit — одно из важных применений P2SH, но не единственное.
• Native SegWit, закодирован с помощью Bech32 и обычно начинается с bc1q для версии witness 0.
• Taproot, закодирован с помощью Bech32m и начинается с bc1p для выходов P2TR версии witness 1.

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

Сравнение типов биткоин-адресов

Общее название	Префикс основной сети	Кодировка	Типичный вывод	Что говорит вам префикс
Legacy	1	Base58Check	P2PKH	Семейство версионных байтов для адреса хеша открытого ключа основной сети
P2SH (включая вложенный SegWit)	3	Base58Check	P2SH; вложенный SegWit — одна из возможных конструкций redeem-скрипта	Назначение — P2SH, а не точный redeem-скрипт внутри него
Native SegWit	bc1q	Bech32	Witness v0, обычно P2WPKH или P2WSH	Основная сеть Bech32 witness-version-0 назначение
Taproot	bc1p	Bech32m	P2TR	Основная сеть witness-version-1 Taproot назначение

Эта таблица полезна для идентификации, но префикс не является полным описанием будущего поведения при трате. Самый наглядный пример — 3... адрес: он идентифицирует P2SH, но P2SH может содержать множество redeem-скриптов. Вложенный SegWit — лишь одна из возможностей.

Legacy P2PKH адреса

Legacy pay-to-public-key-hash, или P2PKH, — это формат адреса, наиболее тесно связанный с ранними кошельками Bitcoin. В основной сети эти Base58Check адреса обычно начинаются с 1.

Адрес представляет собой хэш публичного ключа. Когда кошелек платит на это назначение, он создает P2PKH locking-скрипт, который требует действительную подпись и соответствующий публичный ключ при трате выхода.

OP_DUP
OP_HASH160

OP_EQUALVERIFY
OP_CHECKSIG

Таким образом, видимый адрес — это не сам скрипт. Кошелек декодирует Base58Check адрес, извлекает версию и полезную нагрузку и создает соответствующий scriptPubKey.

P2PKH выходы остаются действительными выходами Bitcoin. “Legacy” не означает недействительный или автоматически небезопасный. Различие становится актуальным при сравнении структуры транзакции: трата традиционного P2PKH выхода помещает данные разблокировки в входной скрипт, а не использует SegWit witness-сериализацию.

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

P2SH и вложенный SegWit

Pay-to-script-hash, или P2SH, перенес часть логики траты за хэш. Адреса P2SH в основной сети используют Base58Check и обычно начинаются с 3.

Стандартный P2SH выход помещает хэш redeem-скрипта в locking-скрипт:

OP_HASH160

OP_EQUAL

Полный redeem script предоставляется только при трате выхода. Это создало важный инструмент совместимости, когда был введен SegWit: программа witness от SegWit могла быть помещена внутрь P2SH redeem script, что позволяло отправителю, понимающему обычные P2SH-адреса, оплачивать выход, который позже будет потрачен по правилам SegWit.

Распространенная конструкция с одним ключом называется P2SH-P2WPKH:

P2SH-адрес
    ↓
хэш redeemScript
    ↓
redeemScript содержит программу witness P2WPKH
    ↓
подпись и публичный ключ предоставляются через данные witness при трате

Префикс 3 не доказывает SegWit

Это один из самых важных ограничений визуальной идентификации адреса. Адрес, начинающийся с 3 говорит вам, что получатель использует основную версию P2SH-адреса. Он не раскрывает полный redeem script до траты выхода.

P2SH существовал до SegWit и может оборачивать другие скрипты. Поэтому считать каждый 3... адрес “адресом SegWit” слишком широко.

Техническая граница: префикс идентифицирует внешний формат адреса. Он не доказывает точный скрипт, скрытый за хэшем P2SH.

Нативный SegWit и bc1q

Нативный SegWit убирает обертку совместимости P2SH и представляет программу witness напрямую. BIP 173 ввел кодировку Bech32 для нативных адресов SegWit.

В основной сети Bitcoin человекочитаемая часть — bc. Версия witness 0 создает адреса, обычно узнаваемые по началу bc1q.

Два распространенных выхода версии witness 0:

• P2WPKH: 20-байтовая программа witness, обычно используемая для платежей с одним ключом.
• P2WSH: 32-байтовая программа witness, которая фиксирует witness script.

Сам адрес дает кошельку версию witness и программу. Для версии witness 0 распространенные выходные скрипты имеют следующие формы:

P2WPKH: OP_0 
P2WSH:  OP_0

Выходные данные напрямую содержат программу-свидетеля вместо обёртки P2SH. При трате UTXO данные подписи или скрипта, требуемые программой-свидетеля, предоставляются в свидетеле транзакции, а не в традиционном scriptSig в стиле P2PKH.

Bech32 также изменяет обнаружение ошибок

Bech32 — это не просто другой алфавит. Он включает контрольную сумму, предназначенную для этого семейства адресов, и отделяет читаемую человеком сетевую часть от закодированных данных свидетеля.

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

Taproot и bc1p

Taproot ввёл выходы pay-to-Taproot, или P2TR. P2TR использует версию свидетеля 1 с 32-байтовой программой-свидетеля. В основной сети Bitcoin результирующий адрес начинается с bc1p.

Версия свидетеля 1 и более поздние используют Bech32m, а не исходную контрольную сумму Bech32. BIP 350 ввёл это изменение после того, как была выявлена слабость в использовании исходного поведения контрольной суммы Bech32 для более новых версий свидетеля.

Это даёт практическое правило идентификации:

bc1q... → версия свидетеля 0 → Bech32
bc1p... → версия свидетеля 1 P2TR → Bech32m

Соответствующий блокирующий скрипт P2TR использует версию свидетеля 1 и 32-байтовый ключ вывода Taproot:

OP_1

Выход A P2TR обязуется к этому ключу выхода Taproot. Позже его можно потратить через путь ключа или, если было зафиксировано дерево скриптов, через действительный раскрытый путь скрипта.

Адрес не раскрывает, какой путь будет в конечном итоге использован. Видя bc1p вы узнаете, что выход является P2TR. Это не говорит вам, будет ли будущий тратящий использовать подпись пути ключа или раскроет путь скрипта.

Что на самом деле говорят вам префиксы Bitcoin

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

Пример начала	Вероятное значение для основной сети	Что это не доказывает
1...	Адрес основной сети P2PKH	Владельца, баланс или личность получателя
3...	Адрес основной сети P2SH	Что redeem-скрипт вложен в SegWit
bc1q...	Собственный адрес witness-version-0	Является ли он P2WPKH или P2WSH только по префиксу
bc1p...	Адрес P2TR witness-version-1	Какой путь траты Taproot будет использован позже

Префикс также не может аутентифицировать человека, который дал вам адрес. Идеально закодированный адрес с действительной контрольной суммой все равно может принадлежать неправильному получателю.

Сеть идет перед типом адреса

Прежде чем выбирать между Legacy, SegWit или Taproot, убедитесь, что адрес принадлежит сети Bitcoin, которую вы собираетесь использовать.

Адреса семейства Bech32 делают это видимым через свою человекочитаемую часть. BIP 173 определяет bc для основной сети Bitcoin и tb для тестовых адресов Bitcoin. Человекочитаемая часть, следовательно, является частью проверки сети, а не украшением.

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

Кошелек должен отклонять неподдерживаемую комбинацию сети/адреса, но конечная ответственность все равно заключается в подтверждении сети, показанной отправляющим приложением. Распознавание формата адреса не заменяет проверку сети.

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

Тип адреса и комиссии за транзакции

Часто можно услышать, что более новый адрес Bitcoin “дешевле”. Это утверждение полезно в некоторых сравнениях, но слишком просто, чтобы использовать его как правило комиссии.

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

SegWit также изменяет учет транзакционных Weight, потому что байты witness взвешиваются иначе, чем байты не-witness. Обычная трата ключа Native SegWit, следовательно, имеет другой профиль Weight, чем сопоставимая трата Legacy P2PKH. Это влияет на виртуальный размер, когда UTXO тратится, но все равно не фиксирует общую комиссию заранее.

Одна и та же сумма BTC может привести к разным будущим затратам

Рассмотрим двух пользователей, каждый из которых получает одинаковое количество биткоинов. Один получает выход P2PKH, а другой — выход P2WPKH. Стоимость идентична. Структура будущего входа — нет.

Когда эти UTXO позже тратятся, их данные разблокировки сериализуются по-разному. Это меняет транзакционные Weight и, следовательно, виртуальный размер. При одинаковой ставке sat/vB разные vSize означают разную общую комиссию.

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

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

Для полной взаимосвязи между Weight, виртуальным размером и sat/vB читайте как работают комиссии за транзакции Bitcoin. Когда вам нужна оценка для конкретной транзакции, а не концептуальное сравнение, используйте Калькулятор комиссии за транзакцию Bitcoin.

Совместимость — это проверка отправителя

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

Это различие было особенно важным при внедрении Native SegWit, а затем Taproot. Сеть Bitcoin могла распознавать тип вывода, в то время как старые приложения не поддерживали создание такого назначения.

Когда сервис отклоняет bc1q или bc1p адрес, не изменяйте адрес вручную. Не удаляйте символы, не меняйте префикс и не конвертируйте его через произвольный сайт. Используйте формат адреса, который фактически сгенерировал ваш принимающий кошелек и который явно поддерживает отправитель.

Отправка между форматами не является конвертацией

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

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

Действительный адрес все еще может быть неправильным

Контрольные суммы выявляют определенные ошибки транскрипции. Они не подтверждают подлинность предполагаемого получателя.

Если вредоносное ПО заменяет скопированный адрес другим действительным адресом Bitcoin, замена может идеально пройти проверку контрольной суммы. Технический формат действителен; назначение неверно.

Вот почему “кошелек принял адрес” не является окончательной проверкой безопасности. Принятие говорит вам, что программное обеспечение распознало действительное или поддерживаемое назначение. Это не доказывает, откуда взялся адрес.

Проверьте перед отправкой

Полезный процесс проверки разделяет проверку формата и проверку получателя.

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

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

Повторное использование адреса — это отдельная проблема

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

Это не делает повторное использование адреса желательным. Повторное использование адреса получения может упростить ассоциацию транзакций в публичном блокчейне и снизить конфиденциальность.

Этот вопрос конфиденциальности отделен от того, является ли адрес P2PKH, P2SH, P2WPKH или P2TR. Современный формат адреса не делает многократное использование одного и того же видимого назначения приватным.

Пределы проверки адреса

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

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

Выбор формата получения

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

Если принимающий кошелек предлагает более одного типа адреса, используйте тип, который соответствует предполагаемой скриптовой политике кошелька и который отправитель может декодировать. Адрес P2WPKH уместен, когда кошелек намеренно генерирует назначение witness-version-0 key-hash. Адрес P2TR уместен, когда кошелек намеренно генерирует назначение Taproot и отправитель его поддерживает. Более старые назначения P2PKH или P2SH остаются действительными, когда рабочий процесс требует этих форматов.

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

Адрес должен исходить от принимающего кошелька. Отправитель должен его поддерживать. Сеть должна совпадать. Эти три проверки важнее, чем погоня за префиксом сама по себе.

Часто задаваемые вопросы об адресах Bitcoin

В чем разница между bc1q и bc1p?

bc1q обычно является началом адреса основной сети Bitcoin witness-version-0, закодированного с помощью Bech32, например P2WPKH или P2WSH. bc1p идентифицирует адрес P2TR основной сети witness-version-1, закодированный с помощью Bech32m.

Использует ли каждый адрес Bitcoin, начинающийся с 3, SegWit?

Нет. Адрес основной сети, начинающийся с 3 является адресом P2SH. Вложенный SegWit может использовать P2SH, но P2SH может содержать другие redeem-скрипты, поэтому префикс сам по себе не доказывает, что выход является вложенным SegWit.

Чувствительны ли адреса Bitcoin к регистру?

Адреса Base58Check используют алфавит, чувствительный к регистру. Кодировки Bech32 и Bech32m не должны смешивать символы верхнего и нижнего регистра; кошельки Bitcoin обычно отображают их в нижнем регистре. Не изменяйте регистр адреса вручную.

Могу ли я отправлять Bitcoin с одного типа адреса на другой?

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

Истекает ли срок действия адреса Bitcoin?

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

Какой тип адреса Bitcoin мне следует использовать?

Используйте адрес, сгенерированный получающим кошельком для сети Bitcoin и типа скрипта, который вы собираетесь использовать, затем убедитесь, что отправитель поддерживает этот формат. Нативный SegWit распространен для современных платежей, в то время как Taproot подходит, когда обе стороны поддерживают P2TR. Не преобразовывайте вручную один формат адреса в другой.

Технические источники

Приведенные выше описания форматов адресов основаны на предложениях по улучшению Bitcoin и документации Bitcoin Core. Эти ссылки определяют кодировки адресов, witness-программы и поведение скриптов; они не доказывают личность или безопасность конкретного адреса получения. Более широкий подход к источникам BitcoinToolkit описан на Источники данных page.

• BIP 13: Формат адреса для pay-to-script-hash — определяет формат адреса Base58Check P2SH.
• BIP 16: Pay to Script Hash — определяет модель трат P2SH и оценку redeem-скрипта.
• BIP 49: Схема вывода для P2WPKH-вложенного-в-P2SH — документирует распространенную конструкцию вложенного-SegWit с одним ключом, обсуждаемую в этом руководстве.
• BIP 141: Segregated Witness — определяет witness-программы, транзакционный Weight и семантику выходов SegWit.
• BIP 173: Формат адреса Base32 для нативных v0-16 witness-выходов — ввел кодировку нативного адреса SegWit Bech32.
• BIP 350: Формат Bech32m для witness-адресов v1+ — определяет Bech32m и правило контрольной суммы для новых версий witness.
• BIP 341: Taproot — определяет правила выхода и трат Taproot, включая witness-версию 1 P2TR.
• Дескрипторы выходов Bitcoin Core — документируют структурированные описания распространенных скриптов выходов Bitcoin и ключевых выражений.

Источники

1. BIP 13: Формат адреса P2SH
2. BIP 141: Segregated Witness
3. BIP 173: Нативные адреса SegWit Bech32
4. BIP 350: Bech32m
5. BIP 341: Taproot
6. Дескрипторы выходов Bitcoin Core

Нашли ошибку? Сообщить о проблеме с контентом или прочитайте наши Политика исправлений.