что такое segwit кошелек
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: какие варианты поддерживают сегвит-адреса биткоина
Сегвит, он же Segwit, или Segregated Witness был активирован в сети биткоина 24 августа 2017 года в виде софтфорка, что значит, что данное обновление совместимо с предыдущими биткоин-транзакциями. С того времени разработчики биткоин-кошельков и криптовалютные биржи медленно внедряют SegWit на своих платформах.
Реализация Segwit привела к более быстрому и дешевому проведению транзакций. Несколько транзакций занимают места как одна без Сегвит, что делает перевод дешевле на 50% в среднем. Кроме того, кошельки Segwit и Core могут легко взаимодействовать друг с другом, в отличие от всех других форков, которые произошли.
Минимальное техническое объяснение: протокол Segwit отделяет криптографическую подпись от самой транзакции, выносит ее в сайдчейн и разворачивает точно такие же блоки с данными. Свободное место в блоке (который майнится) используется для других транзакций. Когда говорится, что поддержка Сегвит составляет, например, 8%, значит, что столько процентов машин установили ПО с такой обработкой подписей.
Стандартный кошелек не будет работать с адресами Segwit. Вы можете перевести свои BTC на кошелек Segwit, как на любой другой стандартный кошелек. Все, что нужно, — это создать новый адрес Segwit из выбранного кошелька Segwit и отправить монеты из прошлого хранилища.
bech32 — адреса SegWit
В кошельке Bitcoin Core создать сегвит-адрес можно через консоль кошелька или командную строку операционной системы. Выполняется для адресов с балансом >0:
В команде параметр addr — старый адрес.
Адреса начинаются с 3 (P2SH-тип), они совместимы со стандартными адресами биткоинов (без поддержки segwit), можно получать и отправлять BTC.
Адреса, начинающиеся с bc1 (bech32 P2WPKH), являются новым типом Segwit, что упрощает использование адресов. Такой адрес не зависит от регистра, можно писать и заглавными, и прописными. Также передает меньше данных в блок. Вероятно, не совместимы со старыми адресами.
В Bitcoin Core 0.16.0 можно выбрать, какой адрес поддерживать.
Напомним, что легаси-адрес начинается с 1.
На сайте http://n.bitcoin.ninja/checktx можно протестировать транзакции segwit на segnet.
Legacy или Segwit?
У Сегвит есть три очевидных преимущества:
Другие надежные кошельки с поддержкой Сегвит
Ledger Wallet
Ledger Wallet — это аппаратный кошелек, который позволяет безопасно хранить личные ключи на устройстве. Приватные адреса, хранящиеся в защищенной области микроконтроллера, не могут быть изъяты из устройства в виде обычного текста. Адреса Segwit были активированы для устройств Ledger 24 августа 2017 года. Этот кошелек первым поддержал нововведение. Рекомендуется переместить BTC на вновь созданный адрес Segwit.
Чтобы перейти на сегвит, следуйте инструкции:
Миграция доступна, если на балансе Legacy-адреса есть деньги. Также учитывайте комиссию за транзакцию.
Если Ledger Nano S используется впервые, то можно сразу выбрать сегвит-адрес.
Trezor
Кошелек Trezor похож на Ledger. Этот холодный кошелек был вторым, который реализовал поддержку SegWit на устройстве. Добавилась новая криптовалюта, а также обновилось ПО и интерфейс.
Преимущество в поддержке более широкого ряда криптовалют: можно хранить сразу несколько на одном устройстве. Также данный кошелек на USB-устройстве легче. Цена выше предыдущего примерно на 10 евро.
Электрум
Electrum — это легкий клиент для хранения BTC, который существует с ноября 2011 года. Модифицированный кошелек с поддержкой SegWit был написан на Python.
Зашифрованный кошелек, содержащий ваши биткоины, защищается паролем. Пользователю не нужно загружать целый блокчейн, чтобы использовать приложение, поскольку оно запрашивает эту информацию с сервера. Транзакции подписываются прямо на устройстве, никакие данные не отправляются без вашего ведома. Это делает кошелек Electrum одним из самых популярных среди других вариантов хранения криптовалюты.
Чтобы получить адрес segwit, начинающийся с 3 (bech32), в Electrum, просто выполните следующие шаги:
Кошелек генерирует Bech32-ключи на bc1, которые длиннее legacy и 3-segwit.
Samourai Wallet
Samourai Wallet — еще один кошелек для хранения адресов с SegWit. Команда также сосредоточилась на безопасности и конфиденциальности. Доступный в использовании, без предзаказов и внешних устройств.
Кошелек зашифровывается на мобильном устройстве по стандарту AES-256 (Advanced Encryption Standard или Рэндал на 256 бит). Безопасный вход в систему через PIN на 5-8 цифр. Он также никогда повторно не использует адреса, а также не передает ценные метаданные о вас или ваших транзакциях.
GreenAddress
Кошелек GreenAddress представляет собой проект с открытым исходным кодом, который позволяет отправлять и получать, а также хранить BTC на устройстве, на котором установлено приложение. Этот кошелек SegWit интегрируется как с компьютером, так и с мобильными устройствами.
Вход в систему с возможностью изменения возможен только с домашней сети. Общественный Wi-Fi позволит проверить баланс и посмотреть транзакции. Ключи при этом не загружаются.
От 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 всегда идет в ногу со временем, присоединяйтесь к нам!