native segwit что это ledger
SegWit и Native SegWit — В чём разница?
Как Вы могли заметить, при добавлении аккаунта Bitcoin в Ledger Live, кроме стандартной учётной записи Legacy, вам предлагается два варианта: Native SegWit и SegWit. Хотя можно легко определить разницу между адресом Native SegWit (начинающимся с “bc1”) и адресом SegWit (начинающимся с “3”), мы хотели бы более подробно рассмотреть, что именно это означает.
SegWit (P2SH) и Native SegWit (bech32) не являются первыми форматами адресов, которые существуют для биткойн-аккаунтов. Самый первый из них был Legacy, где адреса начинались с “1″. По мере того как цена Биткойна начала расти, сборы, уплачиваемые за каждую транзакцию, тоже стали выглядеть более дорогими. Скорость транзакций также была более медленной.
Предложение SegWit (Segregated Witness) в своё время было сильно оспорено – фактически, первоначальное предложение, известное как SegWit2x, было фактически отброшено и заменено тем, что мы теперь знаем как SegWit. В августе 2017 года состоялся софтфорк, реализующий SegWit. С тех пор его быстро приняли, и он начал становиться новым стандартом.
Так что же изменил SegWit?
SegWit уменьшил размер данных каждой транзакции. Это было сделано путём отделения определённых данных подписи транзакции от транзакции. Делая транзакции меньше по размеру, больше транзакций может поместиться в один блок биткойнов. Это, в свою очередь, делает сеть Биткойнов более масштабируемой, а её транзакции — более быстрыми. Более того, это значительно снижает транзакционные сборы за каждую биткойн-транзакцию. SegWit также включил решения для масштабирования второго уровня, что привело к появлению сети Lightning.
Native SegWit, также известный как bech32, является последним шагом в форматах адресов. Он ещё более экономичен по весу, чем его предшественник. Это означает ещё более высокую скорость транзакций по сравнению с транзакциями SegWit, лучшую масштабируемость и ещё более низкие комиссии за транзакцию. Вдобавок к этому, bech32 имеет лучшее обнаружение ошибок и, для лучшей читаемости, делает адреса только в одном (нижнем) регистре. Вот почему это самый популярный вариант… если поддерживается.
Единственным недостатком bech32 является то, что пока не все основные платформы поддерживают этот формат адресов. Хотя транзакции между устаревшими, SegWit и Native SegWit полностью совместимы, всё ещё существует довольно много бирж и поставщиков кошельков, которые пока не поддерживают отправку BTC на адрес bc1. Таким образом, при добавлении учётной записи в Ledger Live вам будет предоставлена возможность добавления Native SegWit и/или адреса SegWit.
Выводы:
- SegWit – уменьшил размер данных о транзакциях, чтобы обеспечить более быстрые транзакции, лучшую масштабируемость и снижение комиссий. Native SegWit (bech32) ещё больше расширил это и включает в себя ещё более низкие сборы. Ещё не все биржи и поставщики кошельков поддерживают отправку биткойнов на адреса Native SegWit. Возможны транзакции между всеми 3 типами адресов.
При подготовке статьи использовались материалы сайта ledger.com.
Если Вам понравилась эта страничка, расскажите о ней своим друзьям (кнопки социальных сетей — внизу страницы). Также вы можете оставить отзыв или поддержать материально.
Segregated Witness для чайников
Масштабируемость биткоина является одной из его главных проблем, над решением которой активно работают. Одним из представителей этих решений является, например, технология Lightning network, но ее реализация пока что не представляется возможной ввиду некоторых уязвимостей. Другое решение — Segregated Witness также направлено на повышение масштабируемости, но ко всему прочему решает еще и целый ряд проблем, включая ту самую уязвимость, мешающую реализации лайтнинга. В этой статье мы рассмотрим основные преимущества Segregated Witness, а также опишем механизм его работы.
Segregated witness, или как многие его называют SegWit, это софт-форк, описанный в серии BIP’ов (141, 142, 143, 144 и 145), главной целью которого является оптимизация структуры транзакций и блоков с помощью вынесения подписей (то, что называют ‘scriptSig‘, ‘witness‘ или же ‘unlocking script‘) из транзакции в отдельную струтуру. Это не только позволяет уменьшить размер транзакций, делая блоки более вместительными, но и решает проблему их «изменяемости» (transaction malleability, именно об этой уязвимости мы и говорили выше), что очень важно для технологий наподобие платежных каналов или лайтнинга, пологающихся на строение транзакции биткоина.
How it works
Before we begin
Для начала кратко напомним, что из себя представляет платежная система в биткоине. В ней нет ничего наподобие списка балансов как это может быть реализовано в каком-нибудь банке. Вместо этого, баланс каждого адреса представлен набором транзакций, отправленных на этот адрес, где транзакция — это структура, в которой главными являются входы (inputs) и выходы (outputs). Входы — это транзакции, на которые мы ссылаемся, чтобы потратить (если точнее то это не транзакции полностью, а их конкретные выходы, т.к в одной транзакции мы можем переводить средства на несколько адресов), а выходы — это адреса, на которые мы хотим перевести средства. Вот так выглядит структура транзакции биткоина:
Поле PubKey script (далее scriptPubKey) в выходах это то, что называют locking script. Оно нужно для того, чтобы только владелец адреса, на который перечисляются срества, смог воспользоваться этим выходом. Поле Signature Script (далее scriptSig) еще называют unlocking script — оно «отпирает» locking script, предоставляя доказательство владения адресом.
Подробнее о транзакциях, а также о работе запирающего и отпирающего скрипта можно почитать здесь.
Backward compability
На самом деле, Segregated Witness меняет не только строение транзакции, но и ее выходы. Это, однако, не значит, что в одной и той же транзакции не могут быть потрачены как традиционные UTXO (unspent transaction outputs), так и сегвитовские — просто первые будут ожидать «доказательства» внутри входа (поле scriptSig), а вторые — снаружи.
Так как Segregated Witness все-таки является софт-форком, его обновления могут быть проигнорированы, а значит более старые системы должны как-то обрабатывать сегвитовские выходы. Дело в том, что для старых нод или кошельков эти выходы выглядят как доступные всем, то есть они могут быть потрачены с пустой подписью, что все еще валидно. Принявшие обновление ноды и кошельки конечно же будут искать все подписи снаружи входов в специальном поле ‘witness’.
Examples
Pay-to-Witness-Public-Key-Hash
Теперь давайте взглянем на примеры транзакций и на то, как они изменятся с Segregated Witness. Мы начнем со стандартной Pay-to-Public-Key-Hash (P2PKH) транзакции.
Нас интересуют выходы, а именно их поля «scriptPubKey». Рассмотрим типичный locking script:
C Segregated Witness он будет выглядеть так:
Как видите, сегвитовский выход намного проще традиционного — он состоит из двух значений, которые будут помещены на стэк исполнения скрипта. Как мы уже упомянули ранее, для старых версий клиента биткоина этот выход будет виден как доступный любому, так как он не требует подписи. А вот для обновленного клиента первое число интерпретируется как номер версии, а второе как аналог запирающего скрипта (witness program). На самом деле, здесь должен быть использован хеш сжатого публичного ключа, об этом мы расскажем немного позже.
Теперь давайте рассмотрим транзакцию, в которой этот выход будет потрачен. В традиционном случае это выглядело бы так:
Однако, чтобы потратить сегвитовский выход, транзакция должна иметь пустое поле sriptSig и содержать все подписи в отдельном месте:
Warning
Несмотря на то, что традиционные клиенты могут обрабатывать сегвитовские транзакции (напомню, что их выходы выглядят как доступные всем для старых клиентов), они не могут тратить их выходы, так как они просто не знают, как это сделать: кошелек старого типа попытается потратить сегвитовский выход с пустой подписью, однако эта транзакция на самом деле не валидна (ноды, имеющие Segregated Witness, не пропустят такую транзакцию). Это значит, что отправитель должен знать, поддерживает ли кошелек получателя segwit или нет, чтобы создавать выходы нужного типа.
Начиная с BIP 143 выходы должны быть созданы с помощью хеша сжатого публичного ключа. Если вы создадите выход используя обычный адрес или несжатый публичный ключ, этот выход будет неиспользуемым.
Pay-to-Witness-Script-Hash
Следующим очень важным типом транзакции является P2SH — он позволяет отправлять транзакции на хеш скрипта вместо хеша публичного ключа (обычный адрес биткоина). Чтобы потратить выход P2SH транзакции нужно предоставить скрипт (его называют redeem script), хеш которого совпадает с хешем скрипта на который отправлены средства, а также подписи/пароли/что-то еще в зависимости от скрипта. Используя такой подход можно отправлять биткоины на адрес, защищенный способом, о котором нам ничего не известно, а также сильно экономить место — в случае, например, кошелька с мультиподписью (multisignature wallet) locking script был бы действительно большим, если бы мы хранили все «замки» полностью, а не только их хеш.
Итак, рассмотрим в качестве примера кошелек с мультиподписью, требующий наличия 2ух подписей из 5. В традиционном виде locking script выхода P2SH транзакции выглядит так:
Чтобы потратить его, нужно предоставить redeem script, определяющий условие мультиподписи 2 из 5, а также 2 подписи и все это должно находится во входе транзакции:
Теперь давайте взглянем, как бы все это выглядело, если бы и отправитель и получатель использовали Segregated Witness.
Locking script выхода:
Опять же, как и в случае с P2PKH транзакцией полученный скрипт намного проще. Здесь 1ое значение это номер версии, а второе — 32 байтный SHA256 хеш redeem script’a (witness program). Эта хеш-функция была выбрана для того, чтобы как-то отличать witness program P2WPKH от оной для P2WSH по длине хеша (32 байта SHA256 и 20 байт RIPEMD160(SHA256(script))).
Транзакция, использующая этот выход:
Embedding Segregated Witness inside P2SH
Итак, мы убедились, что использование Segregated Witness имеет свои преимущества, однако для приведенных выше примеров и отправитель и получатель должны быть обновлены, что возможно далеко не всегда. Рассмотрим, например, такую ситуацию:
Алиса хочет отправить биткоинов Бобу, но у нее нет сегвит-кошелька, в то время как у Боба он есть. Конечно же, они могут просто использовать стандартную транзакцию, однако Боб хочет использовать segwit для сокращения комиссии.
В таком случае Боб может создать P2SH адрес, содержащий в себе segwit скрипт. Для Алисы он будет виден как самый обычный P2SH адрес и она сможет без каких либо проблем перевести на него средства, а Боб сможет потратить этот выход используя сегвит-транзакцию и получив скидку на комиссию (о новой метрике установления комиссии для сегвит транзакций мы расскажем ниже).
Таким образом оба типа сегвит-транзакций — P2WSH и P2WPKH могут быть реализованы внутри P2SH.
P2SH(P2WPKH)
Для использования P2WPKH транзакции внутри P2SH Бобу нужно создать witness program из своего публичного ключа. Затем результат нужно хешировать и преобразовать в P2SH адрес:
Создаем witness program:
Как обычно — 1ое число это версия и 2ое это 20 байтный хеш публичного ключа. Полученный скрипт затем хешируется SHA256 и потом RIPEMD160, выдавая очередной 20 байтный хеш.
HASH160 от witness program P2WPKH:
И преобразовываем в адрес:
Locking script выхода отправленного на этот адрес будет выглядеть как скрипт для обычного P2SH адреса:
Теперь рассмотрим как Боб может потратить этот выход:
Сначала предоставленный нами redeem script (в нашем случае это witness program) будет хеширован и, если он равен хешу, указанному в locking script’e, то он будет выполнен и будут проверены подписи в поле «witness».
P2SH(P2WSH)
Точно также любой P2WSH скрипт может быть реализован внутри P2SH. Возьмем multisig скрипт 2 из 5, рассмотренный ранее. Все шаги будут практически идентичны случаю P2SH(P2WPKH):
Для начала, опять же, создаем witness program:
1ое число — версия, 2ое — 32 байтный SHA256 хеш нашего скрипта мультиподписи. Далее шаги повторяются — берем HASH160 от witness program и преобразовываем в обычный P2SH адрес. Для использования выхода, отправленного на этот адрес, в scriptSig нужно записать witness program, а все подписи и полный скрипт мультисига в поле witness.
Segregated witness benefits
Теперь, когда мы разобрались с технической частью, рассмотрим основные преимущеста segregated witness.
Transaction malleability
Одной из самых важных проблем, которые решает segwit является «изменяемость» транзакций, а если точнее, то их ID, являющиеся хешами. Разберемся немного подробнее.
В традиционном случае подписи, находящиеся внутри транзакции во входах, могут быть изменены третьей стороной без их инвалидации. Это позволяет изменять ID транзакции, являющийся ее хешем, не меняя никаких «фундаментальных» полей вроде входов/выходов/количества средств. Таким образом транзакция все еще валидна, однако теперь имеет другой ID, что создает возможность для разного рода атак, например denial-of-service.
Segwit решает эту проблему, т.к все подписи находятся снаружи транзакции, а значит не хешируются и их изменение никак не повлияет на ID транзакции. Также вводится отдельный идентификатор wtxid — он хеширует не только транзакцию но и всю witness часть, так что если транзакция передается без witness данных, то txid равен wtxid.
Решение данной проблемы позволяет создавать цепочки неподтвержденных транзакций без какого-либа риска — очень важное свойство для таких протоколов как Lightning Network.
Network and Storage Scaling
Witness данные зачастую составляют самую большую часть транзакции. В скриптах наподобие multisig’a они могут занимать до 75% места используемого транзакцией. Благодаря segwit’y передача подписей становится опциональной — нода запрашивает их только если собирается проводить валидацию транзакции. SPV (simple payment verification) клиенты или ноды, не поддерживающие сегвит, в таком случае могут не загружать лишние данные, экономя место на диске.
Block size increase and lower transaction fees
Segwit транзакции обходятся дешевле, нежели традиционные за счет скидки на хранение witness данных. Если быть точнее, то было изменено само понятие «размера» для segwit транзакций. Вместо обычного размера для них было введено понятие «виртуального размера» (virtual size) — все данные, хранящиеся в «witness», учитываются с коэффицентом в 0.25, что также позволяет разместить в блоке больше транзакций. Рассмотрим на примере.
Пусть у нас есть традиционная транзакция размером в 200 байт. В блок размера 1 МB поместится 5000 таких. Теперь возьмем ее segwit эквивалент, где примерно 120 байт это witness данные. Тогда ее vsize = 80 + 0.25 * 120 = 110 и теперь уже 9090 таких транзакций влезут в блок. Также при комиссии, допустим, в 40 satoshi/byte для 1ой транзакции мы получим комисси в 8000 сатоши, а для 2ой 4400 сатоши, что практически в два раза меньше.
Script Versioning
Как вы уже могли заметить, каждый locking script имеет байт, отвечающий за версию скрипта. Использование версий позволяет вносить дополнения и изменения (изменения в синтаксисе, новые операторы и тд.) в виде софт-форков.
Signature Verification Optimization
Segregated Witness также оптимизирует работу алгоритмов с подписями (CHECKSIG, CHECKMULTISIG и тд.). До segwit’a количество хеш-вычислений увеличивалось квадратично от количества подписей, в то время как в обновлении сложность алгоритма понижена до O(n).
So what is the problem?
Так если все так хорошо, в чем же проблема? Обновление имеет немало противников в сети, так как несмотря на все очевидные преимущества, оно имеет и свои слабые стороны. Рассмотрим некоторые из аргументов против.
Conclusion
Несмотря на то, что, возможно, для проблем, решаемых SW, могут быть предоставлены более элегантные решения, мы считаем, что на данный момент это отличный способ повысить масштабируемость сети, а также сделать возможным внедрение таких технологий как Lightning Network, подробный разбор которой мы также проведем в следующих статьях.
SegWit (СегВит) как способ увеличения масштабируемости биткоина
О том, что биткоин станет общепринятым платежным средством, говорят с самого момента его появления, то есть уже более 10 лет. Однако, стоит понимать, что с текущей пропускной способностью его сети это не представляется возможным. В среднем 3, максимум 5–7 транзакций в секунду — все, что может предложить Bitcoin в то время, как, например, у Visa этот показатель измеряется тысячами.
Одна из причин такой медлительности кроется в проблеме масштабирования, которую уже давно пытаются исправить многие разработчики, предлагая решения второго уровня вроде Lightning Network. Но их внедрению препятствует еще ряд недостатков блокчейна биткоина, частично устранить которые помогает обновление протокола SegWit, приведшее к выделению цепи Bitcoin Cash и ряду других драматичных событий. Но, обо всем по порядку.
Что такое SegWit
SegWit — это сокращение от словосочетания Segregated Witness, которое переводится с английского, как «отделенный (сегрегированный) свидетель». Именно такое название носит обновление протокола, изменяющее способ хранения данных в блокчейне с целью улучшения его масштабируемости и скорости работы.
Одна из основных причин вышеописанных проблем заключается в ограничении размера блока биткоина — он не может весить больше 1 MB. В каждом блоке, как известно, содержится информация обо всех добавленных в него транзакциях. При этом большую часть веса транзакции занимают данные свидетеля (witness), записанные в строке кода scriptSig. Речь идет о цифровой подписи отправителя, подтверждающей его намерение перевести указанную в транзакции сумму монет. В каждом блоке эта информация суммарно занимает около 60%!
Второй проблемный момент заключается в том, что подпись формально может быть откорректирована уже после того, как транзакция появилась в блоке, а, значит, существует вероятность изменения ее идентификатора (хеша). В итоге следующие операции, входящие уже в другие блоки, замедляются из-за необходимости построения последовательной цепочки подтвержденных транзакций, для каждой из которых приходится «вытягивать» окончательные данные из прошлых сделок. Эта особенность транзакций получила название пластичности (гибкости) и является основным препятствием для внедрения решений второго уровня в блокчейны биткоина и схожих с ним криптовалют. Кроме того, эту уязвимость теоретически могли использовать злоумышленники, чтобы препятствовать включению транзакций в блоки.
SegWit (Сегвит) решает описанные проблемы путем вынесения раздела кода с цифровой подписью за пределы базовой структуры блокчейна в сайдчейн (побочную цепь) с блоками размером 4 MB. Таким образом повышается эффективность использования полезного объёма основных блоков (их размер остается стандартным — 1MB), что означает возможность включения в них большего количества транзакций (почти в два раза).
Также при помощи SegWit исчезает явление пластичности — внесение изменений в цифровые подписи больше не приводит к замене идентификаторов. Это значит, что транзакции подтверждаются быстрее и устраняются препятствия, мешающие развертыванию скоростных платежных каналов в виде надстроек к основной сети. Еще один приятный плюс — снижение комиссий за проведение переводов вплоть до 50%.
Еще лучше понять задачи и принцип работы технологии SegWit поможет видео ниже:
Что такое SegWitИстория создания SegWit (Сегвит)
О том, что структура блокчейна биткоина является неидеальной и требует внесения изменений, начали говорить уже через несколько лет после его запуска.
В 2012 году группа разработчиков Bitcoin Core называла транзакционную пластичность одной из главных проблем в дальнейшем развитии сети.
В последующие годы с ростом популярности биткоина все чаще случались периоды загруженности блокчейна, во время которых подтверждения транзакций приходилось ждать по нескольку дней. Некоторые для решения проблемы предлагали увеличить размер блока путем проведения хардфорка, однако эта идея не была массово поддержана членами сообщества.
Подготовительный этап
В 2014 году биткоин-разработчики Адам Бэк (Adam Back), Грегори Максвелл (Gregory Maxwell), Питер Уилле (Pieter Wuille) и Мэт Коралло (Matt Corallo) при участии еще нескольких человек основали компанию Blockstream, деятельность которой была сосредоточена на разработке сайдчейнов, улучшающих сеть биткоина. В ее лабораториях и родилась идея по внедрению в сеть Bitcoin обновления Segregated Witness. Концепция SegWit впервые была представлена на конференции Scaling Bitcoin в Гонконге в декабре 2015-го (Lightning Network была презентована двумя месяцами ранее на том же мероприятии в Монреале).
Это предложение по улучшению масштабируемости было встречено в основном положительно, в частности из-за того, что не требовалось изменение существующих правил консенсуса. Для внедрения SegWit достаточно было провести частичное обновление протокола через софтфорк — программное обновление блокчейна без «жесткого» разделения на отдельные цепочки. Соответствующее решение было включено в предложение по улучшению биткоина BIP141 (и последующие BIP 142–145).
В январе 2016-го состоялся запуск тестовой сети под названием SegNet, которая уже через 2 месяца полноценно поддерживала первые версии Lightning Network.
Софтфорк, хардфорк и прочие разногласия
Параллельно с разработкой обновления частью биткоин-сообщества продолжала лоббироваться идея о необходимости увеличения размера блока путем хардфорка. В основном это были сторонники альтернативного клиента Bitcoin Classic.
В феврале 2016-го во время встречи в Гонконге между сторонами конфликта было достигнуто взаимное соглашение об активации SegWit с последующим проведением хардфорка по изменению размера блока до 2 MB.
В апреле апгрейд был готов к релизу, а уже в октябре 2016 года его интегрировали в клиент Bitcoin Core 0.13. Чтобы активировать обновление, разработчики должны были получить поддержку 95% майнеров. Однако, некоторые пулы для майнинга, контролирующие значительную часть мощностей сети биткоина, выступили против запуска SegWit.
Процесс сдвинулся с мертвой точки в апреле 2017-го, когда было сформировано предложение UASF (BIP148), заключающееся в изменении правил проведения софтфорков — для их активации требовалась поддержка не 95% майнеров, а такого же количества полных нод.
Затем в мае состоялась очередная встреча между сторонниками софтфорка и хардфорка. Результатом стало подписание Нью-Йоркского соглашения, которое заключалось в осуществлении альтернативного устраивающего все стороны сценария под названием SegWit2x. Он состоял в активации SegWit путем софтфорка при достижении 80% поддержки участников сети и проведении хардфорка по увеличению размера блока в течение полугода после этого. Важным нюансом описанного события стало то, что в нем не участвовали представители Bitcoin Core, поэтому существовал риск технической несовместимости с самым популярным биткоин-клиентом.
Активация SegWit в основной сети биткоина и ее последствия
1 августа был проведен ранее предложенный софтфорк UASF, изменивший правила для принятия следующих обновлений. Через неделю на блоке 479708 состоялась фиксация SegWit в основной сети биткоина. Окончательная активация многострадального обновления протокола Сегвит произошла 24 августа 2017 года.
В преддверии этих событий несогласные с приближающимся обновлением майнеры под предводительством Роджера Вера таки провели хардфорк, в результате которого 1 августа появилась самостоятельная ветвь в виде криптовалюты Bitcoin Cash. В этой сети размер блока был увеличен до 8 MB, однако несмотря на это преимущество большая часть сообщества все же избрала оригинальный биткоин с внедренным SegWit.
Что касается второй запланированной фазы SegWit2x, которая должна была увеличить размер блока биткоина до 2 MB, ее сторонники 8 ноября 2017-го объявили об отмене хардфорка. В качестве официальной причины было указано нежелание осуществлять очередной раскол сообщества, т.к. поддержка была на уровне всего 30%.
Некоторые отдельные группы разработчиков впоследствии заявляли о намерении самостоятельно реализовать хардфорк и 28 декабря это вроде как было сделано. Но по факту, кроме названия SegWit2x, у этого проекта было мало общего с оригинальной задумкой технологии Сегвит. В итоге появилась монета B2X, которая за последние полтора года обесценилась и сейчас почти нигде не торгуется.
SegWit (Сегвит) в других криптовалютах
После того, как в 2016 году стало известно о завершении разработки технологии SegWit, ее внедрением заинтересовались разработчики многих альткоинов. И поскольку многие из них были основаны на коде биткоина, реализовать это было не так уж и сложно.
Первым проектом, внедрившим SegWit, стал Groestlcoin в январе 2017 года. Немногим позже это обновление было активировано в блокчейнах Emercoin, Vertcoin, Syscoin, DigiByte, Viacoin и Monacoin.
Кроме того, 10 мая 2017 года обновление протокола было внедрено в сеть криптовалюты Litecoin. Именно тогда впервые была показана жизнеспособность модели UASF (активируемых пользователями софтфорков), благодаря которой и состоялся запуск SegWit в опекаемом Чарли Ли блокчейне.
SegWit в 2021 году
В данный момент эта технология используется в 40% всех совершаемых BTC-транзакций. Неполное принятие объясняется тем, что значительное количество участников сети все еще не обновили свое программное обеспечение до версии с поддержкой SegWit и, по сути, продолжают взаимодействовать с блокчейном по старым правилам.
Для сравнения — в сети Litecoin использование Segregated Witness в транзакциях сейчас находится на уровне 55–60%. То есть принятие новой технологии Сегвит почти в 1,5 раза выше, чем у биткоина, но полного перехода тоже еще не состоялось.
Когда состоится абсолютное принятие SegWit в сети Bitcoin (если это вообще случится), предсказать невозможно, поскольку модель софтфорка не предполагает обязательного перехода всех участников сети на новую версию используемого ПО.
SegWit или Legacy?
Поскольку полного принятия SegWit еще не состоялось, в блокчейне биткоина продолжают существовать три разных вида адресов:
Первый тип является оригинальным, т.е. изначально поддерживаемым сетью Bitcoin. Однако, с legacy-адресов нельзя пересылать средства на адреса формата bech32. А значит нет возможности использовать открываемые обновлением преимущества — а это, как минимум более быстрые и дешевые, транзакции.
Compatibility-адреса являются «всеядными», т.е. могут быть использованы как в кошельках и приложениях, которые еще не перешли на Segregated Witness, так и в тех, которые поддерживают эту технологию.
Третий вариант позволяет отправлять средства на адреса любого типа, используя все преимущества SegWit.
Поэтому, вывод напрашивается сам собой — лучше всего использовать нативные segwit-адреса.
При этом стоит помнить, что далеко не все биткоин-кошельки поддерживают взаимодействие с ними.
Кошельки, поддерживающие технологию Segregated Witness
На сегодняшний день работа с SegWit-адресами поддерживается во всех линейках аппаратных кошельков — Ledger, Trezor и KeepKey.
Также о поддержке SegWit (Сегвит) объявили почти все популярные десктопные и мобильные кошельки, среди которых Exodus, Electrum, Samourai Wallet, Green Address, Jaxx и Coinbase Wallet.
Конечно же, работа с новыми адресами Сегвит по умолчанию доступна во всех версиях клиента Bitcoin Core, выпущенных после августа 2017-го.
А вот известный сайт Blockchain.com, который является старейшим онлайн-кошельком, все еще не работает с SegWit.
Плюсы и минусы технологии
К основным преимуществам SegWit относится:
Недостаток у обновления Segregated Witness, по сути, всего один — кратковременный эффект. Ведь даже если в будущем будут реализованы планы по увеличению размера блока до 2 MB, этого все равно может оказаться мало для поддержания приемлемой пропускной способности сети, которая, несомненно, будет пополняться новыми участниками с ростом популярности биткоина.
Но специалисты из Blockstream обещают, что эту проблему поможет устранить Lightning Network. Если им действительно удастся провести полномасштабное внедрение данной надстройки, это может дать тот самый толчок к более активному развитию экосистемы биткоина, который ему так необходим для становления глобальным платежным средством.