Формат bech32 p2wpkh что значит
Bech32 – подробно о формате Bitcoin адресов этого типа
Bech32 – это формат адресов SegWit предложенный в обновлении BIP 0173. Их можно легко узнать по начальным символам: «bc1». Их использование позволило оптимизировать блоки и освободить немного пространства.
Ранее в сети Bitcoin использовались только base58 адреса наряду с усеченной дабл-SHA256 контрольной суммой. Но по причине смешанного регистра сообщество посчитало их слишком громоздкими и создающими малую, но всё же вероятность ошибиться при вводе или проверке. Внедрение SegWit Bech32 адресов позволило ускорить декодирование и уменьшить размеры QR-кодов.
Основные преимущества Bech32 и SegWit в целом
Использование технологии Segregated Witness снизило затраты на оплату комиссий по транзакциям на 25-40 процентов. Предыдущая пропускная способность Bitcoin не могла превысить 7 транзакций в секунду. Отделение данных подписи от самой транзакции позволяет разместить больше транзакций в каждом блоке, и преодолевает этот рубеж.
SegWit поддерживает не только Bech32 адреса. P2SH и P2WPKH тоже обеспечивают работу апдейта. Но уменьшение веса вследствие рационального распределения символов в строке адреса сделало Bech32 лучшим решением на текущем этапе разработки.
Что будет со старыми адресами?
Они по-прежнему поддерживаются сетью и вы можете осуществлять транзакции с их участием.
Bech32 становится всё популярнее. Некогда в 2017 году многие даже не решались использовать их в своих кошельках, на биржах и других криптовалютных продуктах. Но с июня 2020 года тип адресов «bc1» становится общепринятым стандартом. Их использование сервисом подчеркивает намерение разработчиков следовать передовым апдейтам сети Bitcoin и обеспечивать её здоровое функционирование.
Какие форматы бывают у биткоин-адресов?
Что такое биткоин-адрес в формате legacy?
Legacy-адрес — это стандартный для сети биткоина адрес, предложенный Сатоши Накамото. Иначе это формат называют P2PKH (Pay To Public Key Hash), поскольку он требует от получателя подпись, вычисленную из приватного ключа, и публичный ключ. Скрипт транзакции выхода с помощью криптографических функций сверяет их с хешем публичного ключа — и в случае совпадения позволяет расходовать средства. Вероятность того, что система примет некорректно введенный адрес составляет 1 в 232 степени, то есть один случай из 4,29 млрд.Legacy-адрес можно узнать по префиксу 1 (и m или n в тестовой сети). К основным минусам такого адреса относятся чувствительность к регистру при вводе данных, более высокие комиссии за операции, низкая скорость двойного хеширования контрольной суммы, больший вес в QR-кодах и неудобство записи на мобильном устройстве или на бумаге.
Из каких частей состоит биткоин-адрес в формате legacy?
Legacy-адреса уникальны, обычно состоят из 26-35 символов и представляют собой 160-битные хэши открытого ключа ECDSA ключевой пары. С появлением SegWit-адресов их стали называть старыми, однако изначально они были достаточно эффективным средством представления locking scripts в более удобном для пользователей виде и уменьшения рисков отправки средств на некорректный адрес.Стандартный биткоин-адрес состоит из таких частей:
Почему в биткоин-адресах бывает разное количество знаков?
Как зашифрованы части 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.
Что такое биткоин-адрес в формате SegWit?
Какие плюсы и минусы использования 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-адреса?
Виды биткоин адресов
Биткоин – это универсальная криптовалютная платежная система, имеющая массу преимуществ, которые ставят ее на несколько ступеней выше традиционных финансовых, банковских и платежных инструментов, будь-то Visa, Mastercard, PayPal и т.д.
Использование биткоина имеет множество позитивных моментов, среди которых:
Сейчас биткоины может использовать любой человек, используя кошелек, поддерживающий Bitcoin адреса, например, Electrum.
В статье «О разнице между криптовалютными кошельками и адресами» рассматривались различия между криптовалютными адресами и кошельками. В этой статье более подробно описываются различия между существующими биткоин-адресами.
Что такое биткоин-адрес?
Биткоин адрес – это уникальный публичный идентификатор, использующийся для обозначения пункта назначения отправляющихся через блокчейн монет BTC. Фактически это адрес получателя биткоинов, подобный номеру банковского счета.
Так как блокчейн технологии существуют уже более 10 лет, то с каждым годом появляются новшества, улучшающие их функционал и безопасность. Bitcoin не является исключением, и также со временем подвергается некоторым улучшениям. В связи с этим у биткоина есть три типа адресов.
Форматы биткоин адресов
Существуют следующие форматы биткоин адресов:
Некоторые альткоины, например, BitcoinCash (BCH) используют аналогичные форматы адресов.
Кроме того, существуют биткоин-адреса, начинающиеся на 2, но они используются только в тестовой сети.
Каждый биткоин адрес уникален и составляется из 58 цифробуквенных символов (стандарт base58check):
Обычно биткоин-адреса имеют длину в 26-35 символов и начинаются на цифру 3 или 1. Для того, чтобы избежать путаницы в биткоин адресах не используют буквы O и I верхнего регистра (заглавные), букву l в нижнем регистре (маленькая L) и не применяют число 0.
В стандартном биткоин-адресе есть три части:
Длина биткоин адреса в пределах 26-35 символов меняется из-за того, что при обработке приватного ключа могут образовываться начинающиеся на ноль числа. Их длина сокращается из-за того, что нули при записи отбрасываются.
Валидность биткоин адреса проверяется кошельками по контрольной сумме, которая закодирована в каждом из них.
Существуют адреса, на которых отправка средств требует применения нескольких приватных ключей – это так называемые Multi-signature addresses. Использование таких адресов позволяет обезопасить управление средствами, которыми владеют несколько лиц. Так как это более новый тип адресов, они не могут начинаться на единицу.
Как создать биткоин адрес?
Каждый биткоин адрес состоит из пары ключей: публичного (адрес получателя) и приватного (для отправки своих средств). Приватный ключ нужно хранить в безопасном месте. Он используется для передачи средств с помощью кошелька, который управляет адресами, синхронизируется с сетью и передает в нее информацию о транзакции с помощью приватного ключа.
Генерация адреса осуществляется в любом кошельке. Она делается бесплатно, причем каждый пользователь может генерировать пары приватный-публичный ключ в практически неограниченном количестве. Это возможно даже на не подключенном к интернету оффлайн-кошельке (автономно).
Существуют кошельки для настольных компьютеров (например, Electrum), мобильных устройств (например, Jaxx и Coinomi), а также web-кошельки (например, Blockchain.info).
Кроме того, существуют бумажные кошельки, которые являются бумажным хранилищем приватного и публичного ключей. Эти ключи можно импортировать в любой другой биткоин кошелек и осуществлять в нем просмотр баланса, отправку и/или подписывание транзакций.
Как обеспечить безопасность биткоин адреса?
Главным условием для обеспечения безопасности любого биткоин адреса является сохранение в тайне соответствующего ему приватного ключа. Поэтому онлайн и биржевые кошельки не подходят для надежного хранения средств.
Опасность таится не только в хакерах, но и в недобросовестных владельцах бирж, например, Poloniex.
Лучшим способом работы с биткоинами является использование так называемого холодного кошелька, который никогда не подключается к интернету, а служит только для подписи транзакций, сгенерированных на синхронизированном с сетью горячем кошельке.
Кроме закрытия доступа холодного кошелька к сети, нужно обеспечить резервирование приватного ключа, так как любой компьютер (носитель информации) может рано или поздно выйти из строя.
Резервирование можно сделать путем генерации QR-кодов от приватного и публичного ключей и последующей их распечаткой (таким образом получится бумажный кошелек биткоин).
Подробно об обновлении 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 адресов?
Набор символов выбирается так, чтобы минимизировать двусмысленность, связанную с визуальным их сходством. Порядок выбирается для минимизации количества пар символов, которые отличаются менее чем одним битом данных. Контрольная сумма выбрана для максимизации вероятности обнаружения небольшого числа ошибок, что улучшает эффективность ее работы для типичных ошибок.