Совместимы ли все три типа биткойн-адресов (устаревший, segwit, собственный segwit)?

Абсолютно!

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

Тем не менее, вы можете услышать что-то вроде:

«Старые адреса несовместимы с SegWit»

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

Устаревший адрес

Оригинальный формат адреса Биткойн — хеш Pay-to-Pubkey (P2PKH) — строит транзакцию с использованием хэша открытого ключа получателя. Если адрес начинается с 1, это устаревший адрес. Он по-прежнему широко используется из-за простоты и универсальной интеграции, и, хотя P2PKH может отправлять на адрес SegWit, комиссия немного выше, потому что устаревшие транзакции немного больше.

P2SH-адрес

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

Если вы слышали термин «неродной SegWit» или задавались вопросом, почему SegWit называют «родным SegWit», то это из-за этого адреса. Несмотря на то, что адрес отправки не является SegWit, создается транзакция P2SH, которая содержит внутри себя «хеш Pubkey Pay-to-Witness-Pubkey». Это имитирует форматирование SegWit, позволяя собственному адресу SegWit интерпретировать его, ну... естественно.

СегВит и Беч32

Bech32 — это собственный формат адреса SegWit, который более эффективен при использовании блочного пространства. Адрес Bech32 можно определить по его bc1префиксу. SegWit — это формат транзакции, который разбивает ( Seg regates) транзакцию на две части: одну , содержащую стандартные данные идентификатора транзакции (кому, от, сумма, подписи и т . Ончейн на 75% меньше среди других преимуществ. Поскольку свидетель содержит, среди прочего, «уменьшенную версию» устаревших данных, он позволяет отправлять транзакцию SegWit на устаревший адрес (без экономической выгоды) или на адрес SegWit (как более дешевая транзакция, основанная только на свидетеле). ). Однако устаревший адрес не знает, как генерировать данные-свидетели, поэтому он не может включить их в транзакцию SegWit и воспользоваться преимуществами. Это нормально, потому что SegWit-адресу не нужны данные-свидетели, поэтому устаревший адрес не будет иметь проблем с отправкой токенов на SegWit-адрес.

Полная выгода от SegWit

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

Если вы используете адрес Bech32 для отправки транзакции SegWit, все его преимущества реализуются, когда UTXO был отправлен вам как транзакция SegWit, но всегда будет отправляться в любом случае.

Смешанные транзакции сценариев

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

1. Алиса получает 0,5 BTC на свой кошелек SegWit со старого адреса Боба.
2. Алиса получает от Чарли 0,5 BTC, которые были отправлены с помощью SegWit.
3. Алиса отправляет транзакцию в 1 BTC, которая использует как традиционные, так и нативные транзакции SegWit, на адрес Bech32.

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

ПРИМЕЧАНИЕ. Некоторые старые клиенты кошельков или клиенты без поддержки SegWit могут не распознавать более новые версии адресов как действительные и не разрешать вам отправлять на них: это мера предосторожности (в коде кошелька, а не в коде биткойнов), чтобы пользователи от отправки на не биткойн-адрес.

Стержень -Update (Nov 2021)

Недавнее обновление Taproot добавило дополнительные изменения транзакций, включив подпись Шнорра в дополнение к традиционному алгоритму цифровой подписи на эллиптических кривых (ECDSA). Когда биткойн был первоначально выпущен, алгоритм Шнорра находился под патентной защитой. Использование Schnorr дает много преимуществ , самое главное — возможность агрегировать ключи подписи. В то время как мультиподпись P2SH включает в себя открытый ключ и подпись каждой стороны, Schnorr позволяет объединять ключи, обеспечивая конфиденциальность и упрощая вычисления для узлов.

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

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

Давайте лучше посмотрим, что происходит с транзакцией Биткойн:

• Получатель выбирает адрес, на который он хотел бы получить средства. Это будет формат адреса, с которого их кошелек знает, как тратить средства. В интересах получателя выбрать более эффективный формат адреса, чтобы сэкономить на расходовании средств, которые они получат позже.
• Отправитель выбирает входы, которые он хочет потратить. Сценарии ввода высечены в камне типом адреса, на который эти выходные данные были получены ранее. Тем не менее, отправитель заинтересован в том, чтобы выбрать эффективный тип адреса для вывода изменений, чтобы сэкономить будущие расходы.
• Старое программное обеспечение кошелька может не поддерживать отправку на новые типы адресов. В частности, собственные адреса SegWit получили стандарт адресов только в марте 2017 года ( BIP-173 ), и не все кошельки пока поддерживают отправку на эти адреса. В этом случае отправитель должен вместо этого попросить получателя предоставить упакованный адрес segwit. Все кошельки должны иметь возможность отправлять на обернутые адреса segwit, поскольку они используют стандарт адресов Pay to Script Hash (P2SH, BIP-16 ), который был введен в 2012 году.

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

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

Программное обеспечение кошелька, конечно, может иметь ограничения, но обычно речь идет не о комбинациях. Например, некоторые кошельки не могут сгенерировать адрес p2sh-segwit для получения или отправки на bech32. Однако я не слышал о программном обеспечении, которое налагает ограничения на то, куда оно может отправлять, исходя из того, что, например, было потрачено.

возможно ли отправлять транзакции туда и обратно между всеми тремя типами адресов (устаревший, segwit, собственный segwit-bech32)?

Да, конечно. Это совершенно нормально на уровне протокола.

Точно так же, как сказал Марч:

Нет ограничений на отправку с любого типа выходов на любой тип адреса в протоколе Биткойн.

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

Однако старый кошелек (или криптовалютная биржа с ленивой/консервативной технической командой) может не распознать нативные адреса bech32, поэтому вы не сможете отправлять биткойны из такого старого кошелька (или снимать с такого ленивого). обмен криптовалюты) на нативный адрес bech32 SegWit — это единственный существенный минус.

Обобщить:

Комиссия майнера : (самая дорогая) 1 — начальный старый адрес > 3 — начальный p2sh-segwit > bc1 — начальный bech32 (самый дешевый)

Совместимость : (наиболее совместимый) 1-начальный устаревший адрес ≈ 3-начальный p2sh-segwit (почти так же совместим, как и устаревший) > bc1-начальный bech32 (потенциальная проблема совместимости/взаимодействия)

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

Если кто-то слишком упрям, чтобы обновить/переключить свой кошелек, это не имеет значения, потому что (1) вы все равно можете дать ему/ей 3-стартовый SegWit-адрес; (2) вы можете полностью отправлять транзакции туда и обратно между всеми тремя типами адресов, используя кошелек с надлежащей поддержкой SegWit.

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

(Транзакция, отправляющая биткойны с) bc1-начального собственного адреса Bech32 SegWit, имеет наименьший размер данных (количество байтов), либо виртуальный (vByte), либо фактический/сетевой, поэтому она получает самые низкие комиссии майнера.

На самом деле SegWit (v0) не так сильно уменьшает размер транзакционных данных, его дешевая плата за майнинг является в основном искусственной скидкой. Однако транзакции SegWit действительно имеют техническое преимущество перед устаревшими, например, избегая проблемы квадратичного сигэша .

(Транзакция, отправляющая биткойны с) 3-стартового «совместимого» SegWit-адреса, обернутого в P2SH, на самом деле потребляет больше байтов, чем устаревший 1-стартовый адрес (главным образом потому, что сам «хеш-скрипт» P2SH занимает 20 байт), однако у него все еще есть более дешевый майнер. плату, чем 1-стартовый старый адрес из-за скидок.

3-начальный адрес — это P2SH , который был введен Гэвином Андресеном на очень раннем этапе истории биткойна (2012 г.), так что сейчас крайне маловероятно увидеть кошелек, который не может распознавать 3-начальные адреса P2SH.

SegWit использует P2SH для «обертывания» своего специального сценария «каждый может потратить» .

P2SH на самом деле может «обернуть» что угодно. Его типичное использование было мультиподписью в течение довольно долгого времени, намного раньше, чем SegWit.

Когда старый кошелек отправляет биткойны на 3-начальный адрес, его (плательщика) совершенно не волнует, что за вещи «завернуты внутрь» этого адреса. Это может быть как легаси мультиподпись, SegWit, так и что-то другое — что угодно, не важно.

(Это может быть даже совершенно бесполезный адрес!)

В этом случае получатель платежа несет ответственность за то, чтобы он (она) все еще мог тратить биткойны на этот 3-начальный адрес.

Тогда что такое «каждый может потратить»?

Старые версии (до 0.13) полных узлов Биткойн, конечно, вообще не знают о SegWit, поэтому они, очевидно, не могут проверять транзакции SegWit (или блоки, содержащие транзакции SegWit) в соответствии с недавно определенными правилами SegWit.

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

Что касается транзакций SegWit , эти старые узлы не будут принимать/пересылать/майнить какие-либо транзакции SegWit (кроме отправки на 3-начальный адрес SegWit, обернутый P2SH). Они будут принимать только подтвержденные транзакции SegWit, другими словами, только блоки SegWit. Поэтому, если вы хотите нарушить правила SegWit, вы должны, по крайней мере, сами стать (соло) майнером, практически бесплатная попытка, такая как отправка недействительной «грабительской» транзакции с некоторых адресов SegWit, вообще не сработает. (Здесь проявляется небольшой недостаток SegWit, заключающийся в том, что старые полные узлы, не поддерживающие SegWit, не могут видеть транзакции SegWit с нулевым подтверждением)

SegWit был тщательно разработан для достижения этой цели. На самом деле это очень похоже на то, что сделал P2SH.

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

К блокчейну применяются только «правила действительности» или «правила консенсуса».

Адрес SegWit на самом деле означает, что «любой может потратить биткойны на этот адрес» в соответствии со старыми правилами валидности , так что старые узлы по-прежнему будут принимать блоки SegWit. (Поэтому действительно существует теоретический неизбежный риск того, что может произойти разделение цепочки, если некоторые злоумышленники будут настаивать на майнинге/расширении недействительной цепочки блоков, «грабив» адреса SegWit — однако будет по-прежнему четко различима действительная цепочка и недействительная Новые узлы, поддерживающие SegWit, будут принимать только действующую цепочку) Это нарушает старые правила стандартизации , так что старые узлы не будут добывать транзакции SegWit в свои собственные блоки.

В соответствии с новыми правилами действительности , расходование биткойнов с адреса SegWit (как правило) должно предоставлять действительные подписи, без полностью действительных подписей это будет недействительная транзакция, поэтому новые узлы отклонят либо такую ​​недействительную транзакцию, либо (таким образом, недействительный) блок. включая любую недействительную транзакцию. Новые узлы, конечно же, также не будут копировать недействительные транзакции в свои блоки. Однако, в соответствии с новыми правилами стандартизации , (действительные) транзакции SegWit также являются стандартными (не нарушая новые правила стандартности), так что новые узлы с радостью будут добывать действительные транзакции SegWit в своих собственных блоках.