формат bech32 p2wpkh что значит
От Legacy к SegWit
Legacy и SegWit — два странных и непонятных криптоновичку слова, применяемых для обозначения формата адресов Bitcoin-кошельков. Несмотря на сложность вопроса, это одна из важных тем для тех, кто решил приобщиться к миру криптовалют.
Многие уже заметили, что в различных кошельках адреса отличаются друг от друга: некоторые начинаются с “1”, другие с “3”, а есть и вовсе такие, что начинаются с “bc1”. Конечно же, такие отличия могут ввести в ступор пользователя — во-первых, не совсем понятно, для чего такое разнообразие, во-вторых, появляется страх потери средств при переводах (вдруг биткоины так и не дойдут до адресата).
Что ж, боязнь в целом оправдана, но “не так страшен черт как его рисуют”. В этой статье мы разберем все тонкости связанные с bitcoin-адресами и покажем, что на самом деле все просто!
ЧТО ТАКОЕ BITCOIN АДРЕС
Адрес bitcoin кошелька (уникальный идентификатор) — это что-то вроде номера вашего криптовалютного счета. Он необходим как для получения биткоинов, так и для их отправки. Чтобы совершить перевод (транзакцию), пользователю необходимо указать адрес кошелька получателя. В свою очередь, получателю необходимо предоставить свой адрес отправителю. До недавнего времени, проблем с пониманием разных типов адресов и транзакций не было, поскольку все участники сети использовали единый формат биткоин адресов, а именно — Legacy. Но с развитием технологий, сменился не только формат записи адресов, но и способ обработки транзакций, совершаемых между адресами.
Давайте более детально рассмотрим важные моменты этого вопроса…
ЧТО ТАКОЕ LEGACY
Legacy-адрес (P2PKH — Pay To Public Key Hash) — это стандартный формат Bitcoin адреса, изначально предусмотренный в протоколе и используемый большинством крипто-кошельков и сервисов. Такой адрес, предложенный создателем биткоина Сатоши Накамото, можно определить по цифре «1» (префикс), стоящей в начале каждого адреса (пример: 18sp5z1aYXMXGxef1xiPbCYnspcG8eQznh). Этот формат адресов был и остается самым ходовым с момента запуска сети bitcoin. Несмотря на широкое распространение Legacy-адресов, у них есть ряд прямых и косвенных недостатков:
— Чувствительность к регистру вводимых данных и неудобство записи на бумаге;
— Низкий приоритет для майнеров так как таких транзакций в блок помещается намного меньше;
— Урезанная криптографическая стойкость используемой Биткоином цифровой подписи;
— Не “гибкие” транзакции.
Технические тонкости!
Bitcoin использует алгоритм Base58 для преобразования открытых ключей в читаемый человеком формат. Он достаточно схож с известным Base64, но использует сокращенный алфавит, то есть некоторые символы не используются во избежание гомографических атак. В связи с этим, в Legacy-адресах мы никогда не увидим таких символов, как 0 (ноль), О (заглавная буква «о»), I (заглавная «i»), l (строчная «L») а также знаки «+» и «/».
*Гомографическая атака — способ, с помощью которого злоумышленник может ввести в заблуждение пользователей, используя тот факт, что многие различные символы выглядят одинаково (т.е. являются гомографами, отсюда и термин, хотя технически гомоглиф является более точным термином для разных символов, схожих друг с другом). Например, Trustee Wa11et.
Казалось бы, что недостатки не такие уж и существенные, однако, с ростом популярности биткоина они стали играть немаловажную роль. Как мы знаем, комиссия за транзакцию оплачивается в сатошах (малая часть биткоина), поэтому с ростом стоимости самого биткоина цена за транзакцию тоже стала расти. Конечно, при переводе 10 000$ в BTC, комиссия в 5$ будет казаться не большой, но для микро переводов, где такая комиссия составит 10%, а то более от суммы перевода — это значительный недостаток. Добавим к этому медленные переводы и все — “приплыли”!
ЧТО ТАКОЕ SEGWIT
До конца лета 2017 года рядовые пользователи BTC успешно пользовались классическими Legacy адресами для осуществления транзакций. Но 24 августа в сети Bitcoin состоялся софт-форк, предложенный в марте 2016 года разработчиками П. Велле и Г. Максвеллом. Обновление предусматривало активацию протокола Segregated Witness и новый формат биткоин-адреса — Bech32 или SegWit-адрес (P2WPKH — Pay to Witness Public Key Hash).
Segregated Witness (“отделенный свидетель”) позволил сократить вес транзакций в блоках сети Bitcoin за счет удаления из них подписей и выносе их в “дополнительные данные”, с последующей индивидуальной обработкой.
Краткое описание технологии: протокол SegWit отделяет криптографическую подпись от самой транзакции и выносит ее за пределы основного блокчейна. При этом, высвободившееся в основном блоке место заполняется другими транзакциями.
Внедрение SegWit привело к увеличению пропускной способности транзакций, поскольку в блок их стало входить гораздо больше. При этом остро стоявшая проблема высоких комиссий отпала сама собой, так как уже не требовалось выставлять более щедрое вознаграждение майнерам, чтобы они подтверждали Ваши транзакции в первую очередь.
Обновление затронуло не только метод формирования блоков с транзакциями, но и сам формат записи публичных ключей bitcoin-кошельков. SegWit-адреса начинаются с «bc1» (пример: bc1qnnc0enjmp4essg8t8rxqnyg9394qgwwjtpngv9), при этом они вводятся независимо от регистра, т.е. bc1qnnc… = bc1Qnnc… = BC1QNNC… Такой формат записи адресов в достаточной степени упростил их использование и сделал более удобным для записи.
К преимуществам SegWit-адресов можно отнести:
— Высокая степень защиты от ошибок записи;
— Увеличение пропускной способности транзакций;
— Снижение комиссий до 50%.
Основной минус обновленного протокола в том, что не все криптовалютные сервисы его поддерживают, но в этом случае есть решение в виде промежуточного адреса, именуемого как Compatible.
Среди известных крипто кошельков, поддержка SegWit внедрена в Trustee Wallet, Trezor, Electrum, Ledger Nano S.
ЧТО ТАКОЕ MULTISIGNATURE И COMPATIABLE АДРЕСА
Данный тип адресов появился в далеком 2012 году, чтобы хоть как-то решить проблему дорогих транзакций. Главным научным сотрудником Bitcoin Foundation — Г. Андерсоном, было предложено обновление BIP-0016, которое позволило бы улучшить логику исполнения транзакций, разрешив отправку не просто на адреса, но и на программируемые ключи (что-то похожее на смарт контракты в Ethereum). В результате внедрения обновления появились биткоин-адреса начинающиеся с префикса “3” (пример: 3FVeDqkWXGPmgugHD1FLn9xMfeZcF181RG). При этом структура адреса осталась схожей со структурой Legacy-адресов. Такие Multisignature адреса вы часто могли видеть в “кошельках с мультиподписью”, когда от одного адреса есть 2 или 3 приватных ключа.
Не будем углубляться в техническую суть таких адресов, а лишь коснемся их взаимодействия с адресами Legacy и SegWit.
Внедрение SegWit не поддерживалось на старых кошельках, то есть они не видели Bech32-адресов и не могли понять, что делать с таким “получателями”, поэтому промежуточный P2SH-формат, а именно Compatible, стал неким мостом во взаимодействии различных адресов. Специальный скрипт, зашифрованный в ключе к адресу 3ххх позволяет пользователям старых кошельков отправлять средства на новые (3ххх), а владельцам новых — уже тратить их по технологии SegWit (то есть оплачивать транзакции по низким комиссиям).
ОТ LEGACY К SEGWIT В TRUSTEE
После введения протокола SegWit в Trustee Wallet, у некоторых пользователей стали появляться вопросы: “Как так, я отправил часть средств в BTC, а с баланса списались все, почему?”. Чтобы ответить на этот вопрос потребуется немного углубиться в работу самого биткоина.
Биткоин сам по себе достаточно сложен в плане обработки транзакций. Упрощенно этот момент можно описать так: когда вы хотите отправить часть баланса кому-либо, то с вашего кошелька уходит не часть баланса, а вся сумма, разделенная на нового владельца с его долей (тем что вы ему отправили) и сдачей на ваш адрес (тем что осталось от баланса за вычетом комиссии транзакции). Весь этот процесс отправки, разделения и возврата “сдачи” происходит в рамках одного блока, одной транзакции. После подтверждения отправки вы сможете использовать “сдачу” для следующих своих транзакций.
Говоря о поддержке Segwit в Trustee, важно отметить одну особенность. Отправляя средства с Legacy-адреса, сдача возвращается не на Legacy-адрес, а на SegWit. Благодаря этому, переход с устаревшего, медленного и дорогого формата Legacy на более быстрый и дешевый SegWit становится для пользователя легким, удобным и не требует дополнительных затрат, снимая необходимость отдельной транзакции для перевода между своими адресами.
ПОДВЕДЕМ ИТОГИ
Мир не стоит на месте, а уж мир криптовалют и подавно, развитие и совершенствование протоколов неизбежно. Выше мы рассмотрели используемые типы адресов для биткоина и надеемся внесли долю ясности в понимание происходящего. Если у Вас все же остались вопросы, то мы с радостью ответим на них в нашем Telegram чате.
Команда Trustee Wallet всегда идет в ногу со временем, присоединяйтесь к нам!
Какие форматы бывают у биткоин-адресов?
Что такое биткоин-адрес в формате legacy?
Legacy-адрес — это стандартный для сети биткоина адрес, предложенный Сатоши Накамото. Иначе это формат называют P2PKH (Pay To Public Key Hash), поскольку он требует от получателя подпись, вычисленную из приватного ключа, и публичный ключ. Скрипт транзакции выхода с помощью криптографических функций сверяет их с хешем публичного ключа — и в случае совпадения позволяет расходовать средства. Вероятность того, что система примет некорректно введенный адрес составляет 1232, то есть один случай из 4,29 млрд.
Legacy-адрес можно узнать по префиксу 1 (и m или n в тестовой сети). К основным минусам такого адреса относятся чувствительность к регистру при вводе данных, более высокие комиссии за операции, низкая скорость двойного хеширования контрольной суммы, больший вес в QR-кодах и неудобство записи на мобильном устройстве или на бумаге.
Пример legacy-адреса: 1BUrDeWstWetqBFn5Au8m4JFg2xJaKVN4
Из каких частей состоит биткоин-адрес в формате legacy?
Legacy-адреса уникальны, обычно состоят из 26-35 символов и представляют собой 160-битные хэши открытого ключа ECDSA ключевой пары. С появлением SegWit-адресов их стали называть старыми, однако изначально они были достаточно эффективным средством представления locking scripts в более удобном для пользователей виде и уменьшения рисков отправки средств на некорректный адрес.
Стандартный биткоин-адрес состоит из таких частей:
Почему в биткоин-адресах бывает разное количество знаков?
Если при преобразовании приватного ключа в начале результата появились нули, в строку биткоин-адреса в формате legacy они не включаются, и тогда он сокращается на соответствующее количество знаков. Поэтому биткоин-адрес может состоять не из 34, но теоретически даже из 20 символов.
Как зашифрованы части legacy-адреса?
Все части биткоин-адреса в формате legacy зашифрованы с защитой от опечаток по системе кодирования Base58Check. В основе кода лежит латинский алфавит. Вы никогда не увидите в таком биткоин-адресе символы, которые легко спутать между собой (знаки плюс и минус, косая черта, ноль, прописные буквы “o” и “i”, строчная “L”). Согласно системе Base58Check в них применяются только следующие 58 символов:
Что такое биткоин-адрес в формате P2SH?
P2SH-адреса (Pay to script hash) появились в предложении по улучшению биткоина BIP-0016 в январе 2012 года благодаря главному научному сотруднику Bitcoin Foundation Гэвину Андресену. Они имеют ту же структуру, что и legacy-адреса, но начинаются с цифры 3.
Такие адреса предполагают, что при переводе средств получатель должен иметь скрипт, подходящий к скрипту хеша. Эта особенность позволяет снижать комиссию за перевод биткоинов отправителем, перекладывать комиссионные затраты на получателя и создавать адреса с мультиподписью.
Технология P2SH может разрешить использование средств любым пользователем или, наоборот, запретить для всех. Важно помнить, что биткоин-адреса в формате P2SH поддерживают SegWit, но не являются его нативным решением. Не поддерживающие SegWit криптокошельки могут проводить SegWit-транзакции благодаря механизмам P2WPKH-в-P2SH и P2WSH-в-P2SH.
Пример P2SH-адреса: 3H28N5WuREZ93CNmhWcRcrnykWrMqkhFyWN
Что такое биткоин-адрес в формате SegWit?
Весной 2016 года разработчики Питер Велле и Грег Максвелл в обновлении BIP-0173 предложили новый формат адреса: Bech32 (часто он же называется SegWit-адрес, P2WPKH — Pay to Witness Public Key Hash). Сам протокол SegWit (Segregated Witness, «отделенный свидетель») предполагал сокращение размера блока в сети биткоина за счет удаления из него подписи и был активирован в конце августа 2017 года.
SegWit-адреса начинаются с bc1 (в тестовой сети — с tb), содержат до 90 знаков (чаще — около 42), при этом пишутся либо только в верхнем (для QR-кодов), либо только в нижнем регистре (предпочтительно).
SegWit-адреса состоят из:
Пример Bech32-адреса: bc1uf5tdn87k2uz7r2kl5zrfww362ch3746lq5vse7
Какие плюсы и минусы использования Bech32-адресов?
C новыми адресами QR-коды стали меньше, а защита от ошибки выше. Кроме того, использование биткоин-адресов в формате Bech32 на сегодня для пользователей более выгодно, ведь комиссия за отправку средств с них ниже, а скорость обработки выше. Главный минус Bech32-адресов — их поддерживают не все криптокошельки и сервисы.
Среди первых поддержку таких адресов добавили аппаратные криптокошельки Ledger Nano S, TREZOR и Digital Bitbox, десктоп-криптокошельки Electrum и Armory, мобильные криптокошельки Edge, GreenAddress (для iOS- и Android-устройств), а также Samourai Wallet, Wasabi Wallet, GreenBits и Electrum (для Android-устройств).
Можно ли переводить биткоины с legacy-адреса на SegWit-адрес?
Активация SegWit в сети биткоина была софтфорком — это значит, что новая и предыдущая версии сохранили совместимость. То есть вы можете без проблем переводить средства с legacy-адреса на SegWit-адреса. На уровне блокчейна проблем с разницей в форматах адресов не существует.
На практике сложности возникают, если пользователь хочет перевести средства со своего legacy-адреса, например, созданного на криптобирже, на bc1-адрес, а торговая площадка технически еще не внедрила поддержку нового формата адресов. В таком случае стоит использовать пусть и менее эффективный, чем bc1-, но все же более продвинутый, чем legacy- P2SH-адрес.
В обратном направлении, с bc1-адреса на legacy-адрес, средства должны поступить без проблем.
Какие обозреватели блоков отслеживают bc1-адреса?
Подробно об обновлении Segregated Witness и последствиях его принятия в Bitcoin
В данной статье мы постарались детально рассмотреть изменения протокола Bitcoin, которые произошли в результате softfork-обновления Segregated Witness. Мы затронули вопросы, связанные с transaction malleability, сохранением обратной совместимости, увеличением пропускной способности, новыми форматами сериализации транзакций, новыми вариантами скриптов, форматом адресов Bech32 и его преимуществами, понятиями веса, размера и виртуального размера. Более того, ниже приведена самая важная статистика по адаптации обновления и представлены ответы на часто задаваемые вопросы по теме данного обновления.
Перед тем как переходить к детальному описанию всех изменений данного обновления, предлагаем познакомиться с главной идеей Segregated Witness. Дословно Segregated Witness переводится с английского, как «отделенный свидетель». В контесте Bitcoin подразумевается, что данные доказательства владения монетами будут храниться отдельно от основных данных транзакции, как обозначено на схеме. 
Если рассматривать обновление протокола целиком, то оно включает в себя множество других улучшений. SegWit позволяет увеличить пропускную способность сети, отделить данные доказательств владения монетами от остальных данных транзакции, исправить недостатки формата транзакций, связанные с возможностью модификации данных в подписанных транзакциях (transaction malleability), и при этом сохранить обратную совместимость с предыдущими версиями протокола. А наибольшая ценность данного обновления состоит в том, что оно позволяет реализовать множество очень важных off-chain решений поверх протокола Bitcoin.
Проблема transaction malleability и ее решение
Суть в том, что при работе в Bitcoin существует возможность изменить транзакцию таким образом, что она останется корректной при верификации. Эти изменения очень незначительные, они не касаются адресов отправителя и получателя, но их достаточно для изменения результата хеширования. Другими словами, транзакция будет переводить монеты на прежние адреса, но ее измененное хеш-значение уже не даст соответствия модифицированной транзакции с оригинальной.
Очевидно, что вышеописанная ситуация может случиться только с транзакциями, которые еще не получили подтверждения. Без ее решения невозможно добиться надежной работы off-chain протоколов, которые предусматривают построение цепочек из неподтвержденных транзакций. Поскольку при составлении транзакции подписываются не все данные (например, нельзя подписать scriptSig), существует возможность проведения нескольких видов атак:
Прежде всего следует отметить, что существует возможность создать копию оригинальной транзакции, добавить в нее изменения, которые не повлияют на ее корректность при верификации, и отправить в сеть. Модифицированная копия с другим хеш-значением тратит те же монеты, что и оригинальная, поэтому она может конкурировать с оригинальной транзакцией за подтверждение.
Выше были упомянуты off-chain протоколы. Для их реализации решение проблемы transaction malleability необходимо. В основе их работы лежит построение цепочек из неподтвержденных транзакций. Изменение хеш-значения первой транзакции повлечет за собой невалидность всей цепочки неподтвержденных.
В обновлении SegWit были определены строгие правила заполнения полей, поэтому проблемы, связанные с transaction malleability, для транзакций нового формата можно считать решенными. Это позволило задавать данные и сериализовать их однозначно, исключая двойственность.
Обратная совместимость при распространении блока по сети
Согласно старым правилам максимальный размер блока равен 1 MB и содержит транзакции со встроенными доказательствами. В то время как новые правила предполагают, что максимальный базовый размер блока 1 MB, но дополнительно существует структура данных с доказательствами. Соответственно, итоговый размер нового блока превышает 1 MB.
С целью обратной совместимости правила работы протокола позволяют работать старым узлам с новыми блоками, но они будут получать блок только в базовой комплектации с максимальным размером 1 MB. Им недоступна структура witness. Новые же узлы получают полноценный блок с транзакциями и доказательствами. Ознакомиться с этим вопросом поможет следующий рисунок.
Слева представлена схема работы протокола Биткоин до активации Segregated Witness. Блок имел максимальный размер 1 MB, и он распространялся между различными узлами сети в одном виде.
Поскольку размер блока ограничен, то ограничено и количество транзакций, которые можно поместить в него, а от этого зависит пропускная способность системы. Разумеется, когда возник вопрос о повышении пропускной способности, в первую очередь ответ начали искать в способах увеличения максимального размера блока.
Способы увеличения пропускной способности
Рассмотрим два основных способа решения проблемы увеличения пропускной способности системы. Любое предложение тщательно проверяется и тестируется командой разработчиков протокола Биткоина. Если согласие комьюнити достигнуто и решено внедрить предложение в протокол, выходит обновление.
Hardfork обновление. Самое банальное из обновлений и заключается в увеличении размера блока. Предполагается, что один блок будет вмещать больше транзакций, повышая пропускную способность. Однако такой блок не будут принимать узлы, работающие по старому протоколу, в правилах которого записано, что максимальный размер блока не может превышать 1 МВ. Такое изменение требует hardfork, который организационно более сложен, чем softfork.
SoftFork обновление. Segregated Witness позволяет нам решить эту проблему при помощи softfork. Как именно? Он позволяет нам разделить блок на две части, в первой из которых хранятся транзакции, а во второй – доказательства. При этом новые узлы сети получают обе части, а старые – только блок транзакций размером 1 MB. Старые узлы не могут получать блоки с доказательствами и, соответственно, не могут валидировать транзакции, которые получают, но это позволяет им участвовать в достижении консенсуса и не прибегать к hardfork, а постепенно переходить к новому ПО.
Новшества Segregated Witness
Рассмотрим, что входит в обновление Segregated Witness. Первым и самым важным новшеством Segregated Witness стал новый формат сериализации транзакций. Кроме уже известных полей, в новой транзакции присутствуют три новых: marker, flag, которые применяются для версирования и в данном случае они строго заданы, но в следующих протоколах они могут меняться, а также поле witness. Witness (witness data) – это фактически набор доказательств владения монетами, которые вынесены за пределы основной части транзакции. Структурно он выглядит, как набор входов, при этом каждый элемент witness data соответствует входу с определенным номером, что позволяет сопоставить доказательства с конкретными потраченными монетами.
Witness transaction id
Чтобы получить идентификатор транзакции (transaction id, txid), нужно привести саму транзакцию к одной последовательности данных по специальному формату сериализации, а потом получить хеш-значение от этой последовательности данных. С введением Segregated Witness появился и новый идентификатор, witness transaction id (wtxid), и новый формат сериализации, соответственно. Для старых транзакций, которые тратят средства, не используя Segregated Witness, wtxid будет таким же, как txid, потому что у них не будет новых полей, которые добавились в Segregated Witness.
Wtxid нужен, чтобы построить альтернативный Merkle tree для доказательств. Строится он точно так же, как и для обычных транзакций, только вместо хеша транзакции здесь применяется wtxid. Соответственно, wtxid попарно хешируются и дают в результате Merkle root.
Важно отметить, что Merkle root вставляется в coinbase транзакцию, а не в заголовок блока. Если бы root находился в заголовке блока, то изменилась бы структура блока. Узлы, которые поддерживают старый протокол, не могли бы работать с такими блоками. И все старания сохранить обратную совместимость упирались бы в эту несостыковку. Поэтому root вставляется в один из выходов coinbase транзакции. Когда все узлы перейдут на Segregated Witness, эта ситуация может измениться и будут рассматриваться новые подходы.
Witness programs для задания условий траты монет
Давайте рассмотрим, как строится скрипт Segregated Witness транзакции и как он позволяет старым узлам сети понимать, что транзакции Segregated Witness правильные, несмотря на то, что они не получают доказательств владения монетами.
Скрипт описывающий правила траты монет из транзакции нового формата состоит из двух частей. Первая часть – это witness version byte (байт определяющий версию witness program). Он может принимать значения от 0 до 16 (OP0-OP16), сейчас используется OP0. В будущем могут появляться новые версии протокола c поддержкой других версий witness program. Вторая часть – это witness program. Эта часть может иметь размер от 2 до 40 байт.
Witness program является результатом хеширования witness script. Сам witness script содержит полное описание условий траты монет. Witness data содержит доказательства владения монетами, которые должны удовлетворять условиям из witness script. Соответственно witness data всегда состоит из двух частей: witness script и доказательства владения монетами.
Стоит отметить, что witness program не содержит никаких операций (совпадения хеш-значений, проверки электронных подписей), а сам скрипт начинается с кода OP0, следовательно, он валиден для всех старых узлов. Причем узлы, которые не обновились до SegWit, не проверяют доказательства владения монетами для выходов нового формата, они такую трату считают правильной в любом случае. Строго говоря, старые узлы будут принимать транзакции нового формата даже если ее отправитель на самом деле не владеет соответствующими монетами. Именно поэтому SegWit требует, чтобы владельцы большинства майнинговой мощности Биткоина приняли это обновление. Еще одна особенность состоит в том, что scriptSig у транзакции, которая тратит монеты из выхода нового формата, будет пустым.
Новые варианты задания условий траты монет
С введением SegWit было предложено два стандартных формата для scriptPubKey, которые стали альтернативой двум наиболее распространенным форматам задания правил траты монет еще до появления этого обновления. Рассмотрим их по порядку.
Pay to witness public key hash (P2WPKH) является аналогом стандартного pay to public key hash. В чем состоит его отличие? Как было отмечено раньше, scriptSig не заполняется и остается пустым. Все доказательства владения монетами переносятся в структуру witness data.
При этом в scriptPubKey вставляется скрипт, который был рассмотрен ранее, версия и хеш публичного ключа, который является witness program. Узел в сети отличает такой скрипт траты от других благодаря тому, что версия у него равна единице, а размер данных 20 байт. Другая версия и другой размер несут в себе другие правила траты.
В данном случае scriptPubKey содержит две части: номер witness версии равный нулю и хеш-значение открытого ключа получателя. ScriptSig будет пустым, а witness data будет содержать электронную подпись и открытый ключ для ее проверки.
Pay to witness script hash (P2WSH) – это аналог стандартного pay to script hash. В данном случае могут использоваться custom script для задания правил траты монет. Как узел сети отличает такой скрипт от предыдущего? В этом случае версия по-прежнему имеет значение единицы, а witness программа занимает 32 байта и является хеш-значением от witness script. Если на узел сети придет транзакция, содержащая какой-то скрипт, который будет иметь первую версию, но его размер будет отличаться от значений 20 или 32 байта, то узел отклонит эту транзакцию, потому что он не будет знать, как с ней работать.
Witness data здесь делится на две части. В первой содержится набор доказательств владения монетами, то есть набор подписей. Во второй части размещается witness script, содержимое которого как раз и задает правила траты монет, но в данном случае оно указывается в момент траты, а в момент отправки монет указывалось его хеш-значение.
В данном случае scriptPubKey содержит две части: номер witness версии равный нулю и хеш-значение witness script для случая мультиподписи 1-из-2. ScriptSig будет пустым, а witness data будет содержать электронную подпись и исходный witness script в открытом виде.
P2SH обертка
Новый формат скрипта отличается от старого. Соответственно, старые сервисы и кошельки не будут знать, как работать с таким форматом скрипта и как его составить. С целью обратной совместимости в Segregated Witness транзакциях при помощи P2SH используется специальная «обертка», которая позволяет сформировать транзакцию, обладающую свойствами Segregated Witness транзакции, но не отличающуюся от обычной P2SH для внешнего мира.
P2SH применяется, чтобы упростить работу отправителя и не обременять его деталями реализации Redeem Script получателя. В этом случае получатель дает отправителю только хеш-значение Redeem Script, а сам скрипт передает в scriptSig вместе с доказательствами.
В данном случае scriptPubKey содержит операцию хеширования, хеш-значение redeem scrip и операцию сравнения (как для старой версии P2SH). ScriptSig тут будет содержать хеш-значение открытого ключа, а witness data будет содержать электронную подпись и открытый ключ.
Такой подход позволяет не обновленным цифровым кошелькам отправлять транзакции на Segregated Witness адреса, фактически ничего не зная о новых способах задания условий траты монет.
Новый формат адресов Bech32
Спецификация Bech32 адреса
Адрес Bech32 имеет длину, которая не превышает 90 символов, и содержит:
Зачем включать разделитель в адреса? Это позволяет однозначно отделить человекочитаемую часть от части с данными, избежав потенциальных столкновений с другими человекочитаемыми частями, которые используют префикс. Это также позволяет избегать ограничений в наборе символов для человекочитаемой части. Сепаратор равен 1, потому что использование не алфавитно-цифрового символа затруднит копирование адресов (без выбора двойного щелчка в нескольких приложениях). Поэтому был выбран буквенно-цифровой символ вне основного набора символов. Также использование системы счисления по основанию 32 сопровождается увеличением длины адреса на 15% по сравнению с системой счисления по основанию 58, но это не имеет значения при копировании адресов.
Контрольная сумма Bech32 адреса
Последние 6 символов адреса являются контрольной суммой. Контрольная сумма построена на основе БЧХ-кода, который гарантирует обнаружение любой ошибки, затрагивающей не более 4 символов, а шанс того, что контрольная сумма сойдется, когда допущено более 4 ошибок, один из 109.
Одним из преимуществ использования БЧХ-кодов является то, что они могут использоваться для исправления ошибок. Если в адресе было допущено до 4 ошибок, то они будут исправлены автоматически. А если допущено больше ошибок, то они будут обнаружены с высокой вероятностью, но уже без возможности их автоматического исправления.
Верхний и нижний регистр в адресе
Нижний регистр применяется, когда требуется определение значения символа для контрольной суммы.
ПО всегда выводит всю строку адреса Bech32 в нижнем регистре. Если требуется версия в верхнем регистре (например, в целях презентации или использования в QR-коде), то это доступно опционально. Более того, ПО не будет принимать адреса, в которых некоторые символы в верхнем регистре, а некоторые в нижнем. Для отображения нижний регистр обычно более предпочтителен, но для QR-кодов следует использовать верхний регистр, поскольку он позволяет буквенно-цифровое представление, которое кодируется на 45% компактнее, чем байтовое представление.
Понятия веса и размера блока
Еще одним важным изменением, которое внесло обновление Segregated Witness, является введение такого понятия, как вес транзакции и вес блока. До Segregated Witness обычно говорили только о размере транзакции и размере блока. При этом размер блока был ограничен 1 MB. После активации обновления существует два формата транзакций. Соответственно, дальше поддерживать нужно оба.
С целью решения этой проблемы было введено понятие веса транзакции и соответствующих весовых единиц (weight units). Размер основной части транзакции теперь учитывается с коэффициентом 3, а размер witness data с коэффициентом 1. Как можно догадаться, любые данные, которые включались в witness data требовали в 3 раза меньшей комиссии, чем основные данные транзакции. Подобный подход позволяет валидаторам определить более выгодную транзакцию в отношении занимаемого в блоке места и получаемым вознаграждением. Вес рассчитывается по специальной формуле.
block weight = base size * 3 + total size
block weight – вес блока (измеряется в весовых единицах)
base size – базовый размер блока (измеряется в байтах)
total size – итоговый размер блока (измеряется в байтах)
В этой формуле базовый размер транзакции значит, что размер транзакции при сериализации по старым правилам умножается на три и результат суммируется с размером транзакции, сериализованной по новым правилам. В результате получаем вес транзакции.
Вне зависимости от того, по новым или по старым правилам сериализована транзакция старого образца, размер она всегда будет иметь одинаковый, соответственно, вес будет ровно в 4 раза больше. А для Segregated Witness транзакции вес будет чуть меньше, потому что в размер транзакции не будут включаться данные доказательств владения монетами.
Вместе с весом было введено понятие виртуального размера, который вычисляется путем деления веса на четыре. Виртуальный размер (virtual size) используется, чтобы рассчитать комиссии для транзакций и чтобы валидаторы могли понять, насколько им выгодно включать определенную транзакцию в блок используя привычную цену записи, которая измеряется в единицах spb (satoshi per byte).
virtual size = weight units / 4
Поскольку вес транзакции для не Segregated Witness будет в 4 раза больше, чем размер, то виртуальный размер транзакции будет равен обычному размеру. Соответственно, для старых транзакций подсчет комиссии не изменится. Для новых транзакций он будет чуть меньше, потому что подписи выносятся в отдельную структуру. Таким образом, за них можно платить меньшие комиссии, но иметь тот же приоритет у майнеров при включении в блок. При этом, максимальный размер блока без witness data (base size) остался 1 MB, а максимальный вес блока равен 4 MB.
Здесь может возникнуть логичный вопрос: «каким будет фактический размер блока вместе с witness data?». Абсолютно точно ответить на него невозможно. Очевидно, что это значение будет находиться в пределах от 1 MB до 4 MB. Но можно сделать более точную теоретическую оценку. Получится около 1.8 MB. Откуда это значение? Типичный блок с транзакциями на текущий момент состоит примерно на 60% из открытых данных. Если посчитать вес блока размером 1 MB, состоящего на 40% из данных доказательств владения монетами, то получим следующие данные.
400000 байт * 4 = 1600000 условных единиц веса
600000 байт * 1 = 600000 условных единиц веса
1600000 + 600000 = 2200000 условных единиц веса
4000000 / 2200000 = 1.81 MB
То есть, можно предполагать, что эффективный размера блока будет около 1.8 MB. Но очевидно, что на практике это значение будет полностью зависеть от состава транзакций в этом блоке.
Статистика адаптации обновления
По состоянию на июль 2018 года количество SegWit транзакций преодолело отметку 35% от общего количества в сети Биткоин. При этом основные сервисы для работы с Биткоином и цифровые кошельки реализовали поддержку Segregated Witness совсем недавно (например, Electrum и Bitxfy).
Диаграмма взята из материалов исследования BitMex Research
В динамике итогового размера блока после активации обновления также можно заметить существенные изменения. В моменты увеличения потока новых транзакций почти все блоки получаются значительно больше 1 MB, а иногда даже больше 2 MB. Кроме того, совершенно очевидно, что после активации SegWit вопрос о необходимости срочного решения проблемы низкой пропускной способности уже не кажется таким острым.
По данным аналитики BitMex Research
Если посмотреть на зависимость средней комиссии за транзакцию от количества транзакций нового формата, то тоже можно заметить очень сильную корреляцию в изменениях этих величин.
И не будем забывать, что Segregated Witness дало возможность развитию off-chain решений поверх протокола Bitcoin. Конечно же, адаптация lightning network – это на много более сложная задача по сравнению с SegWit, тем не менее, работа в этом отношении идет полным ходом и уже есть значительные достижения.
Часто задаваемые вопросы
— Правильно ли утверждать, что для Segregated Witness транзакции не будет работать RBF (replace-by-fee)?
Нет, replace by fee будет работать для Segregated Witness транзакций, потому что он основан не на том, какие у вас правила траты, а на том, что вы используете одни монеты и указываете sequence number входа транзакции. Если вы увеличиваете значение на входе, используя те же монеты, и указываете корректные доказательства того, что вы владеете этими монетами, то вы точно так же можете заменить предыдущую транзакцию.
— Как можно изменить хеш неподтвержденной транзакции?
Хеш транзакции является результатом вычисления хеш-функции от всех данных, которые хранятся в транзакции. ScriptSig, который содержится в транзакции, участвует в подсчете хеша, но не может быть подписан. Незначительные изменения в этом поле, которые не повлекут за собой изменения правил проверки подписи, вызовут изменения хеш-значения транзакции. Это значит, что подпись остается валидной, транзакция валидна, но хеш-значение у нее изменится.
— Как в транзакции хранятся witness data?
Как было отмечено, в Segregated Witness транзакции ввели новый формат сериализации. Кроме того, что у нас есть набор входов и выходов, добавляются и другие байты, где хранятся доказательства. Соответственно, там и хранятся эти данные. Максимально просто можно это представить так: есть просто набор данных, где написано, что существует два входа транзакции (байты первого входа и байты второго входа), два выхода, а после них еще два набора Witness data, которые точно так же записаны в виде байтов. Фактически данные доказательств владения монетами перенесены в другое место при сериализации.
— Почему бы не использовать существующий набор символов, например RFC3548 или z-base-32 для Bech32 адресов?
Набор символов выбирается так, чтобы минимизировать двусмысленность, связанную с визуальным их сходством. Порядок выбирается для минимизации количества пар символов, которые отличаются менее чем одним битом данных. Контрольная сумма выбрана для максимизации вероятности обнаружения небольшого числа ошибок, что улучшает эффективность ее работы для типичных ошибок.