Bitcoin address formats and performance comparison
FixedFloat uses Bech32 addresses by default, as our team is committed to introducing new technologies.
Bitcoin address performance comparison chart
For simplicity, we use the following abbreviations:
I — P2PKH, adress starts with “1”
II — P2SH, adress starts with “3”
III — Bech32, adress starts with “bc1”
Bech32 adoption
Bech32 is a bitcoin address format specified by BIP 0173. It is used for the native segwit version 0 output types, P2WPKH and P2WSH. The upcoming Taproot softfork will add another output type called Pay to Taproot (P2TR). P2TR outputs and future native segwit versions will be using an updated variant of Bech32, called Bech32m (specified by BIP 0350). This page tracks the adoption of Bech32 and Bech32m.
Ideally wallets and services would first support sending to new addresses. When most wallets and services support sending to the new address type, people are more likely to adopt it for receiving.
The amount of bech32 addresses on the blockchain is tracked on this website: https://p2sh.info/dashboard/db/bech32-statistics?orgId=1
| No | |
| ?? | Maybe / Haven’t checked / placeholder |
| Planned | The developers said they plan to |
| PR Merged | In the case of software, code has been written and merged, and it will be in next release. |
| Yes | Feature has been released |
Contents
Software Wallets
| Name | Send to Bech32 | Receive to P2WPKH/P2WSH | Send to Bech32m | Receive to P2TR | Notes |
|---|---|---|---|---|---|
| Armory | Yes | No | Planned around activation | ?? | |
| AQUA | Yes | Yes | ?? | ?? | |
| bcoin | Yes | Yes | Since 2.2.0 | ?? | |
| Bisq | Yes | Yes | Dependent on BitcoinJ | ?? | As of v1.5.0 https://bisq.network/blog/bisq-v1.5.0-highlights/ |
| Bitcoin Core | Since 0.16.0 | Since 0.16.0 | Since 0.21.1 | Since 22.0 | Uses P2WPKH as default address since version 0.20.0. Creating P2TR addresses requires manual import for now. |
| Bitcoin Knots | Since 0.16.0 | Since 0.16.0 | Since 0.21.1 | Since 22.0 | |
| Blockstream Green | Yes | Yes | Since Mobile 3.7.6+, Desktop 1.0.4+ | Planned | Bech32m sending support as of GDK 0.0.47 |
| Breadwallet | Yes | Yes | ?? | ?? | https://www.reddit.com/r/BRDapp/comments/9xx1hq/as_of_today_brd_fully_supports_native_segwit/ |
| Bitcoin Wallet for Android | Yes | Yes | Since 9.0 | No | Tested as of v9.20 (October 2022) |
| BlueWallet | Yes | Yes | Since 6.2.14 | No | Tested as of v6.3.1 (October 2022) |
| Breez | Yes | Yes | Yes | Yes, via the dev console | https://github.com/breez/breez/pull/209 |
| BTC.com | No | No | No | No | wallet discontinued: https://wallet.btc.com/#/announcement |
| Caravan | Yes | Yes | Planned | ?? | |
| Casa | Yes | No | Yes | Planned | |
| C-Lightning | Yes | Yes | Yes | ?? | |
| Coinomi | Yes | Yes | No | No | Tested as of v1.26.0 (October 2022) |
| Electrum | Yes | Yes | Since 4.1.0 | Planned: Descriptor-based keypath spends | https://github.com/spesmilo/electrum/issues/7544 |
| Exodus | Yes | Yes | Yes | Not yet planned | https://support.exodus.com/article/1480-bitcoin-faqs-learn-more-about-btc# |
| Fully Noded | Yes | Yes | Yes | Since v0.2.26 | https://twitter.com/FullyNoded/status/1438652812410298370 |
| Guarda Wallet | Yes | Yes | Yes | Currently not planned | twitter announcement |
| Iris Wallet | Yes | Yes | Yes | Yes | https://twitter.com/cryptoquick/status/1585187190627528710 |
| JoinMarket | Yes | Yes | Since v0.9.5 | ?? | |
| LND | Yes | Yes | Since v0.15 | Since v0.15 | The coming LND v0.15 release will introduce full P2TR support including scriptpath spends, PSBT signing, and a MuSig2 API. |
| Muun | Yes | Yes | Yes | Yes | https://twitter.com/MuunWallet/status/1459294066135474177 |
| Mycelium | Yes | Yes | No | No | Bech32m not supported as of version 3.16.0.13, tested on October 12th, 2022. https://github.com/mycelium-com/wallet-android/issues/645 |
| Nunchuk | Yes | Yes | Yes | Yes | https://twitter.com/nunchuk_io/status/1511365917808103426 |
| Phoenix | Yes | Yes | Support in iOS, but not Android | No | |
| Samourai Wallet | Yes | Yes | Since v0.99.98 | Currently not planned | https://twitter.com/SamouraiWallet/status/1415788631491497985?s=20 |
| Sparrow Wallet | Yes | Yes | Yes | Yes | https://twitter.com/SparrowWallet/status/1415632270434705408 |
| Specter Wallet | Yes | Yes | Yes | Yes | https://twitter.com/_benkaufman/status/1431293856675508228 |
| Trust Wallet | Yes | Yes | Yes | Not planned | https://github.com/trustwallet/wallet-core/releases/tag/2.6.5, https://twitter.com/catenocrypt/status/1520152930065817601 |
| Uniblow | Yes | Yes | Since v1.2.2 | Not yet planned | release1.2.2 |
| Wallet of Satoshi | Yes | Yes | Yes | ?? | https://twitter.com/walletofsatoshi/status/1459782761472872451 |
| Wasabi Wallet | Yes | Yes | Since Wasabi 2.0 | Planned: via NBitcoin | https://twitter.com/NicolasDorier/status/1413693010236170241 https://mempool.space/testnet/tx/05a23151b6ad114fb71e851147861d6c992a438ad4f62d6f0749bc9f200ef254 |
Hardware Wallets
Hardware wallet manufacturers typically publish a web wallet or browser add-on wallet for use with their hardware. Users can also sometimes connect their hardware wallet to a software wallet like Electrum.
| Name | Send to Bech32 | Receive to P2WPKH/P2WSH | Send to Bech32m | Receive to P2TR | Notes |
|---|---|---|---|---|---|
| Trezor + Trezor Suite | Yes | Yes | Yes | Yes | since Trezor Suite 21.12.2 + Trezor Firmware 1.10.4 (Model One) / 2.4.3 (Model T) |
| Ledger Live (desktop app) | Yes | Yes | Yes | Yes | Ledger Live Desktop 2.35 + Bitcoin App 2.0.0, Ledger Live Mobile support TBD. https://blockstream.info/tx/41d46e6f6e58a325eb6c913aa603f4db313f4a1db0649952f06fe2cd70546451 |
| KeepKey chrome app | No | No | ?? | ?? | |
| BitBox Desktop app | Yes | Yes | Yes | Yes | https://twitter.com/_benma_/status/1504455969631350792 |
| Trezor + Electrum | Yes | Yes | Yes | Planned | |
| Ledger + Electrum | Yes | Yes | ?? | ?? | |
| BitBox + Electrum | Yes | Yes | Yes | ?? | https://twitter.com/_benma_/status/1504458280000761857 |
| KeepKey + Electrum | Yes | Yes | ?? | ?? | |
| Archos + Electrum | Yes | Yes | ?? | ?? | |
| Coldcard + Electrum | Yes | Yes | Yes | Yes | https://blog.coinkite.com/edge-firmware/ |
| Ballet + app | Yes | Yes | ?? | ?? | |
| SeedSigner | Yes | Yes | Planned | ?? | |
| Tangem + app | Yes | Yes | ?? | ?? | |
| Blockstream Jade + Blockstream Green | Yes | Yes | Yes | Planned | Bech32m sending support as of GDK 0.0.47 available via Blockstream Green mobile apps 3.7.6+ and desktop app 1.0.4+ |
| Keystone | Yes | Yes, but only with BTC-only firmware | Planned for Q1 2022 | Evaluating | https://twitter.com/KeystoneWallet/status/1460110906789031938 |
| Foundation Passport | Yes | Yes | Yes | Planned | https://twitter.com/ShrtCrct6102/status/1661102603810250761 |
Web Wallets / Wallet Service Providers
| Name | Send to Bech32 | Receive to P2WPKH/P2WSH | Send to Bech32m | Receive to P2TR | Notes |
|---|---|---|---|---|---|
| Bitcoin Beach Wallet | Yes | Yes | Yes | No | https://twitter.com/nicolasburtey/status/1556659398365401088 |
| Coin Wallet | Yes | Yes | ?? | ?? | |
| BitGo | Yes | Yes | Yes | Yes | Full native segwit support on v2 platform, no plans to add native segwit support on v1 platform. Also see: https://blog.bitgo.com/native-segwit-addresses-via-bitgos-api-4946f2007be9, Taproot: https://blog.bitgo.com/taproot-support-for-bitgo-wallets-9ed97f412460 |
| Bitnob | Yes | Yes | Yes | Yes | https://twitter.com/bernard_parah/status/1469962690483400706 |
| blockchain.com web | Yes | Yes | Yes | ?? | https://twitter.com/Pellicceama/status/1563171639063629828 |
| Fireblocks | Yes | Yes | Yes | Planned for 2022 | |
| HolyTransaction | Yes | No | Yes | ?? | |
| Coinb.in | Yes | Yes | ?? | ?? | open source JavaScript implementation |
| Guarda Wallet | Yes | Yes | Yes | Currently not planned | https://twitter.com/GuardaWallet/status/1194270398730448896 |
Exchanges
| Name | Send to Bech32 | Receive to P2WPKH/P2WSH | Send to Bech32m | Receive to P2TR | Notes |
|---|---|---|---|---|---|
| AgoraDesk | Yes | Yes | Yes | Yes | |
| Anycoin Direct | Yes | No | ?? | ?? | https://anycoindirect.eu/en/news/details/segwit-activated |
| Binance | Yes | Yes | No | No | https://twitter.com/colemaktypo/status/1460337599499882502 |
| Bitaroo | Yes | Yes | Yes | No | |
| BitBargain.co.uk | Yes | No | ?? | ?? | |
| Bitcoin.de | Yes | No | No | No | https://twitter.com/Ben_deWaal/status/1460464528181936130 |
| Bitfinex | Yes | No | Planned | No | https://twitter.com/paoloardoino/status/1460620727342796800 |
| BitMEX | Yes | Yes | Yes | ?? | https://twitter.com/BitMEXResearch/status/1492152557044654082 |
| Bitonic | Yes | ?? | No | ?? | https://twitter.com/BitcoinenNL/status/1460284373291384833 |
| Bitpanda | Yes | ?? | Yes | ?? | https://twitter.com/christiant5r/status/1461369956252139520 |
| Bittrex | No | No | ?? | ?? | https://www.reddit.com/r/Bitcoin/comments/gqt1m6/bittrex_does_not_even_support_withdrawals_to/ |
| Bittylicious | Yes | No | ?? | ?? | https://twitter.com/Bittylicious_/status/998881327347888128 |
| Bitstamp | Yes | Yes | Planned | ?? | https://www.bitstamp.net/article/weve-added-support-bech32-bitcoin-addresses-bitsta/ |
| Bitso | Yes | No | Yes | ?? | |
| Bitwage | ?? | No | ?? | ?? | |
| Bitwala | Yes | Yes | ?? | ?? | |
| Bottlepay | Yes | Yes | No | ?? | https://help.bottlepay.com/en/articles/4909780-what-bitcoin-addresses-do-you-support-for-on-chain-withdrawals, https://twitter.com/Stack_Russel_UK/status/1460330265751044097 |
| BSDEX | Yes | No | No | No | https://www.bsdex.de/en/faq/#deposit-and-withdrawal-options-which-cryptocurrency-address-formats-are-supported-in-bsdex |
| Bull Bitcoin | Yes | Yes | Yes | Planned | https://twitter.com/francispouliot_/status/1464264391155666950 |
| CardCoins.co | Yes | No deposits | Yes | No deposits | https://twitter.com/CardCoinsCo/status/1452680654030872589 |
| CEX.IO | No | No | ?? | ?? | |
| Coinbase.com | Yes | No | Not a priority currently | No | |
| CoinCorner | Yes | Yes | Yes | ?? | https://twitter.com/CoinCorner/status/1461360995746545667 |
| CoinFalcon | Yes | No | ?? | ?? | |
| Coinmate.io | Yes | Yes | Yes | Yes | https://coinmate.io/cz/taproot-revolucni-upgrade-bitcoinu/ |
| Coinsbank.com | Yes | Yes | ?? | ?? | |
| Coinygram | Yes | No | ?? | ?? | |
| Flyp.me | Yes | No | Yes | ?? | |
| FTX US Derivatives | Yes | Yes | Yes | ?? | Formerly LedgerX |
| GDax | Yes | No | ?? | ?? | https://www.reddit.com/r/Bitcoin/comments/8c738k/coinbase_gdax_already_allows_sending_to_bc1/ |
| Gemini | Yes | Yes | No | No | https://np.reddit.com/r/Bitcoin/comments/b66n0v/psa_gemini_is_full_on_with_native_segwit_and_uses/ |
| Genesis | ?? | No | ?? | ?? | |
| Globitex | No | No | ?? | ?? | |
| HitBTC | Yes | No | ?? | ?? | |
| Hodl Hodl | Yes | Yes | ?? | ?? | https://medium.com/@hodlhodl/hodl-hodl-segwit-compatible-exchange-a2231968ac56 |
| Independent Reserve | Yes | No | ?? | ?? | https://www.independentreserve.com/bitcoin/investing |
| Itbit | ?? | No | ?? | ?? | |
| Kraken | Yes | No | Yes | No | https://blog.kraken.com/post/16740/bitcoin-taproot-address-now-supported-on-kraken/ |
| Liberalcoins | Yes | Yes | ?? | ?? | https://liberalcoins.com |
| LocalBitcoins | Yes | No | ?? | ?? | https://twitter.com/LocalBitcoins/status/1322194709159301120 |
| Luno | Yes | No | Planned | ?? | https://www.luno.com/blog/en/post/luno-launches-support-for-bech32-addresses |
| Okcoin | Yes | Yes | Yes | ?? | https://twitter.com/Okcoin/status/1471563103049756672 |
| Paxful.com | Yes | No | ?? | ?? | https://paxful.com/support/en-us/articles/360011766520-Can-I-Withdraw-Bitcoin-from-Paxful-Wallet-to-My-External-Wallet- |
| Purse.io | Yes | Yes | ?? | ?? | |
| Poloniex.com | Yes | No | ?? | ?? | https://www.reddit.com/r/Bitcoin/comments/a3jhcf/you_can_now_withdraw_from_poloniex_to_bech32/ |
| River.com | Yes | Yes | Yes | ?? | |
| Robinhood.com | Yes | ?? | No | ?? | https://robinhood.com/us/en/support/articles/cryptocurrency-wallets/#Supportedaddressformatsforcryptowithdrawals |
| Square CashApp | Yes | No | Yes | ?? | https://cash.app/help/us/en-us/20211114-bitcoin-taproot-upgrade |
| StackinSat.com | Yes | No deposits | Yes | No deposits | https://twitter.com/StackinSat_FR/status/1500898826416230401 |
| Strike | Yes | Yes | No | No | https://twitter.com/BTCBoromir/status/1460373287792521232 |
| Swan | Yes | No deposits | Yes | No deposits | https://twitter.com/SwanBitcoin/status/1468318386916663298 |
| TheRockTrading.com | Yes | Yes | ?? | ?? | https://twitter.com/TheRockTrading/status/976787499648512003 |
| VBTC | Yes | Planned | Yes | Planned | https://twitter.com/VBTC_Vietnam/status/1460978196816416775 |
| Walltime | Yes | Yes | ?? | ?? | https://walltime.info |
| Xapo | Yes | No | ?? | ?? |
Bitcoin ATM Models
Hopefully when a model updates then all its ATMs everywhere will gain that feature. See https://coinatmradar.com/shop/buy-bitcoin-atm/
| Name | Send to Bech32 | Receive to P2WPKH/P2WSH | Send to Bech32m | Receive to P2TR | Notes |
|---|---|---|---|---|---|
| Bitaccess BTM | Yes | Yes | Work in progress | Planned | https://twitter.com/DylanSeago/status/1520212294898274305 |
| GenesisCoin | No | No | ?? | ?? | |
| General Bytes | Yes | Yes | ?? | ?? | Depending on configuration. Since version 20190613 https://www.generalbytes.com/en/support/changelog |
| Lamassu | Yes | Yes (optional) | Planned | ?? | https://twitter.com/LamassuBTC/status/1459918440303673349 |
Blockchain Explorers
To investigate bech32 capability, you can use mainnet TXIDs 4ef47f6eb681d5d9fa2f7e16336cd629303c635e8da51e425b76088be9c8744c and 514a33f1d46179b89e1fea7bbb07b682ab14083a276979f91038369d1a8d689b or look up the addresses bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq and bc1qc7slrfxkknqcq2jevvvkdgvrt8080852dfjewde450xdlk4ugp7szw5tk9 .
Some blockchain explorers can only parse the bech32 address and display it, they don’t build an index so users cannot search for bech32 addresses.
To verify bech32m readiness, you can look up the mainnet TXID b10c007c60e14f9d087e0291d4d0c7869697c6681d979c6639dbd960792b4d41 on which the first output should be addressed as bc1pqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqsyjer9e . Note that the superseded bech32 encoding only differs in the last six characters that encode the checksum: bc1pqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqs_3wf0qm_ .
Подробно об обновлении 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), существует возможность проведения нескольких видов атак:
- Изменение формата подписи. В протоколе Bitcoin формат подписи утвержден не строго и зависит от реализации библиотеки OpenSSL, в которой для подписи тоже не определен строгий формат. Третья сторона может изменить перехваченную транзакцию, что повлечет за собой изменение хеш-значения.
- Воздействие непосредственно на scriptSig. Как было отмечено ранее, 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
- адрес в Base58 занимает больше памяти в QR-кодах, поскольку не может использовать режим буквенно-цифрового представления;
- base58 является очень неудобным для надежной записи на бумагу, ввода с мобильной клавиатуры или чтения вслух;
- двойное хеширование контрольной суммы является медленным;
- декодирование base58 является сложным и сравнительно медленным.
Спецификация Bech32 адреса
Адрес Bech32 имеет длину, которая не превышает 90 символов, и содержит:
- Часть, удобную для чтения человеком. Сюда входят данные, которые может понадобиться передать или которые имеют какое-либо отношение к владельцу адреса, длина минимум 1 символ. Например, по умолчанию для адресов mainnet используются символы «bc», а для testnet символы «tb».
- Разделитель, который всегда равен «1». Если «1» разрешен внутри человекочитаемой части, то разделителем является последний из символов «1».
- Часть с данными имеет длину как минимум 6 символов и состоит только из буквенно-цифровых символов, исключая «1», «b», «i», и «o». В качестве основных данных тут используется версия witness program и данные самой witness program (от 2 до 40 байт).
Зачем включать разделитель в адреса? Это позволяет однозначно отделить человекочитаемую часть от части с данными, избежав потенциальных столкновений с другими человекочитаемыми частями, которые используют префикс. Это также позволяет избегать ограничений в наборе символов для человекочитаемой части. Сепаратор равен 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 адресов?
Набор символов выбирается так, чтобы минимизировать двусмысленность, связанную с визуальным их сходством. Порядок выбирается для минимизации количества пар символов, которые отличаются менее чем одним битом данных. Контрольная сумма выбрана для максимизации вероятности обнаружения небольшого числа ошибок, что улучшает эффективность ее работы для типичных ошибок.
Какие существуют виды биткоин-адресов?
В сети биткоина существует несколько видов адресов. Их можно легко отличить по префиксу — символам в начале адреса:
- Legacy (P2PKH): начинается с цифры 1. Пример: 1N4Qbzg6LSXUXyXu2MDuGfzxwMA7do8AyL.
- Script (P2SH): начинается с цифры 3. Пример: 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy. (P2WPKH): начинается с комбинации “bc1q”. Пример: bc1qfg9t7fwn0atn4yf9spca5502vk8dyhq8a9aqd8.
- Taproot (P2TR): начинается с комбинации “bc1p”. Пример: bc1peu5hzzyj8cnqm05le6ag7uwry0ysmtf3v4uuxv3v8hqhvsatca8ss2vuwx.
Что такое биткоин-адрес в формате Legacy?
Legacy-адрес — это самый первый стандарт адреса в сети биткоина, предложенный еще Сатоши Накамото. Иначе его называют P2PKH (Pay To Public Key Hash), поскольку он требует от получателя подпись, вычисленную из приватного ключа, и публичный ключ.
Адрес типа Legacy состоит из трех частей:
- префикс;
- сгенерированный в результате применения к приватному ключу алгоритмов SHA256 и RIPEMD публичный ключ;
- контрольная сумма.
Как входящие, так и исходящие переводы с таких адресов поддерживают все кошельки и приложения, работающие в сети биткоина. Главный минус Legacy-адресов — высокие комиссии. Также в них низкая скорость двойного хеширования контрольной суммы и больший вес в QR-кодах.
Каковы отличия Script (P2SH) от Legacy?
Script-адреса появились в предложении по улучшению биткоина BIP-0016 в январе 2012 года благодаря главному научному сотруднику Bitcoin Foundation Гэвину Андресену.
Они имеют ту же структуру, что и Legacy-адреса, но начинаются с цифры 3. Такие адреса предполагают, что при переводе средств получатель должен иметь скрипт, подходящий к скрипту хеша. Эта особенность позволяет снижать комиссию за перевод, перекладывать комиссионные затраты на получателя и создавать адреса с мультиподписью.
В чем преимущества формата SegWit?
Весной 2016 года разработчики Питер Велле и Грег Максвелл в обновлении BIP-0173 предложили новый вид адреса под названием Bech32. Его также называют Segregated Witness (SegWit) или P2WPKH (Pay to Witness Public Key Hash).
Главное преимущество Taproot-адресов для их владельцев — наиболее низкие комиссии по сравнению с другими форматами и более дешевые платежи в сети Lightning Network.
Однако у Taproot есть большой недостаток — данный вид пока поддерживает только небольшое число кошельков. В середине августа 2022 года лишь 0,56% всех исходящих переводов в сети биткоина совершались с адресов этого типа.
Постепенное распространение нового стандарта — норма для децентрализованной сети биткоина, которой пользуются огромное количество приложений и пользователей. Аналогичная ситуация наблюдалась после внедрения SegWit.
Можно ли переводить биткоины между адресами разных форматов?
Сегодня Legacy, Script и SegWit являются полностью совместимыми между собой. То есть между ними можно свободно проводить как входящие, так и исходящие переводы.
Несколько по-другому дело обстоит с Taproot. Большинство используемых некастодиальных кошельков поддерживают отправку транзакций на адрес типа Bech32m, однако не имеют функций по созданию такого адреса. Кроме того, не все биржи криптовалют позволяют отправлять средства на Taproot-адрес. Текущую ситуацию с внедрением Taproot в популярные биткоин-кошельки можно посмотреть на сайте Bitcoin Wiki.
Транзакции P2TR-адресов поддерживают многие используемые обозреватели блоков биткоина, например Blockchair или Blockstream.
Ответы на частые вопросы
Что такое биткоин-адрес?
Биткоин-адрес — это уникальный идентификатор, с помощью которого пользователь может отправлять и получать криптовалюту. Каждый BTC-адрес уникален и генерируется путем сложных механизмов шифрования. Служит аналогом банковского счета в сети биткоина.
Какой формат биткоин-кошелька лучше?
По состоянию на 2022 год рекомендуем использовать SegWit — он является современным стандартом, позволяет платить низкие комиссии за переводы в сети биткоина и поддерживается большинством кошельков. В будущем этот формат, скорее всего, сменит Taproot.
Как выбрать вид биткоин-адреса?
Зачастую приложение для хранения биткоинов позволяет выбрать формат адреса на этапе создания адреса.
Сколько символов в адресе биткоин-кошелька?
Legacy-адрес для первой криптовалюты состоит из 34 символов, SegWit-адреса (Bech32) чаще всего включают 42 знаков, Taproot (Bech32m) — 62 символа.
Сколько всего биткоин-адресов?
По данным Glassnode, в августе 2022 года в сети биткоина было более 38 млн адресов с ненулевым балансом. Ежедневно транзакции отправляют или получают около 1 млн биткоин-адресов.