Bitcoin Wiki - User contributions [en]

Bech32 adoption

2024-04-04T20:45:37Z

Manu: /* Hardware Wallets */ Added Krux

[[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 [[Taproot]] softfork added another output type called Pay to Taproot (P2TR). P2TR outputs and future native segwit versions use 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

{| class="wikitable"
|-
| {{No}} ||
|-
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder
|-
| {{Planned}} || The developers said they plan to
|-
| {{Acceptable|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
|}

=== Software Wallets ===
{| class="wikitable sortable"
|-
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes
|-
| Armory || {{Yes}} || {{No}} || {{Planned|Planned around activation}} || {{Evaluating|??}} ||
|-
| AQUA || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| bcoin || {{Yes}} || {{Yes}} || {{Yes|Since 2.2.0}} || {{Evaluating|??}} ||
|-
| Bisq || {{Yes}} || {{Yes}} || {{No}} || {{No}} || As of v1.5.0 https://bisq.network/blog/bisq-v1.5.0-highlights/
|-
| Bitcoin Core || {{Yes|Since 0.16.0}} || {{Yes|Since 0.16.0}} || {{Yes|Since 0.21.1}} || {{Yes|Since 22.0}} || Uses P2WPKH as default address since version [https://bitcoin.org/en/release/v0.20.0 0.20.0]. Creating P2TR addresses requires manual import for now.
|-
| Bitcoin Knots || {{Yes|Since 0.16.0}} || {{Yes|Since 0.16.0}} || {{Yes|Since 0.21.1}} || {{Yes|Since 22.0}} ||
|-
| Blockstream Green || {{Yes}} || {{Yes}} || {{Yes|Since Mobile 3.7.6+, Desktop 1.0.4+}} || {{Planned|Planned}} || Bech32m sending support as of [https://github.com/Blockstream/gdk/releases/tag/release_0.0.47 GDK 0.0.47]
|-
| Breadwallet || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.reddit.com/r/BRDapp/comments/9xx1hq/as_of_today_brd_fully_supports_native_segwit/
|-
| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Bitcoin Wallet for Android] || {{Yes}} || {{Yes}} || {{Yes|Since 9.0}} || {{No}} || Tested as of v9.20 (October 2022)
|-
| BlueWallet || {{Yes}} || {{Yes}} || {{Yes|Since 6.2.14}} || {{No}} || Tested as of v6.3.1 (October 2022)
|-
| Breez || {{Yes}} || {{Yes}} || {{Yes}} || {{Acceptable|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
|-
| [https://github.com/unchained-capital/caravan Caravan] || {{Yes}} || {{Yes}} || {{Planned}} || {{Evaluating|??}} ||
|-
| Casa || {{Yes}} || {{No}} || {{Yes}} || {{Planned}} ||
|-
| C-Lightning || {{Yes}} || {{Yes}} || {{Yes}} || {{Evaluating|??}} ||
|-
| Coinomi || {{Yes}} || {{Yes}} || {{No}} || {{No}} || Tested as of v1.26.0 (October 2022)
|-
| [https://edge.app Edge] || {{Yes}} || {{Yes}} || {{Yes}} || {{Planned}} || https://twitter.com/thedavidcoen/status/1696526932815523957
|-
| Electrum || {{Yes}} || {{Yes}} || {{Yes|Since 4.1.0}} || {{Planned|Planned: Descriptor-based keypath spends}} || https://github.com/spesmilo/electrum/issues/7544
|-
| Exodus || {{Yes}} || {{Yes}} || {{Yes}} || {{No|Not yet planned}} || https://support.exodus.com/article/1480-bitcoin-faqs-learn-more-about-btc#
|-
| Fully Noded || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes|Since v0.2.26}} || https://twitter.com/FullyNoded/status/1438652812410298370
|-
| Guarda Wallet || {{Yes}} || {{Yes}} || {{Yes}} || {{No|Currently not planned}} || [https://twitter.com/GuardaWallet/status/1194270398730448896 twitter announcement]
|-
| Iris Wallet || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || https://twitter.com/cryptoquick/status/1585187190627528710
|-
| JoinMarket || {{Yes}} || {{Yes}} || {{Yes|Since v0.9.5}} || {{Evaluating|??}} ||
|-
| Liana || {{Yes}} || {{Yes}} || {{Yes}} || {{No}} || https://twitter.com/KLoaec/status/1685291936549044224
|-
| LND || {{Yes}} || {{Yes}} || {{Yes|Since v0.15}} || {{Yes|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}} || {{Yes}} || {{Yes|Since v2.2.0}} ||
|-
| Samourai Wallet || {{Yes}} || {{Yes}} || {{Yes|Since v0.99.98}} || {{No|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}} || {{No|Not planned}} || https://github.com/trustwallet/wallet-core/releases/tag/2.6.5, https://twitter.com/catenocrypt/status/1520152930065817601
|-
| Uniblow || {{Yes}} || {{Yes}} || {{Yes | Since v1.2.2}} || {{No|Not yet planned}} || [https://github.com/bitlogik/uniblow/releases/tag/v1.2.2 release1.2.2]
|-
| Wallet of Satoshi || {{Yes}} || {{Yes}} || {{Yes}} || {{No}} || https://twitter.com/walletofsatoshi/status/1459782761472872451
|-
| Wasabi Wallet || {{Yes}} || {{Yes}} || {{Yes | Since Wasabi 2.0}} || {{Planned|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]].

{| class="wikitable sortable"
|-
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes
|-
| Trezor + Trezor Suite || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || since [https://blog.trezor.io/trezor-suite-and-firmware-updates-december-2021-d1e74c3ea283 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}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| BitBox Desktop app || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || https://twitter.com/_benma_/status/1504455969631350792
|-
| Trezor + Electrum || {{Yes}} || {{Yes}} || {{Yes}} || {{Planned}} ||
|-
| Ledger + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| BitBox + Electrum || {{Yes}} || {{Yes}} || {{Yes}} || {{Evaluating|??}} || https://twitter.com/_benma_/status/1504458280000761857
|-
| KeepKey + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| Archos + Electrum || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| Coldcard + Electrum || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || https://blog.coinkite.com/edge-firmware/
|-
| Ballet + app || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| SeedSigner || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || https://twitter.com/KeithMukai/status/1750547895994982906
|-
| Tangem + app|| {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| Blockstream Jade + Blockstream Green || {{Yes}} || {{Yes}} || {{Yes}} || {{Planned|Planned}} || Bech32m sending support as of [https://github.com/Blockstream/gdk/releases/tag/release_0.0.47 GDK 0.0.47] available via Blockstream Green mobile apps 3.7.6+ and desktop app 1.0.4+
|-
| Keystone || {{Yes}} || {{Acceptable|Yes, but only with BTC-only firmware}} || {{Planned|Planned for Q1 2022}} || {{Evaluating}} || https://twitter.com/KeystoneWallet/status/1460110906789031938
|-
| Foundation Passport || {{Yes}} || {{Yes}} || {{Yes}} || {{Planned|Planned}} || https://twitter.com/ShrtCrct6102/status/1661102603810250761
|-
| Krux || {{Yes}} || {{Yes}} || {{Yes}} || {{Planned|Planned}} || https://selfcustody.github.io/krux/getting-started/usage/using-a-single-sig-wallet/
|}

=== Web Wallets / Wallet Service Providers ===

{| class="wikitable sortable"
|-
! 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
|-
| [https://coin.space Coin Wallet] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| 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
|-
| [https://bitmask.app BitMask Wallet] || {{Yes}} || Taproot Only || {{Yes}} || {{Yes}} || https://twitter.com/cryptoquick/status/1685061519653076992
|-
| Bitnob || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || https://twitter.com/bernard_parah/status/1469962690483400706
|-
| blockchain.com web|| {{Yes}} || {{Yes}} || {{Yes}} || {{Evaluating|??}} || https://twitter.com/Pellicceama/status/1563171639063629828
|-
| Fireblocks || {{Yes}} || {{Yes}} || {{Yes}} || {{Planned|Planned for 2022}} ||
|-
| HolyTransaction || {{Yes}} || {{No}} || {{Yes}} || {{Evaluating|??}} ||
|-
| [https://coinb.in Coinb.in] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || open source JavaScript implementation
|-
| Guarda Wallet || {{Yes}} || {{Yes}} || {{Yes}} || {{No|Currently not planned}} || https://twitter.com/GuardaWallet/status/1194270398730448896
|}

=== Exchanges ===



{| class="wikitable sortable"
|-
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes
|-
| [[AgoraDesk]] || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} ||
|-
| Anycoin Direct || {{Yes}} || {{No}} || {{Yes}} || {{Evaluating|??}} || https://twitter.com/AnycoinDirect/status/1691731011447464135
|-
| Binance || {{Yes}} || {{Yes}} || {{No}} || {{No}} || https://twitter.com/colemaktypo/status/1460337599499882502
|-
| Bitaroo || {{Yes}} || {{Yes}} || {{Yes}} || {{No}} ||
|-
| BitBargain.co.uk || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| Bitcoin.de || {{Yes}} || {{No}} || {{No}} || {{No}} || https://twitter.com/Ben_deWaal/status/1460464528181936130
|-
| Bitfinex || {{Yes}} || {{No}} || {{Yes}} || {{No}} || https://twitter.com/kilrau/status/1752252008139018670
|-
| BitMEX || {{Yes}} || {{Yes}} || {{Yes}} || {{Evaluating|??}} || https://twitter.com/BitMEXResearch/status/1492152557044654082
|-
| Bitonic || {{Yes}} || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || https://twitter.com/BitcoinenNL/status/1460284373291384833
|-
| Bitpanda || {{Yes}} || {{Evaluating|??}} || {{Yes}} || {{Evaluating|??}} || https://twitter.com/christiant5r/status/1461369956252139520
|-
| Bittrex || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.reddit.com/r/Bitcoin/comments/gqt1m6/bittrex_does_not_even_support_withdrawals_to/
|-
| Bittylicious || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/Bittylicious_/status/998881327347888128
|-
| Bitstamp || {{Yes}} || {{Yes}} || {{Planned}} || {{Evaluating|??}} || https://www.bitstamp.net/article/weve-added-support-bech32-bitcoin-addresses-bitsta/
|-
| Bitso || {{Yes}} || {{No}} || {{Yes}} || {{Evaluating|??}} ||
|-
| Bitwage || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| Bitwala || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| Bitypreço || {{Yes}} || {{Yes}} || {{Yes}} || {{No}} ||
|-
| Boltz || {{Yes}} || {{No}} || {{Yes}} || {{Yes}} || https://blog.boltz.exchange/p/introducing-taproot-swaps-putting
|-
| Bottlepay || {{Yes}} || {{Yes}} || {{No}} || {{Evaluating|??}} || 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}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| Coinbase.com || {{Yes}} || {{No}} || {{No|Not a priority currently}} || {{No}} ||
|-
| CoinCorner || {{Yes}} || {{Yes}} || {{Yes}} || {{Evaluating|??}} || https://twitter.com/CoinCorner/status/1461360995746545667
|-
| CoinFalcon || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| [https://coinmate.io Coinmate.io] || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || https://coinmate.io/cz/taproot-revolucni-upgrade-bitcoinu/
|-
| Coinsbank.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| Coinygram || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| Flyp.me || {{Yes}} || {{No}} || {{Yes}} || {{Evaluating|??}} ||
|-
| LedgerX || {{Yes}} || {{Yes}} || {{Yes}} || {{Evaluating|??}} || Formerly FTX US Derivatives
|-
| GDax || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || 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 || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| Globitex || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| HitBTC || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| Hodl Hodl || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://medium.com/@hodlhodl/hodl-hodl-segwit-compatible-exchange-a2231968ac56
|-
| Independent Reserve|| {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.independentreserve.com/bitcoin/investing
|-
| Itbit || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| Kraken || {{Yes}} || {{No}} || {{Yes}} || {{No}} || https://blog.kraken.com/post/16740/bitcoin-taproot-address-now-supported-on-kraken/
|-
| Liberalcoins || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://liberalcoins.com
|-
| [[LocalBitcoins]] || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/LocalBitcoins/status/1322194709159301120
|-
| Luno || {{Yes}} || {{No}} || {{Yes}} || {{Evaluating|??}} || https://twitter.com/dunxen/status/1751703331620126814
|-
| Okcoin || {{Yes}} || {{Yes}} || {{Yes}} || {{Evaluating|??}} || https://twitter.com/Okcoin/status/1471563103049756672
|-
| Paxful.com || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://paxful.com/support/en-us/articles/360011766520-Can-I-Withdraw-Bitcoin-from-Paxful-Wallet-to-My-External-Wallet-
|-
| PeachBitcoin.com || {{Yes}} || {{No}} || {{Yes}} || {{No}} || https://github.com/sbddesign/bech32m-adoption/pull/33
|-
| Purse.io || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| Poloniex.com || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} || https://www.reddit.com/r/Bitcoin/comments/a3jhcf/you_can_now_withdraw_from_poloniex_to_bech32/
|-
| Relai || {{Yes}} || {{Yes}} || {{No}} || {{No}} || https://twitter.com/_adembilican_/status/1738602193249349880
|-
| River.com || {{Yes}} || {{Yes}} || {{Yes}} || {{Evaluating|??}} ||
|-
| Robinhood.com || {{Yes}} || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || https://robinhood.com/us/en/support/articles/cryptocurrency-wallets/#Supportedaddressformatsforcryptowithdrawals
|-
| Square CashApp || {{Yes}} || {{No}} || {{Yes}} || {{Evaluating|??}} || 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}} || {{Yes}} || {{No}} || https://github.com/sbddesign/bech32m-adoption/pull/29
|-
| Swan || {{Yes}} || No deposits || {{Yes}} || No deposits || https://twitter.com/SwanBitcoin/status/1468318386916663298
|-
| TheRockTrading.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/TheRockTrading/status/976787499648512003
|-
| VBTC || {{Yes}} || {{Planned}} || {{Yes}} || {{Planned}} || https://twitter.com/VBTC_Vietnam/status/1460978196816416775
|-
| Xapo || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|}

=== 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/

{| class="wikitable sortable"
|-
! Name !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes
|-
| Bitaccess BTM || {{Yes}} || {{Yes}} || {{Planned|Work in progress}} || {{Planned}} || https://twitter.com/DylanSeago/status/1520212294898274305
|-
| GenesisCoin || {{No}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| General Bytes || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Depending on configuration. Since version 20190613 https://www.generalbytes.com/en/support/changelog
|-
| Lamassu || {{Yes}} || {{Yes|Yes (optional)}} || {{Yes}} || {{Evaluating|??}} || https://twitter.com/LamassuBTC/status/1459918440303673349
|}

=== Blockchain Explorers ===

To investigate bech32 capability, you can use mainnet TXIDs <code>4ef47f6eb681d5d9fa2f7e16336cd629303c635e8da51e425b76088be9c8744c</code> and <code>514a33f1d46179b89e1fea7bbb07b682ab14083a276979f91038369d1a8d689b</code> or look up the addresses <code>bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq</code> and <code>bc1qc7slrfxkknqcq2jevvvkdgvrt8080852dfjewde450xdlk4ugp7szw5tk9</code>.

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 <code>b10c007c60e14f9d087e0291d4d0c7869697c6681d979c6639dbd960792b4d41</code> on which the first output should be addressed as <code>bc1pqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqsyjer9e</code>. Note that the superseded bech32 encoding only differs in the last six characters that encode the checksum: <code>bc1pqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqs_3wf0qm_</code>.

See also: https://en.bitcoin.it/wiki/Category:Block_chain_browsers

{| class="wikitable sortable"
|-
! Name !! Display Bech32 !! Index Bech32 !! Display Bech32m !! Index Bech32m !! Notes
|-
| bitaps.com || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || https://bitaps.com
|-
| Bitflyer || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || https://chainflyer.bitflyer.jp
|-
| Blockbook || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || https://btc1.trezor.io
|-
| blockchain.com || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || https://www.blockchain.com/explorer
|-
| Blockchair || {{Yes}} || {{Yes}} || {{Yes|Ready, but old txns not reindexed yet}} || {{Yes|Ready, but old txns not reindexed yet}} || https://github.com/Blockchair/Blockchair.Support/issues/567#issuecomment-966393097, https://twitter.com/Blockchair/status/1458817396433731585
|-
| Blockcypher || {{Yes}} || {{Yes}} || {{Yes}} || {{No}} || https://live.blockcypher.com/btc
|-
| Blockonomics || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || https://www.blockonomics.co
|-
| Blockpath || {{Yes}} || {{Yes}} || {{No}} || {{No}} || https://blockpath.com
|-
| BTC.com || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || https://BTC.com
|-
| Esplora || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || Open source explorer, instances are https://blockstream.info/ and https://www.localbitcoinschain.com/. [https://github.com/Blockstream/esplora/issues/323 Issue] for BIP350 support.
|-
| Insight || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || Open source explorer, instances include https://insight.bitpay.com/
|-
| Mempool || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || Open source explorer, instances include https://mempool.space https://mempool.ninja https://mempool.emzy.de https://mempool.bisq.services https://mempool.bitcoin.ninja https://mempool.bitaroo.net/
|-
| OKLink || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || https://www.oklink.com
|-
| OXT || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || https://oxt.me/
|-
| Tradeblock || {{Yes}} || {{Yes}} || {{Yes}} || {{Planned|Yes, but search field rejects bech32m addresses}} || https://tradeblock.com/bitcoin
|-
| WalletExplorer || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || https://walletexplorer.com/
|-
| Bitcoin Explorer || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || https://bitcoinexplorer.org, https://twitter.com/BitcoinExplorer/status/1425148093977309187
|-
| BitRef || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || https://bitref.com
|-
| Tokenview || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || https://tokenview.io
|}

=== Payment Processors ===



{| class="wikitable sortable"
|-
! Name !! P2WPKH/P2WSH Invoices !! Bech32 Withdrawal addresses !! P2TR Invoices !! Bech32m Withdrawal addresses !! Notes
|-
| [https://apirone.com Apirone] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Payment notifications, merchant dashboard, plugins for Magento, WooCommerce, OpenCart 2, Opencart 3.x, Virtuemart
|-
| [https://bitaps.com Bitaps] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || Payment forwarding API, Wallet API, fault tolerance callback.
|-
| [https://btcpayserver.org BTCPay Server] || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes|Supported since 1.3.0}} || https://twitter.com/NicolasDorier/status/1432354289599451136, https://twitter.com/NicolasDorier/status/1457527754350415873
|-
| [https://coingate.com CoinGate] || {{No}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| [https://confirmo.net CONFIRMO] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| [https://cryptochill.com CryptoChill] || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Planned}} || Highly customizable Bitcoin and Lightning Network payment gateway and custodial wallets provider. TSS/HD wallets, API, SDK.
|-
| [https://github.com/nickfarrow/SatSale SatSale] || {{Yes}} || n/a || {{Yes}} || n/a || Supports any address format supported by backend Bitcoin Core. Invoices use address format configured as default there. Has no withdrawal functionality in itself, payments are received in Core wallet.
|}

=== Mining Pools ===

{| class="wikitable sortable"
|-
! Name !! Payout to Bech32 !! Payout to Bech32m !! Notes
|-
| [https://pool.btc.com/ BTC.com Pool] || {{No}} || {{Evaluating|??}} ||
|-
| [http://ckpool.org/ Ckpool] || {{Yes}} || {{Evaluating|??}} ||
|-
| [https://kano.is/ KanoPool] || {{Yes}} || {{Evaluating|??}} || [https://bitcointalk.org/index.php?topic=789369.msg53374508#msg53374508 bitcointalk source]
|-
| [https://luxor.tech Luxor Mining] || {{Yes}} || {{Yes}} || [https://twitter.com/LuxorTechTeam/status/1685021778005872641 Tweet]
|-
| [http://poolin.com/ Poolin] || {{Yes}} || {{Evaluating|??}} || [https://bitcointalk.org/index.php?topic=5169994.msg52184844#msg52184844 bitcointalk source]
|-
| [https://sbicrypto.com SBICrypto Pool] || {{Yes}} || {{Acceptable|Ready to release at activation}} ||
|-
| [https://slushpool.com/ Slush Pool] || {{Yes}} || {{Planned|At activation}} || [https://twitter.com/braiins_systems/status/1432376840484794375 Tweet]
|-
| [https://ukrpool.com/ Ukr Pool] || {{Yes}} || {{Evaluating|??}} || [https://bitcointalk.org/index.php?topic=5124825.msg51358033#msg51358033 bitcointalk source]
|-
| [https://pool.viabtc.com/ ViaBTC Pool] || {{No}} || {{Evaluating|??}} ||
|}

=== Libraries ===

{| class="wikitable sortable"
|-
! Name !! Language !! Send to Bech32 !! Receive to P2WPKH/P2WSH !! Send to Bech32m !! Receive to P2TR !! Notes
|-
| [https://github.com/bitcoin/libbase58 libbase58] || C || {{No}} || n/a || {{No}} || n/a
|-
| [https://github.com/MetacoSA/NBitcoin NBitcoin] || .NET || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || https://twitter.com/NicolasDorier/status/1432354289599451136
|-
| [https://github.com/bcoin-org/bcoin bcoin] || JS || {{Yes}} || {{Yes}} || {{Yes}} || {{Evaluating|??}} || https://github.com/bcoin-org/bcoin/pull/1038
|-
| [https://github.com/btcsuite btcsuite/btcutil] || Go || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} ||
|-
| [https://github.com/bitcoinjs/bitcoinjs-lib bitcoinjs-lib] || JS || {{Yes}} || {{Yes}} || {{Yes|Yes, since v6.0.0}} || {{Yes}} || https://twitter.com/junderwood4649/status/1655457044068196358
|-
| [https://bitcoinj.github.io/ bitcoinj] || Java || {{Yes}} || {{Yes}} || {{Yes}} || {{Evaluating|??}} || https://github.com/bitcoinj/bitcoinj/commit/183986c9801f10f1bf46bd46621e535973d39ef8
|-
| [https://github.com/bitcoin-s/bitcoin-s-core bitcoin-s] || Scala || {{Yes}} || {{Yes}} || {{Yes}} || {{Planned|Planned for 2021}} || https://twitter.com/Chris_Stewart_5/status/1459205497463136270
|-
| [https://github.com/rust-bitcoin/rust-bitcoin rust-bitcoin] || Rust || {{Yes}} || {{Evaluating|??}} || {{Yes}} || {{Evaluating|??}} || https://twitter.com/RCasatta/status/1423695925252329476
|-
| [https://lightningdevkit.org Lightning Dev Kit] || Rust || {{Yes}} || {{Yes}} || {{Yes}} || {{Evaluating|Pending BOLT update}} ||
|-
| [https://bitcoindevkit.org Bitcoin Dev Kit] || Rust || {{Yes}} || {{Yes}} || {{Yes|Yes, since [https://github.com/bitcoindevkit/bdk/releases/tag/v0.14.0 0.14.0]}} || {{Yes|Yes, since [https://github.com/bitcoindevkit/bdk/releases/tag/v0.19.0 0.19.0]}} || P2TR support is "experimental", see [https://github.com/bitcoindevkit/bdk/pull/593 PR #593]
|-
| [https://github.com/ElementsProject/libwally-core libwally-core] || C || {{Yes}} || {{Yes}} || {{Yes|Yes, since [https://github.com/ElementsProject/libwally-core/releases/tag/release_0.8.4 0.8.4]}} || {{Yes|Yes, since [https://github.com/ElementsProject/libwally-core/releases/tag/release_0.8.4 0.8.4]}} ||
|-
| [https://github.com/Blockstream/gdk GDK] || C || {{Yes}} || {{Yes}} || {{Yes|Yes, since [https://github.com/Blockstream/gdk/releases/tag/release_0.0.47 0.0.47]}} || {{Evaluating|??}} ||
|-
| [https://github.com/Simplexum/python-bitcointx python-bitcointx] || Python || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || https://github.com/Simplexum/python-bitcointx/issues/57
|-
| [https://github.com/dgarage/NBXplorer/ NBXPlorer] || C# || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || https://twitter.com/NicolasDorier/status/1432354822888431619
|-
| [https://github.com/acinq/bitcoin-kmp Kotlin Multiplatform Bitcoin Library] || Kotlin || {{Yes}} || {{Yes}} || {{Yes}} || {{Planned}} || https://twitter.com/realtbast/status/1458533450919649284
|-
| [https://github.com/libbitcoin Libbitcoin] || C++ || {{Yes}} || {{Evaluating|??}} || {{Yes}} || {{Evaluating|??}} || https://github.com/libbitcoin/libbitcoin-system/blob/master/include/bitcoin/system/wallet/addresses/witness_address.hpp#L41
|-
| [https://github.com/chaintope/bitcoinrb Bitcoinrb] || Ruby || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || https://github.com/chaintope/bitcoinrb/wiki/Taproot
|}


=== References ===

[[Category:Software]]

Setting up a Tor hidden service

2023-05-08T18:10:41Z

Manu: /* Windows */ Adding more info and details

If you use a Bitcoin [[full node]] over Tor, then usually it will only be able to make outgoing connections. Therefore, you will only get a maximum of 10 total connections. This is fine, and is not something you usually need to worry about, but if your computer is often online and you want to be a big help to the network, you can run a Tor hidden service in order to accept incoming connections over Tor.

Note that there is no need to forward port 8333 when using a Tor hidden service. The hidden service will cause most firewalls and NAT setups to be bypassed. For this reason, running a Tor hidden service is also a good idea if you want incoming connections but are for some reason unable to forward port 8333.

=== Prerequisites ===

These instructions are for Linux. It is possible to do on Windows, the instructions are presented at the end.

You need Tor (at least version 0.2.7.1). Figure out where your <tt>torrc</tt> file is (<tt>/etc/tor/torrc</tt> is one possibility). This guide assumes default Tor settings. This guide assumes that Tor is running under the user and group <tt>tor</tt>, which will usually be the case if you install Tor using your distro's package manager. Note that since version 22.0 Bitcoin '''does not''' support Tor hidden service version 2 (ie. short onion addresses), only support Tor version 3 hidden services (Tor v3, ie. long onion addresses).

You need Bitcoin Core (or similar). For method 1, you need at least version 0.12.0. Find <tt>bitcoin.conf</tt> in your [[data directory]].

=== Linux Method 1 (recommended) ===

This sets up an automatic hidden service that is initiated by Bitcoin Core. On the first startup of <tt>bitcoind</tt> after configuring Bitcoin Core to use Tor ControlPort as follows, Bitcoin Core will generate a file called <tt>onion_private_key</tt> in the [[data directory]]. The file <tt>onion_private_key</tt> contains the private key needed to generate your unique <tt>XXXXXXX.onion</tt> address. KEEP THIS SAFE. If someone copies this file they can run a server with your .onion address. Also, if you delete this file, the next time bitcoind loads it will generate a new key file and <tt>xxxxxxxx.onion</tt> address. Note that while a malicious party cannot necessarily associate the server with you as a person, as long as your server has the same xxxx.onion address they will know it is run by the same person. For absolute security delete <tt>onion_private_key</tt> at each reboot or some frequent interval.

Add these lines to your <tt>torrc</tt>:

<pre>ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1</pre>

You need to figure out what user bitcoind or bitcoin-qt is running as. Run the following command while Bitcoin is running:
<pre>ps -eo user,group,comm |egrep 'bitcoind|bitcoin-qt' |awk '{print "Bitcoin user: " $1}'</pre>
Write down the reported user.

Run the following command as root, which adds your Bitcoin user to the tor group. Replace BITCOIN_USER with the actual user name found above:
<pre>usermod -a -G tor BITCOIN_USER</pre>

At this point your node will work over Tor without further configuartion. Bitcoin Core v0.12 and later automatically tries to connect to Tor via the ControlPort if <tt>listen=1</tt> is set in <tt>bitcoin.conf</tt>. By default Bitcoin Core will usually connect over the regular Internet as well as allow connections to and from the Tor hidden service. This will help other users who wish to submit transactions to the bitcoin network securely and obscurely, but transactions you submit could theoretically be traced back to your ip address. If you want Bitcoin Core to only connect via Tor (for anonymity), add these lines to [[Running_Bitcoin#Bitcoin.conf_Configuration_File|bitcoin.conf]]:

<pre>proxy=127.0.0.1:9050
listen=1
bind=127.0.0.1</pre>

If you additionally want Bitcoin Core to only connect out to Tor ''hidden services'', also add this line (not particularly recommended):
<pre>onlynet=onion</pre>

Doing so will make your specific bitcoind node arguably more secure because it will never have an unencrypted connection to another node, but if everyone used <tt>onlynet=onion</tt> nobody on the onion bitcoin chain would be able to communicate with the clearnet chain. It is essential that some nodes access both clearnet and Tor. If you need to submit bitcoin transactions to the network with the highest level of obscurity, use <tt>onlynet=onion</tt>. If you only wish to give access to your node to other Tor users, do not use it.

Now restart Tor, and then Bitcoin Core. At some point during startup in <tt>~/.bitcoin/debug.log</tt> you will see
<pre>tor: Got service ID XXXXXXXXXXX, advertising service XXXXXXXXXXX.onion:8333</pre> This is the .onion address of your server. You should eventually get incoming connections via the hidden service.

=== Linux Method 2 ===

This sets up a manual hidden service controlled by the tor daemon. The hidden service address (xxxx.onion). Note that as in method 1, your xxxxx.onion address will stay the same until you delete your key file. Someone tracking you can't necessarily associate the xxxx.onion with you, but they will know it is run by the same person or entity.

Add these lines to your <tt>torrc</tt>:
<pre>HiddenServiceDir /var/lib/tor/bitcoin-service/
HiddenServicePort 8333 127.0.0.1:8333</pre>

Restart Tor. As root, run <tt>cat /var/lib/tor/bitcoin-service/hostname</tt>. Your onion address will be reported. If it didn't work, then probably your distro's version of Tor doesn't actually use <tt>/var/lib/tor</tt> for this purpose. You should try to figure out the correct HiddenServiceDir location.

In the following steps, replace ONION_ADDR with the onion address reported above.

If you don't care about anonymity and are only looking to help the network, add the following lines to bitcoin.conf:
<pre>onion=127.0.0.1:9050
listen=1
externalip=ONION_ADDR
discover=1</pre>
This will allow you to accept connections both via your onion address and your IP address (if you have port 8333 forwarded), and Tor will only be used for connections to and from Tor hidden services.

If you care about anonymity, '''instead''' of the above, add the following lines to bitcoin.conf to use Tor for everything:
<pre>proxy=127.0.0.1:9050
listen=1
bind=127.0.0.1
externalip=ONION_ADDR</pre>

If you additionally want Bitcoin Core to only connect out to Tor ''hidden services'', also add this line (not particularly recommended):
<pre>onlynet=onion</pre>

Now restart Bitcoin Core. You should eventually get incoming connections via your hidden service.

=== Windows ===

First you need to '''download''' Tor, we recommend the '''Tor Expert Bundle''' (intended for developers who need to bundle tor with their applications), it contains only the tor and pluggable transports binaries, bridge strings, and geoip data. The latest version for Windows 64bits (x86_64) or Windows 32bits (i686) is located [https://www.torproject.org/download/tor/ here on torproject.org].

Then '''extract the contents on a folder''' in a place that your user can access, like ''%UserProfile%''.

On your Windows Explorer go to that folder and '''create a file called ''torrc'''''. Open it with Notepad, type the content below and save:
<pre>ControlPort 9051
CookieAuthentication 1</pre>

'''Open Windows PowerShell''' (maybe you will need to ''Open as Administrator''), navigate to the extracted folder (ex.: ''cd C:\Users\MyUserName\torExpertBundle''), and enter the folder ''Tor'' (ie.: ''cd Tor''). Type ''dir'' you should see some files and ''tor.exe'' among them. So type the code below (remember to change the folder accordingly to where you extracted)

<pre>tor.exe --service install -options -f "C:\Users\MyUserName\torExpertBundle\Tor\torrc"</pre>

If the code succeeds it will say something related to the creation of a new entry on Windows Services. Access Windows Services by pressing the Windows button and typing ''services'' then enter. You should see ''Tor Win32 Service (Provides an anonymous Internet communication system)'' on the list. Check if the status is ''Running'' and initialization type is ''Automatic''. To verify if Tor is really working as a service, open Windows PowerShell then type:
<pre>netstat -aon | findstr ":9050"</pre>

You should see something like '':9050 LISTENING'':
<pre> TCP 127.0.0.1:9050 0.0.0.0:0 LISTENING 4000</pre>

Then type:
<pre>netstat -aon | findstr ":9051"</pre>

You should see something like '':9051 LISTENING'':
<pre> TCP 127.0.0.1:9051 0.0.0.0:0 LISTENING 4000</pre>

If you don't see any ''LISTENING'' output, it means that Tor service is not working properly and this issue may be related to Windows permissions on the folder you extracted. To fix it go to where you extracted the Tor Expert Bundle and check the top folder ''Properties > Security > Advanced'' and verify if in the Permissions tab you have ''SERVICE'' with ''Full Control'', if not click ''Add'', click on the link ''Select a Secure Entity and type ''SERVICE'' (all letters in UPPERCASE) then hit enter and select ''Full Control'' (Try to start the Tor service again in Windows Services, if it doesn't work, try adding ''SYSTEM'' and ''LOCAL SERVICE'' with ''Full Control'' on folder permissions and repeat the tests above).

See BitcoinCore ''debug.log'' file what is happening on the communication with the Tor service, edit your ''bitcoin.conf'' file and add this line at the end ''debug=tor'', then restart BitcoinCore. If everything is ok, you should see something like that:
<pre>2022-06-13T21:45:32Z Config file arg: debug="tor"
2022-06-13T21:45:44Z torcontrol thread start
2022-06-13T21:45:44Z tor: Reading cached private key from C:\YourBitcoinFolder\onion_v3_private_key
2022-06-13T21:45:44Z tor: Successfully connected!
2022-06-13T21:45:44Z tor: Connected to Tor version 0.4.x.x
2022-06-13T21:45:44Z tor: Supported authentication method: COOKIE
2022-06-13T21:45:44Z tor: Supported authentication method: SAFECOOKIE
2022-06-13T21:45:44Z tor: Using SAFECOOKIE authentication, reading cookie authentication from C:\Windows\ServiceProfiles\LocalService\AppData\Roaming\tor\control_auth_cookie
2022-06-13T21:45:44Z Leaving InitialBlockDownload (latching to false)
2022-06-13T21:45:44Z tor: SAFECOOKIE authentication challenge successful
2022-06-13T21:45:44Z tor: AUTHCHALLENGE ServerHash xxxxx ServerNonce xxxxx
2022-06-13T21:45:44Z tor: Authentication successful</pre>

If you get ''tor: Authentication cookie C:\Windows\ServiceProfiles\LocalService\AppData\Roaming\tor\control_auth_cookie could not be opened (check permissions)'' on Bitcoin ''debug.log'' this means that you need to navigate to the folder ''C:\Windows\ServiceProfiles\LocalService'' and enter ''Properties > Security > Advanced'' to verify if in the Permissions tab you have ''SERVICE'' with ''Full Control'', if not click ''Add'', click on the link ''Select a Secure Entity and type ''SERVICE'' (all letters in UPPERCASE) then hit enter and select ''Full Control'' (Try to start BitcoinCore again, if it doesn't work, try adding ''SYSTEM'' and ''LOCAL SERVICE'' with ''Full Control'' on folder permissions and repeat the tests above... you may need to add ''All Application Packages'', ''NETWORK SERVICE'', ''USERS'', or other security groups, with at least "Read & execute" in order to work).

== Related Resources ==

* [https://www.keepitsimplebitcoin.com/how-to-install-tor/ KeepItSimpleBitcoin How To Install Tor (Mac OS, Linux, Windows)] - text and video instructions including Bitcoin Core config.
* [https://bitcoincoredocs.com/tor.html Bitcoin Core Docs Tor] - Explanation of the Bitcoin Core configs related to Tor.

[[Category:Guides]]
[[Category:Privacy]]

Setting up a Tor hidden service

2022-06-21T00:24:37Z

Manu: added Related Resources

If you use a Bitcoin [[full node]] over Tor, then usually it will only be able to make outgoing connections. Therefore, you will only get a maximum of 10 total connections. This is fine, and is not something you usually need to worry about, but if your computer is often online and you want to be a big help to the network, you can run a Tor hidden service in order to accept incoming connections over Tor.

Note that there is no need to forward port 8333 when using a Tor hidden service. The hidden service will cause most firewalls and NAT setups to be bypassed. For this reason, running a Tor hidden service is also a good idea if you want incoming connections but are for some reason unable to forward port 8333.

=== Prerequisites ===

These instructions are for Linux. It is possible to do on Windows, the instructions are presented at the end.

You need Tor (at least version 0.2.7.1). Figure out where your <tt>torrc</tt> file is (<tt>/etc/tor/torrc</tt> is one possibility). This guide assumes default Tor settings. This guide assumes that Tor is running under the user and group <tt>tor</tt>, which will usually be the case if you install Tor using your distro's package manager. Note that since version 22.0 Bitcoin '''does not''' support Tor hidden service version 2 (ie. short onion addresses), only support Tor version 3 hidden services (Tor v3, ie. long onion addresses).

You need Bitcoin Core (or similar). For method 1, you need at least version 0.12.0. Find <tt>bitcoin.conf</tt> in your [[data directory]].

=== Linux Method 1 (recommended) ===

This sets up an automatic hidden service that is initiated by Bitcoin Core. On the first startup of <tt>bitcoind</tt> after configuring Bitcoin Core to use Tor ControlPort as follows, Bitcoin Core will generate a file called <tt>onion_private_key</tt> in the [[data directory]]. The file <tt>onion_private_key</tt> contains the private key needed to generate your unique <tt>XXXXXXX.onion</tt> address. KEEP THIS SAFE. If someone copies this file they can run a server with your .onion address. Also, if you delete this file, the next time bitcoind loads it will generate a new key file and <tt>xxxxxxxx.onion</tt> address. Note that while a malicious party cannot necessarily associate the server with you as a person, as long as your server has the same xxxx.onion address they will know it is run by the same person. For absolute security delete <tt>onion_private_key</tt> at each reboot or some frequent interval.

Add these lines to your <tt>torrc</tt>:

<pre>ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1</pre>

You need to figure out what user bitcoind or bitcoin-qt is running as. Run the following command while Bitcoin is running:
<pre>ps -eo user,group,comm |egrep 'bitcoind|bitcoin-qt' |awk '{print "Bitcoin user: " $1}'</pre>
Write down the reported user.

Run the following command as root, which adds your Bitcoin user to the tor group. Replace BITCOIN_USER with the actual user name found above:
<pre>usermod -a -G tor BITCOIN_USER</pre>

At this point your node will work over Tor without further configuartion. Bitcoin Core v0.12 and later automatically tries to connect to Tor via the ControlPort if <tt>listen=1</tt> is set in <tt>bitcoin.conf</tt>. By default Bitcoin Core will usually connect over the regular Internet as well as allow connections to and from the Tor hidden service. This will help other users who wish to submit transactions to the bitcoin network securely and obscurely, but transactions you submit could theoretically be traced back to your ip address. If you want Bitcoin Core to only connect via Tor (for anonymity), add these lines to [[Running_Bitcoin#Bitcoin.conf_Configuration_File|bitcoin.conf]]:

<pre>proxy=127.0.0.1:9050
listen=1
bind=127.0.0.1</pre>

If you additionally want Bitcoin Core to only connect out to Tor ''hidden services'', also add this line (not particularly recommended):
<pre>onlynet=onion</pre>

Doing so will make your specific bitcoind node arguably more secure because it will never have an unencrypted connection to another node, but if everyone used <tt>onlynet=onion</tt> nobody on the onion bitcoin chain would be able to communicate with the clearnet chain. It is essential that some nodes access both clearnet and Tor. If you need to submit bitcoin transactions to the network with the highest level of obscurity, use <tt>onlynet=onion</tt>. If you only wish to give access to your node to other Tor users, do not use it.

Now restart Tor, and then Bitcoin Core. At some point during startup in <tt>~/.bitcoin/debug.log</tt> you will see
<pre>tor: Got service ID XXXXXXXXXXX, advertising service XXXXXXXXXXX.onion:8333</pre> This is the .onion address of your server. You should eventually get incoming connections via the hidden service.

=== Linux Method 2 ===

This sets up a manual hidden service controlled by the tor daemon. The hidden service address (xxxx.onion). Note that as in method 1, your xxxxx.onion address will stay the same until you delete your key file. Someone tracking you can't necessarily associate the xxxx.onion with you, but they will know it is run by the same person or entity.

Add these lines to your <tt>torrc</tt>:
<pre>HiddenServiceDir /var/lib/tor/bitcoin-service/
HiddenServicePort 8333 127.0.0.1:8333</pre>

Restart Tor. As root, run <tt>cat /var/lib/tor/bitcoin-service/hostname</tt>. Your onion address will be reported. If it didn't work, then probably your distro's version of Tor doesn't actually use <tt>/var/lib/tor</tt> for this purpose. You should try to figure out the correct HiddenServiceDir location.

In the following steps, replace ONION_ADDR with the onion address reported above.

If you don't care about anonymity and are only looking to help the network, add the following lines to bitcoin.conf:
<pre>onion=127.0.0.1:9050
listen=1
externalip=ONION_ADDR
discover=1</pre>
This will allow you to accept connections both via your onion address and your IP address (if you have port 8333 forwarded), and Tor will only be used for connections to and from Tor hidden services.

If you care about anonymity, '''instead''' of the above, add the following lines to bitcoin.conf to use Tor for everything:
<pre>proxy=127.0.0.1:9050
listen=1
bind=127.0.0.1
externalip=ONION_ADDR</pre>

If you additionally want Bitcoin Core to only connect out to Tor ''hidden services'', also add this line (not particularly recommended):
<pre>onlynet=onion</pre>

Now restart Bitcoin Core. You should eventually get incoming connections via your hidden service.

=== Windows ===

First you need to download Tor, we recommend the Windows Expert Bundle that contains just Tor and nothing else. This version, without the browser, is located [https://www.torproject.org/download/tor/ here on torproject.org].

Then extract the contents on a folder in a place that your user can access, like ''%UserProfile%''.

On your Windows Explorer go to that folder and create a file called ''torrc''. Open it with Notepad, type the content below and save the file:
<pre>ControlPort 9051
CookieAuthentication 1</pre>

Open Windows PowerShell and navigate to the extracted folder (ex.: ''cd C:\Users\MyUserName\torExpertBundle''), and access the folder ''Tor'' (ie.: ''cd Tor''). Type ''dir'' you should see some files and ''tor.exe'' among them. So type the code below (remember to change the folder accordingly to where you extracted)

<pre>tor.exe --service install -options -f "C:\Users\MyUserName\torExpertBundle\Tor\torrc"</pre>

This will create an entry at Windows Services. Access Windows Services by pressing the Windows button and typing ''services'' then enter. You should see ''Tor Win32 Service (Provides an anonymous Internet communication system)'' on the list. Check if the status is ''Running'' and initialization type is ''Automatic''. To verify if it Tor is really working as a service, open Windows PowerShell then type:
<pre>netstat -aon | findstr ":9050"</pre>

You should see '':9050 LISTENING'':
<pre> TCP 127.0.0.1:9050 0.0.0.0:0 LISTENING 4000</pre>

Then type:
<pre>netstat -aon | findstr ":9051"</pre>

You should see '':9051 LISTENING'':
<pre> TCP 127.0.0.1:9051 0.0.0.0:0 LISTENING 4000</pre>

If you don't see these then the Tor service is not working properly and this issue may be related to Windows permissions on the folder you extracted. To fix it go to where you extracted the Tor Expert Bundle and check the top folder ''Properties > Security > Advanced'' and verify if in the Permissions tab you have ''SERVICE'' with ''Full Control'', if not click ''Add'', click on the link ''Select a Secure Entity and type ''SERVICE'' (all letters in UPPERCASE) then hit enter and select ''Full Control'' (Try to start the Tor service again in Windows Services, if it doesn't work, try adding ''SYSTEM'' and ''LOCAL SERVICE'' with ''Full Control'' on folder permissions and repeat the tests above).

If you want to see on BitcoinCore ''debug.log'' file what is happening on the communication with the Tor service, edit your ''bitcoin.conf'' file and add this line at the end ''debug=tor'', then restart BitcoinCore. If everything is ok, you should see something like that:
<pre>2022-06-13T21:45:32Z Config file arg: debug="tor"
2022-06-13T21:45:44Z torcontrol thread start
2022-06-13T21:45:44Z tor: Reading cached private key from C:\YourBitcoinFolder\onion_v3_private_key
2022-06-13T21:45:44Z tor: Successfully connected!
2022-06-13T21:45:44Z tor: Connected to Tor version 0.4.x.x
2022-06-13T21:45:44Z tor: Supported authentication method: COOKIE
2022-06-13T21:45:44Z tor: Supported authentication method: SAFECOOKIE
2022-06-13T21:45:44Z tor: Using SAFECOOKIE authentication, reading cookie authentication from C:\Windows\ServiceProfiles\LocalService\AppData\Roaming\tor\control_auth_cookie
2022-06-13T21:45:44Z Leaving InitialBlockDownload (latching to false)
2022-06-13T21:45:44Z tor: SAFECOOKIE authentication challenge successful
2022-06-13T21:45:44Z tor: AUTHCHALLENGE ServerHash xxxxx ServerNonce xxxxx
2022-06-13T21:45:44Z tor: Authentication successful</pre>

== Related Resources ==

* [https://www.keepitsimplebitcoin.com/how-to-install-tor/ KeepItSimpleBitcoin How To Install Tor (Mac OS, Linux, Windows)] - text and video instructions including Bitcoin Core config.
* [https://bitcoincoredocs.com/tor.html Bitcoin Core Docs Tor] - Explanation of the Bitcoin Core configs related to Tor.

[[Category:Guides]]
[[Category:Privacy]]

Setting up a Tor hidden service

2022-06-21T00:20:09Z

Manu: Adding related resources and category

If you use a Bitcoin [[full node]] over Tor, then usually it will only be able to make outgoing connections. Therefore, you will only get a maximum of 10 total connections. This is fine, and is not something you usually need to worry about, but if your computer is often online and you want to be a big help to the network, you can run a Tor hidden service in order to accept incoming connections over Tor.

Note that there is no need to forward port 8333 when using a Tor hidden service. The hidden service will cause most firewalls and NAT setups to be bypassed. For this reason, running a Tor hidden service is also a good idea if you want incoming connections but are for some reason unable to forward port 8333.

=== Prerequisites ===

These instructions are for Linux. It is possible to do on Windows, the instructions are presented at the end.

You need Tor (at least version 0.2.7.1). Figure out where your <tt>torrc</tt> file is (<tt>/etc/tor/torrc</tt> is one possibility). This guide assumes default Tor settings. This guide assumes that Tor is running under the user and group <tt>tor</tt>, which will usually be the case if you install Tor using your distro's package manager. Note that since version 22.0 Bitcoin '''does not''' support Tor hidden service version 2 (ie. short onion addresses), only support Tor version 3 hidden services (Tor v3, ie. long onion addresses).

You need Bitcoin Core (or similar). For method 1, you need at least version 0.12.0. Find <tt>bitcoin.conf</tt> in your [[data directory]].

=== Linux Method 1 (recommended) ===

This sets up an automatic hidden service that is initiated by Bitcoin Core. On the first startup of <tt>bitcoind</tt> after configuring Bitcoin Core to use Tor ControlPort as follows, Bitcoin Core will generate a file called <tt>onion_private_key</tt> in the [[data directory]]. The file <tt>onion_private_key</tt> contains the private key needed to generate your unique <tt>XXXXXXX.onion</tt> address. KEEP THIS SAFE. If someone copies this file they can run a server with your .onion address. Also, if you delete this file, the next time bitcoind loads it will generate a new key file and <tt>xxxxxxxx.onion</tt> address. Note that while a malicious party cannot necessarily associate the server with you as a person, as long as your server has the same xxxx.onion address they will know it is run by the same person. For absolute security delete <tt>onion_private_key</tt> at each reboot or some frequent interval.

Add these lines to your <tt>torrc</tt>:

<pre>ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1</pre>

You need to figure out what user bitcoind or bitcoin-qt is running as. Run the following command while Bitcoin is running:
<pre>ps -eo user,group,comm |egrep 'bitcoind|bitcoin-qt' |awk '{print "Bitcoin user: " $1}'</pre>
Write down the reported user.

Run the following command as root, which adds your Bitcoin user to the tor group. Replace BITCOIN_USER with the actual user name found above:
<pre>usermod -a -G tor BITCOIN_USER</pre>

At this point your node will work over Tor without further configuartion. Bitcoin Core v0.12 and later automatically tries to connect to Tor via the ControlPort if <tt>listen=1</tt> is set in <tt>bitcoin.conf</tt>. By default Bitcoin Core will usually connect over the regular Internet as well as allow connections to and from the Tor hidden service. This will help other users who wish to submit transactions to the bitcoin network securely and obscurely, but transactions you submit could theoretically be traced back to your ip address. If you want Bitcoin Core to only connect via Tor (for anonymity), add these lines to [[Running_Bitcoin#Bitcoin.conf_Configuration_File|bitcoin.conf]]:

<pre>proxy=127.0.0.1:9050
listen=1
bind=127.0.0.1</pre>

If you additionally want Bitcoin Core to only connect out to Tor ''hidden services'', also add this line (not particularly recommended):
<pre>onlynet=onion</pre>

Doing so will make your specific bitcoind node arguably more secure because it will never have an unencrypted connection to another node, but if everyone used <tt>onlynet=onion</tt> nobody on the onion bitcoin chain would be able to communicate with the clearnet chain. It is essential that some nodes access both clearnet and Tor. If you need to submit bitcoin transactions to the network with the highest level of obscurity, use <tt>onlynet=onion</tt>. If you only wish to give access to your node to other Tor users, do not use it.

Now restart Tor, and then Bitcoin Core. At some point during startup in <tt>~/.bitcoin/debug.log</tt> you will see
<pre>tor: Got service ID XXXXXXXXXXX, advertising service XXXXXXXXXXX.onion:8333</pre> This is the .onion address of your server. You should eventually get incoming connections via the hidden service.

=== Linux Method 2 ===

This sets up a manual hidden service controlled by the tor daemon. The hidden service address (xxxx.onion). Note that as in method 1, your xxxxx.onion address will stay the same until you delete your key file. Someone tracking you can't necessarily associate the xxxx.onion with you, but they will know it is run by the same person or entity.

Add these lines to your <tt>torrc</tt>:
<pre>HiddenServiceDir /var/lib/tor/bitcoin-service/
HiddenServicePort 8333 127.0.0.1:8333</pre>

Restart Tor. As root, run <tt>cat /var/lib/tor/bitcoin-service/hostname</tt>. Your onion address will be reported. If it didn't work, then probably your distro's version of Tor doesn't actually use <tt>/var/lib/tor</tt> for this purpose. You should try to figure out the correct HiddenServiceDir location.

In the following steps, replace ONION_ADDR with the onion address reported above.

If you don't care about anonymity and are only looking to help the network, add the following lines to bitcoin.conf:
<pre>onion=127.0.0.1:9050
listen=1
externalip=ONION_ADDR
discover=1</pre>
This will allow you to accept connections both via your onion address and your IP address (if you have port 8333 forwarded), and Tor will only be used for connections to and from Tor hidden services.

If you care about anonymity, '''instead''' of the above, add the following lines to bitcoin.conf to use Tor for everything:
<pre>proxy=127.0.0.1:9050
listen=1
bind=127.0.0.1
externalip=ONION_ADDR</pre>

If you additionally want Bitcoin Core to only connect out to Tor ''hidden services'', also add this line (not particularly recommended):
<pre>onlynet=onion</pre>

Now restart Bitcoin Core. You should eventually get incoming connections via your hidden service.

=== Windows ===

First you need to download Tor, we recommend the Windows Expert Bundle that contains just Tor and nothing else. This version, without the browser, is located [https://www.torproject.org/download/tor/ here on torproject.org].

Then extract the contents on a folder in a place that your user can access, like ''%UserProfile%''.

On your Windows Explorer go to that folder and create a file called ''torrc''. Open it with Notepad, type the content below and save the file:
<pre>ControlPort 9051
CookieAuthentication 1</pre>

Open Windows PowerShell and navigate to the extracted folder (ex.: ''cd C:\Users\MyUserName\torExpertBundle''), and access the folder ''Tor'' (ie.: ''cd Tor''). Type ''dir'' you should see some files and ''tor.exe'' among them. So type the code below (remember to change the folder accordingly to where you extracted)

<pre>tor.exe --service install -options -f "C:\Users\MyUserName\torExpertBundle\Tor\torrc"</pre>

This will create an entry at Windows Services. Access Windows Services by pressing the Windows button and typing ''services'' then enter. You should see ''Tor Win32 Service (Provides an anonymous Internet communication system)'' on the list. Check if the status is ''Running'' and initialization type is ''Automatic''. To verify if it Tor is really working as a service, open Windows PowerShell then type:
<pre>netstat -aon | findstr ":9050"</pre>

You should see '':9050 LISTENING'':
<pre> TCP 127.0.0.1:9050 0.0.0.0:0 LISTENING 4000</pre>

Then type:
<pre>netstat -aon | findstr ":9051"</pre>

You should see '':9051 LISTENING'':
<pre> TCP 127.0.0.1:9051 0.0.0.0:0 LISTENING 4000</pre>

If you don't see these then the Tor service is not working properly and this issue may be related to Windows permissions on the folder you extracted. To fix it go to where you extracted the Tor Expert Bundle and check the top folder ''Properties > Security > Advanced'' and verify if in the Permissions tab you have ''SERVICE'' with ''Full Control'', if not click ''Add'', click on the link ''Select a Secure Entity and type ''SERVICE'' (all letters in UPPERCASE) then hit enter and select ''Full Control'' (Try to start the Tor service again in Windows Services, if it doesn't work, try adding ''SYSTEM'' and ''LOCAL SERVICE'' with ''Full Control'' on folder permissions and repeat the tests above).

If you want to see on BitcoinCore ''debug.log'' file what is happening on the communication with the Tor service, edit your ''bitcoin.conf'' file and add this line at the end ''debug=tor'', then restart BitcoinCore. If everything is ok, you should see something like that:
<pre>2022-06-13T21:45:32Z Config file arg: debug="tor"
2022-06-13T21:45:44Z torcontrol thread start
2022-06-13T21:45:44Z tor: Reading cached private key from C:\YourBitcoinFolder\onion_v3_private_key
2022-06-13T21:45:44Z tor: Successfully connected!
2022-06-13T21:45:44Z tor: Connected to Tor version 0.4.x.x
2022-06-13T21:45:44Z tor: Supported authentication method: COOKIE
2022-06-13T21:45:44Z tor: Supported authentication method: SAFECOOKIE
2022-06-13T21:45:44Z tor: Using SAFECOOKIE authentication, reading cookie authentication from C:\Windows\ServiceProfiles\LocalService\AppData\Roaming\tor\control_auth_cookie
2022-06-13T21:45:44Z Leaving InitialBlockDownload (latching to false)
2022-06-13T21:45:44Z tor: SAFECOOKIE authentication challenge successful
2022-06-13T21:45:44Z tor: AUTHCHALLENGE ServerHash xxxxx ServerNonce xxxxx
2022-06-13T21:45:44Z tor: Authentication successful</pre>

== Related Resources ==

* [https://www.keepitsimplebitcoin.com/how-to-install-tor/ KeepItSimpleBitcoin How To Install Tor (Mac OS, Linux, Windows)] - text and video instructions including Bitcoin Core config.

[[Category:Guides]]
[[Category:Privacy]]

Electrum

2022-06-19T21:28:11Z

Manu: /* Windows */

[[Image:Electrum_logo.png|400px]][[Image:Capture-Electrum404.jpg|thumb|500px|Electrum 4.0.4 on Windows 7 with showing zero balance and a connected state]]

[https://electrum.org Electrum] is a lightweight Bitcoin client, based on a client-server protocol.
It was released on 5 November 2011.

== Main features ==
* Encrypted wallet: the file that contains bitcoin [[private keys]] is protected with a password, and never leaves the user's computer.
* Deterministic key generation: If you lose your wallet file, you can recover it from its [[seed phrase|seed]]. You are protected from your own mistakes. (Note that Electrum's seed phrase is not according to the BIP39 standard.)
* Instant on: by default the client does not download the blockchain, it requests that information from a server. No delays, always up-to-date.
* Transactions are signed locally: Your private keys are not shared with the server. You do not have to trust the server with your money.
* [[Cold storage]]: Keeping private keys offline is supported. Has a watch-only mode for online use.
* [[Multi-signature]]: Dividing the power to spend coins between multiple wallets is supported.
* [[Hardware wallet]] integration: Many leading hardware wallets can interface with Electrum, including [[Coldcard]], [[Trezor]] and [[Ledger]].
* Redundancy: You are not tied to a particular server, and the server does not need to know you. One server going down doesn't cause user downtimes.
* No single point of failure: The server code is open source, anyone can run a server. Private keys can be exported and imported into other wallets.
* Firewall friendly: The client does not need to open a port, it simply polls the server for updates.
* Free software: MIT License. Anyone can audit the code.
* Written in Python. The code is short, and easy to review.
* Add-ons: third-party plugins are supported.
* Support for Bitcoin URIs, signed URIs and Bitcoin aliases

__TOC__

== Verifying Electrum Binaries ==

Electrum binaries can be downloaded from https://electrum.org/#download. Next to each download link there is also a signature file which can be downloaded. The signature files are for independently verifying the Electrum files were not tampered with. This step should not be overlooked as users have reported malicious funds-stealing builds of Electeum existing in the wild.

To verify the Electrm binaries using the signatures, you need to have GPG installed. Listed below is the process for each operating system. For all operating systems, you must have Electrum's signing key downloaded to verify the Electrum binaries. This can be downloaded from https://raw.githubusercontent.com/spesmilo/electrum/master/pubkeys/ThomasV.asc.

=== Windows ===

Windows 10 has "Ubuntu on Windows" and allows you ton follow the Linux instructions [[#Linux|below]]

On Windows, you should install GPG4Win from this location: https://gpg4win.org/download.html. Once you run the installer, you will be presented with a "components choosing dialog like this:

[[File:GPG4Win-Install.png]]

Leave the boxes ticked at their defaults and go to the next step of the installer. When the installation is finished, go to the Windows Start Menu and look for a program named "Kleopatra", and launch it. If you see the following window then GPG4Win has been successfully installed.

[[File:GPG4Win-Kleopatra.png]]

Click on the Import button, and navigate to the location you saved the Electrum signing key in (you may have to change the Filter at the bottom right to "All Files" to see the key). Then Kleopatra will give you a message requesting to certify the key:

[[File:GPG4Win-Certify.png]]

Click yes, and then tick all of the email addresses in the next window to finish the process.

[[File:GPG4Win-Email.png]]

After you close the window by clicking the Certify button, click on the Decrypt/Verify button on the main window, and select the signature corresponding to the Electrum binary you have downloaded. If verification is successful, you will get the following window. Otherwise, the signature doesn't match the binary, and you need to download both of them again, and check the URL of the site you are downloading from.

[[File:GPG4Win-Verify.png|none|frame|The Kleopatra message when signature verification succeeds.]]

[[File:GPG4Win-VerifyFail.png|none|frame|The Kleopatra error message when signature verification fails.]]

=== MacOS ===

On MacOS, you should use the GPG tools suite from GPGTools: https://gpgtools.org/. Download the .dmg file, double click on it and drag its contents to the Applications folder that appears to start the installation.

Inside the installer, click on the Customize button, and uncheck the boxes for the Mail clients. They are not necessary to verify signatures, and are trialware.

[[File:GPGTools-Customize.png]][[File:GPGTools-Mail.png]]

After the installer is finished, GPG Keychain should open automatically. If not, then open Finder and navigate to the Applications folder to open it yourself. You will be presented with this dialog:

[[File:GPGTools-NewKey.png]]

GPG Keychain needs to create a keypair to certify other public keys. Choose a name, email address and password that you will remember. Leave the rest of the options at their default and click on Generate Key.

In the main window that appears, click on the Import button to import the Electrum signing key you downloaded.

[[File:GPGTools-MainWindow.png]]

Once it has been imported, double-click on the key to open its properties, and set its trust level to Full.

[[File:GPGTools-Properties.png]]

Then, you can just double click inside Finder on the Electrum signature for the corresponding binary to start GPG Keychain verification which will inform you about the result and whether the signature and binary are good or not.

[[File:GPGTools-Verify.png|none|frame|The GPG Keychain message when signature verification succeeds.]]

[[File:GPGTools-VerifyFail.png|none|frame|The GPG Keychain error message when signature verification fails.]]

=== Linux ===

On Linux, the <code>gpg</code> command line program is preinstalled in most distributions. If for some reason it's not, look for a package called "gnupg", "gpg" or "gpg2" in your package manager.

Once that's done with, you run the following GPG commands to import and trust the key which Electrum binaries are signed with, and the signature files are made from:

<code>gpg --import /<path>/<to>/<file>/<location>/ThomasV.asc</code>

[[File:GPG-Import.png]]

<code>gpg --sign-key 6694D8DE7BE8EE5631BED9502BD5824B7F9470E6</code>

Then you download the Electrum program and its signature to the same folder, and check its authenticity with the following GPG command:

<code>gpg --verify /<path>/<to>/<file>/<location>/<filename>.asc</code>

This is the path to the signature file you downloaded. If verification succeeds, you will get output indicating that the verification was successful.

[[File:GPG-Verify.png|none|frame|The GPG message when signature verification succeeds.]]

[[File:GPG-Verify.png|none|frame|The GPG message when signature verification fails.]]

==Documentation==

Documentation is hosted on http://docs.electrum.org/.

It includes tutorials for the multi-signature, cold storage and hardware wallet features.

==History==

Electrum was announced 5 November 2011.<ref>[http://bitcointalk.org/index.php?topic=50936.0 Electrum - a new thin client]</ref>. It has since gone through many changes in each version.

[[Image:Capture-Electrum.png|thumb|500px|An early version of Electrum with its Qt GUI]]

Version 1.7 added support for third-party plugins.

Version 2.0 introduced support for the [[Trezor]] hardware wallet, TrustedCoin 2FA, [[multisig]] wallets and changed the way the wallet files are stored by using [[BIP_0032|BIP32]] derivation. These wallets are incompatible with older versions.

Version 2.4.3 added support for the [[Hardware_wallet#KeepKey:_Your_Private_Bitcoin_Vault|KeepKey]] hardware wallet.

Version 2.6 introduced the new Kivy GUI for the Android client.

Version 2.7 added a fee slider, [[RBF]] functionality and support for [[Hardware_wallet#Ledger_Nano_S|Ledger Nano S]]. The wallet format has also been changed, making them incompatible with older versions.

Version 3.0 introduced a new server protocol and support for generating [[Segwit]] wallets.

On December 27, 2018, an advisory was published<ref>[https://bitcointalk.org/index.php?topic=5090097.0 Electrum vulnerability allows arbitrary messages, phishing]</ref> about a phishing vulnerability where the server returns a a fake update message after a transaction is broadcasted, with a link to a phishing domain with a malicious Electrum binary. Users who ran the malicious binary reported theft of all bitcoin funds. A mitigation was applied in version 3.2.1 which renders the rich-text message in plain-text, making it less convincing.

Version 4.0.0 introduced support for [[Lightning Network]] wallets.

== Server software ==

The server code is open source, anyone can run a server. There are several implementations.

Public Electrum servers run by strangers can easily spy on Electrum users. For this reason many people run their own server. For maximum [[Full node#Why should you use a full node wallet|trustlessness, privacy and security]]; users should point Electrum to their own servers.

=== bwt ===

'''bwt''' is a lightweight and performant HD wallet indexer backed by a bitcoin full node that [https://github.com/shesek/bwt#electrum-plugin can also be installed as an Electrum plugin].

=== ElectrumX ===

ElectrumX is the latest iteration of general purpose Electrum servers. Written in Python, it tries to be as efficient as possible to keep synchronization times low. ElectrumX is able to serve thousands of clients at once, it is suited to be an always-on server that contributes to bitcoin. Make sure that the version of ElectrumX you download supports Bitcoin. As of May 2020 some versions of ElectrumX only support [[altcoin]]s.

GitHub: https://github.com/spesmilo/electrumx



=== Electrum Personal Server ===

Electrum Personal Server has a different approach to a normal server. It is intended to be used by a single person only. Instead of creating a database of every transaction and address ever used on the bitcoin blockchain, Electrum Personal Server only tracks the user's own wallets. This allows it to be much more efficient with resources, it does not need any extra data files and is compatible with [[Bitcoin Core]]'s pruning feature.

Electrum Personal Server is probably the best way to combine Electrum's feature-richness (hardware wallet integration, multi-signature, [[seed phrase]], etc) with a [[full node]]'s strong security and privacy.

GitHub: https://github.com/chris-belcher/electrum-personal-server

==See also==

* [[Thin Client Security]]
* [[Hardware wallet]]
* [[Seed phrase]]
* [[Multi-signature]]
* [[Cold storage]]

==External Links==

* [http://electrum.org/ Electrum] project website
* [https://github.com/spesmilo/electrum/ Electrum] project source

==References==
<references />

[[Category:Clients]]
[[Category:Open Source]]

BIP 0174

2022-06-19T21:23:22Z

Manu: Removed broken <tt> html tag

{{bip}}
{{BipMoved|bip-0174.mediawiki}}

<pre>
BIP: 174
Layer: Applications
Title: Partially Signed Bitcoin Transaction Format
Author: Andrew Chow <achow101@gmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0174
Status: Final
Type: Standards Track
Created: 2017-07-12
License: BSD-2-Clause
</pre>

==Introduction==

===Abstract===

This document proposes a binary transaction format which contains the information
necessary for a signer to produce signatures for the transaction and holds the
signatures for an input while the input does not have a complete set of signatures.
The signer can be offline as all necessary information will be provided in the
transaction.

The generic format is described here in addition to the specification for version 0
of this format.

===Copyright===

This BIP is licensed under the 2-clause BSD license.

===Motivation===

Creating unsigned or partially signed transactions to be passed around to multiple
signers is currently implementation dependent, making it hard for people who use
different wallet software from being able to easily do so. One of the goals of this
document is to create a standard and extensible format that can be used between clients to allow
people to pass around the same transaction to sign and combine their signatures. The
format is also designed to be easily extended for future use which is harder to do
with existing transaction formats.

Signing transactions also requires users to have access to the UTXOs being spent. This transaction
format will allow offline signers such as air-gapped wallets and hardware wallets
to be able to sign transactions without needing direct access to the UTXO set and without
risk of being defrauded.

==Specification==

The Partially Signed Bitcoin Transaction (PSBT) format consists of key-value maps.
Each map consists of a sequence of key-value records, terminated by a 0x00 byte <ref>'''Why
is the separator here 0x00 instead of 0xff?'''
The separator here is used to distinguish between each chunk of data. A separator of 0x00 would mean that
the unserializer can read it as a key length of 0, which would never occur with actual keys. It can thus
be used as a separator and allow for easier unserializer implementation.</ref>.

<psbt> := <magic> <global-map> <input-map>* <output-map>*
<magic> := 0x70 0x73 0x62 0x74 0xFF
<global-map> := <keypair>* 0x00
<input-map> := <keypair>* 0x00
<output-map> := <keypair>* 0x00
<keypair> := <key> <value>
<key> := <keylen> <keytype> <keydata>
<value> := <valuelen> <valuedata>

Where:

;<keytype>
: A [https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer compact size] unsigned integer representing the type. This compact size unsigned integer must be minimally encoded, i.e. if the value can be represented using one byte, it must be represented as one byte. There can be multiple entries with the same <keytype> within a specific <map>, but the <key> must be unique.
;<keylen>
: The compact size unsigned integer containing the combined length of <keytype> and <keydata>
;<valuelen>
: The compact size unsigned integer containing the length of <valuedata>.
;<magic>
: Magic bytes which are ASCII for psbt <ref>'''Why use 4 bytes for psbt?''' The
transaction format needed to start with a 5 byte header which uniquely identifies
it. The first bytes were chosen to be the ASCII for psbt because that stands for
Partially Signed Bitcoin Transaction. </ref> followed by a separator of 0xFF<ref>'''Why Use a separator after the magic bytes?''' The separator
is part of the 5 byte header for PSBT. This byte is a separator of 0xff because
this will cause any non-PSBT unserializer to fail to properly unserialize the PSBT
as a normal transaction. Likewise, since the 5 byte header is fixed, no transaction
in the non-PSBT format will be able to be unserialized by a PSBT unserializer.</ref>. This integer must be serialized in most significant byte order.

The currently defined global types are as follows:

{|
! Name
! <keytype>
! <keydata>
! <keydata> Description
! <valuedata>
! <valuedata> Description
! Versions Requiring Inclusion
! Versions Requiring Exclusion
! Versions Allowing Inclusion
! Parent BIP
|-
| Unsigned Transaction
| PSBT_GLOBAL_UNSIGNED_TX = 0x00
| None
| No key data
| <transaction>
| The transaction in network serialization. The scriptSigs and witnesses for each input must be empty. The transaction must be in the old serialization format (without witnesses).
| 0
| 2
| 0
| 174
|-
| Extended Public Key
| PSBT_GLOBAL_XPUB = 0x01
| <xpub>
| The 78 byte serialized extended public key as defined by BIP 32. Extended public keys are those that can be used to derive public keys used in the inputs and outputs of this transaction. It should be the public key at the highest hardened derivation index so that the unhardened child keys used in the transaction can be derived.
| <32-bit uint> <32-bit uint>*
| The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32-bit little endian unsigned integer indexes concatenated with each other. The number of 32 bit unsigned integer indexes must match the depth provided in the extended public key.
|
|
| 0, 2
| 174
|-
| Transaction Version
| PSBT_GLOBAL_TX_VERSION = 0x02
| None
| No key data
| <32-bit uint>
| The 32-bit little endian signed integer representing the version number of the transaction being created. Note that this is not the same as the PSBT version number specified by the PSBT_GLOBAL_VERSION field.
| 2
| 0
| 2
| [[bip-0370.mediawiki|370]]
|-
| Fallback Locktime
| PSBT_GLOBAL_FALLBACK_LOCKTIME = 0x03
| None
| No key data
| <32-bit uint>
| The 32-bit little endian unsigned integer representing the transaction locktime to use if no inputs specify a required locktime.
|
| 0
| 2
| [[bip-0370.mediawiki|370]]
|-
| Input Count
| PSBT_GLOBAL_INPUT_COUNT = 0x04
| None
| No key data
| <compact size uint>
| Compact size unsigned integer representing the number of inputs in this PSBT.
| 2
| 0
| 2
| [[bip-0370.mediawiki|370]]
|-
| Output Count
| PSBT_GLOBAL_OUTPUT_COUNT = 0x05
| None
| No key data
| <compact size uint>
| Compact size unsigned integer representing the number of outputs in this PSBT.
| 2
| 0
| 2
| [[bip-0370.mediawiki|370]]
|-
| Transaction Modifiable Flags
| PSBT_GLOBAL_TX_MODIFIABLE = 0x06
| None
| No key data
| <8-bit uint>
| An 8 bit little endian unsigned integer as a bitfield for various transaction modification flags. Bit 0 is the Inputs Modifiable Flag and indicates whether inputs can be modified. Bit 1 is the Outputs Modifiable Flag and indicates whether outputs can be modified. Bit 2 is the Has SIGHASH_SINGLE flag and indicates whether the transaction has a SIGHASH_SINGLE signature who's input and output pairing must be preserved. Bit 2 essentially indicates that the Constructor must iterate the inputs to determine whether and how to add an input.
|
| 0
| 2
| [[bip-0370.mediawiki|370]]
|-
| PSBT Version Number
| PSBT_GLOBAL_VERSION = 0xFB
| None
| No key data
| <32-bit uint>
| The 32-bit little endian unsigned integer representing the version number of this PSBT. If omitted, the version number is 0.
|
|
| 0, 2
| 174
|-
| Proprietary Use Type
| PSBT_GLOBAL_PROPRIETARY = 0xFC
| <identifierlen> <identifier> <subtype> <subkeydata>
| Compact size unsigned integer <identifierlen>, followed by identifier prefix of that length <identifer>, followed by a subtype <subtype>, followed by the key data itself <subkeydata>.
| <data>
| Any value data as defined by the proprietary type user.
|
|
| 0, 2
| 174
|}

The currently defined per-input types are defined as follows:

{|
! Name
! <keytype>
! <keydata>
! <keydata> Description
! <valuedata>
! <valuedata> Description
! Versions Requiring Inclusion
! Versions Requiring Exclusion
! Versions Allowing Inclusion
! Parent BIP
|-
| Non-Witness UTXO
| PSBT_IN_NON_WITNESS_UTXO = 0x00
| None
| No key data
| <transaction>
| The transaction in network serialization format the current input spends from. This should be present for inputs that spend non-segwit outputs and can be present for inputs that spend segwit outputs. An input can have both PSBT_IN_NON_WITNESS_UTXO and PSBT_IN_WITNESS_UTXO. <ref>'''Why can both UTXO types be provided?''' Many wallets began requiring the full previous transaction (i.e. PSBT_IN_NON_WITNESS_UTXO) for segwit inputs when PSBT was already in use. In order to be compatible with software which were expecting PSBT_IN_WITNESS_UTXO, both UTXO types must be allowed.</ref>
|
|
| 0, 2
| 174
|-
| Witness UTXO
| PSBT_IN_WITNESS_UTXO = 0x01
| None
| No key data
| <64-bit int> <scriptPubKeylen> <scriptPubKey>
| The entire transaction output in network serialization which the current input spends from. This should only be present for inputs which spend segwit outputs, including P2SH embedded ones. An input can have both PSBT_IN_NON_WITNESS_UTXO and PSBT_IN_WITNESS_UTXO
|
|
| 0, 2
| 174
|-
| Partial Signature
| PSBT_IN_PARTIAL_SIG = 0x02
| <pubkey>
| The public key which corresponds to this signature.
| <signature>
| The signature as would be pushed to the stack from a scriptSig or witness. The signature should be a valid ECDSA signature corresponding to the pubkey that would return true when verified and not a value that would return false or be invalid otherwise (such as a NULLDUMMY).
|
|
| 0, 2
| 174
|-
| Sighash Type
| PSBT_IN_SIGHASH_TYPE = 0x03
| None
| No key data
| <32-bit uint>
| The 32-bit unsigned integer specifying the sighash type to be used for this input. Signatures for this input must use the sighash type, finalizers must fail to finalize inputs which have signatures that do not match the specified sighash type. Signers who cannot produce signatures with the sighash type must not provide a signature.
|
|
| 0, 2
| 174
|-
| Redeem Script
| PSBT_IN_REDEEM_SCRIPT = 0x04
| None
| No key data
| <redeemScript>
| The redeemScript for this input if it has one.
|
|
| 0, 2
| 174
|-
| Witness Script
| PSBT_IN_WITNESS_SCRIPT = 0x05
| None
| No key data
| <witnessScript>
| The witnessScript for this input if it has one.
|
|
| 0, 2
| 174
|-
| BIP 32 Derivation Path
| PSBT_IN_BIP32_DERIVATION = 0x06
| <pubkey>
| The public key
| <32-bit uint> <32-bit uint>*
| The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32 bit unsigned integer indexes concatenated with each other. Public keys are those that will be needed to sign this input.
|
|
| 0, 2
| 174
|-
| Finalized scriptSig
| PSBT_IN_FINAL_SCRIPTSIG = 0x07
| None
| No key data
| <scriptSig>
| The Finalized scriptSig contains a fully constructed scriptSig with signatures and any other scripts necessary for the input to pass validation.
|
|
| 0, 2
| 174
|-
| Finalized scriptWitness
| PSBT_IN_FINAL_SCRIPTWITNESS = 0x08
| None
| No key data
| <scriptWitness>
| The Finalized scriptWitness contains a fully constructed scriptWitness with signatures and any other scripts necessary for the input to pass validation.
|
|
| 0, 2
| 174
|-
| Proof-of-reserves commitment
| PSBT_IN_POR_COMMITMENT = 0x09
| None
| No key data
| <porCommitment>
| The UTF-8 encoded commitment message string for the proof-of-reserves. See [[bip-0127.mediawiki|BIP 127]] for more information.
|
|
| 0, 2
| [[bip-0127.mediawiki|127]]
|-
| RIPEMD160 preimage
| PSBT_IN_RIPEMD160 = 0x0a
| <20-byte hash>
| The resulting hash of the preimage
| <preimage>
| The hash preimage, encoded as a byte vector, which must equal the key when run through the RIPEMD160 algorithm
|
|
| 0, 2
| 174
|-
| SHA256 preimage
| PSBT_IN_SHA256 = 0x0b
| <32-byte hash>
| The resulting hash of the preimage
| <preimage>
| The hash preimage, encoded as a byte vector, which must equal the key when run through the SHA256 algorithm
|
|
| 0, 2
| 174
|-
| HASH160 preimage
| PSBT_IN_HASH160 = 0x0c
| <20-byte hash>
| The resulting hash of the preimage
| <preimage>
| The hash preimage, encoded as a byte vector, which must equal the key when run through the SHA256 algorithm followed by the RIPEMD160 algorithm
|
|
| 0, 2
| 174
|-
| HASH256 preimage
| PSBT_IN_HASH256 = 0x0d
| <32-byte hash>
| The resulting hash of the preimage
| <preimage>
| The hash preimage, encoded as a byte vector, which must equal the key when run through the SHA256 algorithm twice
|
|
| 0, 2
| 174
|-
| Previous TXID
| PSBT_IN_PREVIOUS_TXID = 0x0e
| None
| No key data
| <txid>
| 32 byte txid of the previous transaction whose output at PSBT_IN_OUTPUT_INDEX is being spent.
| 2
| 0
| 2
| [[bip-0370.mediawiki|370]]
|-
| Spent Output Index
| PSBT_IN_OUTPUT_INDEX = 0x0f
| None
| No key data
| <32-bit uint>
| 32 bit little endian integer representing the index of the output being spent in the transaction with the txid of PSBT_IN_PREVIOUS_TXID.
| 2
| 0
| 2
| [[bip-0370.mediawiki|370]]
|-
| Sequence Number
| PSBT_IN_SEQUENCE = 0x10
| None
| No key data
| <32-bit uint>
| The 32 bit unsigned little endian integer for the sequence number of this input. If omitted, the sequence number is assumed to be the final sequence number (0xffffffff).
|
| 0
| 2
| [[bip-0370.mediawiki|370]]
|-
| Required Time-based Locktime
| PSBT_IN_REQUIRED_TIME_LOCKTIME = 0x11
| None
| No key data
| <32-bit uint>
| 32 bit unsigned little endian integer greater than or equal to 500000000 representing the minimum Unix timestamp that this input requires to be set as the transaction's lock time.
|
| 0
| 2
| [[bip-0370.mediawiki|370]]
|-
| Required Height-based Locktime
| PSBT_IN_REQUIRED_HEIGHT_LOCKTIME = 0x12
| None
| No key data
| <32-bit uiht>
| 32 bit unsigned little endian integer less than 500000000 representing the minimum block height that this input requires to be set as the transaction's lock time.
|
| 0
| 2
| [[bip-0370.mediawiki|370]]
|-
| Taproot Key Spend Signature
| PSBT_IN_TAP_KEY_SIG = 0x13
| None
| No key data
| <signature>
| The 64 or 65 byte Schnorr signature for key path spending a Taproot output. Finalizers should remove this field after PSBT_IN_FINAL_SCRIPTWITNESS is constructed.
|
|
| 0, 2
| [[bip-0371.mediawiki|371]]
|-
| Taproot Script Spend Signature
| PSBT_IN_TAP_SCRIPT_SIG = 0x14
| <xonlypubkey> <leafhash>
| A 32 byte X-only public key involved in a leaf script concatenated with the 32 byte hash of the leaf it is part of.
| <signature>
| The 64 or 65 byte Schnorr signature for this pubkey and leaf combination. Finalizers should remove this field after PSBT_IN_FINAL_SCRIPTWITNESS is constructed.
|
|
| 0, 2
| [[bip-0371.mediawiki|371]]
|-
| Taproot Leaf Script
| PSBT_IN_TAP_LEAF_SCRIPT = 0x15
| <control block>
| The control block for this leaf as specified in BIP 341. The control block contains the merkle tree path to this leaf.
| <script> <8-bit uint>
| The script for this leaf as would be provided in the witness stack followed by the single byte leaf version. Note that the leaves included in this field should be those that the signers of this input are expected to be able to sign for. Finalizers should remove this field after PSBT_IN_FINAL_SCRIPTWITNESS is constructed.
|
|
| 0, 2
| [[bip-0371.mediawiki|371]]
|-
| Taproot Key BIP 32 Derivation Path
| PSBT_IN_TAP_BIP32_DERIVATION = 0x16
| <xonlypubkey>
| A 32 byte X-only public key involved in this input. It may be the internal key, or a key present in a leaf script.
| <hashes len> <leaf hash>* <4 byte fingerprint> <32-bit uint>*
| A compact size unsigned integer representing the number of leaf hashes, followed by a list of leaf hashes, followed by the 4 byte master key fingerprint concatenated with the derivation path of the public key. The derivation path is represented as 32-bit little endian unsigned integer indexes concatenated with each other. Public keys are those needed to spend this output. The leaf hashes are of the leaves which involve this public key. The internal key does not have leaf hashes, so can be indicated with a hashes len of 0. Finalizers should remove this field after PSBT_IN_FINAL_SCRIPTWITNESS is constructed.
|
|
| 0, 2
| [[bip-0371.mediawiki|371]]
|-
| Taproot Internal Key
| PSBT_IN_TAP_INTERNAL_KEY = 0x17
| None
| No key data
| <xonlypubkey>
| The X-only pubkey used as the internal key in this output. Finalizers should remove this field after PSBT_IN_FINAL_SCRIPTWITNESS is constructed.
|
|
| 0, 2
| [[bip-0371.mediawiki|371]]
|-
| Taproot Merkle Root
| PSBT_IN_TAP_MERKLE_ROOT = 0x18
| None
| No key data
| <32-byte hash>
| The 32 byte Merkle root hash. Finalizers should remove this field after PSBT_IN_FINAL_SCRIPTWITNESS is constructed.
|
|
| 0, 2
| [[bip-0371.mediawiki|371]]
|-
| Proprietary Use Type
| PSBT_IN_PROPRIETARY = 0xFC
| <identifierlen> <identifier> <subtype> <subkeydata>
| Compact size unsigned integer <identifierlen>, followed by identifier prefix of that length <identifer>, followed by a subtype <subtype>, followed by the key data itself <subkeydata>.
| <data>
| Any value data as defined by the proprietary type user.
|
|
| 0, 2
| 174
|}

The currently defined per-output <ref>'''Why do we need per-output data?''' Per-output data allows signers
to verify that the outputs are going to the intended recipient. The output data can also be use by signers to
determine which outputs are change outputs and verify that the change is returning to the correct place.</ref> types are defined as follows:

{|
! Name
! <keytype>
! <keydata>
! <keydata> Description
! <valuedata>
! <valuedata> Description
! Versions Requiring Inclusion
! Versions Requiring Exclusion
! Versions Allowing Inclusion
! Parent BIP
|-
| Redeem Script
| PSBT_OUT_REDEEM_SCRIPT = 0x00
| None
| No key data
| <redeemScript>
| The redeemScript for this output if it has one.
|
|
| 0, 2
| 174
|-
| Witness Script
| PSBT_OUT_WITNESS_SCRIPT = 0x01
| None
| No key data
| <witnessScript>
| The witnessScript for this output if it has one.
|
|
| 0, 2
| 174
|-
| BIP 32 Derivation Path
| PSBT_OUT_BIP32_DERIVATION = 0x02
| <public key>
| The public key
| <32-bit uint> <32-bit uint>*
| The master key fingerprint concatenated with the derivation path of the public key. The derivation path is represented as 32-bit little endian unsigned integer indexes concatenated with each other. Public keys are those needed to spend this output.
|
|
| 0, 2
| 174
|-
| Output Amount
| PSBT_OUT_AMOUNT = 0x03
| None
| No key data
| <64-bit int>
| 64 bit signed little endian integer representing the output's amount in satoshis.
| 2
| 0
| 2
| [[bip-0370.mediawiki|370]]
|-
| Output Script
| PSBT_OUT_SCRIPT = 0x04
| None
| No key data
| <script>
| The script for this output, also known as the scriptPubKey. Must be omitted in PSBTv0. Must be provided in PSBTv2.
| 2
| 0
| 2
| [[bip-0370.mediawiki|370]]
|-
| Taproot Internal Key
| PSBT_OUT_TAP_INTERNAL_KEY = 0x05
| None
| No key data
| <xonlypubkey>
| The X-only pubkey used as the internal key in this output.
|
|
| 0, 2
| [[bip-0371.mediawiki|371]]
|-
| Taproot Tree
| PSBT_OUT_TAP_TREE = 0x06
| None
| No key data
| {<8-bit uint depth> <8-bit uint leaf version> <scriptlen> <script>}*
| One or more tuples representing the depth, leaf version, and script for a leaf in the Taproot tree, allowing the entire tree to be reconstructed. The tuples must be in depth first search order so that the tree is correctly reconstructed. Each tuple is an 8-bit unsigned integer representing the depth in the Taproot tree for this script, an 8-bit unsigned integer representing the leaf version, the length of the script as a compact size unsigned integer, and the script itself.
|
|
| 0, 2
| [[bip-0371.mediawiki|371]]
|-
| Taproot Key BIP 32 Derivation Path
| PSBT_OUT_TAP_BIP32_DERIVATION = 0x07
| <xonlypubkey>
| A 32 byte X-only public key involved in this output. It may be the internal key, or a key present in a leaf script.
| <hashes len> <leaf hash>* <4 byte fingerprint> <32-bit uint>*
| A compact size unsigned integer representing the number of leaf hashes, followed by a list of leaf hashes, followed by the 4 byte master key fingerprint concatenated with the derivation path of the public key. The derivation path is represented as 32-bit little endian unsigned integer indexes concatenated with each other. Public keys are those needed to spend this output. The leaf hashes are of the leaves which involve this public key. The internal key does not have leaf hashes, so can be indicated with a hashes len of 0. Finalizers should remove this field after PSBT_IN_FINAL_SCRIPTWITNESS is constructed.
|
|
| 0, 2
| [[bip-0371.mediawiki|371]]
|-
| Proprietary Use Type
| PSBT_OUT_PROPRIETARY = 0xFC
| <identifierlen> <identifier> <subtype> <subkeydata>
| Compact size unsigned integer <identifierlen>, followed by identifier prefix of that length <identifer>, followed by a subtype <subtype>, followed by the key data itself <subkeydata>.
| <data>
| Any value data as defined by the proprietary type user.
|
|
| 0, 2
| 174
|}

Types can be skipped when they are unnecessary. For example, if an input is a witness
input, then it should not have a Non-Witness UTXO key-value pair.

If the signer encounters key-value pairs that it does not understand, it must
pass those key-value pairs through when re-serializing the transaction.

All keys must have the data that they specify. If any key or value does not match the
specified format for that type, the PSBT must be considered invalid. For example, any
key that has no data except for the type specifier must only have the type specifier in
the key.

===Handling Duplicated Keys===

Keys within each scope should never be duplicated; all keys in the format are unique. PSBTs containing duplicate keys are invalid. However implementors
will still need to handle events where keys are duplicated when combining transactions with duplicated fields. In this event, the software may choose
whichever value it wishes.<ref>'''Why can the values be arbitrarily chosen?''' When there are duplicated keys, the values that can be chosen will either be
valid or invalid. If the values are invalid, a signer would simply produce an invalid signature and the final transaction itself would be invalid. If the
values are valid, then it does not matter which is chosen as either way the transaction is still valid.</ref>

===Proprietary Use Type===

For all global, per-input, and per-output maps, the type 0xFC is reserved for proprietary use.
The proprietary use type requires keys that follow the type with a compact size unsigned integer representing the length of the string identifer, followed by the string identifier, then a subtype, and finally any key data.

The identifier can be any variable length string that software can use to identify whether the particular data in the proprietary type can be used by it.
It can also be the empty string although this is not recommended.

The subtype is defined by the proprietary type user and can mean whatever they want it to mean.
The subtype must also be a compact size unsigned integer in the same form as the normal types.
The key data and value data are defined by the proprietary type user.

The proprietary use type is for private use by individuals and organizations who wish to use PSBT in their processes.
It is useful when there are additional data that they need attached to a PSBT but such data are not useful or available for the general public.
The proprietary use type is not to be used by any public specification and there is no expectation that any publicly available software be able to understand any specific meanings of it and the subtypes.
This type must be used for internal processes only.

==Version 0==

Partially Signed Bitcoin Transactions version 0 is the first version of the PSBT format.
Version 0 PSBTs must either omit PSBT_GLOBAL_VERSION or include it and set it to 0.
Version 0 PSBTs must include PSBT_GLOBAL_UNSIGNED_TX, if omitted, the PSBT is invalid.

==Roles==

Using the transaction format involves many different roles. Multiple roles can be handled by a single entity, but each role is specialized in what it should be capable of doing.

===Creator===

The Creator creates a new PSBT. It must create an unsigned transaction and place it in the PSBT.
The Creator must create empty input and output fields.

===Updater===

The Updater must only accept a PSBT.
The Updater adds information to the PSBT that it has access to. If it has the UTXO for an input, it should add it to the PSBT.
The Updater should also add redeemScripts, witnessScripts, and BIP 32 derivation paths to the input and output data if it knows them.

A single entity is likely to be both a Creator and Updater.

===Signer===

The Signer must only accept a PSBT.
The Signer must only use the UTXOs provided in the PSBT to produce signatures for inputs.
Before signing a non-witness input, the Signer must verify that the TXID of the non-witness UTXO matches the TXID specified in the unsigned transaction.
Before signing a witness input, the Signer must verify that the witnessScript (if provided) matches the hash specified in the UTXO or the redeemScript, and the redeemScript (if provided) matches the hash in the UTXO.
The Signer may choose to fail to sign a segwit input if a non-witness UTXO is not provided. <ref>'''Why would non-witness UTXOs be provided for segwit inputs?''' The sighash algorithm for Segwit specified in BIP 173 is known to have an issue where an attacker could trick a user to sending Bitcoin to fees if they are able to convince the user to sign a malicious transaction multiple times. This is possible because the amounts in PSBT_IN_WITNESS_UTXO of other segwit inputs can be modified without effecting the signature for a particular input. In order to prevent this kind of attack, many wallets are requiring that the full previous transaction (i.e. PSBT_IN_NON_WITNESS_UTXO) be provided to ensure that the amounts of other inputs are not being tampered with.</ref>
The Signer should not need any additional data sources, as all necessary information is provided in the PSBT format.
The Signer must only add data to a PSBT.
Any signatures created by the Signer must be added as a "Partial Signature" key-value pair for the respective input it relates to.
If a Signer cannot sign a transaction, it must not add a Partial Signature.

The Signer can additionally compute the addresses and values being sent, and the transaction fee, optionally showing this data to the user as a confirmation of intent and the consequences of signing the PSBT.

Signers do not need to sign for all possible input types. For example, a signer may choose to only sign Segwit inputs.

A single entity is likely to be both a Signer and an Updater as it can update a PSBT with necessary information prior to signing it.

====Data Signers Check For====

For a Signer to only produce valid signatures for what it expects to sign, it must check that the following conditions are true:

* If a non-witness UTXO is provided, its hash must match the hash specified in the prevout
* If a witness UTXO is provided, no non-witness signature may be created
* If a redeemScript is provided, the scriptPubKey must be for that redeemScript
* If a witnessScript is provided, the scriptPubKey or the redeemScript must be for that witnessScript
* If a sighash type is provided, the signer must check that the sighash is acceptable. If unacceptable, they must fail.
* If a sighash type is not provided, the signer should sign using SIGHASH_ALL, but may use any sighash type they wish.

=====Simple Signer Algorithm=====

A simple signer can use the following algorithm to determine what and how to sign

<pre>
sign_witness(script_code, i):
for key, sighash_type in psbt.inputs[i].items:
if sighash_type == None:
sighash_type = SIGHASH_ALL
if IsMine(key) and IsAcceptable(sighash_type):
sign(witness_sighash(script_code, i, input))

sign_non_witness(script_code, i):
for key, sighash_type in psbt.inputs[i].items:
if sighash_type == None:
sighash_type = SIGHASH_ALL
if IsMine(key) and IsAcceptable(sighash_type):
sign(non_witness_sighash(script_code, i, input))

for input,i in enumerate(psbt.inputs):
if non_witness_utxo.exists:
assert(sha256d(non_witness_utxo) == psbt.tx.input[i].prevout.hash)
if redeemScript.exists:
assert(non_witness_utxo.vout[psbt.tx.input[i].prevout.n].scriptPubKey == P2SH(redeemScript))
sign_non_witness(redeemScript, i)
else:
sign_non_witness(non_witness_utxo.vout[psbt.tx.input[i].prevout.n].scriptPubKey, i)
else if witness_utxo.exists:
if redeemScript.exists:
assert(witness_utxo.scriptPubKey == P2SH(redeemScript))
script = redeemScript
else:
script = witness_utxo.scriptPubKey
if IsP2WPKH(script):
sign_witness(P2PKH(script[2:22]), i)
else if IsP2WSH(script):
assert(script == P2WSH(witnessScript))
sign_witness(witnessScript, i)
else:
assert False
</pre>

====Change Detection====

Signers may wish to display the inputs and outputs to users for extra verification.
In such displays, signers may wish to identify which outputs are change outputs in order to omit them to avoid additional user confusion.
In order to detect change, a signer can use the BIP 32 derivation paths provided in inputs and outputs as well as the extended public keys provided globally.

For a single key output, a signer can observe whether the master fingerprint for the public key for that output belongs to itself.
If it does, it can then derive the public key at the specified derivation path and check whether that key is the one present in that output.

For outputs involving multiple keys, a signer can first examine the inputs that it is signing.
It should determine the general pattern of the script and internally produce a representation of the policy that the script represents.
Such a policy can include things like how many keys are present, what order they are in, how many signers are necessary, which signers are required, etc.
The signer can then use the BIP 32 derivation paths for each of the pubkeys to find which global extended public key is the one that can derive that particular public key.
To do so, the signer would extract the derivation path to the highest hardened index and use that to lookup the public key with that index and master fingerprint.
The signer would construct this script policy with extended public keys for all of the inputs and outputs.
Change outputs would then be identified as being the outputs which have the same script policy as the inputs that are being signed.

===Combiner===

The Combiner can accept 1 or many PSBTs.
The Combiner must merge them into one PSBT (if possible), or fail.
The resulting PSBT must contain all of the key-value pairs from each of the PSBTs.
The Combiner must remove any duplicate key-value pairs, in accordance with the specification. It can pick arbitrarily when conflicts occur.
A Combiner must not combine two different PSBTs. PSBTs can be uniquely identified by 0x00 global transaction typed key-value pair.
For every type that a Combiner understands, it may refuse to combine PSBTs if it detects that there will be inconsistencies or conflicts for that type in the combined PSBT.

The Combiner does not need to know how to interpret scripts in order to combine PSBTs. It can do so without understanding scripts or the network serialization format.

In general, the result of a Combiner combining two PSBTs from independent participants A and B should be functionally equivalent to a result obtained from processing the original PSBT by A and then B in a sequence.
Or, for participants performing fA(psbt) and fB(psbt): Combine(fA(psbt), fB(psbt)) == fA(fB(psbt)) == fB(fA(psbt))

===Input Finalizer===

The Input Finalizer must only accept a PSBT.
For each input, the Input Finalizer determines if the input has enough data to pass validation. If it does, it must construct the 0x07 Finalized scriptSig and 0x08 Finalized scriptWitness and place them into the input key-value map.
If scriptSig is empty for an input, 0x07 should remain unset rather than assigned an empty array.
Likewise, if no scriptWitness exists for an input, 0x08 should remain unset rather than assigned an empty array.
All other data except the UTXO and unknown fields in the input key-value map should be cleared from the PSBT. The UTXO should be kept to allow Transaction Extractors to verify the final network serialized transaction.

===Transaction Extractor===

The Transaction Extractor must only accept a PSBT.
It checks whether all inputs have complete scriptSigs and scriptWitnesses by checking for the presence of 0x07 Finalized scriptSig and 0x08 Finalized scriptWitness typed records. If they do, the Transaction Extractor should construct complete scriptSigs and scriptWitnesses and encode them into network serialized transactions. Otherwise the Extractor must not modify the PSBT.
The Extractor should produce a fully valid, network serialized transaction if all inputs are complete.

The Transaction Extractor does not need to know how to interpret scripts in order to extract the network serialized transaction. However it may be able to in order to validate the network serialized transaction at the same time.

A single entity is likely to be both a Transaction Extractor and an Input Finalizer.

==Encoding==

A PSBT can be represented in two ways: in binary (as a file) or as a Base64 string using the encoding described in [https://tools.ietf.org/html/rfc4648#section-4 RFC4648].

Binary PSBT files should use the .psbt file extension.
A MIME type name will be added to this document once one has been registered.

==Extensibility==

The Partially Signed Transaction format can be extended in the future by adding
new types for key-value pairs. Backwards compatibilty will still be maintained as those new
types will be ignored and passed-through by signers which do not know about them.

===Version Numbers===

The Version number field exists only as a safeguard in the event that a backwards incompatible change is introduced to PSBT.
If a parser encounters a version number it does not recognize, it should exit immediately as this indicates that the PSBT will contain types that it does not know about and cannot be ignored.
Current PSBTs are Version 0. Any PSBT that does not have the version field is version 0.
It is not expected that any backwards incompatible change will be introduced to PSBT, so it is not expected that the version field will ever actually be seen.

Updaters and combiners that need to add a version number to a PSBT should use the highest version number required.
For example, if a combiner sees two PSBTs for the same transaction, one with version 0, and the other with version 1, then it should combine them and produce a PSBT with version 1.
If an updater is updating a PSBT and needs to add a field that is only available in version 1, then it should set the PSBT version number to 1 unless a version higher than that is already specified.

===Procedure For New Fields===

New fields should first be proposed on the bitcoin-dev mailing list.
If a field requires significant description as to its usage, it should be accompanied by a separate BIP.
The field must be added to the field listing tables in the Specification section.
Although some PSBT version 0 implementations encode types as uint8_t rather than compact size,
it is still safe to add >0xFD fields to PSBT 0, because these old parsers ignore
unknown fields, and <keytype> is prefixed by its length.

===Procedure For New Versions===

New PSBT versions must be described in a separate BIP.
The BIP may reference this BIP and any components of PSBT version 0 that are retained in the new version.
Any new fields described in the new version must be added to the field listing tables in the Specification section.

==Compatibility==

This transaction format is designed so that it is unable to be properly unserialized
by normal transaction unserializers. Likewise, a normal transaction will not be
able to be unserialized by an unserializer for the PSBT format.

==Examples==

===Manual CoinJoin Workflow===

<img src="bip-0174/coinjoin-workflow.svg" align="middle"></img>

===2-of-3 Multisig Workflow===

<img src="bip-0174/multisig-workflow.svg" align="middle"></img>

==Test Vectors==

The following are invalid PSBTs:

* Case: Network transaction, not PSBT format
** Bytes in Hex: <pre>0200000001268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf6000000006a473044022070b2245123e6bf474d60c5b50c043d4c691a5d2435f09a34a7662a9dc251790a022001329ca9dacf280bdf30740ec0390422422c81cb45839457aeb76fc12edd95b3012102657d118d3357b8e0f4c2cd46db7b39f6d9c38d9a70abcb9b2de5dc8dbfe4ce31feffffff02d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787b32e1300</pre>
** Base64 String: <pre>AgAAAAEmgXE3Ht/yhek3re6ks3t4AAwFZsuzrWRkFxPKQhcb9gAAAABqRzBEAiBwsiRRI+a/R01gxbUMBD1MaRpdJDXwmjSnZiqdwlF5CgIgATKcqdrPKAvfMHQOwDkEIkIsgctFg5RXrrdvwS7dlbMBIQJlfRGNM1e44PTCzUbbezn22cONmnCry5st5dyNv+TOMf7///8C09/1BQAAAAAZdqkU0MWZA8W6woaHYOkP1SGkZlqnZSCIrADh9QUAAAAAF6kUNUXm4zuDLEcFDyTT7rk8nAOUi8eHsy4TAA==</pre>

* Case: PSBT missing outputs
** Bytes in Hex: <pre>70736274ff0100750200000001268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf60000000000feffffff02d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787b32e1300000100fda5010100000000010289a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e50100000017160014be18d152a9b012039daf3da7de4f53349eecb985ffffffff86f8aa43a71dff1448893a530a7237ef6b4608bbb2dd2d0171e63aec6a4890b40100000017160014fe3e9ef1a745e974d902c4355943abcb34bd5353ffffffff0200c2eb0b000000001976a91485cff1097fd9e008bb34af709c62197b38978a4888ac72fef84e2c00000017a914339725ba21efd62ac753a9bcd067d6c7a6a39d05870247304402202712be22e0270f394f568311dc7ca9a68970b8025fdd3b240229f07f8a5f3a240220018b38d7dcd314e734c9276bd6fb40f673325bc4baa144c800d2f2f02db2765c012103d2e15674941bad4a996372cb87e1856d3652606d98562fe39c5e9e7e413f210502483045022100d12b852d85dcd961d2f5f4ab660654df6eedcc794c0c33ce5cc309ffb5fce58d022067338a8e0e1725c197fb1a88af59f51e44e4255b20167c8684031c05d1f2592a01210223b72beef0965d10be0778efecd61fcac6f79a4ea169393380734464f84f2ab30000000000</pre>
** Base64 String: <pre>cHNidP8BAHUCAAAAASaBcTce3/KF6Tet7qSze3gADAVmy7OtZGQXE8pCFxv2AAAAAAD+////AtPf9QUAAAAAGXapFNDFmQPFusKGh2DpD9UhpGZap2UgiKwA4fUFAAAAABepFDVF5uM7gyxHBQ8k0+65PJwDlIvHh7MuEwAAAQD9pQEBAAAAAAECiaPHHqtNIOA3G7ukzGmPopXJRjr6Ljl/hTPMti+VZ+UBAAAAFxYAFL4Y0VKpsBIDna89p95PUzSe7LmF/////4b4qkOnHf8USIk6UwpyN+9rRgi7st0tAXHmOuxqSJC0AQAAABcWABT+Pp7xp0XpdNkCxDVZQ6vLNL1TU/////8CAMLrCwAAAAAZdqkUhc/xCX/Z4Ai7NK9wnGIZeziXikiIrHL++E4sAAAAF6kUM5cluiHv1irHU6m80GfWx6ajnQWHAkcwRAIgJxK+IuAnDzlPVoMR3HyppolwuAJf3TskAinwf4pfOiQCIAGLONfc0xTnNMkna9b7QPZzMlvEuqFEyADS8vAtsnZcASED0uFWdJQbrUqZY3LLh+GFbTZSYG2YVi/jnF6efkE/IQUCSDBFAiEA0SuFLYXc2WHS9fSrZgZU327tzHlMDDPOXMMJ/7X85Y0CIGczio4OFyXBl/saiK9Z9R5E5CVbIBZ8hoQDHAXR8lkqASECI7cr7vCWXRC+B3jv7NYfysb3mk6haTkzgHNEZPhPKrMAAAAAAA==</pre>

* Case: PSBT where one input has a filled scriptSig in the unsigned tx
** Bytes in Hex: <pre>70736274ff0100fd0a010200000002ab0949a08c5af7c49b8212f417e2f15ab3f5c33dcf153821a8139f877a5b7be4000000006a47304402204759661797c01b036b25928948686218347d89864b719e1f7fcf57d1e511658702205309eabf56aa4d8891ffd111fdf1336f3a29da866d7f8486d75546ceedaf93190121035cdc61fc7ba971c0b501a646a2a83b102cb43881217ca682dc86e2d73fa88292feffffffab0949a08c5af7c49b8212f417e2f15ab3f5c33dcf153821a8139f877a5b7be40100000000feffffff02603bea0b000000001976a914768a40bbd740cbe81d988e71de2a4d5c71396b1d88ac8e240000000000001976a9146f4620b553fa095e721b9ee0efe9fa039cca459788ac00000000000001012000e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787010416001485d13537f2e265405a34dbafa9e3dda01fb82308000000</pre>
** Base64 String: <pre>cHNidP8BAP0KAQIAAAACqwlJoIxa98SbghL0F+LxWrP1wz3PFTghqBOfh3pbe+QAAAAAakcwRAIgR1lmF5fAGwNrJZKJSGhiGDR9iYZLcZ4ff89X0eURZYcCIFMJ6r9Wqk2Ikf/REf3xM286KdqGbX+EhtdVRs7tr5MZASEDXNxh/HupccC1AaZGoqg7ECy0OIEhfKaC3Ibi1z+ogpL+////qwlJoIxa98SbghL0F+LxWrP1wz3PFTghqBOfh3pbe+QBAAAAAP7///8CYDvqCwAAAAAZdqkUdopAu9dAy+gdmI5x3ipNXHE5ax2IrI4kAAAAAAAAGXapFG9GILVT+glechue4O/p+gOcykWXiKwAAAAAAAABASAA4fUFAAAAABepFDVF5uM7gyxHBQ8k0+65PJwDlIvHhwEEFgAUhdE1N/LiZUBaNNuvqePdoB+4IwgAAAA=</pre>

* Case: PSBT where inputs and outputs are provided but without an unsigned tx
** Bytes in Hex: <pre>70736274ff000100fda5010100000000010289a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e50100000017160014be18d152a9b012039daf3da7de4f53349eecb985ffffffff86f8aa43a71dff1448893a530a7237ef6b4608bbb2dd2d0171e63aec6a4890b40100000017160014fe3e9ef1a745e974d902c4355943abcb34bd5353ffffffff0200c2eb0b000000001976a91485cff1097fd9e008bb34af709c62197b38978a4888ac72fef84e2c00000017a914339725ba21efd62ac753a9bcd067d6c7a6a39d05870247304402202712be22e0270f394f568311dc7ca9a68970b8025fdd3b240229f07f8a5f3a240220018b38d7dcd314e734c9276bd6fb40f673325bc4baa144c800d2f2f02db2765c012103d2e15674941bad4a996372cb87e1856d3652606d98562fe39c5e9e7e413f210502483045022100d12b852d85dcd961d2f5f4ab660654df6eedcc794c0c33ce5cc309ffb5fce58d022067338a8e0e1725c197fb1a88af59f51e44e4255b20167c8684031c05d1f2592a01210223b72beef0965d10be0778efecd61fcac6f79a4ea169393380734464f84f2ab30000000000</pre>
** Base64 String: <pre>cHNidP8AAQD9pQEBAAAAAAECiaPHHqtNIOA3G7ukzGmPopXJRjr6Ljl/hTPMti+VZ+UBAAAAFxYAFL4Y0VKpsBIDna89p95PUzSe7LmF/////4b4qkOnHf8USIk6UwpyN+9rRgi7st0tAXHmOuxqSJC0AQAAABcWABT+Pp7xp0XpdNkCxDVZQ6vLNL1TU/////8CAMLrCwAAAAAZdqkUhc/xCX/Z4Ai7NK9wnGIZeziXikiIrHL++E4sAAAAF6kUM5cluiHv1irHU6m80GfWx6ajnQWHAkcwRAIgJxK+IuAnDzlPVoMR3HyppolwuAJf3TskAinwf4pfOiQCIAGLONfc0xTnNMkna9b7QPZzMlvEuqFEyADS8vAtsnZcASED0uFWdJQbrUqZY3LLh+GFbTZSYG2YVi/jnF6efkE/IQUCSDBFAiEA0SuFLYXc2WHS9fSrZgZU327tzHlMDDPOXMMJ/7X85Y0CIGczio4OFyXBl/saiK9Z9R5E5CVbIBZ8hoQDHAXR8lkqASECI7cr7vCWXRC+B3jv7NYfysb3mk6haTkzgHNEZPhPKrMAAAAAAA==</pre>

* Case: PSBT with duplicate keys in an input
** Bytes in Hex: <pre>70736274ff0100750200000001268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf60000000000feffffff02d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787b32e1300000100fda5010100000000010289a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e50100000017160014be18d152a9b012039daf3da7de4f53349eecb985ffffffff86f8aa43a71dff1448893a530a7237ef6b4608bbb2dd2d0171e63aec6a4890b40100000017160014fe3e9ef1a745e974d902c4355943abcb34bd5353ffffffff0200c2eb0b000000001976a91485cff1097fd9e008bb34af709c62197b38978a4888ac72fef84e2c00000017a914339725ba21efd62ac753a9bcd067d6c7a6a39d05870247304402202712be22e0270f394f568311dc7ca9a68970b8025fdd3b240229f07f8a5f3a240220018b38d7dcd314e734c9276bd6fb40f673325bc4baa144c800d2f2f02db2765c012103d2e15674941bad4a996372cb87e1856d3652606d98562fe39c5e9e7e413f210502483045022100d12b852d85dcd961d2f5f4ab660654df6eedcc794c0c33ce5cc309ffb5fce58d022067338a8e0e1725c197fb1a88af59f51e44e4255b20167c8684031c05d1f2592a01210223b72beef0965d10be0778efecd61fcac6f79a4ea169393380734464f84f2ab30000000001003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a010000000000000000</pre>
** Base64 String: <pre>cHNidP8BAHUCAAAAASaBcTce3/KF6Tet7qSze3gADAVmy7OtZGQXE8pCFxv2AAAAAAD+////AtPf9QUAAAAAGXapFNDFmQPFusKGh2DpD9UhpGZap2UgiKwA4fUFAAAAABepFDVF5uM7gyxHBQ8k0+65PJwDlIvHh7MuEwAAAQD9pQEBAAAAAAECiaPHHqtNIOA3G7ukzGmPopXJRjr6Ljl/hTPMti+VZ+UBAAAAFxYAFL4Y0VKpsBIDna89p95PUzSe7LmF/////4b4qkOnHf8USIk6UwpyN+9rRgi7st0tAXHmOuxqSJC0AQAAABcWABT+Pp7xp0XpdNkCxDVZQ6vLNL1TU/////8CAMLrCwAAAAAZdqkUhc/xCX/Z4Ai7NK9wnGIZeziXikiIrHL++E4sAAAAF6kUM5cluiHv1irHU6m80GfWx6ajnQWHAkcwRAIgJxK+IuAnDzlPVoMR3HyppolwuAJf3TskAinwf4pfOiQCIAGLONfc0xTnNMkna9b7QPZzMlvEuqFEyADS8vAtsnZcASED0uFWdJQbrUqZY3LLh+GFbTZSYG2YVi/jnF6efkE/IQUCSDBFAiEA0SuFLYXc2WHS9fSrZgZU327tzHlMDDPOXMMJ/7X85Y0CIGczio4OFyXBl/saiK9Z9R5E5CVbIBZ8hoQDHAXR8lkqASECI7cr7vCWXRC+B3jv7NYfysb3mk6haTkzgHNEZPhPKrMAAAAAAQA/AgAAAAH//////////////////////////////////////////wAAAAAA/////wEAAAAAAAAAAANqAQAAAAAAAAAA</pre>

* Case: PSBT with invalid global transaction typed key
** Bytes in Hex: <pre>70736274ff020001550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre>
** Base64 String: <pre>cHNidP8CAAFVAgAAAAEnmiMjpd+1H8RfIg+liw/BPh4zQnkqhdfjbNYzO1y8OQAAAAAA/////wGgWuoLAAAAABl2qRT/6cAGEJfMO2NvLLBGD6T8Qn0rRYisAAAAAAABASCVXuoLAAAAABepFGNFIA9o0YnhrcDfHE0W6o8UwNvrhyICA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb1GRjBDAiAEJLWO/6qmlOFVnqXJO7/UqJBkIkBVzfBwtncUaUQtBwIfXI6w/qZRbWC4rLM61k7eYOh4W/s6qUuZvfhhUduamgEBBCIAIHcf0YrUWWZt1J89Vk49vEL0yEd042CtoWgWqO1IjVaBAQVHUiEDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYhA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9Uq4iBgOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RhC0prpnAAAAgAAAAIAEAACAIgYD3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg70QtKa6ZwAAAIAAAACABQAAgAAA</pre>

* Case: PSBT with invalid input witness utxo typed key
** Bytes in Hex: <pre>70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac000000000002010020955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre>
** Base64 String: <pre>cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAIBACCVXuoLAAAAABepFGNFIA9o0YnhrcDfHE0W6o8UwNvrhyICA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb1GRjBDAiAEJLWO/6qmlOFVnqXJO7/UqJBkIkBVzfBwtncUaUQtBwIfXI6w/qZRbWC4rLM61k7eYOh4W/s6qUuZvfhhUduamgEBBCIAIHcf0YrUWWZt1J89Vk49vEL0yEd042CtoWgWqO1IjVaBAQVHUiEDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYhA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9Uq4iBgOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RhC0prpnAAAAgAAAAIAEAACAIgYD3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg70QtKa6ZwAAAIAAAACABQAAgAAA</pre>

* Case: PSBT with invalid pubkey length for input partial signature typed key
** Bytes in Hex: <pre>70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87210203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd46304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre>
** Base64 String: <pre>cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIQIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYwQwIgBCS1jv+qppThVZ6lyTu/1KiQZCJAVc3wcLZ3FGlELQcCH1yOsP6mUW1guKyzOtZO3mDoeFv7OqlLmb34YVHbmpoBAQQiACB3H9GK1FlmbdSfPVZOPbxC9MhHdONgraFoFqjtSI1WgQEFR1IhA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb1GIQPeVdHh2sgF4/iljB+/m5TALz26r+En/vykmV8m+CCDvVKuIgYDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYQtKa6ZwAAAIAAAACABAAAgCIGA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9ELSmumcAAACAAAAAgAUAAIAAAA==</pre>

* Case: PSBT with invalid redeemscript typed key
** Bytes in Hex: <pre>70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a01020400220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre>
** Base64 String: <pre>cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIgIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUZGMEMCIAQktY7/qqaU4VWepck7v9SokGQiQFXN8HC2dxRpRC0HAh9cjrD+plFtYLisszrWTt5g6Hhb+zqpS5m9+GFR25qaAQIEACIAIHcf0YrUWWZt1J89Vk49vEL0yEd042CtoWgWqO1IjVaBAQVHUiEDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYhA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9Uq4iBgOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RhC0prpnAAAAgAAAAIAEAACAIgYD3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg70QtKa6ZwAAAIAAAACABQAAgAAA</pre>

* Case: PSBT with invalid witnessscript typed key
** Bytes in Hex: <pre>70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d568102050047522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre>
** Base64 String: <pre>cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIgIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUZGMEMCIAQktY7/qqaU4VWepck7v9SokGQiQFXN8HC2dxRpRC0HAh9cjrD+plFtYLisszrWTt5g6Hhb+zqpS5m9+GFR25qaAQEEIgAgdx/RitRZZm3Unz1WTj28QvTIR3TjYK2haBao7UiNVoECBQBHUiEDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYhA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9Uq4iBgOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RhC0prpnAAAAgAAAAIAEAACAIgYD3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg70QtKa6ZwAAAIAAAACABQAAgAAA</pre>

* Case: PSBT with invalid pubkey in input BIP 32 derivation paths typed key
** Bytes in Hex: <pre>70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae210603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd10b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre>
** Base64 String: <pre>cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIgIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUZGMEMCIAQktY7/qqaU4VWepck7v9SokGQiQFXN8HC2dxRpRC0HAh9cjrD+plFtYLisszrWTt5g6Hhb+zqpS5m9+GFR25qaAQEEIgAgdx/RitRZZm3Unz1WTj28QvTIR3TjYK2haBao7UiNVoEBBUdSIQOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RiED3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg71SriEGA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb0QtKa6ZwAAAIAAAACABAAAgCIGA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9ELSmumcAAACAAAAAgAUAAIAAAA==</pre>

* Case: PSBT with invalid non-witness utxo typed key
** Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f0000000000020000bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000000107da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae0001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870107232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b20289030108da0400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre>
** Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAIAALsCAAAAAarXOTEBi9JfhK5AC2iEi+CdtwbqwqwYKYur7nGrZW+LAAAAAEhHMEQCIFj2/HxqM+GzFUjUgcgmwBW9MBNarULNZ3kNq2bSrSQ7AiBKHO0mBMZzW2OT5bQWkd14sA8MWUL7n3UYVvqpOBV9ugH+////AoDw+gIAAAAAF6kUD7lGNCFpa4LIM68kHHjBfdveSTSH0PIKJwEAAAAXqRQpynT4oI+BmZQoGFyXtdhS5AY/YYdlAAAAAQfaAEcwRAIgdAGK1BgAl7hzMjwAFXILNoTMgSOJEEjn282bVa1nnJkCIHPTabdA4+tT3O+jOCPIBwUUylWn3ZVE8VfBZ5EyYRGMAUgwRQIhAPYQOLMI3B2oZaNIUnRvAVdyk0IIxtJEVDk82ZvfIhd3AiAFbmdaZ1ptCgK4WxTl4pB02KJam1dgvqKBb2YZEKAG6gFHUiEClYO/Oa4KYJdHrRma3dY0+mEIVZ1sXNObTCGD8auW4H8hAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXUq4AAQEgAMLrCwAAAAAXqRS39fr0Dj1ApaRZsds1NfK3L6kh6IcBByMiACCMI1MXN0O1ld+0oHtyuo5C43l9p06H/n2ddJfjsgKJAwEI2gQARzBEAiBi63pVYQenxz9FrEq1od3fb3B1+xJ1lpp/OD7/94S8sgIgDAXbt0cNvy8IVX3TVscyXB7TCRPpls04QJRdsSIo2l8BRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBR1IhAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcIQI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8Oc1KuACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=</pre>

* Case: PSBT with invalid final scriptsig typed key
** Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f618765000000020700da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae0001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870107232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b20289030108da0400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre>
** Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAACBwDaAEcwRAIgdAGK1BgAl7hzMjwAFXILNoTMgSOJEEjn282bVa1nnJkCIHPTabdA4+tT3O+jOCPIBwUUylWn3ZVE8VfBZ5EyYRGMAUgwRQIhAPYQOLMI3B2oZaNIUnRvAVdyk0IIxtJEVDk82ZvfIhd3AiAFbmdaZ1ptCgK4WxTl4pB02KJam1dgvqKBb2YZEKAG6gFHUiEClYO/Oa4KYJdHrRma3dY0+mEIVZ1sXNObTCGD8auW4H8hAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXUq4AAQEgAMLrCwAAAAAXqRS39fr0Dj1ApaRZsds1NfK3L6kh6IcBByMiACCMI1MXN0O1ld+0oHtyuo5C43l9p06H/n2ddJfjsgKJAwEI2gQARzBEAiBi63pVYQenxz9FrEq1od3fb3B1+xJ1lpp/OD7/94S8sgIgDAXbt0cNvy8IVX3TVscyXB7TCRPpls04QJRdsSIo2l8BRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBR1IhAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcIQI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8Oc1KuACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=</pre>

* Case: PSBT with invalid final script witness typed key
** Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000000107da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae0001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870107232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903020800da0400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre>
** Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAABB9oARzBEAiB0AYrUGACXuHMyPAAVcgs2hMyBI4kQSOfbzZtVrWecmQIgc9Npt0Dj61Pc76M4I8gHBRTKVafdlUTxV8FnkTJhEYwBSDBFAiEA9hA4swjcHahlo0hSdG8BV3KTQgjG0kRUOTzZm98iF3cCIAVuZ1pnWm0KArhbFOXikHTYolqbV2C+ooFvZhkQoAbqAUdSIQKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfyEC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtdSrgABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohwEHIyIAIIwjUxc3Q7WV37Sge3K6jkLjeX2nTof+fZ10l+OyAokDAggA2gQARzBEAiBi63pVYQenxz9FrEq1od3fb3B1+xJ1lpp/OD7/94S8sgIgDAXbt0cNvy8IVX3TVscyXB7TCRPpls04QJRdsSIo2l8BRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBR1IhAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcIQI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8Oc1KuACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=</pre>

* Case: PSBT with invalid pubkey in output BIP 32 derivation paths typed key
** Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000000107da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae0001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870107232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b20289030108da0400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00210203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca58710d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre>
** Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAABB9oARzBEAiB0AYrUGACXuHMyPAAVcgs2hMyBI4kQSOfbzZtVrWecmQIgc9Npt0Dj61Pc76M4I8gHBRTKVafdlUTxV8FnkTJhEYwBSDBFAiEA9hA4swjcHahlo0hSdG8BV3KTQgjG0kRUOTzZm98iF3cCIAVuZ1pnWm0KArhbFOXikHTYolqbV2C+ooFvZhkQoAbqAUdSIQKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfyEC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtdSrgABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohwEHIyIAIIwjUxc3Q7WV37Sge3K6jkLjeX2nTof+fZ10l+OyAokDAQjaBABHMEQCIGLrelVhB6fHP0WsSrWh3d9vcHX7EnWWmn84Pv/3hLyyAiAMBdu3Rw2/LwhVfdNWxzJcHtMJE+mWzThAlF2xIijaXwFHMEQCIGX0W6WZi1mif/4ae+0BavHx+Q1Us6qPdFCqX1aiUQO9AiB/ckcDrR7blmgLKEtW1P/LiPf7dZ6rvgiqMPKbhROD0gFHUiEDCJ3BDHrG21T5EymvYXMz2ziM6tDCMfcjN50bmQMLAtwhAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zUq4AIQIDqaTDf1mW06ol26xrVwrwZQOUSSlCRgs1R1PtnuylhxDZDGpPAAAAgAAAAIAEAACAACICAn9jmXV9Lv9VoTatAsaEsYOLZVbl8bazQoKpS2tQBRCWENkMak8AAACAAAAAgAUAAIAA</pre>

* Case: PSBT with invalid input sighash type typed key
** Bytes in Hex: <pre>70736274ff0100730200000001301ae986e516a1ec8ac5b4bc6573d32f83b465e23ad76167d68b38e730b4dbdb0000000000ffffffff02747b01000000000017a91403aa17ae882b5d0d54b25d63104e4ffece7b9ea2876043993b0000000017a914b921b1ba6f722e4bfa83b6557a3139986a42ec8387000000000001011f00ca9a3b00000000160014d2d94b64ae08587eefc8eeb187c601e939f9037c0203000100000000010016001462e9e982fff34dd8239610316b090cd2a3b747cb000100220020876bad832f1d168015ed41232a9ea65a1815d9ef13c0ef8759f64b5b2b278a65010125512103b7ce23a01c5b4bf00a642537cdfabb315b668332867478ef51309d2bd57f8a8751ae00</pre>
** Base64 String: <pre>cHNidP8BAHMCAAAAATAa6YblFqHsisW0vGVz0y+DtGXiOtdhZ9aLOOcwtNvbAAAAAAD/////AnR7AQAAAAAAF6kUA6oXrogrXQ1Usl1jEE5P/s57nqKHYEOZOwAAAAAXqRS5IbG6b3IuS/qDtlV6MTmYakLsg4cAAAAAAAEBHwDKmjsAAAAAFgAU0tlLZK4IWH7vyO6xh8YB6Tn5A3wCAwABAAAAAAEAFgAUYunpgv/zTdgjlhAxawkM0qO3R8sAAQAiACCHa62DLx0WgBXtQSMqnqZaGBXZ7xPA74dZ9ktbKyeKZQEBJVEhA7fOI6AcW0vwCmQlN836uzFbZoMyhnR471EwnSvVf4qHUa4A</pre>

* Case: PSBT with invalid output redeemScript typed key
** Bytes in Hex: <pre>70736274ff0100730200000001301ae986e516a1ec8ac5b4bc6573d32f83b465e23ad76167d68b38e730b4dbdb0000000000ffffffff02747b01000000000017a91403aa17ae882b5d0d54b25d63104e4ffece7b9ea2876043993b0000000017a914b921b1ba6f722e4bfa83b6557a3139986a42ec8387000000000001011f00ca9a3b00000000160014d2d94b64ae08587eefc8eeb187c601e939f9037c0002000016001462e9e982fff34dd8239610316b090cd2a3b747cb000100220020876bad832f1d168015ed41232a9ea65a1815d9ef13c0ef8759f64b5b2b278a65010125512103b7ce23a01c5b4bf00a642537cdfabb315b668332867478ef51309d2bd57f8a8751ae00</pre>
** Base64 String: <pre>cHNidP8BAHMCAAAAATAa6YblFqHsisW0vGVz0y+DtGXiOtdhZ9aLOOcwtNvbAAAAAAD/////AnR7AQAAAAAAF6kUA6oXrogrXQ1Usl1jEE5P/s57nqKHYEOZOwAAAAAXqRS5IbG6b3IuS/qDtlV6MTmYakLsg4cAAAAAAAEBHwDKmjsAAAAAFgAU0tlLZK4IWH7vyO6xh8YB6Tn5A3wAAgAAFgAUYunpgv/zTdgjlhAxawkM0qO3R8sAAQAiACCHa62DLx0WgBXtQSMqnqZaGBXZ7xPA74dZ9ktbKyeKZQEBJVEhA7fOI6AcW0vwCmQlN836uzFbZoMyhnR471EwnSvVf4qHUa4A</pre>

* Case: PSBT with invalid output witnessScript typed key
** Bytes in Hex: <pre>70736274ff0100730200000001301ae986e516a1ec8ac5b4bc6573d32f83b465e23ad76167d68b38e730b4dbdb0000000000ffffffff02747b01000000000017a91403aa17ae882b5d0d54b25d63104e4ffece7b9ea2876043993b0000000017a914b921b1ba6f722e4bfa83b6557a3139986a42ec8387000000000001011f00ca9a3b00000000160014d2d94b64ae08587eefc8eeb187c601e939f9037c00010016001462e9e982fff34dd8239610316b090cd2a3b747cb000100220020876bad832f1d168015ed41232a9ea65a1815d9ef13c0ef8759f64b5b2b278a6521010025512103b7ce23a01c5b4bf00a642537cdfabb315b668332867478ef51309d06d57f8a8751ae00</pre>
** Base64 String: <pre>cHNidP8BAHMCAAAAATAa6YblFqHsisW0vGVz0y+DtGXiOtdhZ9aLOOcwtNvbAAAAAAD/////AnR7AQAAAAAAF6kUA6oXrogrXQ1Usl1jEE5P/s57nqKHYEOZOwAAAAAXqRS5IbG6b3IuS/qDtlV6MTmYakLsg4cAAAAAAAEBHwDKmjsAAAAAFgAU0tlLZK4IWH7vyO6xh8YB6Tn5A3wAAQAWABRi6emC//NN2COWEDFrCQzSo7dHywABACIAIIdrrYMvHRaAFe1BIyqeploYFdnvE8Dvh1n2S1srJ4plIQEAJVEhA7fOI6AcW0vwCmQlN836uzFbZoMyhnR471EwnQbVf4qHUa4A</pre>

* Case: PSBT with unsigned tx serialized with witness serialization format
** Bytes in Hex: <pre>70736274ff01007802000000000101268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf60000000000feffffff02d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc78700b32e1300000100fda5010100000000010289a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e50100000017160014be18d152a9b012039daf3da7de4f53349eecb985ffffffff86f8aa43a71dff1448893a530a7237ef6b4608bbb2dd2d0171e63aec6a4890b40100000017160014fe3e9ef1a745e974d902c4355943abcb34bd5353ffffffff0200c2eb0b000000001976a91485cff1097fd9e008bb34af709c62197b38978a4888ac72fef84e2c00000017a914339725ba21efd62ac753a9bcd067d6c7a6a39d05870247304402202712be22e0270f394f568311dc7ca9a68970b8025fdd3b240229f07f8a5f3a240220018b38d7dcd314e734c9276bd6fb40f673325bc4baa144c800d2f2f02db2765c012103d2e15674941bad4a996372cb87e1856d3652606d98562fe39c5e9e7e413f210502483045022100d12b852d85dcd961d2f5f4ab660654df6eedcc794c0c33ce5cc309ffb5fce58d022067338a8e0e1725c197fb1a88af59f51e44e4255b20167c8684031c05d1f2592a01210223b72beef0965d10be0778efecd61fcac6f79a4ea169393380734464f84f2ab300000000000000</pre>
** Base64 String: <pre>cHNidP8BAHgCAAAAAAEBJoFxNx7f8oXpN63upLN7eAAMBWbLs61kZBcTykIXG/YAAAAAAP7///8C09/1BQAAAAAZdqkU0MWZA8W6woaHYOkP1SGkZlqnZSCIrADh9QUAAAAAF6kUNUXm4zuDLEcFDyTT7rk8nAOUi8eHALMuEwAAAQD9pQEBAAAAAAECiaPHHqtNIOA3G7ukzGmPopXJRjr6Ljl/hTPMti+VZ+UBAAAAFxYAFL4Y0VKpsBIDna89p95PUzSe7LmF/////4b4qkOnHf8USIk6UwpyN+9rRgi7st0tAXHmOuxqSJC0AQAAABcWABT+Pp7xp0XpdNkCxDVZQ6vLNL1TU/////8CAMLrCwAAAAAZdqkUhc/xCX/Z4Ai7NK9wnGIZeziXikiIrHL++E4sAAAAF6kUM5cluiHv1irHU6m80GfWx6ajnQWHAkcwRAIgJxK+IuAnDzlPVoMR3HyppolwuAJf3TskAinwf4pfOiQCIAGLONfc0xTnNMkna9b7QPZzMlvEuqFEyADS8vAtsnZcASED0uFWdJQbrUqZY3LLh+GFbTZSYG2YVi/jnF6efkE/IQUCSDBFAiEA0SuFLYXc2WHS9fSrZgZU327tzHlMDDPOXMMJ/7X85Y0CIGczio4OFyXBl/saiK9Z9R5E5CVbIBZ8hoQDHAXR8lkqASECI7cr7vCWXRC+B3jv7NYfysb3mk6haTkzgHNEZPhPKrMAAAAAAAAA</pre>

The following are valid PSBTs:

* Case: PSBT with one P2PKH input. Outputs are empty
** Bytes in Hex: <pre>70736274ff0100750200000001268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf60000000000feffffff02d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787b32e1300000100fda5010100000000010289a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e50100000017160014be18d152a9b012039daf3da7de4f53349eecb985ffffffff86f8aa43a71dff1448893a530a7237ef6b4608bbb2dd2d0171e63aec6a4890b40100000017160014fe3e9ef1a745e974d902c4355943abcb34bd5353ffffffff0200c2eb0b000000001976a91485cff1097fd9e008bb34af709c62197b38978a4888ac72fef84e2c00000017a914339725ba21efd62ac753a9bcd067d6c7a6a39d05870247304402202712be22e0270f394f568311dc7ca9a68970b8025fdd3b240229f07f8a5f3a240220018b38d7dcd314e734c9276bd6fb40f673325bc4baa144c800d2f2f02db2765c012103d2e15674941bad4a996372cb87e1856d3652606d98562fe39c5e9e7e413f210502483045022100d12b852d85dcd961d2f5f4ab660654df6eedcc794c0c33ce5cc309ffb5fce58d022067338a8e0e1725c197fb1a88af59f51e44e4255b20167c8684031c05d1f2592a01210223b72beef0965d10be0778efecd61fcac6f79a4ea169393380734464f84f2ab300000000000000</pre>
** Base64 String: <pre>cHNidP8BAHUCAAAAASaBcTce3/KF6Tet7qSze3gADAVmy7OtZGQXE8pCFxv2AAAAAAD+////AtPf9QUAAAAAGXapFNDFmQPFusKGh2DpD9UhpGZap2UgiKwA4fUFAAAAABepFDVF5uM7gyxHBQ8k0+65PJwDlIvHh7MuEwAAAQD9pQEBAAAAAAECiaPHHqtNIOA3G7ukzGmPopXJRjr6Ljl/hTPMti+VZ+UBAAAAFxYAFL4Y0VKpsBIDna89p95PUzSe7LmF/////4b4qkOnHf8USIk6UwpyN+9rRgi7st0tAXHmOuxqSJC0AQAAABcWABT+Pp7xp0XpdNkCxDVZQ6vLNL1TU/////8CAMLrCwAAAAAZdqkUhc/xCX/Z4Ai7NK9wnGIZeziXikiIrHL++E4sAAAAF6kUM5cluiHv1irHU6m80GfWx6ajnQWHAkcwRAIgJxK+IuAnDzlPVoMR3HyppolwuAJf3TskAinwf4pfOiQCIAGLONfc0xTnNMkna9b7QPZzMlvEuqFEyADS8vAtsnZcASED0uFWdJQbrUqZY3LLh+GFbTZSYG2YVi/jnF6efkE/IQUCSDBFAiEA0SuFLYXc2WHS9fSrZgZU327tzHlMDDPOXMMJ/7X85Y0CIGczio4OFyXBl/saiK9Z9R5E5CVbIBZ8hoQDHAXR8lkqASECI7cr7vCWXRC+B3jv7NYfysb3mk6haTkzgHNEZPhPKrMAAAAAAAAA</pre>

* Case: PSBT with one P2PKH input and one P2SH-P2WPKH input. First input is signed and finalized. Outputs are empty
** Bytes in Hex: <pre>70736274ff0100a00200000002ab0949a08c5af7c49b8212f417e2f15ab3f5c33dcf153821a8139f877a5b7be40000000000feffffffab0949a08c5af7c49b8212f417e2f15ab3f5c33dcf153821a8139f877a5b7be40100000000feffffff02603bea0b000000001976a914768a40bbd740cbe81d988e71de2a4d5c71396b1d88ac8e240000000000001976a9146f4620b553fa095e721b9ee0efe9fa039cca459788ac000000000001076a47304402204759661797c01b036b25928948686218347d89864b719e1f7fcf57d1e511658702205309eabf56aa4d8891ffd111fdf1336f3a29da866d7f8486d75546ceedaf93190121035cdc61fc7ba971c0b501a646a2a83b102cb43881217ca682dc86e2d73fa882920001012000e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787010416001485d13537f2e265405a34dbafa9e3dda01fb82308000000</pre>
** Base64 String: <pre>cHNidP8BAKACAAAAAqsJSaCMWvfEm4IS9Bfi8Vqz9cM9zxU4IagTn4d6W3vkAAAAAAD+////qwlJoIxa98SbghL0F+LxWrP1wz3PFTghqBOfh3pbe+QBAAAAAP7///8CYDvqCwAAAAAZdqkUdopAu9dAy+gdmI5x3ipNXHE5ax2IrI4kAAAAAAAAGXapFG9GILVT+glechue4O/p+gOcykWXiKwAAAAAAAEHakcwRAIgR1lmF5fAGwNrJZKJSGhiGDR9iYZLcZ4ff89X0eURZYcCIFMJ6r9Wqk2Ikf/REf3xM286KdqGbX+EhtdVRs7tr5MZASEDXNxh/HupccC1AaZGoqg7ECy0OIEhfKaC3Ibi1z+ogpIAAQEgAOH1BQAAAAAXqRQ1RebjO4MsRwUPJNPuuTycA5SLx4cBBBYAFIXRNTfy4mVAWjTbr6nj3aAfuCMIAAAA</pre>

* Case: PSBT with one P2PKH input which has a non-final scriptSig and has a sighash type specified. Outputs are empty
** Bytes in Hex: <pre>70736274ff0100750200000001268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf60000000000feffffff02d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787b32e1300000100fda5010100000000010289a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e50100000017160014be18d152a9b012039daf3da7de4f53349eecb985ffffffff86f8aa43a71dff1448893a530a7237ef6b4608bbb2dd2d0171e63aec6a4890b40100000017160014fe3e9ef1a745e974d902c4355943abcb34bd5353ffffffff0200c2eb0b000000001976a91485cff1097fd9e008bb34af709c62197b38978a4888ac72fef84e2c00000017a914339725ba21efd62ac753a9bcd067d6c7a6a39d05870247304402202712be22e0270f394f568311dc7ca9a68970b8025fdd3b240229f07f8a5f3a240220018b38d7dcd314e734c9276bd6fb40f673325bc4baa144c800d2f2f02db2765c012103d2e15674941bad4a996372cb87e1856d3652606d98562fe39c5e9e7e413f210502483045022100d12b852d85dcd961d2f5f4ab660654df6eedcc794c0c33ce5cc309ffb5fce58d022067338a8e0e1725c197fb1a88af59f51e44e4255b20167c8684031c05d1f2592a01210223b72beef0965d10be0778efecd61fcac6f79a4ea169393380734464f84f2ab30000000001030401000000000000</pre>
** Base64 String: <pre>cHNidP8BAHUCAAAAASaBcTce3/KF6Tet7qSze3gADAVmy7OtZGQXE8pCFxv2AAAAAAD+////AtPf9QUAAAAAGXapFNDFmQPFusKGh2DpD9UhpGZap2UgiKwA4fUFAAAAABepFDVF5uM7gyxHBQ8k0+65PJwDlIvHh7MuEwAAAQD9pQEBAAAAAAECiaPHHqtNIOA3G7ukzGmPopXJRjr6Ljl/hTPMti+VZ+UBAAAAFxYAFL4Y0VKpsBIDna89p95PUzSe7LmF/////4b4qkOnHf8USIk6UwpyN+9rRgi7st0tAXHmOuxqSJC0AQAAABcWABT+Pp7xp0XpdNkCxDVZQ6vLNL1TU/////8CAMLrCwAAAAAZdqkUhc/xCX/Z4Ai7NK9wnGIZeziXikiIrHL++E4sAAAAF6kUM5cluiHv1irHU6m80GfWx6ajnQWHAkcwRAIgJxK+IuAnDzlPVoMR3HyppolwuAJf3TskAinwf4pfOiQCIAGLONfc0xTnNMkna9b7QPZzMlvEuqFEyADS8vAtsnZcASED0uFWdJQbrUqZY3LLh+GFbTZSYG2YVi/jnF6efkE/IQUCSDBFAiEA0SuFLYXc2WHS9fSrZgZU327tzHlMDDPOXMMJ/7X85Y0CIGczio4OFyXBl/saiK9Z9R5E5CVbIBZ8hoQDHAXR8lkqASECI7cr7vCWXRC+B3jv7NYfysb3mk6haTkzgHNEZPhPKrMAAAAAAQMEAQAAAAAAAA==</pre>

* Case: PSBT with one P2PKH input and one P2SH-P2WPKH input both with non-final scriptSigs. P2SH-P2WPKH input's redeemScript is available. Outputs filled.
** Bytes in Hex: <pre>70736274ff0100a00200000002ab0949a08c5af7c49b8212f417e2f15ab3f5c33dcf153821a8139f877a5b7be40000000000feffffffab0949a08c5af7c49b8212f417e2f15ab3f5c33dcf153821a8139f877a5b7be40100000000feffffff02603bea0b000000001976a914768a40bbd740cbe81d988e71de2a4d5c71396b1d88ac8e240000000000001976a9146f4620b553fa095e721b9ee0efe9fa039cca459788ac00000000000100df0200000001268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf6000000006a473044022070b2245123e6bf474d60c5b50c043d4c691a5d2435f09a34a7662a9dc251790a022001329ca9dacf280bdf30740ec0390422422c81cb45839457aeb76fc12edd95b3012102657d118d3357b8e0f4c2cd46db7b39f6d9c38d9a70abcb9b2de5dc8dbfe4ce31feffffff02d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787b32e13000001012000e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787010416001485d13537f2e265405a34dbafa9e3dda01fb8230800220202ead596687ca806043edc3de116cdf29d5e9257c196cd055cf698c8d02bf24e9910b4a6ba670000008000000080020000800022020394f62be9df19952c5587768aeb7698061ad2c4a25c894f47d8c162b4d7213d0510b4a6ba6700000080010000800200008000</pre>
** Base64 String: <pre>cHNidP8BAKACAAAAAqsJSaCMWvfEm4IS9Bfi8Vqz9cM9zxU4IagTn4d6W3vkAAAAAAD+////qwlJoIxa98SbghL0F+LxWrP1wz3PFTghqBOfh3pbe+QBAAAAAP7///8CYDvqCwAAAAAZdqkUdopAu9dAy+gdmI5x3ipNXHE5ax2IrI4kAAAAAAAAGXapFG9GILVT+glechue4O/p+gOcykWXiKwAAAAAAAEA3wIAAAABJoFxNx7f8oXpN63upLN7eAAMBWbLs61kZBcTykIXG/YAAAAAakcwRAIgcLIkUSPmv0dNYMW1DAQ9TGkaXSQ18Jo0p2YqncJReQoCIAEynKnazygL3zB0DsA5BCJCLIHLRYOUV663b8Eu3ZWzASECZX0RjTNXuOD0ws1G23s59tnDjZpwq8ubLeXcjb/kzjH+////AtPf9QUAAAAAGXapFNDFmQPFusKGh2DpD9UhpGZap2UgiKwA4fUFAAAAABepFDVF5uM7gyxHBQ8k0+65PJwDlIvHh7MuEwAAAQEgAOH1BQAAAAAXqRQ1RebjO4MsRwUPJNPuuTycA5SLx4cBBBYAFIXRNTfy4mVAWjTbr6nj3aAfuCMIACICAurVlmh8qAYEPtw94RbN8p1eklfBls0FXPaYyNAr8k6ZELSmumcAAACAAAAAgAIAAIAAIgIDlPYr6d8ZlSxVh3aK63aYBhrSxKJciU9H2MFitNchPQUQtKa6ZwAAAIABAACAAgAAgAA=</pre>

* Case: PSBT with one P2SH-P2WSH input of a 2-of-2 multisig, redeemScript, witnessScript, and keypaths are available. Contains one signature.
** Bytes in Hex: <pre>70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre>
** Base64 String: <pre>cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIgIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUZGMEMCIAQktY7/qqaU4VWepck7v9SokGQiQFXN8HC2dxRpRC0HAh9cjrD+plFtYLisszrWTt5g6Hhb+zqpS5m9+GFR25qaAQEEIgAgdx/RitRZZm3Unz1WTj28QvTIR3TjYK2haBao7UiNVoEBBUdSIQOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RiED3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg71SriIGA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb1GELSmumcAAACAAAAAgAQAAIAiBgPeVdHh2sgF4/iljB+/m5TALz26r+En/vykmV8m+CCDvRC0prpnAAAAgAAAAIAFAACAAAA=</pre>

* Case: PSBT with one P2WSH input of a 2-of-2 multisig. witnessScript, keypaths, and global xpubs are available. Contains no signatures. Outputs filled.
** Bytes in Hex: <pre>70736274ff01005202000000019dfc6628c26c5899fe1bd3dc338665bfd55d7ada10f6220973df2d386dec12760100000000ffffffff01f03dcd1d000000001600147b3a00bfdc14d27795c2b74901d09da6ef133579000000004f01043587cf02da3fd0088000000097048b1ad0445b1ec8275517727c87b4e4ebc18a203ffa0f94c01566bd38e9000351b743887ee1d40dc32a6043724f2d6459b3b5a4d73daec8fbae0472f3bc43e20cd90c6a4fae000080000000804f01043587cf02da3fd00880000001b90452427139cd78c2cff2444be353cd58605e3e513285e528b407fae3f6173503d30a5e97c8adbc557dac2ad9a7e39c1722ebac69e668b6f2667cc1d671c83cab0cd90c6a4fae000080010000800001012b0065cd1d000000002200202c5486126c4978079a814e13715d65f36459e4d6ccaded266d0508645bafa6320105475221029da12cdb5b235692b91536afefe5c91c3ab9473d8e43b533836ab456299c88712103372b34234ed7cf9c1fea5d05d441557927be9542b162eb02e1ab2ce80224c00b52ae2206029da12cdb5b235692b91536afefe5c91c3ab9473d8e43b533836ab456299c887110d90c6a4fae0000800000008000000000220603372b34234ed7cf9c1fea5d05d441557927be9542b162eb02e1ab2ce80224c00b10d90c6a4fae0000800100008000000000002202039eff1f547a1d5f92dfa2ba7af6ac971a4bd03ba4a734b03156a256b8ad3a1ef910ede45cc500000080000000800100008000</pre>
** Base64 String: <pre>cHNidP8BAFICAAAAAZ38ZijCbFiZ/hvT3DOGZb/VXXraEPYiCXPfLTht7BJ2AQAAAAD/////AfA9zR0AAAAAFgAUezoAv9wU0neVwrdJAdCdpu8TNXkAAAAATwEENYfPAto/0AiAAAAAlwSLGtBEWx7IJ1UXcnyHtOTrwYogP/oPlMAVZr046QADUbdDiH7h1A3DKmBDck8tZFmztaTXPa7I+64EcvO8Q+IM2QxqT64AAIAAAACATwEENYfPAto/0AiAAAABuQRSQnE5zXjCz/JES+NTzVhgXj5RMoXlKLQH+uP2FzUD0wpel8itvFV9rCrZp+OcFyLrrGnmaLbyZnzB1nHIPKsM2QxqT64AAIABAACAAAEBKwBlzR0AAAAAIgAgLFSGEmxJeAeagU4TcV1l82RZ5NbMre0mbQUIZFuvpjIBBUdSIQKdoSzbWyNWkrkVNq/v5ckcOrlHPY5DtTODarRWKZyIcSEDNys0I07Xz5wf6l0F1EFVeSe+lUKxYusC4ass6AIkwAtSriIGAp2hLNtbI1aSuRU2r+/lyRw6uUc9jkO1M4NqtFYpnIhxENkMak+uAACAAAAAgAAAAAAiBgM3KzQjTtfPnB/qXQXUQVV5J76VQrFi6wLhqyzoAiTACxDZDGpPrgAAgAEAAIAAAAAAACICA57/H1R6HV+S36K6evaslxpL0DukpzSwMVaiVritOh75EO3kXMUAAACAAAAAgAEAAIAA</pre>

* Case: PSBT with unknown types in the inputs.
** Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a010000000000000af00102030405060708090f0102030405060708090a0b0c0d0e0f0000</pre>
** Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAACvABAgMEBQYHCAkPAQIDBAUGBwgJCgsMDQ4PAAA=</pre>

* Case: PSBT with `PSBT_GLOBAL_XPUB`.
** Bytes in Hex: <pre>70736274ff01009d0100000002710ea76ab45c5cb6438e607e59cc037626981805ae9e0dfd9089012abb0be5350100000000ffffffff190994d6a8b3c8c82ccbcfb2fba4106aa06639b872a8d447465c0d42588d6d670000000000ffffffff0200e1f505000000001976a914b6bc2c0ee5655a843d79afedd0ccc3f7dd64340988ac605af405000000001600141188ef8e4ce0449eaac8fb141cbf5a1176e6a088000000004f010488b21e039e530cac800000003dbc8a5c9769f031b17e77fea1518603221a18fd18f2b9a54c6c8c1ac75cbc3502f230584b155d1c7f1cd45120a653c48d650b431b67c5b2c13f27d7142037c1691027569c503100008000000080000000800001011f00e1f5050000000016001433b982f91b28f160c920b4ab95e58ce50dda3a4a220203309680f33c7de38ea6a47cd4ecd66f1f5a49747c6ffb8808ed09039243e3ad5c47304402202d704ced830c56a909344bd742b6852dccd103e963bae92d38e75254d2bb424502202d86c437195df46c0ceda084f2a291c3da2d64070f76bf9b90b195e7ef28f77201220603309680f33c7de38ea6a47cd4ecd66f1f5a49747c6ffb8808ed09039243e3ad5c1827569c5031000080000000800000008000000000010000000001011f00e1f50500000000160014388fb944307eb77ef45197d0b0b245e079f011de220202c777161f73d0b7c72b9ee7bde650293d13f095bc7656ad1f525da5fd2e10b11047304402204cb1fb5f869c942e0e26100576125439179ae88dca8a9dc3ba08f7953988faa60220521f49ca791c27d70e273c9b14616985909361e25be274ea200d7e08827e514d01220602c777161f73d0b7c72b9ee7bde650293d13f095bc7656ad1f525da5fd2e10b1101827569c5031000080000000800000008000000000000000000000220202d20ca502ee289686d21815bd43a80637b0698e1fbcdbe4caed445f6c1a0a90ef1827569c50310000800000008000000080000000000400000000</pre>
** Base64 String: <pre>cHNidP8BAJ0BAAAAAnEOp2q0XFy2Q45gflnMA3YmmBgFrp4N/ZCJASq7C+U1AQAAAAD/////GQmU1qizyMgsy8+y+6QQaqBmObhyqNRHRlwNQliNbWcAAAAAAP////8CAOH1BQAAAAAZdqkUtrwsDuVlWoQ9ea/t0MzD991kNAmIrGBa9AUAAAAAFgAUEYjvjkzgRJ6qyPsUHL9aEXbmoIgAAAAATwEEiLIeA55TDKyAAAAAPbyKXJdp8DGxfnf+oVGGAyIaGP0Y8rmlTGyMGsdcvDUC8jBYSxVdHH8c1FEgplPEjWULQxtnxbLBPyfXFCA3wWkQJ1acUDEAAIAAAACAAAAAgAABAR8A4fUFAAAAABYAFDO5gvkbKPFgySC0q5XljOUN2jpKIgIDMJaA8zx9446mpHzU7NZvH1pJdHxv+4gI7QkDkkPjrVxHMEQCIC1wTO2DDFapCTRL10K2hS3M0QPpY7rpLTjnUlTSu0JFAiAthsQ3GV30bAztoITyopHD2i1kBw92v5uQsZXn7yj3cgEiBgMwloDzPH3jjqakfNTs1m8fWkl0fG/7iAjtCQOSQ+OtXBgnVpxQMQAAgAAAAIAAAACAAAAAAAEAAAAAAQEfAOH1BQAAAAAWABQ4j7lEMH63fvRRl9CwskXgefAR3iICAsd3Fh9z0LfHK57nveZQKT0T8JW8dlatH1Jdpf0uELEQRzBEAiBMsftfhpyULg4mEAV2ElQ5F5rojcqKncO6CPeVOYj6pgIgUh9JynkcJ9cOJzybFGFphZCTYeJb4nTqIA1+CIJ+UU0BIgYCx3cWH3PQt8crnue95lApPRPwlbx2Vq0fUl2l/S4QsRAYJ1acUDEAAIAAAACAAAAAgAAAAAAAAAAAAAAiAgLSDKUC7iiWhtIYFb1DqAY3sGmOH7zb5MrtRF9sGgqQ7xgnVpxQMQAAgAAAAIAAAACAAAAAAAQAAAAA</pre>

* Case: PSBT with global unsigned tx that has 0 inputs and 0 outputs
** Bytes in Hex: <pre>70736274ff01000a0000000000000000000000</pre>
** Base64 String: <pre>cHNidP8BAAoAAAAAAAAAAAAAAA==</pre>

* Case: PSBT with 0 inputs
** Bytes in Hex: <pre>70736274ff01004c020000000002d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787b32e1300000000</pre>
** Base64 String: <pre>cHNidP8BAEwCAAAAAALT3/UFAAAAABl2qRTQxZkDxbrChodg6Q/VIaRmWqdlIIisAOH1BQAAAAAXqRQ1RebjO4MsRwUPJNPuuTycA5SLx4ezLhMAAAAA</pre>

Fails Signer checks

* Case: A Witness UTXO is provided for a non-witness input
** Bytes in Hex: <pre>70736274ff0100a00200000002ab0949a08c5af7c49b8212f417e2f15ab3f5c33dcf153821a8139f877a5b7be40000000000feffffffab0949a08c5af7c49b8212f417e2f15ab3f5c33dcf153821a8139f877a5b7be40100000000feffffff02603bea0b000000001976a914768a40bbd740cbe81d988e71de2a4d5c71396b1d88ac8e240000000000001976a9146f4620b553fa095e721b9ee0efe9fa039cca459788ac0000000000010122d3dff505000000001976a914d48ed3110b94014cb114bd32d6f4d066dc74256b88ac0001012000e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787010416001485d13537f2e265405a34dbafa9e3dda01fb8230800220202ead596687ca806043edc3de116cdf29d5e9257c196cd055cf698c8d02bf24e9910b4a6ba670000008000000080020000800022020394f62be9df19952c5587768aeb7698061ad2c4a25c894f47d8c162b4d7213d0510b4a6ba6700000080010000800200008000</pre>
** Base64 String: <pre>cHNidP8BAKACAAAAAqsJSaCMWvfEm4IS9Bfi8Vqz9cM9zxU4IagTn4d6W3vkAAAAAAD+////qwlJoIxa98SbghL0F+LxWrP1wz3PFTghqBOfh3pbe+QBAAAAAP7///8CYDvqCwAAAAAZdqkUdopAu9dAy+gdmI5x3ipNXHE5ax2IrI4kAAAAAAAAGXapFG9GILVT+glechue4O/p+gOcykWXiKwAAAAAAAEBItPf9QUAAAAAGXapFNSO0xELlAFMsRS9Mtb00GbcdCVriKwAAQEgAOH1BQAAAAAXqRQ1RebjO4MsRwUPJNPuuTycA5SLx4cBBBYAFIXRNTfy4mVAWjTbr6nj3aAfuCMIACICAurVlmh8qAYEPtw94RbN8p1eklfBls0FXPaYyNAr8k6ZELSmumcAAACAAAAAgAIAAIAAIgIDlPYr6d8ZlSxVh3aK63aYBhrSxKJciU9H2MFitNchPQUQtKa6ZwAAAIABAACAAgAAgAA=</pre>

* Case: redeemScript with non-witness UTXO does not match the scriptPubKey
** Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f618765000000220202dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d7483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01010304010000000104475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752af2206029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f10d90c6a4f000000800000008000000080220602dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d710d90c6a4f0000008000000080010000800001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8872202023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e73473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d2010103040100000001042200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903010547522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae2206023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7310d90c6a4f000000800000008003000080220603089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc10d90c6a4f00000080000000800200008000220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre>
** Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAAiAgLath/0mhTban0CsM0fu3j8SxgxK1tOVNrk26L7/vU210gwRQIhAPYQOLMI3B2oZaNIUnRvAVdyk0IIxtJEVDk82ZvfIhd3AiAFbmdaZ1ptCgK4WxTl4pB02KJam1dgvqKBb2YZEKAG6gEBAwQBAAAAAQRHUiEClYO/Oa4KYJdHrRma3dY0+mEIVZ1sXNObTCGD8auW4H8hAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXUq8iBgKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfxDZDGpPAAAAgAAAAIAAAACAIgYC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtcQ2QxqTwAAAIAAAACAAQAAgAABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohyICAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBAQMEAQAAAAEEIgAgjCNTFzdDtZXftKB7crqOQuN5fadOh/59nXSX47ICiQMBBUdSIQMIncEMesbbVPkTKa9hczPbOIzq0MIx9yM3nRuZAwsC3CECOt2QTz1tz1nduQaw3uI1Kbf/ue1Q5ehhUZJoYCIfDnNSriIGAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zENkMak8AAACAAAAAgAMAAIAiBgMIncEMesbbVPkTKa9hczPbOIzq0MIx9yM3nRuZAwsC3BDZDGpPAAAAgAAAAIACAACAACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=</pre>

* Case: redeemScript with witness UTXO does not match the scriptPubKey
** Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f618765000000220202dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d7483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01010304010000000104475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae2206029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f10d90c6a4f000000800000008000000080220602dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d710d90c6a4f0000008000000080010000800001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8872202023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e73473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d2010103040100000001042200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028900010547522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae2206023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7310d90c6a4f000000800000008003000080220603089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc10d90c6a4f00000080000000800200008000220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre>
** Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAAiAgLath/0mhTban0CsM0fu3j8SxgxK1tOVNrk26L7/vU210gwRQIhAPYQOLMI3B2oZaNIUnRvAVdyk0IIxtJEVDk82ZvfIhd3AiAFbmdaZ1ptCgK4WxTl4pB02KJam1dgvqKBb2YZEKAG6gEBAwQBAAAAAQRHUiEClYO/Oa4KYJdHrRma3dY0+mEIVZ1sXNObTCGD8auW4H8hAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXUq4iBgKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfxDZDGpPAAAAgAAAAIAAAACAIgYC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtcQ2QxqTwAAAIAAAACAAQAAgAABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohyICAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBAQMEAQAAAAEEIgAgjCNTFzdDtZXftKB7crqOQuN5fadOh/59nXSX47ICiQABBUdSIQMIncEMesbbVPkTKa9hczPbOIzq0MIx9yM3nRuZAwsC3CECOt2QTz1tz1nduQaw3uI1Kbf/ue1Q5ehhUZJoYCIfDnNSriIGAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zENkMak8AAACAAAAAgAMAAIAiBgMIncEMesbbVPkTKa9hczPbOIzq0MIx9yM3nRuZAwsC3BDZDGpPAAAAgAAAAIACAACAACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=</pre>

* Case: witnessScript with witness UTXO does not match the redeemScript
** Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f618765000000220202dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d7483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01010304010000000104475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae2206029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f10d90c6a4f000000800000008000000080220602dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d710d90c6a4f0000008000000080010000800001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8872202023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e73473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d2010103040100000001042200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903010547522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ad2206023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7310d90c6a4f000000800000008003000080220603089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc10d90c6a4f00000080000000800200008000220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre>
** Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAAiAgLath/0mhTban0CsM0fu3j8SxgxK1tOVNrk26L7/vU210gwRQIhAPYQOLMI3B2oZaNIUnRvAVdyk0IIxtJEVDk82ZvfIhd3AiAFbmdaZ1ptCgK4WxTl4pB02KJam1dgvqKBb2YZEKAG6gEBAwQBAAAAAQRHUiEClYO/Oa4KYJdHrRma3dY0+mEIVZ1sXNObTCGD8auW4H8hAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXUq4iBgKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfxDZDGpPAAAAgAAAAIAAAACAIgYC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtcQ2QxqTwAAAIAAAACAAQAAgAABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohyICAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBAQMEAQAAAAEEIgAgjCNTFzdDtZXftKB7crqOQuN5fadOh/59nXSX47ICiQMBBUdSIQMIncEMesbbVPkTKa9hczPbOIzq0MIx9yM3nRuZAwsC3CECOt2QTz1tz1nduQaw3uI1Kbf/ue1Q5ehhUZJoYCIfDnNSrSIGAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zENkMak8AAACAAAAAgAMAAIAiBgMIncEMesbbVPkTKa9hczPbOIzq0MIx9yM3nRuZAwsC3BDZDGpPAAAAgAAAAIACAACAACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=</pre>

The private keys in the tests below are derived from the following master private key:

* Extended Private Key: <pre>tprv8ZgxMBicQKsPd9TeAdPADNnSyH9SSUUbTVeFszDE23Ki6TBB5nCefAdHkK8Fm3qMQR6sHwA56zqRmKmxnHk37JkiFzvncDqoKmPWubu7hDF</pre>
** Seed: <pre>cUkG8i1RFfWGWy5ziR11zJ5V4U4W3viSFCfyJmZnvQaUsd1xuF3T</pre>

A creator creating a PSBT for a transaction which creates the following outputs:

* scriptPubKey: 0014d85c2b71d0060b09c9886aeb815e50991dda124d, Amount: 1.49990000
* scriptPubKey: 001400aea9a2e5f0f876a588df5546e8742d1d87008f, Amount: 1.00000000

and spends the following inputs:

* TXID: 75ddabb27b8845f5247975c8a5ba7c6f336c4570708ebe230caf6db5217ae858, Index: 0
* TXID: 1dea7cd05979072a3578cab271c02244ea8a090bbb46aa680a65ecd027048d83, Index: 1

must create this PSBT:
* Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f000000000000000000</pre>
* Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAAAAAA=</pre>

Given the above PSBT, an updater with only the following:

* Redeem Scripts:
** 5221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae
** 00208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903
* Witness Scripts:
** 522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae
* Previous Transactions:
** <pre>0200000000010158e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd7501000000171600145f275f436b09a8cc9a2eb2a2f528485c68a56323feffffff02d8231f1b0100000017a914aed962d6654f9a2b36608eb9d64d2b260db4f1118700c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e88702483045022100a22edcc6e5bc511af4cc4ae0de0fcd75c7e04d8c1c3a8aa9d820ed4b967384ec02200642963597b9b1bc22c75e9f3e117284a962188bf5e8a74c895089046a20ad770121035509a48eb623e10aace8bfd0212fdb8a8e5af3c94b0b133b95e114cab89e4f7965000000</pre>
** <pre>0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f618765000000</pre>
* Public Keys
** Key: 029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f, Derivation Path: m/0'/0'/0'
** Key: 02dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d7, Derivation Path: m/0'/0'/1'
** Key: 03089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc, Derivation Path: m/0'/0'/2'
** Key: 023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e73, Derivation Path: m/0'/0'/3'
** Key: 03a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca58771, Derivation Path: m/0'/0'/4'
** Key: 027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b50051096, Derivation Path: m/0'/0'/5'

Must create this PSBT:

* Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000000104475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae2206029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f10d90c6a4f000000800000008000000080220602dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d710d90c6a4f0000008000000080010000800001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e88701042200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903010547522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae2206023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7310d90c6a4f000000800000008003000080220603089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc10d90c6a4f00000080000000800200008000220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre>
* Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAABBEdSIQKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfyEC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtdSriIGApWDvzmuCmCXR60Zmt3WNPphCFWdbFzTm0whg/GrluB/ENkMak8AAACAAAAAgAAAAIAiBgLath/0mhTban0CsM0fu3j8SxgxK1tOVNrk26L7/vU21xDZDGpPAAAAgAAAAIABAACAAAEBIADC6wsAAAAAF6kUt/X69A49QKWkWbHbNTXyty+pIeiHAQQiACCMI1MXN0O1ld+0oHtyuo5C43l9p06H/n2ddJfjsgKJAwEFR1IhAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcIQI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8Oc1KuIgYCOt2QTz1tz1nduQaw3uI1Kbf/ue1Q5ehhUZJoYCIfDnMQ2QxqTwAAAIAAAACAAwAAgCIGAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcENkMak8AAACAAAAAgAIAAIAAIgIDqaTDf1mW06ol26xrVwrwZQOUSSlCRgs1R1Ptnuylh3EQ2QxqTwAAAIAAAACABAAAgAAiAgJ/Y5l1fS7/VaE2rQLGhLGDi2VW5fG2s0KCqUtrUAUQlhDZDGpPAAAAgAAAAIAFAACAAA==</pre>

An updater which adds SIGHASH_ALL to the above PSBT must create this PSBT:

* Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f618765000000010304010000000104475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae2206029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f10d90c6a4f000000800000008000000080220602dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d710d90c6a4f0000008000000080010000800001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870103040100000001042200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903010547522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae2206023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7310d90c6a4f000000800000008003000080220603089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc10d90c6a4f00000080000000800200008000220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre>
* Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAABAwQBAAAAAQRHUiEClYO/Oa4KYJdHrRma3dY0+mEIVZ1sXNObTCGD8auW4H8hAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXUq4iBgKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfxDZDGpPAAAAgAAAAIAAAACAIgYC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtcQ2QxqTwAAAIAAAACAAQAAgAABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohwEDBAEAAAABBCIAIIwjUxc3Q7WV37Sge3K6jkLjeX2nTof+fZ10l+OyAokDAQVHUiEDCJ3BDHrG21T5EymvYXMz2ziM6tDCMfcjN50bmQMLAtwhAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zUq4iBgI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8OcxDZDGpPAAAAgAAAAIADAACAIgYDCJ3BDHrG21T5EymvYXMz2ziM6tDCMfcjN50bmQMLAtwQ2QxqTwAAAIAAAACAAgAAgAAiAgOppMN/WZbTqiXbrGtXCvBlA5RJKUJGCzVHU+2e7KWHcRDZDGpPAAAAgAAAAIAEAACAACICAn9jmXV9Lv9VoTatAsaEsYOLZVbl8bazQoKpS2tQBRCWENkMak8AAACAAAAAgAUAAIAA</pre>

Given the above updated PSBT, a signer that supports SIGHASH_ALL for P2PKH and P2WPKH spends and uses RFC6979 for nonce generation and has the following keys:
* cP53pDbR5WtAD8dYAW9hhTjuvvTVaEiQBdrz9XPrgLBeRFiyCbQr (m/0'/0'/0')
* cR6SXDoyfQrcp4piaiHE97Rsgta9mNhGTen9XeonVgwsh4iSgw6d (m/0'/0'/2')
must create this PSBT:

* Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000002202029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01010304010000000104475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae2206029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f10d90c6a4f000000800000008000000080220602dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d710d90c6a4f0000008000000080010000800001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e887220203089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f010103040100000001042200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903010547522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae2206023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7310d90c6a4f000000800000008003000080220603089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc10d90c6a4f00000080000000800200008000220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre>
* Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAAiAgKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgf0cwRAIgdAGK1BgAl7hzMjwAFXILNoTMgSOJEEjn282bVa1nnJkCIHPTabdA4+tT3O+jOCPIBwUUylWn3ZVE8VfBZ5EyYRGMAQEDBAEAAAABBEdSIQKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfyEC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtdSriIGApWDvzmuCmCXR60Zmt3WNPphCFWdbFzTm0whg/GrluB/ENkMak8AAACAAAAAgAAAAIAiBgLath/0mhTban0CsM0fu3j8SxgxK1tOVNrk26L7/vU21xDZDGpPAAAAgAAAAIABAACAAAEBIADC6wsAAAAAF6kUt/X69A49QKWkWbHbNTXyty+pIeiHIgIDCJ3BDHrG21T5EymvYXMz2ziM6tDCMfcjN50bmQMLAtxHMEQCIGLrelVhB6fHP0WsSrWh3d9vcHX7EnWWmn84Pv/3hLyyAiAMBdu3Rw2/LwhVfdNWxzJcHtMJE+mWzThAlF2xIijaXwEBAwQBAAAAAQQiACCMI1MXN0O1ld+0oHtyuo5C43l9p06H/n2ddJfjsgKJAwEFR1IhAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcIQI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8Oc1KuIgYCOt2QTz1tz1nduQaw3uI1Kbf/ue1Q5ehhUZJoYCIfDnMQ2QxqTwAAAIAAAACAAwAAgCIGAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcENkMak8AAACAAAAAgAIAAIAAIgIDqaTDf1mW06ol26xrVwrwZQOUSSlCRgs1R1Ptnuylh3EQ2QxqTwAAAIAAAACABAAAgAAiAgJ/Y5l1fS7/VaE2rQLGhLGDi2VW5fG2s0KCqUtrUAUQlhDZDGpPAAAAgAAAAIAFAACAAA==</pre>

Given the above updated PSBT, a signer with the following keys:
* cT7J9YpCwY3AVRFSjN6ukeEeWY6mhpbJPxRaDaP5QTdygQRxP9Au (m/0'/0'/1')
* cNBc3SWUip9PPm1GjRoLEJT6T41iNzCYtD7qro84FMnM5zEqeJsE (m/0'/0'/3')
must create this PSBT:

* Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f618765000000220202dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d7483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01010304010000000104475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae2206029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f10d90c6a4f000000800000008000000080220602dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d710d90c6a4f0000008000000080010000800001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8872202023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e73473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d2010103040100000001042200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903010547522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae2206023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7310d90c6a4f000000800000008003000080220603089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc10d90c6a4f00000080000000800200008000220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre>
* Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAAiAgLath/0mhTban0CsM0fu3j8SxgxK1tOVNrk26L7/vU210gwRQIhAPYQOLMI3B2oZaNIUnRvAVdyk0IIxtJEVDk82ZvfIhd3AiAFbmdaZ1ptCgK4WxTl4pB02KJam1dgvqKBb2YZEKAG6gEBAwQBAAAAAQRHUiEClYO/Oa4KYJdHrRma3dY0+mEIVZ1sXNObTCGD8auW4H8hAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXUq4iBgKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfxDZDGpPAAAAgAAAAIAAAACAIgYC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtcQ2QxqTwAAAIAAAACAAQAAgAABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohyICAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBAQMEAQAAAAEEIgAgjCNTFzdDtZXftKB7crqOQuN5fadOh/59nXSX47ICiQMBBUdSIQMIncEMesbbVPkTKa9hczPbOIzq0MIx9yM3nRuZAwsC3CECOt2QTz1tz1nduQaw3uI1Kbf/ue1Q5ehhUZJoYCIfDnNSriIGAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zENkMak8AAACAAAAAgAMAAIAiBgMIncEMesbbVPkTKa9hczPbOIzq0MIx9yM3nRuZAwsC3BDZDGpPAAAAgAAAAIACAACAACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=</pre>

Given both of the above PSBTs, a combiner must create this PSBT:

* Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000002202029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01220202dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d7483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01010304010000000104475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae2206029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f10d90c6a4f000000800000008000000080220602dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d710d90c6a4f0000008000000080010000800001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e887220203089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f012202023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e73473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d2010103040100000001042200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903010547522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae2206023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7310d90c6a4f000000800000008003000080220603089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc10d90c6a4f00000080000000800200008000220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre>
* Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAAiAgKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgf0cwRAIgdAGK1BgAl7hzMjwAFXILNoTMgSOJEEjn282bVa1nnJkCIHPTabdA4+tT3O+jOCPIBwUUylWn3ZVE8VfBZ5EyYRGMASICAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXSDBFAiEA9hA4swjcHahlo0hSdG8BV3KTQgjG0kRUOTzZm98iF3cCIAVuZ1pnWm0KArhbFOXikHTYolqbV2C+ooFvZhkQoAbqAQEDBAEAAAABBEdSIQKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfyEC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtdSriIGApWDvzmuCmCXR60Zmt3WNPphCFWdbFzTm0whg/GrluB/ENkMak8AAACAAAAAgAAAAIAiBgLath/0mhTban0CsM0fu3j8SxgxK1tOVNrk26L7/vU21xDZDGpPAAAAgAAAAIABAACAAAEBIADC6wsAAAAAF6kUt/X69A49QKWkWbHbNTXyty+pIeiHIgIDCJ3BDHrG21T5EymvYXMz2ziM6tDCMfcjN50bmQMLAtxHMEQCIGLrelVhB6fHP0WsSrWh3d9vcHX7EnWWmn84Pv/3hLyyAiAMBdu3Rw2/LwhVfdNWxzJcHtMJE+mWzThAlF2xIijaXwEiAgI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8Oc0cwRAIgZfRbpZmLWaJ//hp77QFq8fH5DVSzqo90UKpfVqJRA70CIH9yRwOtHtuWaAsoS1bU/8uI9/t1nqu+CKow8puFE4PSAQEDBAEAAAABBCIAIIwjUxc3Q7WV37Sge3K6jkLjeX2nTof+fZ10l+OyAokDAQVHUiEDCJ3BDHrG21T5EymvYXMz2ziM6tDCMfcjN50bmQMLAtwhAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zUq4iBgI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8OcxDZDGpPAAAAgAAAAIADAACAIgYDCJ3BDHrG21T5EymvYXMz2ziM6tDCMfcjN50bmQMLAtwQ2QxqTwAAAIAAAACAAgAAgAAiAgOppMN/WZbTqiXbrGtXCvBlA5RJKUJGCzVHU+2e7KWHcRDZDGpPAAAAgAAAAIAEAACAACICAn9jmXV9Lv9VoTatAsaEsYOLZVbl8bazQoKpS2tQBRCWENkMak8AAACAAAAAgAUAAIAA</pre>

Given the above PSBT, an input finalizer must create this PSBT:

* Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000000107da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae0001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870107232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b20289030108da0400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre>
* Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAABB9oARzBEAiB0AYrUGACXuHMyPAAVcgs2hMyBI4kQSOfbzZtVrWecmQIgc9Npt0Dj61Pc76M4I8gHBRTKVafdlUTxV8FnkTJhEYwBSDBFAiEA9hA4swjcHahlo0hSdG8BV3KTQgjG0kRUOTzZm98iF3cCIAVuZ1pnWm0KArhbFOXikHTYolqbV2C+ooFvZhkQoAbqAUdSIQKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfyEC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtdSrgABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohwEHIyIAIIwjUxc3Q7WV37Sge3K6jkLjeX2nTof+fZ10l+OyAokDAQjaBABHMEQCIGLrelVhB6fHP0WsSrWh3d9vcHX7EnWWmn84Pv/3hLyyAiAMBdu3Rw2/LwhVfdNWxzJcHtMJE+mWzThAlF2xIijaXwFHMEQCIGX0W6WZi1mif/4ae+0BavHx+Q1Us6qPdFCqX1aiUQO9AiB/ckcDrR7blmgLKEtW1P/LiPf7dZ6rvgiqMPKbhROD0gFHUiEDCJ3BDHrG21T5EymvYXMz2ziM6tDCMfcjN50bmQMLAtwhAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zUq4AIgIDqaTDf1mW06ol26xrVwrwZQOUSSlCRgs1R1Ptnuylh3EQ2QxqTwAAAIAAAACABAAAgAAiAgJ/Y5l1fS7/VaE2rQLGhLGDi2VW5fG2s0KCqUtrUAUQlhDZDGpPAAAAgAAAAIAFAACAAA==</pre>

Given the above PSBT, a transaction extractor must create this Bitcoin transaction:

* Bytes in Hex: <pre>0200000000010258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd7500000000da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752aeffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d01000000232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f000400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00000000</pre>

Given these two PSBTs with unknown key-value pairs:
* Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a0100000000000af00102030405060708090f0102030405060708090a0b0c0d0e0f000af00102030405060708090f0102030405060708090a0b0c0d0e0f000af00102030405060708090f0102030405060708090a0b0c0d0e0f00</pre>
** Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAK8AECAwQFBgcICQ8BAgMEBQYHCAkKCwwNDg8ACvABAgMEBQYHCAkPAQIDBAUGBwgJCgsMDQ4PAArwAQIDBAUGBwgJDwECAwQFBgcICQoLDA0ODwA=</pre>

* Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a0100000000000af00102030405060708100f0102030405060708090a0b0c0d0e0f000af00102030405060708100f0102030405060708090a0b0c0d0e0f000af00102030405060708100f0102030405060708090a0b0c0d0e0f00</pre>
** Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAK8AECAwQFBgcIEA8BAgMEBQYHCAkKCwwNDg8ACvABAgMEBQYHCBAPAQIDBAUGBwgJCgsMDQ4PAArwAQIDBAUGBwgQDwECAwQFBgcICQoLDA0ODwA=</pre>

A combiner which orders keys lexicographically must produce the following PSBT:

* Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a0100000000000af00102030405060708090f0102030405060708090a0b0c0d0e0f0af00102030405060708100f0102030405060708090a0b0c0d0e0f000af00102030405060708090f0102030405060708090a0b0c0d0e0f0af00102030405060708100f0102030405060708090a0b0c0d0e0f000af00102030405060708090f0102030405060708090a0b0c0d0e0f0af00102030405060708100f0102030405060708090a0b0c0d0e0f00</pre>
* Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAK8AECAwQFBgcICQ8BAgMEBQYHCAkKCwwNDg8K8AECAwQFBgcIEA8BAgMEBQYHCAkKCwwNDg8ACvABAgMEBQYHCAkPAQIDBAUGBwgJCgsMDQ4PCvABAgMEBQYHCBAPAQIDBAUGBwgJCgsMDQ4PAArwAQIDBAUGBwgJDwECAwQFBgcICQoLDA0ODwrwAQIDBAUGBwgQDwECAwQFBgcICQoLDA0ODwA=</pre>

==Rationale==

<references/>

==Reference implementation==

The reference implementation of the PSBT format is available at https://github.com/achow101/bitcoin/tree/psbt.

==Acknowledgements==

Special thanks to Pieter Wuille for suggesting that such a transaction format should be made
and for coming up with the name and abbreviation of PSBT.

Thanks to Pieter Wuille, Gregory Maxwell, Jonathan Underwood, Daniel Cousens and those who commented on the bitcoin-dev mailing list for additional comments
and suggestions for improving this proposal.

Original Bitcoin client

2022-06-19T20:38:27Z

Manu: link broken, added archive.org version

The '''Satoshi [[Clients|client]]''' or the '''Satoshi code''' refers to [[bitcoind]], bitcoin-client, bitcoin-qt and [[Bitcoin Core]]. This is in honor of [[Satoshi Nakamoto]] for creating [[Bitcoin]].
<dl>
<dt>In the most widest sense:
<dd>All releases of bitcoin-x.y.z (starting 2009) and future official releases by the [https://bitcoin.org/en/development "bitcoin core developers"]. 
<dt>In the narrow sense:
<dd>Only the bitcoin releases up to version 0.3.19 which Satoshi Nakamoto himself was chief and main developer. He retired afterwards (end of 2010) completely from this project. With the next release also [[Testnet]] was reset with a new genesis block.
<dt>Original Satoshi clients:
<dd>Only the bitcoin releases 0.1.0 up to 0.1.5 which supported only Windows 2000 / Windows NT and Windows XP (perhaps Windows Vista). The next bitcoin release 0.2.0 from Dec 2009, nearly a year later, starts to support Linux and the [https://bitcointalk.org/index.php?topic=5.0 community] got more and more actively involved in the development.
</dl>
For history, one of the earliest available proof of a running bitcoin-0.1.0 with a [https://web.archive.org/web/20130521105629/http://sourceforge.net/mailarchive/attachment.php?list_name=bitcoin-list&message_id=da7b3ce30901101113v2ec6bf61xf018265479eb7faf%40mail.gmail.com&counter=1 human readable debug log].
There might have been also (private) earlier client code before 0.1.0 available only to Satoshi Nakamoto.
==See also==
* [[Running Bitcoin]]
* [[Bitcoind#History of official bitcoind (and predecessor) releases|History of Bitcoind]]
* [[Original_Bitcoin_client/API_calls_list|Original Bitcoin client API]]

{{Bitcoin Core documentation}}

Fallback Nodes

2022-06-17T21:28:08Z

Manu: /* Tor network */

This is a list of nodes which are considered reliable.

== How to use this list ==

=== Connect to nodes ===

You can connect to these nodes with the ''-addnode=ip'' switch instead of the usual node harvesting process (through IRC or via the embedded nodelist). You can connect to more than one node by using ''-addnode=ip'' more than once. It is usually a good idea to connect to more than one of these nodes.

==== Nodes without a fixed ip ====

If the node IP is not fixed (see "Fixed" column), you will have to resolve the node's name (first column) each time the IP changes. Some nodes may have their ip change once a day, some others once a month, and some others may stay on the same IP for years. Still, as long as the IP is not fixed, there is no guarantee it will stay the same.

In order to enable hostname lookups for the ''-addnode'' and ''-connect'' parameters, you must additionally provide the ''-dns'' parameter. Example:
bitcoind -dns -addnode=bitcoin.es

Versions prior to 0.3.22 do not support hostnames to the ''-addnode'' parameter, so you must do the resolving part for it. For example on linux:
bitcoind -addnode=$(dig +short bitcoin.es)

=== IP Transactions ===

[[Bitcoin Core]] versions prior to 0.8.0 also could send [[IP Transactions]] to these nodes. If you included your bitcoin address in the "message" field, you might have had your coins back.

=== Tor network ===

BitcoinCore will automatically use Tor if it is available at default (''127.0.0.1:9050''), to use Bitcoin-Qt over Tor hidden services '''only''', in a terminal/console enter:
bitcoin-qt -proxy=127.0.0.1:9050 -onlynet=tor

To use Bitcoin with one specific Tor node, run
bitcoin-qt -proxy=127.0.0.1:9050 -connect=abcde.onion
, where abcde.onion needs to be substituted with one of the [[Fallback_Nodes#Tor_nodes|Tor nodes below]]. These parameters can be added to [[Running_Bitcoin#Bitcoin.conf_Configuration_File|bitcoin.conf]] to make them permanent.

More details on how to execute BitcoinCore with Tor see [[Setting_up_a_Tor_hidden_service|Setting up a Tor hidden service]]. You can find detailed information on running clients and hidden services within Tor in the [https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md documentation].

== Nodes list ==

=== IPv4 Nodes ===

This entire list was last checked on 2017-11-15.

{|class="wikitable sortable"
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-

|-
| bitcoin.moneypot.com || [https://www.moneypot.com moneypot] || 212.47.228.216 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || 2015-09-15 || No
|-
| node.bitcoin.xxx || [http://www.bitcoin.xxx Bitcoin.xxx] || 66.228.49.201 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || 2014-08-28 || Yes
|-
| bitcoin.coinprism.com || [[Coinprism]] || 137.116.225.142 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || 2014-04-26 || Yes
|-
| btcnode1.evolyn.net || Evolyn || 85.214.251.25 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || 2014-01-26 || Yes
|-
| InductiveSoul.US || [[User:Inductivesoul|Inductive Soul]] || 67.186.224.85 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || 2013-11-13 || Yes
|-
| archivum.info || Ferraro Ltd.|| 88.198.58.172 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| 62.75.216.13 || exMULTI, Inc. || 62.75.216.13 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No
|-
| 69.64.34.118 || exMULTI, Inc. || 69.64.34.118 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No
|-
| 79.160.221.140 || K-Norway || 79.160.221.140 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| netzbasis.de || unknown3 || 81.169.129.25 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| btc.turboadmin.com || osmosis || 98.143.152.14 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No
|-
| fallback.bitcoin.zhoutong.com || Zhou Tong || 117.121.241.140 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No
|-
| bauhaus.csail.mit.edu || imsaguy || 128.30.96.44 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| jun.dashjr.org || Luke-Jr || 173.242.112.53 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || 2017-11-15 ||
|-
| cheaperinbitcoins.com || Xenland/Shane || 184.154.36.82 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| django.webflows.fr || unknown2 || 188.165.213.169 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| 204.9.55.71 || toasty || 204.9.55.71 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| btcnode.novit.ro || ovidiusoft - novit.ro || 93.187.142.114 || {{Table Value No}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| porgressbar.sk || progressbar hackerspace || 91.210.181.21 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| faucet.bitcoin.st || bitcoin street || 64.27.57.225 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| bitcoin.securepayment.cc || SecurePayment CC || 63.247.147.163 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| www.dcscdn.com || [[User:Danw12|Danw12]] || 199.115.228.181 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || ||
|-
| ns2.dcscdn.com || [[User:Danw12|Danw12]] || 199.115.228.182 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || ||
|-
| coin.soul-dev.com || Soul-Dev || || || {{Fallback Nodes/Node Down}} || ||
|-
| messier.bzfx.net || BZFX/[[User:A Meteorite|A Meteorite]] || 91.121.205.50 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || ||
|-
| btcnode1.bitgroup.cc || BitGroup || 198.211.116.191 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| btcnode2.bitgroup.cc || BitGroup || 162.243.120.138 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| btcnode3.bitgroup.cc || BitGroup || 95.85.8.237 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| btcnode.xiro.co || Xiro Labs || 91.121.108.61 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || 2017-11-15 || No
|-
| stuff.liam-w.io || [[User:liamwli|Liam W]] || 185.122.57.203 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No
|-
| bitcoin.bitdonut.co || James Hartig || || || {{Fallback Nodes/Node Down}} || ||
|-
| coinno.de || jaknam || || || {{Fallback Nodes/Node Down}} || ||
|-
| 82.165.44.44 || anonymous || || || {{Fallback Nodes/Node Down}} || ||
|-
| bitcoin1.dassori.me || gdassori || || || {{Fallback Nodes/Node Down}} || ||
|-
| bitcoin2.dassori.me || gdassori || || || {{Fallback Nodes/Node Down}} || ||
|-
| blockchainnode.meulie.net || [[User:Evert|Evert]] || || || {{Fallback Nodes/Node Up}} || 2017-11-15 ||
|-
| fullnode.fybsg.com || Nagato || || || {{Fallback Nodes/Node Down}} || ||
|-
| n.bitcoin-fr.io || [[User:Arthur|Arthur]] || 62.210.66.227 || || {{Fallback Nodes/Node Up}} || 2017-11-15 ||
|-
| homeplex.tk || [[User:Victorsueca|Victorsueca]] || 90.165.120.190 || || {{Fallback Nodes/Node Down}} || ||
|-
| mars.jordandoyle.uk || [https://doyle.wf Jordan Doyle] || 91.121.83.82 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes

|}

=== IPv6 Nodes ===
{|class="wikitable sortable"
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-

| InductiveSoul.US || [[User:Inductivesoul|Inductive Soul]] || 2601:7:6680:2ac:4d29:40ff:7513:fcc7 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || 11-13-2013 (MDY) || Yes
|-
| caffeinator.net || [[User:Atrophy|Atrophy]] || || || {{Fallback Nodes/Node Up}} || 2013-05-10 ||
|-
| 2001:470:8:2e1::40 || ? || 2001:470:8:2e1::40 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| messier.bzfx.net || BZFX/[[User:A Meteorite|A Meteorite]] || 2001:41d0:1:d632::1 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || ||
|-
| stuff.liam-w.io || [[User:liamwli|Liam W]] || 2a06:8ec0:3::1:2e47 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || No
|-
| bitcoin.bitdonut.co || James Hartig || || || || ||
|-
| n.bitcoin-fr.io || [[User:Arthur|Arthur]] || 2001:bc8:c087:2001::1 || || || ||
|-
| mars.jordandoyle.uk || [https://doyle.wf Jordan Doyle] || || || || ||

|}

=== Tor nodes ===

This entire list was last checked on 2018-10-24.

{|class="wikitable sortable"
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-
| nkf5e6b7pl4jfd4a.onion || BlueMatt || Up || 2018-10-24 || No
|}

== Adding a node ==

Before adding yourself as a fallback node, you should be sure your node will stay online for a long time. If a node is offline for more than 24 hours it will be removed from the list.

To add a node in this list, you just need the ip/hostname and your name, the other fields will be filled automatically. Insert the following lines before the <tt>END NODELIST</tt> line:

<nowiki>|-
| ip || your name</nowiki>

==See Also==

* [[Network|Bitcoin Network]]
* [http://nodes.bitcoin.st Fallback Nodes] List of longest running Bitcoin Nodes listed by Country.
* [https://getaddr.bitnodes.io/ Bitnodes project]
* [https://blockchain.info/connected-nodes Recently connected nodes at blockchain.info]

{{Bitcoin Core documentation}}

Hidden Service

2022-06-17T21:27:11Z

Manu: /* See also */

Tor can also provide anonymity to websites and other servers. Servers configured to receive inbound connections only through Tor are called hidden services. Rather than utilizing a server's IP address (and thus its network location,) a hidden service is accessed through its .onion address. The Tor network understands these addresses and can route data to and from hidden services, even to those hosted behind firewall or network address translators (NAT), while preserving the anonymity of both parties. Tor is necessary to access hidden services.

Hidden services have been deployed on the Tor network since 2004. Other than the database that stores the hidden-service descriptors, Tor is decentralized by design; there is no direct readable list of all hidden services, although a number of hidden services catalog publicly known onion addresses.

Because hidden services do not use exit nodes, connection to a hidden service is encrypted end-to-end and not subject to eavesdropping. Contrary to popular opinion, this makes an additional traditional TLS layer atop a hidden service not only redundant, but also pointless. There are, however, security issues involving Tor hidden services. For example, services that are reachable through Tor hidden services ''and'' the public Internet, are susceptible to correlation attacks and thus not perfectly hidden. Other pitfalls include misconfigured services (e.g. identifying information included by default in web server error responses), uptime and downtime statistics, intersection attacks, and user error.

Hidden services can help users store and transact bitcoin with relative privacy and safety.

== See also ==

* [[Tor]]
* [[Setting_up_a_Tor_hidden_service]]

Tor

2022-06-17T21:26:35Z

Manu: /* Bitcoin Core */

'''Tor''' is a distributed 'onion' network, that makes it more difficult for an adversary to track any one peer on the network. Tor also is very useful to access the 'uncensored' internet in countries such as China and Iran. Bitcoin's security model assumes that your node is well connected to the rest of the network, so even in less-censored countries using bitcoin over both Tor and clearnet can avoid being partitioned from the network by the internet service provider. Preserving privacy means not only hiding the content of messages, but also hiding who is talking to whom (traffic analysis). Tor provides anonymous connections that are strongly resistant to both eavesdropping and traffic analysis.

Bitcoin can run easily on the Tor network.

=Tor installation & use=
''todo explain: onion routing (how tor network helps to anonymize), encryption used, exit nodes, routers'' 

Please follow the instructions provided with installation files and read the [http://www.torproject.org/download/download.html.en#warning list of warnings]. ''Tor doesn't magically anonymize all your traffic just because you install it.'' 
Down the page you can find examples how to configure applications to use Tor to anonymize the origin of your traffic. 
[http://www.torproject.org/docs/tor-doc-windows.html.en This] is a detailed installation guide for Windows. Before you setup Bitcoin or mIRC to use Tor, please install Tor and start in. 
[[{{ns:file}}:20110109-tor-running.png]] On the taskbar of your compute you'll see a small green onion when Tor is running.
[[{{ns:file}}:20110109-bitcoin-mirc-vidalia.png]]

'''Note on 2022''': This project that executes Tor service on Windows with the above interface, and display an icon on the taskbar is called Tor Vidalia Bundle and it's not maintained anymore, deprecated and not recommended. To see how to configure Tor service on Linx or Windows check [[Setting_up_a_Tor_hidden_service|Setting up a Tor hidden service]].

= Bitcoin Core =

See [[Setting_up_a_Tor_hidden_service|Setting up a Tor hidden service]], ''see also [https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md Bitcoin Core instructions for Tor]''.

==GUI==
Once you have your Tor client up & running, you can configure your Bitcoin client to use it. 
Select in menu Settings -> Options 
[[{{ns:file}}:20110108-btc-options.png]] 

Check "Connect through socks 4 proxy" with the address 127.0.0.1 and port 9050 (the Tor default port number) 
[[{{ns:file}}:20110108-btc-client-tor-as-proxy.png]] 
Configuring an application to use Tor is also called to torify it.
(needs a brief howto here)

''the note about bitcoin-otc promote on a more appropriate place in this page? reference to trading and IRC''
Conducting business using [[bitcoin-otc]] can be done more anonymously when directly connected to a Freenode IRC hidden service.

==bitcoind==

Run bitcoind with -proxy=127.0.0.1:9050 (or whatever your SocksPort is).

bitcoind will detect that you are using a proxy on 9050 and will force the "nolisten" flag. If you are not running tor on 9050, you need to set "nolisten" manually otherwise you will listen on your public IP and possibly reveal that you are running a node.

=Hidden services=
[[Hidden Service| Hidden services]] run within the Tor network and can be connected to using the -connect= parameter to bitcoind so long as bitcoin is configured to use a Tor proxy. Bitcoin users do not need to use hidden services, since Tor can be used to increase anonymity of normal internet traffic, including bitcoin connections, but there are some technical reasons why hidden services may be beneficial; for more information see the Tor project's documentation.

Services are listed at [[Fallback_Nodes#Tor_network]] along with instructions for using them.

=Pooled Mining=

Some mining pools are available as a hidden service on the tor network. Any pool can be reached over tor. The general methodology here is to tell your mining client to use your local Tor proxy. This is client specific but there are some helpful hints.

==Linux / BSD==

Any client can have its traffic routed via Tor by using the torify command and invoking the miner with that. Another method is to set the http_proxy environment variable as some miners use libraries which support that.

==Windows / OS X==

It is possible to set the http_proxy environment variable as some miners use libraries which support that.

=mIRC=

mIRC is a popular IRC client. This is a guide how to connect to Freenode IRC using Tor + SASL + mIRC. 
==Register your nick with freenode nickserv ==
Freenode only allows SASL authenticated users to connect to the onion IRC server. SASL authentication works only with a registered nickname. 
Connect to Freenode IRC without using tor & execute 
/msg nickserv register <password> <email> 
 
You will see something like this 
-NickServ- An email containing nickname activation instructions has been sent to <email> 
-NickServ- If you do not complete registration within one day, your nickname will expire. 
 
To finish your nick registration go the provided email and copy/paste the command from e-mail to irc. 

==Add SASL support to your mIRC installation ==
Download the SASL.dll and sasl.mrc files and copy them to your mIRC installation directory 
Load sasl.mrc script (Alt + R to open script editor, Ctrl + L to load file, browse to sasl.mrc, press OK or "save & exit"). 
[[{{ns:file}}:20110109-sasl-script-loaded.png]] 
Type /dialog -m SASL.main SASL.main to open the SASL connection manager. 
[[{{ns:file}}:20110109-sasl-dialog.png]] 
Add Freenode entry. 
[[{{ns:file}}:20110109-sasl-manager.png]][[{{ns:file}}:20110109-sasl-manager-network.png]] 
Network is Freenode. 
Username and NS Password must match your nickserv reservation. 
Auth Type can be PLAIN 

==setup mIRC to use Tor ==
Add the entry for Freenode onion IRC server 
[[{{ns:file}}:20110109-onion-irc-add.png]] 
Configure mIRC to use a Proxy (your local Tor proxy) 
[[{{ns:file}}:20110109-mirc-proxy.png]] 
 
Now you should be able to connect. 
[https://www.bitcointalk.org/index.php?topic=2602 Bitcoin forum where this topic is discussed]

=How Tor works=
Unlike Freenet, I2P, etc., Tor's security is very well-defined. While weaknesses do exist (described below), they have been known since Tor was created, and new weaknesses of significance are not expected.

Tor sends TCP packets over 3 (normal) or 7 (hidden services) Tor relays. This is why it is so slow: your packet might have to go through 100 computers (counting Internet routers) before it reaches its destination. Tor uses multiple ''layers'' of encryption that are ''pulled away'' for each node. Hence the name '''T'''he '''O'''nion '''R'''outer, which is always capitalized as '''Tor''', and never TOR or t.o.r.

Say that I want to connect to bitcoin.org through Tor. I first select three Tor relays that I know about. Then, I send a message to my ISP that looks like this:
Send to this IP: <IP of Relay1>
<Encrypted data for Relay1>
When Relay1 receives this, he decrypts the payload using his private key. The payload contains this:
Send to this Tor node: <Relay2>
<Encrypted data for Relay2>
Relay2 decrypts his payload:
Send to this Tor node: <Relay3>
<Encrypted data for Relay3>
Relay3 receives the real TCP payload, which he sends to the destination:
Send to this IP: <IP of destination>
<Unencrypted payload>
The payload is not and can not be further encrypted by Tor. However, if the protocol itself uses encryption (HTTPS, SSH, etc.), the data will be encrypted. This means that the last node (the ''exit node'') can see everything you do on HTTP sites, and can steal your passwords if they are transmitted unencrypted. Many people become exit nodes just so they can view this information -- Tor is much more dangerous than open WiFi for snooping!

The encryption arrangement described above ensures that no single Tor node knows both the sender and the destination. Relay1 and your ISP know that you are using Tor and sending a packet at a certain time, but they don't know what you're sending or who you're sending to. Relay3 knows exactly what you're sending, but he can't determine who is sending it because Relay2 and Relay1 are blocking him. All three relays need to work together in order to conclusively connect the sender and the destination.

However, Tor is weak to a ''timing attack'' that allows only two participants in certain positions to determine the sender with high accuracy. Consider this Tor connection:
Sender <-> S-ISP <-> Relay1 <-> Relay2 <-> Relay3 <-> D-ISP <-> Destination
If the sender's ISP (S-ISP) and the destination are working together, they can record the size and times of packets sent and received. Over a large number of packets, they can determine with very high accuracy that the sender is, in fact, the person sending packets to the destination. This requires active surveillance or detailed logging by both sides. Relay1 can also perform the same role as S-ISP.

Additionally, more configurations are possible if the underlying connection is not encrypted (normal HTTP, for example):
*S-ISP & Relay3
*Relay1 & Relay3
*S-ISP & D-ISP
*Relay1 & D-ISP
This second set can always see that the sender is connected to the destination, but they can only see what the sender is doing on the site if the connection is not encrypted. (Pathnames are encrypted in HTTPS.)

Because the first relay (the ''entry node'') is a weak point in the connection, Tor takes certain defensive measures. When you first start Tor, it chooses three ''entry guards'' that don't change for the entire time that you run Tor. You will always use one of those three unless one goes down. If all of those nodes are safe and your ISP is safe, then you are OK.

These timing attacks are of special importance to Bitcoin because anyone can be the "destination" in a connection. Packets are broadcast to every peer in the Bitcoin network. This might allow your ISP alone to associate your transactions to you without much difficulty. However, a timing attack relies on receiving at least several dozen packets from the sender, so the "destination" might actually have to be one of your direct Bitcoin peers. It's not too difficult to flood the Bitcoin network with peers, though. Because of this attack, it is wise to use an [[EWallet]] instead of the Bitcoin client when using Tor.

To discover Tor relays, Tor uses a centralized directory server model. There are nine authoritative directory servers. To become a relay, you register with one of these. The directory servers share their data and produce a ''network status consensus'' document every so often containing all Tor nodes. Tor clients don't connect directly to the authoritative directory servers -- they connect to one of many ''directory mirrors'', which have a copy of the network status consensus. Since there is no peer-to-peer bootstrap mechanism in Tor, the entire network can be destroyed if half of the authoritative directory servers are destroyed, and the entire network can be subverted if half of the authoritative directory servers become evil.

Hidden services allow both the sender and destination to remain anonymous. A hidden service connection is made like this:
*The destination tells several Tor relays to act as ''introduction points'' for the hidden service. The destination stays connected to all of these introduction points through a regular three-node Tor circuit.
*The destination registers these introduction points on a Tor DHT. The introduction points are associated with the first 16 characters of an encoded SHA-1 hash of the destination's key. This is the information in .onion addresses. The use of SHA-1 is a possible weakness.
*The sender creates a four-node Tor circuit. The fourth node is called the ''rendezvous point''.
*The sender searches the DHT for the introduction points of the desired hidden service. The sender connects to one through a regular three-node Tor circuit and, through the introduction point, tells the destination about the rendezvous point he has chosen.
*The destination connects to the rendezvous point over a three-node Tor circuit. The sender and destination are now in contact over a seven-node connection.

For clients, hidden services are more secure than encrypted Tor HTTPS connections because:
*If the destination remains anonymous, they are less likely to become controlled by an evil party.
*The destination's ISP isn't involved as they are in the HTTPS case. Only these configurations are possible for a timing attack:
**S-ISP & Destination
**Relay1 & Destination

Running a hidden service is more dangerous, however. A simple intersection attack can be performed by the hidden service's ISP alone:
*Your Internet service is cut off.
*If the hidden service went down at that exact moment, you are unmasked.
The same sort of timing attacks as above are also possible.

See the [http://www.usenix.org/events/sec04/tech/full_papers/dingledine/dingledine_html/index.html Tor design paper] for more info.

=Exchange Restrictions=

Some exchanges will treat activity occurring through Tor with greater precautions. For instance, the now-defunct Mt. Gox signup sheet read:
: Please be advised that accessing your account via the Tor network and/or public proxies may result in a temporary suspension of your account, and having to submit AML documents.

=External Tor Hidden Services=

* [irc://p4fsi4ockecnea7l.onion Freenode hidden service]

=External links=

* [http://tor.eff.org/ Tor project]
* [http://www.torproject.org/docs/tor-doc-windows.html.en Tor installation guide - Windows]
* [https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ Tor FAQ]
* [http://www.torproject.org/about/overview.html.en how Tor works - overview]
* [http://freenode.net/irc_servers.shtml#tor Freenode over Tor info]
* [http://wiki.honk-honk.org/wiki/SaslServ#mIRC howto enable SASL in mIRC]
* [http://honk-honk.org/SASL/SASL.dll SASL.dll library for mIRC]
* [http://honk-honk.org/SASL/sasl.mrc sasl script for mIRC]
* [http://freenode.net/sasl/ Freenode resources on SASL]

[[Category:Privacy]]

Tor

2022-06-17T21:24:18Z

Manu: /* Tor installation & use */

'''Tor''' is a distributed 'onion' network, that makes it more difficult for an adversary to track any one peer on the network. Tor also is very useful to access the 'uncensored' internet in countries such as China and Iran. Bitcoin's security model assumes that your node is well connected to the rest of the network, so even in less-censored countries using bitcoin over both Tor and clearnet can avoid being partitioned from the network by the internet service provider. Preserving privacy means not only hiding the content of messages, but also hiding who is talking to whom (traffic analysis). Tor provides anonymous connections that are strongly resistant to both eavesdropping and traffic analysis.

Bitcoin can run easily on the Tor network.

=Tor installation & use=
''todo explain: onion routing (how tor network helps to anonymize), encryption used, exit nodes, routers'' 

Please follow the instructions provided with installation files and read the [http://www.torproject.org/download/download.html.en#warning list of warnings]. ''Tor doesn't magically anonymize all your traffic just because you install it.'' 
Down the page you can find examples how to configure applications to use Tor to anonymize the origin of your traffic. 
[http://www.torproject.org/docs/tor-doc-windows.html.en This] is a detailed installation guide for Windows. Before you setup Bitcoin or mIRC to use Tor, please install Tor and start in. 
[[{{ns:file}}:20110109-tor-running.png]] On the taskbar of your compute you'll see a small green onion when Tor is running.
[[{{ns:file}}:20110109-bitcoin-mirc-vidalia.png]]

'''Note on 2022''': This project that executes Tor service on Windows with the above interface, and display an icon on the taskbar is called Tor Vidalia Bundle and it's not maintained anymore, deprecated and not recommended. To see how to configure Tor service on Linx or Windows check [[Setting_up_a_Tor_hidden_service|Setting up a Tor hidden service]].

= Bitcoin Core =

''See also [https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md Bitcoin Core instructions for Tor]''

==GUI==
Once you have your Tor client up & running, you can configure your Bitcoin client to use it. 
Select in menu Settings -> Options 
[[{{ns:file}}:20110108-btc-options.png]] 

Check "Connect through socks 4 proxy" with the address 127.0.0.1 and port 9050 (the Tor default port number) 
[[{{ns:file}}:20110108-btc-client-tor-as-proxy.png]] 
Configuring an application to use Tor is also called to torify it.
(needs a brief howto here)

''the note about bitcoin-otc promote on a more appropriate place in this page? reference to trading and IRC''
Conducting business using [[bitcoin-otc]] can be done more anonymously when directly connected to a Freenode IRC hidden service.

==bitcoind==

Run bitcoind with -proxy=127.0.0.1:9050 (or whatever your SocksPort is).

bitcoind will detect that you are using a proxy on 9050 and will force the "nolisten" flag. If you are not running tor on 9050, you need to set "nolisten" manually otherwise you will listen on your public IP and possibly reveal that you are running a node.

=Hidden services=
[[Hidden Service| Hidden services]] run within the Tor network and can be connected to using the -connect= parameter to bitcoind so long as bitcoin is configured to use a Tor proxy. Bitcoin users do not need to use hidden services, since Tor can be used to increase anonymity of normal internet traffic, including bitcoin connections, but there are some technical reasons why hidden services may be beneficial; for more information see the Tor project's documentation.

Services are listed at [[Fallback_Nodes#Tor_network]] along with instructions for using them.

=Pooled Mining=

Some mining pools are available as a hidden service on the tor network. Any pool can be reached over tor. The general methodology here is to tell your mining client to use your local Tor proxy. This is client specific but there are some helpful hints.

==Linux / BSD==

Any client can have its traffic routed via Tor by using the torify command and invoking the miner with that. Another method is to set the http_proxy environment variable as some miners use libraries which support that.

==Windows / OS X==

It is possible to set the http_proxy environment variable as some miners use libraries which support that.

=mIRC=

mIRC is a popular IRC client. This is a guide how to connect to Freenode IRC using Tor + SASL + mIRC. 
==Register your nick with freenode nickserv ==
Freenode only allows SASL authenticated users to connect to the onion IRC server. SASL authentication works only with a registered nickname. 
Connect to Freenode IRC without using tor & execute 
/msg nickserv register <password> <email> 
 
You will see something like this 
-NickServ- An email containing nickname activation instructions has been sent to <email> 
-NickServ- If you do not complete registration within one day, your nickname will expire. 
 
To finish your nick registration go the provided email and copy/paste the command from e-mail to irc. 

==Add SASL support to your mIRC installation ==
Download the SASL.dll and sasl.mrc files and copy them to your mIRC installation directory 
Load sasl.mrc script (Alt + R to open script editor, Ctrl + L to load file, browse to sasl.mrc, press OK or "save & exit"). 
[[{{ns:file}}:20110109-sasl-script-loaded.png]] 
Type /dialog -m SASL.main SASL.main to open the SASL connection manager. 
[[{{ns:file}}:20110109-sasl-dialog.png]] 
Add Freenode entry. 
[[{{ns:file}}:20110109-sasl-manager.png]][[{{ns:file}}:20110109-sasl-manager-network.png]] 
Network is Freenode. 
Username and NS Password must match your nickserv reservation. 
Auth Type can be PLAIN 

==setup mIRC to use Tor ==
Add the entry for Freenode onion IRC server 
[[{{ns:file}}:20110109-onion-irc-add.png]] 
Configure mIRC to use a Proxy (your local Tor proxy) 
[[{{ns:file}}:20110109-mirc-proxy.png]] 
 
Now you should be able to connect. 
[https://www.bitcointalk.org/index.php?topic=2602 Bitcoin forum where this topic is discussed]

=How Tor works=
Unlike Freenet, I2P, etc., Tor's security is very well-defined. While weaknesses do exist (described below), they have been known since Tor was created, and new weaknesses of significance are not expected.

Tor sends TCP packets over 3 (normal) or 7 (hidden services) Tor relays. This is why it is so slow: your packet might have to go through 100 computers (counting Internet routers) before it reaches its destination. Tor uses multiple ''layers'' of encryption that are ''pulled away'' for each node. Hence the name '''T'''he '''O'''nion '''R'''outer, which is always capitalized as '''Tor''', and never TOR or t.o.r.

Say that I want to connect to bitcoin.org through Tor. I first select three Tor relays that I know about. Then, I send a message to my ISP that looks like this:
Send to this IP: <IP of Relay1>
<Encrypted data for Relay1>
When Relay1 receives this, he decrypts the payload using his private key. The payload contains this:
Send to this Tor node: <Relay2>
<Encrypted data for Relay2>
Relay2 decrypts his payload:
Send to this Tor node: <Relay3>
<Encrypted data for Relay3>
Relay3 receives the real TCP payload, which he sends to the destination:
Send to this IP: <IP of destination>
<Unencrypted payload>
The payload is not and can not be further encrypted by Tor. However, if the protocol itself uses encryption (HTTPS, SSH, etc.), the data will be encrypted. This means that the last node (the ''exit node'') can see everything you do on HTTP sites, and can steal your passwords if they are transmitted unencrypted. Many people become exit nodes just so they can view this information -- Tor is much more dangerous than open WiFi for snooping!

The encryption arrangement described above ensures that no single Tor node knows both the sender and the destination. Relay1 and your ISP know that you are using Tor and sending a packet at a certain time, but they don't know what you're sending or who you're sending to. Relay3 knows exactly what you're sending, but he can't determine who is sending it because Relay2 and Relay1 are blocking him. All three relays need to work together in order to conclusively connect the sender and the destination.

However, Tor is weak to a ''timing attack'' that allows only two participants in certain positions to determine the sender with high accuracy. Consider this Tor connection:
Sender <-> S-ISP <-> Relay1 <-> Relay2 <-> Relay3 <-> D-ISP <-> Destination
If the sender's ISP (S-ISP) and the destination are working together, they can record the size and times of packets sent and received. Over a large number of packets, they can determine with very high accuracy that the sender is, in fact, the person sending packets to the destination. This requires active surveillance or detailed logging by both sides. Relay1 can also perform the same role as S-ISP.

Additionally, more configurations are possible if the underlying connection is not encrypted (normal HTTP, for example):
*S-ISP & Relay3
*Relay1 & Relay3
*S-ISP & D-ISP
*Relay1 & D-ISP
This second set can always see that the sender is connected to the destination, but they can only see what the sender is doing on the site if the connection is not encrypted. (Pathnames are encrypted in HTTPS.)

Because the first relay (the ''entry node'') is a weak point in the connection, Tor takes certain defensive measures. When you first start Tor, it chooses three ''entry guards'' that don't change for the entire time that you run Tor. You will always use one of those three unless one goes down. If all of those nodes are safe and your ISP is safe, then you are OK.

These timing attacks are of special importance to Bitcoin because anyone can be the "destination" in a connection. Packets are broadcast to every peer in the Bitcoin network. This might allow your ISP alone to associate your transactions to you without much difficulty. However, a timing attack relies on receiving at least several dozen packets from the sender, so the "destination" might actually have to be one of your direct Bitcoin peers. It's not too difficult to flood the Bitcoin network with peers, though. Because of this attack, it is wise to use an [[EWallet]] instead of the Bitcoin client when using Tor.

To discover Tor relays, Tor uses a centralized directory server model. There are nine authoritative directory servers. To become a relay, you register with one of these. The directory servers share their data and produce a ''network status consensus'' document every so often containing all Tor nodes. Tor clients don't connect directly to the authoritative directory servers -- they connect to one of many ''directory mirrors'', which have a copy of the network status consensus. Since there is no peer-to-peer bootstrap mechanism in Tor, the entire network can be destroyed if half of the authoritative directory servers are destroyed, and the entire network can be subverted if half of the authoritative directory servers become evil.

Hidden services allow both the sender and destination to remain anonymous. A hidden service connection is made like this:
*The destination tells several Tor relays to act as ''introduction points'' for the hidden service. The destination stays connected to all of these introduction points through a regular three-node Tor circuit.
*The destination registers these introduction points on a Tor DHT. The introduction points are associated with the first 16 characters of an encoded SHA-1 hash of the destination's key. This is the information in .onion addresses. The use of SHA-1 is a possible weakness.
*The sender creates a four-node Tor circuit. The fourth node is called the ''rendezvous point''.
*The sender searches the DHT for the introduction points of the desired hidden service. The sender connects to one through a regular three-node Tor circuit and, through the introduction point, tells the destination about the rendezvous point he has chosen.
*The destination connects to the rendezvous point over a three-node Tor circuit. The sender and destination are now in contact over a seven-node connection.

For clients, hidden services are more secure than encrypted Tor HTTPS connections because:
*If the destination remains anonymous, they are less likely to become controlled by an evil party.
*The destination's ISP isn't involved as they are in the HTTPS case. Only these configurations are possible for a timing attack:
**S-ISP & Destination
**Relay1 & Destination

Running a hidden service is more dangerous, however. A simple intersection attack can be performed by the hidden service's ISP alone:
*Your Internet service is cut off.
*If the hidden service went down at that exact moment, you are unmasked.
The same sort of timing attacks as above are also possible.

See the [http://www.usenix.org/events/sec04/tech/full_papers/dingledine/dingledine_html/index.html Tor design paper] for more info.

=Exchange Restrictions=

Some exchanges will treat activity occurring through Tor with greater precautions. For instance, the now-defunct Mt. Gox signup sheet read:
: Please be advised that accessing your account via the Tor network and/or public proxies may result in a temporary suspension of your account, and having to submit AML documents.

=External Tor Hidden Services=

* [irc://p4fsi4ockecnea7l.onion Freenode hidden service]

=External links=

* [http://tor.eff.org/ Tor project]
* [http://www.torproject.org/docs/tor-doc-windows.html.en Tor installation guide - Windows]
* [https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ Tor FAQ]
* [http://www.torproject.org/about/overview.html.en how Tor works - overview]
* [http://freenode.net/irc_servers.shtml#tor Freenode over Tor info]
* [http://wiki.honk-honk.org/wiki/SaslServ#mIRC howto enable SASL in mIRC]
* [http://honk-honk.org/SASL/SASL.dll SASL.dll library for mIRC]
* [http://honk-honk.org/SASL/sasl.mrc sasl script for mIRC]
* [http://freenode.net/sasl/ Freenode resources on SASL]

[[Category:Privacy]]

Tor

2022-06-17T21:24:05Z

Manu: Adding info about Tor Vidalia Bundle

'''Tor''' is a distributed 'onion' network, that makes it more difficult for an adversary to track any one peer on the network. Tor also is very useful to access the 'uncensored' internet in countries such as China and Iran. Bitcoin's security model assumes that your node is well connected to the rest of the network, so even in less-censored countries using bitcoin over both Tor and clearnet can avoid being partitioned from the network by the internet service provider. Preserving privacy means not only hiding the content of messages, but also hiding who is talking to whom (traffic analysis). Tor provides anonymous connections that are strongly resistant to both eavesdropping and traffic analysis.

Bitcoin can run easily on the Tor network.

=Tor installation & use=
''todo explain: onion routing (how tor network helps to anonymize), encryption used, exit nodes, routers'' 

Please follow the instructions provided with installation files and read the [http://www.torproject.org/download/download.html.en#warning list of warnings]. ''Tor doesn't magically anonymize all your traffic just because you install it.'' 
Down the page you can find examples how to configure applications to use Tor to anonymize the origin of your traffic. 
[http://www.torproject.org/docs/tor-doc-windows.html.en This] is a detailed installation guide for Windows. Before you setup Bitcoin or mIRC to use Tor, please install Tor and start in. 
[[{{ns:file}}:20110109-tor-running.png]] On the taskbar of your compute you'll see a small green onion when Tor is running.
[[{{ns:file}}:20110109-bitcoin-mirc-vidalia.png]]

Note on 2022: This project that executes Tor service on Windows with the above interface, and display an icon on the taskbar is called Tor Vidalia Bundle and it's not maintained anymore, deprecated and not recommended. To see how to configure Tor service on Linx or Windows check [[Setting_up_a_Tor_hidden_service|Setting up a Tor hidden service]].

= Bitcoin Core =

''See also [https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md Bitcoin Core instructions for Tor]''

==GUI==
Once you have your Tor client up & running, you can configure your Bitcoin client to use it. 
Select in menu Settings -> Options 
[[{{ns:file}}:20110108-btc-options.png]] 

Check "Connect through socks 4 proxy" with the address 127.0.0.1 and port 9050 (the Tor default port number) 
[[{{ns:file}}:20110108-btc-client-tor-as-proxy.png]] 
Configuring an application to use Tor is also called to torify it.
(needs a brief howto here)

''the note about bitcoin-otc promote on a more appropriate place in this page? reference to trading and IRC''
Conducting business using [[bitcoin-otc]] can be done more anonymously when directly connected to a Freenode IRC hidden service.

==bitcoind==

Run bitcoind with -proxy=127.0.0.1:9050 (or whatever your SocksPort is).

bitcoind will detect that you are using a proxy on 9050 and will force the "nolisten" flag. If you are not running tor on 9050, you need to set "nolisten" manually otherwise you will listen on your public IP and possibly reveal that you are running a node.

=Hidden services=
[[Hidden Service| Hidden services]] run within the Tor network and can be connected to using the -connect= parameter to bitcoind so long as bitcoin is configured to use a Tor proxy. Bitcoin users do not need to use hidden services, since Tor can be used to increase anonymity of normal internet traffic, including bitcoin connections, but there are some technical reasons why hidden services may be beneficial; for more information see the Tor project's documentation.

Services are listed at [[Fallback_Nodes#Tor_network]] along with instructions for using them.

=Pooled Mining=

Some mining pools are available as a hidden service on the tor network. Any pool can be reached over tor. The general methodology here is to tell your mining client to use your local Tor proxy. This is client specific but there are some helpful hints.

==Linux / BSD==

Any client can have its traffic routed via Tor by using the torify command and invoking the miner with that. Another method is to set the http_proxy environment variable as some miners use libraries which support that.

==Windows / OS X==

It is possible to set the http_proxy environment variable as some miners use libraries which support that.

=mIRC=

mIRC is a popular IRC client. This is a guide how to connect to Freenode IRC using Tor + SASL + mIRC. 
==Register your nick with freenode nickserv ==
Freenode only allows SASL authenticated users to connect to the onion IRC server. SASL authentication works only with a registered nickname. 
Connect to Freenode IRC without using tor & execute 
/msg nickserv register <password> <email> 
 
You will see something like this 
-NickServ- An email containing nickname activation instructions has been sent to <email> 
-NickServ- If you do not complete registration within one day, your nickname will expire. 
 
To finish your nick registration go the provided email and copy/paste the command from e-mail to irc. 

==Add SASL support to your mIRC installation ==
Download the SASL.dll and sasl.mrc files and copy them to your mIRC installation directory 
Load sasl.mrc script (Alt + R to open script editor, Ctrl + L to load file, browse to sasl.mrc, press OK or "save & exit"). 
[[{{ns:file}}:20110109-sasl-script-loaded.png]] 
Type /dialog -m SASL.main SASL.main to open the SASL connection manager. 
[[{{ns:file}}:20110109-sasl-dialog.png]] 
Add Freenode entry. 
[[{{ns:file}}:20110109-sasl-manager.png]][[{{ns:file}}:20110109-sasl-manager-network.png]] 
Network is Freenode. 
Username and NS Password must match your nickserv reservation. 
Auth Type can be PLAIN 

==setup mIRC to use Tor ==
Add the entry for Freenode onion IRC server 
[[{{ns:file}}:20110109-onion-irc-add.png]] 
Configure mIRC to use a Proxy (your local Tor proxy) 
[[{{ns:file}}:20110109-mirc-proxy.png]] 
 
Now you should be able to connect. 
[https://www.bitcointalk.org/index.php?topic=2602 Bitcoin forum where this topic is discussed]

=How Tor works=
Unlike Freenet, I2P, etc., Tor's security is very well-defined. While weaknesses do exist (described below), they have been known since Tor was created, and new weaknesses of significance are not expected.

Tor sends TCP packets over 3 (normal) or 7 (hidden services) Tor relays. This is why it is so slow: your packet might have to go through 100 computers (counting Internet routers) before it reaches its destination. Tor uses multiple ''layers'' of encryption that are ''pulled away'' for each node. Hence the name '''T'''he '''O'''nion '''R'''outer, which is always capitalized as '''Tor''', and never TOR or t.o.r.

Say that I want to connect to bitcoin.org through Tor. I first select three Tor relays that I know about. Then, I send a message to my ISP that looks like this:
Send to this IP: <IP of Relay1>
<Encrypted data for Relay1>
When Relay1 receives this, he decrypts the payload using his private key. The payload contains this:
Send to this Tor node: <Relay2>
<Encrypted data for Relay2>
Relay2 decrypts his payload:
Send to this Tor node: <Relay3>
<Encrypted data for Relay3>
Relay3 receives the real TCP payload, which he sends to the destination:
Send to this IP: <IP of destination>
<Unencrypted payload>
The payload is not and can not be further encrypted by Tor. However, if the protocol itself uses encryption (HTTPS, SSH, etc.), the data will be encrypted. This means that the last node (the ''exit node'') can see everything you do on HTTP sites, and can steal your passwords if they are transmitted unencrypted. Many people become exit nodes just so they can view this information -- Tor is much more dangerous than open WiFi for snooping!

The encryption arrangement described above ensures that no single Tor node knows both the sender and the destination. Relay1 and your ISP know that you are using Tor and sending a packet at a certain time, but they don't know what you're sending or who you're sending to. Relay3 knows exactly what you're sending, but he can't determine who is sending it because Relay2 and Relay1 are blocking him. All three relays need to work together in order to conclusively connect the sender and the destination.

However, Tor is weak to a ''timing attack'' that allows only two participants in certain positions to determine the sender with high accuracy. Consider this Tor connection:
Sender <-> S-ISP <-> Relay1 <-> Relay2 <-> Relay3 <-> D-ISP <-> Destination
If the sender's ISP (S-ISP) and the destination are working together, they can record the size and times of packets sent and received. Over a large number of packets, they can determine with very high accuracy that the sender is, in fact, the person sending packets to the destination. This requires active surveillance or detailed logging by both sides. Relay1 can also perform the same role as S-ISP.

Additionally, more configurations are possible if the underlying connection is not encrypted (normal HTTP, for example):
*S-ISP & Relay3
*Relay1 & Relay3
*S-ISP & D-ISP
*Relay1 & D-ISP
This second set can always see that the sender is connected to the destination, but they can only see what the sender is doing on the site if the connection is not encrypted. (Pathnames are encrypted in HTTPS.)

Because the first relay (the ''entry node'') is a weak point in the connection, Tor takes certain defensive measures. When you first start Tor, it chooses three ''entry guards'' that don't change for the entire time that you run Tor. You will always use one of those three unless one goes down. If all of those nodes are safe and your ISP is safe, then you are OK.

These timing attacks are of special importance to Bitcoin because anyone can be the "destination" in a connection. Packets are broadcast to every peer in the Bitcoin network. This might allow your ISP alone to associate your transactions to you without much difficulty. However, a timing attack relies on receiving at least several dozen packets from the sender, so the "destination" might actually have to be one of your direct Bitcoin peers. It's not too difficult to flood the Bitcoin network with peers, though. Because of this attack, it is wise to use an [[EWallet]] instead of the Bitcoin client when using Tor.

To discover Tor relays, Tor uses a centralized directory server model. There are nine authoritative directory servers. To become a relay, you register with one of these. The directory servers share their data and produce a ''network status consensus'' document every so often containing all Tor nodes. Tor clients don't connect directly to the authoritative directory servers -- they connect to one of many ''directory mirrors'', which have a copy of the network status consensus. Since there is no peer-to-peer bootstrap mechanism in Tor, the entire network can be destroyed if half of the authoritative directory servers are destroyed, and the entire network can be subverted if half of the authoritative directory servers become evil.

Hidden services allow both the sender and destination to remain anonymous. A hidden service connection is made like this:
*The destination tells several Tor relays to act as ''introduction points'' for the hidden service. The destination stays connected to all of these introduction points through a regular three-node Tor circuit.
*The destination registers these introduction points on a Tor DHT. The introduction points are associated with the first 16 characters of an encoded SHA-1 hash of the destination's key. This is the information in .onion addresses. The use of SHA-1 is a possible weakness.
*The sender creates a four-node Tor circuit. The fourth node is called the ''rendezvous point''.
*The sender searches the DHT for the introduction points of the desired hidden service. The sender connects to one through a regular three-node Tor circuit and, through the introduction point, tells the destination about the rendezvous point he has chosen.
*The destination connects to the rendezvous point over a three-node Tor circuit. The sender and destination are now in contact over a seven-node connection.

For clients, hidden services are more secure than encrypted Tor HTTPS connections because:
*If the destination remains anonymous, they are less likely to become controlled by an evil party.
*The destination's ISP isn't involved as they are in the HTTPS case. Only these configurations are possible for a timing attack:
**S-ISP & Destination
**Relay1 & Destination

Running a hidden service is more dangerous, however. A simple intersection attack can be performed by the hidden service's ISP alone:
*Your Internet service is cut off.
*If the hidden service went down at that exact moment, you are unmasked.
The same sort of timing attacks as above are also possible.

See the [http://www.usenix.org/events/sec04/tech/full_papers/dingledine/dingledine_html/index.html Tor design paper] for more info.

=Exchange Restrictions=

Some exchanges will treat activity occurring through Tor with greater precautions. For instance, the now-defunct Mt. Gox signup sheet read:
: Please be advised that accessing your account via the Tor network and/or public proxies may result in a temporary suspension of your account, and having to submit AML documents.

=External Tor Hidden Services=

* [irc://p4fsi4ockecnea7l.onion Freenode hidden service]

=External links=

* [http://tor.eff.org/ Tor project]
* [http://www.torproject.org/docs/tor-doc-windows.html.en Tor installation guide - Windows]
* [https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ Tor FAQ]
* [http://www.torproject.org/about/overview.html.en how Tor works - overview]
* [http://freenode.net/irc_servers.shtml#tor Freenode over Tor info]
* [http://wiki.honk-honk.org/wiki/SaslServ#mIRC howto enable SASL in mIRC]
* [http://honk-honk.org/SASL/SASL.dll SASL.dll library for mIRC]
* [http://honk-honk.org/SASL/sasl.mrc sasl script for mIRC]
* [http://freenode.net/sasl/ Freenode resources on SASL]

[[Category:Privacy]]

Setting up a Tor hidden service

2022-06-17T21:20:29Z

Manu: Adding link to bitcoin.conf

If you use a Bitcoin [[full node]] over Tor, then usually it will only be able to make outgoing connections. Therefore, you will only get a maximum of 10 total connections. This is fine, and is not something you usually need to worry about, but if your computer is often online and you want to be a big help to the network, you can run a Tor hidden service in order to accept incoming connections over Tor.

Note that there is no need to forward port 8333 when using a Tor hidden service. The hidden service will cause most firewalls and NAT setups to be bypassed. For this reason, running a Tor hidden service is also a good idea if you want incoming connections but are for some reason unable to forward port 8333.

=== Prerequisites ===

These instructions are for Linux. It is possible to do on Windows, the instructions are presented at the end.

You need Tor (at least version 0.2.7.1). Figure out where your <tt>torrc</tt> file is (<tt>/etc/tor/torrc</tt> is one possibility). This guide assumes default Tor settings. This guide assumes that Tor is running under the user and group <tt>tor</tt>, which will usually be the case if you install Tor using your distro's package manager. Note that since version 22.0 Bitcoin '''does not''' support Tor hidden service version 2 (ie. short onion addresses), only support Tor version 3 hidden services (Tor v3, ie. long onion addresses).

You need Bitcoin Core (or similar). For method 1, you need at least version 0.12.0. Find <tt>bitcoin.conf</tt> in your [[data directory]].

=== Linux Method 1 (recommended) ===

This sets up an automatic hidden service that is initiated by Bitcoin Core. On the first startup of <tt>bitcoind</tt> after configuring Bitcoin Core to use Tor ControlPort as follows, Bitcoin Core will generate a file called <tt>onion_private_key</tt> in the [[data directory]]. The file <tt>onion_private_key</tt> contains the private key needed to generate your unique <tt>XXXXXXX.onion</tt> address. KEEP THIS SAFE. If someone copies this file they can run a server with your .onion address. Also, if you delete this file, the next time bitcoind loads it will generate a new key file and <tt>xxxxxxxx.onion</tt> address. Note that while a malicious party cannot necessarily associate the server with you as a person, as long as your server has the same xxxx.onion address they will know it is run by the same person. For absolute security delete <tt>onion_private_key</tt> at each reboot or some frequent interval.

Add these lines to your <tt>torrc</tt>:

<pre>ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1</pre>

You need to figure out what user bitcoind or bitcoin-qt is running as. Run the following command while Bitcoin is running:
<pre>ps -eo user,group,comm |egrep 'bitcoind|bitcoin-qt' |awk '{print "Bitcoin user: " $1}'</pre>
Write down the reported user.

Run the following command as root, which adds your Bitcoin user to the tor group. Replace BITCOIN_USER with the actual user name found above:
<pre>usermod -a -G tor BITCOIN_USER</pre>

At this point your node will work over Tor without further configuartion. Bitcoin Core v0.12 and later automatically tries to connect to Tor via the ControlPort if <tt>listen=1</tt> is set in <tt>bitcoin.conf</tt>. By default Bitcoin Core will usually connect over the regular Internet as well as allow connections to and from the Tor hidden service. This will help other users who wish to submit transactions to the bitcoin network securely and obscurely, but transactions you submit could theoretically be traced back to your ip address. If you want Bitcoin Core to only connect via Tor (for anonymity), add these lines to [[Running_Bitcoin#Bitcoin.conf_Configuration_File|bitcoin.conf]]:

<pre>proxy=127.0.0.1:9050
listen=1
bind=127.0.0.1</pre>

If you additionally want Bitcoin Core to only connect out to Tor ''hidden services'', also add this line (not particularly recommended):
<pre>onlynet=onion</pre>

Doing so will make your specific bitcoind node arguably more secure because it will never have an unencrypted connection to another node, but if everyone used <tt>onlynet=onion</tt> nobody on the onion bitcoin chain would be able to communicate with the clearnet chain. It is essential that some nodes access both clearnet and Tor. If you need to submit bitcoin transactions to the network with the highest level of obscurity, use <tt>onlynet=onion</tt>. If you only wish to give access to your node to other Tor users, do not use it.

Now restart Tor, and then Bitcoin Core. At some point during startup in <tt>~/.bitcoin/debug.log</tt> you will see
<pre>tor: Got service ID XXXXXXXXXXX, advertising service XXXXXXXXXXX.onion:8333</pre> This is the .onion address of your server. You should eventually get incoming connections via the hidden service.

=== Linux Method 2 ===

This sets up a manual hidden service controlled by the tor daemon. The hidden service address (xxxx.onion). Note that as in method 1, your xxxxx.onion address will stay the same until you delete your key file. Someone tracking you can't necessarily associate the xxxx.onion with you, but they will know it is run by the same person or entity.

Add these lines to your <tt>torrc</tt>:
<pre>HiddenServiceDir /var/lib/tor/bitcoin-service/
HiddenServicePort 8333 127.0.0.1:8333</pre>

Restart Tor. As root, run <tt>cat /var/lib/tor/bitcoin-service/hostname</tt>. Your onion address will be reported. If it didn't work, then probably your distro's version of Tor doesn't actually use <tt>/var/lib/tor</tt> for this purpose. You should try to figure out the correct HiddenServiceDir location.

In the following steps, replace ONION_ADDR with the onion address reported above.

If you don't care about anonymity and are only looking to help the network, add the following lines to bitcoin.conf:
<pre>onion=127.0.0.1:9050
listen=1
externalip=ONION_ADDR
discover=1</pre>
This will allow you to accept connections both via your onion address and your IP address (if you have port 8333 forwarded), and Tor will only be used for connections to and from Tor hidden services.

If you care about anonymity, '''instead''' of the above, add the following lines to bitcoin.conf to use Tor for everything:
<pre>proxy=127.0.0.1:9050
listen=1
bind=127.0.0.1
externalip=ONION_ADDR</pre>

If you additionally want Bitcoin Core to only connect out to Tor ''hidden services'', also add this line (not particularly recommended):
<pre>onlynet=onion</pre>

Now restart Bitcoin Core. You should eventually get incoming connections via your hidden service.

=== Windows ===

First you need to download Tor, we recommend the Windows Expert Bundle that contains just Tor and nothing else. This version, without the browser, is located [https://www.torproject.org/download/tor/ here on torproject.org].

Then extract the contents on a folder in a place that your user can access, like ''%UserProfile%''.

On your Windows Explorer go to that folder and create a file called ''torrc''. Open it with Notepad, type the content below and save the file:
<pre>ControlPort 9051
CookieAuthentication 1</pre>

Open Windows PowerShell and navigate to the extracted folder (ex.: ''cd C:\Users\MyUserName\torExpertBundle''), and access the folder ''Tor'' (ie.: ''cd Tor''). Type ''dir'' you should see some files and ''tor.exe'' among them. So type the code below (remember to change the folder accordingly to where you extracted)

<pre>tor.exe --service install -options -f "C:\Users\MyUserName\torExpertBundle\Tor\torrc"</pre>

This will create an entry at Windows Services. Access Windows Services by pressing the Windows button and typing ''services'' then enter. You should see ''Tor Win32 Service (Provides an anonymous Internet communication system)'' on the list. Check if the status is ''Running'' and initialization type is ''Automatic''. To verify if it Tor is really working as a service, open Windows PowerShell then type:
<pre>netstat -aon | findstr ":9050"</pre>

You should see '':9050 LISTENING'':
<pre> TCP 127.0.0.1:9050 0.0.0.0:0 LISTENING 4000</pre>

Then type:
<pre>netstat -aon | findstr ":9051"</pre>

You should see '':9051 LISTENING'':
<pre> TCP 127.0.0.1:9051 0.0.0.0:0 LISTENING 4000</pre>

If you don't see these then the Tor service is not working properly and this issue may be related to Windows permissions on the folder you extracted. To fix it go to where you extracted the Tor Expert Bundle and check the top folder ''Properties > Security > Advanced'' and verify if in the Permissions tab you have ''SERVICE'' with ''Full Control'', if not click ''Add'', click on the link ''Select a Secure Entity and type ''SERVICE'' (all letters in UPPERCASE) then hit enter and select ''Full Control'' (Try to start the Tor service again in Windows Services, if it doesn't work, try adding ''SYSTEM'' and ''LOCAL SERVICE'' with ''Full Control'' on folder permissions and repeat the tests above).

If you want to see on BitcoinCore ''debug.log'' file what is happening on the communication with the Tor service, edit your ''bitcoin.conf'' file and add this line at the end ''debug=tor'', then restart BitcoinCore. If everything is ok, you should see something like that:
<pre>2022-06-13T21:45:32Z Config file arg: debug="tor"
2022-06-13T21:45:44Z torcontrol thread start
2022-06-13T21:45:44Z tor: Reading cached private key from C:\YourBitcoinFolder\onion_v3_private_key
2022-06-13T21:45:44Z tor: Successfully connected!
2022-06-13T21:45:44Z tor: Connected to Tor version 0.4.x.x
2022-06-13T21:45:44Z tor: Supported authentication method: COOKIE
2022-06-13T21:45:44Z tor: Supported authentication method: SAFECOOKIE
2022-06-13T21:45:44Z tor: Using SAFECOOKIE authentication, reading cookie authentication from C:\Windows\ServiceProfiles\LocalService\AppData\Roaming\tor\control_auth_cookie
2022-06-13T21:45:44Z Leaving InitialBlockDownload (latching to false)
2022-06-13T21:45:44Z tor: SAFECOOKIE authentication challenge successful
2022-06-13T21:45:44Z tor: AUTHCHALLENGE ServerHash xxxxx ServerNonce xxxxx
2022-06-13T21:45:44Z tor: Authentication successful</pre>

[[Category:Guides]]

Fallback Nodes

2022-06-17T21:07:00Z

Manu: adding info about Tor

This is a list of nodes which are considered reliable.

== How to use this list ==

=== Connect to nodes ===

You can connect to these nodes with the ''-addnode=ip'' switch instead of the usual node harvesting process (through IRC or via the embedded nodelist). You can connect to more than one node by using ''-addnode=ip'' more than once. It is usually a good idea to connect to more than one of these nodes.

==== Nodes without a fixed ip ====

If the node IP is not fixed (see "Fixed" column), you will have to resolve the node's name (first column) each time the IP changes. Some nodes may have their ip change once a day, some others once a month, and some others may stay on the same IP for years. Still, as long as the IP is not fixed, there is no guarantee it will stay the same.

In order to enable hostname lookups for the ''-addnode'' and ''-connect'' parameters, you must additionally provide the ''-dns'' parameter. Example:
bitcoind -dns -addnode=bitcoin.es

Versions prior to 0.3.22 do not support hostnames to the ''-addnode'' parameter, so you must do the resolving part for it. For example on linux:
bitcoind -addnode=$(dig +short bitcoin.es)

=== IP Transactions ===

[[Bitcoin Core]] versions prior to 0.8.0 also could send [[IP Transactions]] to these nodes. If you included your bitcoin address in the "message" field, you might have had your coins back.

=== Tor network ===

BitcoinCore will automatically use Tor if it is available at default (''127.0.0.1:9050''), to use Bitcoin-Qt over Tor hidden services '''only''', in a terminal/console enter:
bitcoin-qt -proxy=127.0.0.1:9050 -onlynet=tor

To use Bitcoin with one specific Tor node, run
bitcoin-qt -proxy=127.0.0.1:9050 -connect=abcde.onion
, where abcde.onion needs to be substituted with one of the [[Fallback_Nodes#Tor_nodes|Tor nodes below]]. These parameters can be added to [[Running_Bitcoin#Bitcoin.conf_Configuration_File|bitcoin.conf]] to make them permanent.

You can find detailed information on running clients and hidden services within Tor in the [https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md documentation].

== Nodes list ==

=== IPv4 Nodes ===

This entire list was last checked on 2017-11-15.

{|class="wikitable sortable"
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-

|-
| bitcoin.moneypot.com || [https://www.moneypot.com moneypot] || 212.47.228.216 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || 2015-09-15 || No
|-
| node.bitcoin.xxx || [http://www.bitcoin.xxx Bitcoin.xxx] || 66.228.49.201 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || 2014-08-28 || Yes
|-
| bitcoin.coinprism.com || [[Coinprism]] || 137.116.225.142 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || 2014-04-26 || Yes
|-
| btcnode1.evolyn.net || Evolyn || 85.214.251.25 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || 2014-01-26 || Yes
|-
| InductiveSoul.US || [[User:Inductivesoul|Inductive Soul]] || 67.186.224.85 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || 2013-11-13 || Yes
|-
| archivum.info || Ferraro Ltd.|| 88.198.58.172 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| 62.75.216.13 || exMULTI, Inc. || 62.75.216.13 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No
|-
| 69.64.34.118 || exMULTI, Inc. || 69.64.34.118 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No
|-
| 79.160.221.140 || K-Norway || 79.160.221.140 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| netzbasis.de || unknown3 || 81.169.129.25 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| btc.turboadmin.com || osmosis || 98.143.152.14 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No
|-
| fallback.bitcoin.zhoutong.com || Zhou Tong || 117.121.241.140 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No
|-
| bauhaus.csail.mit.edu || imsaguy || 128.30.96.44 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| jun.dashjr.org || Luke-Jr || 173.242.112.53 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || 2017-11-15 ||
|-
| cheaperinbitcoins.com || Xenland/Shane || 184.154.36.82 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| django.webflows.fr || unknown2 || 188.165.213.169 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| 204.9.55.71 || toasty || 204.9.55.71 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| btcnode.novit.ro || ovidiusoft - novit.ro || 93.187.142.114 || {{Table Value No}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| porgressbar.sk || progressbar hackerspace || 91.210.181.21 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| faucet.bitcoin.st || bitcoin street || 64.27.57.225 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| bitcoin.securepayment.cc || SecurePayment CC || 63.247.147.163 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| www.dcscdn.com || [[User:Danw12|Danw12]] || 199.115.228.181 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || ||
|-
| ns2.dcscdn.com || [[User:Danw12|Danw12]] || 199.115.228.182 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || ||
|-
| coin.soul-dev.com || Soul-Dev || || || {{Fallback Nodes/Node Down}} || ||
|-
| messier.bzfx.net || BZFX/[[User:A Meteorite|A Meteorite]] || 91.121.205.50 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || ||
|-
| btcnode1.bitgroup.cc || BitGroup || 198.211.116.191 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| btcnode2.bitgroup.cc || BitGroup || 162.243.120.138 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| btcnode3.bitgroup.cc || BitGroup || 95.85.8.237 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| btcnode.xiro.co || Xiro Labs || 91.121.108.61 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || 2017-11-15 || No
|-
| stuff.liam-w.io || [[User:liamwli|Liam W]] || 185.122.57.203 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No
|-
| bitcoin.bitdonut.co || James Hartig || || || {{Fallback Nodes/Node Down}} || ||
|-
| coinno.de || jaknam || || || {{Fallback Nodes/Node Down}} || ||
|-
| 82.165.44.44 || anonymous || || || {{Fallback Nodes/Node Down}} || ||
|-
| bitcoin1.dassori.me || gdassori || || || {{Fallback Nodes/Node Down}} || ||
|-
| bitcoin2.dassori.me || gdassori || || || {{Fallback Nodes/Node Down}} || ||
|-
| blockchainnode.meulie.net || [[User:Evert|Evert]] || || || {{Fallback Nodes/Node Up}} || 2017-11-15 ||
|-
| fullnode.fybsg.com || Nagato || || || {{Fallback Nodes/Node Down}} || ||
|-
| n.bitcoin-fr.io || [[User:Arthur|Arthur]] || 62.210.66.227 || || {{Fallback Nodes/Node Up}} || 2017-11-15 ||
|-
| homeplex.tk || [[User:Victorsueca|Victorsueca]] || 90.165.120.190 || || {{Fallback Nodes/Node Down}} || ||
|-
| mars.jordandoyle.uk || [https://doyle.wf Jordan Doyle] || 91.121.83.82 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes

|}

=== IPv6 Nodes ===
{|class="wikitable sortable"
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-

| InductiveSoul.US || [[User:Inductivesoul|Inductive Soul]] || 2601:7:6680:2ac:4d29:40ff:7513:fcc7 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || 11-13-2013 (MDY) || Yes
|-
| caffeinator.net || [[User:Atrophy|Atrophy]] || || || {{Fallback Nodes/Node Up}} || 2013-05-10 ||
|-
| 2001:470:8:2e1::40 || ? || 2001:470:8:2e1::40 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes
|-
| messier.bzfx.net || BZFX/[[User:A Meteorite|A Meteorite]] || 2001:41d0:1:d632::1 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || ||
|-
| stuff.liam-w.io || [[User:liamwli|Liam W]] || 2a06:8ec0:3::1:2e47 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || No
|-
| bitcoin.bitdonut.co || James Hartig || || || || ||
|-
| n.bitcoin-fr.io || [[User:Arthur|Arthur]] || 2001:bc8:c087:2001::1 || || || ||
|-
| mars.jordandoyle.uk || [https://doyle.wf Jordan Doyle] || || || || ||

|}

=== Tor nodes ===

This entire list was last checked on 2018-10-24.

{|class="wikitable sortable"
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-
| nkf5e6b7pl4jfd4a.onion || BlueMatt || Up || 2018-10-24 || No
|}

== Adding a node ==

Before adding yourself as a fallback node, you should be sure your node will stay online for a long time. If a node is offline for more than 24 hours it will be removed from the list.

To add a node in this list, you just need the ip/hostname and your name, the other fields will be filled automatically. Insert the following lines before the <tt>END NODELIST</tt> line:

<nowiki>|-
| ip || your name</nowiki>

==See Also==

* [[Network|Bitcoin Network]]
* [http://nodes.bitcoin.st Fallback Nodes] List of longest running Bitcoin Nodes listed by Country.
* [https://getaddr.bitnodes.io/ Bitnodes project]
* [https://blockchain.info/connected-nodes Recently connected nodes at blockchain.info]

{{Bitcoin Core documentation}}

Setting up a Tor hidden service

2022-06-17T21:03:07Z

Manu: Specifying Linux sessions

If you use a Bitcoin [[full node]] over Tor, then usually it will only be able to make outgoing connections. Therefore, you will only get a maximum of 10 total connections. This is fine, and is not something you usually need to worry about, but if your computer is often online and you want to be a big help to the network, you can run a Tor hidden service in order to accept incoming connections over Tor.

Note that there is no need to forward port 8333 when using a Tor hidden service. The hidden service will cause most firewalls and NAT setups to be bypassed. For this reason, running a Tor hidden service is also a good idea if you want incoming connections but are for some reason unable to forward port 8333.

=== Prerequisites ===

These instructions are for Linux. It is possible to do on Windows, the instructions are presented at the end.

You need Tor (at least version 0.2.7.1). Figure out where your <tt>torrc</tt> file is (<tt>/etc/tor/torrc</tt> is one possibility). This guide assumes default Tor settings. This guide assumes that Tor is running under the user and group <tt>tor</tt>, which will usually be the case if you install Tor using your distro's package manager. Note that since version 22.0 Bitcoin '''does not''' support Tor hidden service version 2 (ie. short onion addresses), only support Tor version 3 hidden services (Tor v3, ie. long onion addresses).

You need Bitcoin Core (or similar). For method 1, you need at least version 0.12.0. Find <tt>bitcoin.conf</tt> in your [[data directory]].

=== Linux Method 1 (recommended) ===

This sets up an automatic hidden service that is initiated by Bitcoin Core. On the first startup of <tt>bitcoind</tt> after configuring Bitcoin Core to use Tor ControlPort as follows, Bitcoin Core will generate a file called <tt>onion_private_key</tt> in the [[data directory]]. The file <tt>onion_private_key</tt> contains the private key needed to generate your unique <tt>XXXXXXX.onion</tt> address. KEEP THIS SAFE. If someone copies this file they can run a server with your .onion address. Also, if you delete this file, the next time bitcoind loads it will generate a new key file and <tt>xxxxxxxx.onion</tt> address. Note that while a malicious party cannot necessarily associate the server with you as a person, as long as your server has the same xxxx.onion address they will know it is run by the same person. For absolute security delete <tt>onion_private_key</tt> at each reboot or some frequent interval.

Add these lines to your <tt>torrc</tt>:

<pre>ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1</pre>

You need to figure out what user bitcoind or bitcoin-qt is running as. Run the following command while Bitcoin is running:
<pre>ps -eo user,group,comm |egrep 'bitcoind|bitcoin-qt' |awk '{print "Bitcoin user: " $1}'</pre>
Write down the reported user.

Run the following command as root, which adds your Bitcoin user to the tor group. Replace BITCOIN_USER with the actual user name found above:
<pre>usermod -a -G tor BITCOIN_USER</pre>

At this point your node will work over Tor without further configuartion. Bitcoin Core v0.12 and later automatically tries to connect to Tor via the ControlPort if <tt>listen=1</tt> is set in <tt>bitcoin.conf</tt>. By default Bitcoin Core will usually connect over the regular Internet as well as allow connections to and from the Tor hidden service. This will help other users who wish to submit transactions to the bitcoin network securely and obscurely, but transactions you submit could theoretically be traced back to your ip address. If you want Bitcoin Core to only connect via Tor (for anonymity), add these lines to bitcoin.conf:

<pre>proxy=127.0.0.1:9050
listen=1
bind=127.0.0.1</pre>

If you additionally want Bitcoin Core to only connect out to Tor ''hidden services'', also add this line (not particularly recommended):
<pre>onlynet=onion</pre>

Doing so will make your specific bitcoind node arguably more secure because it will never have an unencrypted connection to another node, but if everyone used <tt>onlynet=onion</tt> nobody on the onion bitcoin chain would be able to communicate with the clearnet chain. It is essential that some nodes access both clearnet and Tor. If you need to submit bitcoin transactions to the network with the highest level of obscurity, use <tt>onlynet=onion</tt>. If you only wish to give access to your node to other Tor users, do not use it.

Now restart Tor, and then Bitcoin Core. At some point during startup in <tt>~/.bitcoin/debug.log</tt> you will see
<pre>tor: Got service ID XXXXXXXXXXX, advertising service XXXXXXXXXXX.onion:8333</pre> This is the .onion address of your server. You should eventually get incoming connections via the hidden service.

=== Linux Method 2 ===

This sets up a manual hidden service controlled by the tor daemon. The hidden service address (xxxx.onion). Note that as in method 1, your xxxxx.onion address will stay the same until you delete your key file. Someone tracking you can't necessarily associate the xxxx.onion with you, but they will know it is run by the same person or entity.

Add these lines to your <tt>torrc</tt>:
<pre>HiddenServiceDir /var/lib/tor/bitcoin-service/
HiddenServicePort 8333 127.0.0.1:8333</pre>

Restart Tor. As root, run <tt>cat /var/lib/tor/bitcoin-service/hostname</tt>. Your onion address will be reported. If it didn't work, then probably your distro's version of Tor doesn't actually use <tt>/var/lib/tor</tt> for this purpose. You should try to figure out the correct HiddenServiceDir location.

In the following steps, replace ONION_ADDR with the onion address reported above.

If you don't care about anonymity and are only looking to help the network, add the following lines to bitcoin.conf:
<pre>onion=127.0.0.1:9050
listen=1
externalip=ONION_ADDR
discover=1</pre>
This will allow you to accept connections both via your onion address and your IP address (if you have port 8333 forwarded), and Tor will only be used for connections to and from Tor hidden services.

If you care about anonymity, '''instead''' of the above, add the following lines to bitcoin.conf to use Tor for everything:
<pre>proxy=127.0.0.1:9050
listen=1
bind=127.0.0.1
externalip=ONION_ADDR</pre>

If you additionally want Bitcoin Core to only connect out to Tor ''hidden services'', also add this line (not particularly recommended):
<pre>onlynet=onion</pre>

Now restart Bitcoin Core. You should eventually get incoming connections via your hidden service.

=== Windows ===

First you need to download Tor, we recommend the Windows Expert Bundle that contains just Tor and nothing else. This version, without the browser, is located [https://www.torproject.org/download/tor/ here on torproject.org].

Then extract the contents on a folder in a place that your user can access, like ''%UserProfile%''.

On your Windows Explorer go to that folder and create a file called ''torrc''. Open it with Notepad, type the content below and save the file:
<pre>ControlPort 9051
CookieAuthentication 1</pre>

Open Windows PowerShell and navigate to the extracted folder (ex.: ''cd C:\Users\MyUserName\torExpertBundle''), and access the folder ''Tor'' (ie.: ''cd Tor''). Type ''dir'' you should see some files and ''tor.exe'' among them. So type the code below (remember to change the folder accordingly to where you extracted)

<pre>tor.exe --service install -options -f "C:\Users\MyUserName\torExpertBundle\Tor\torrc"</pre>

This will create an entry at Windows Services. Access Windows Services by pressing the Windows button and typing ''services'' then enter. You should see ''Tor Win32 Service (Provides an anonymous Internet communication system)'' on the list. Check if the status is ''Running'' and initialization type is ''Automatic''. To verify if it Tor is really working as a service, open Windows PowerShell then type:
<pre>netstat -aon | findstr ":9050"</pre>

You should see '':9050 LISTENING'':
<pre> TCP 127.0.0.1:9050 0.0.0.0:0 LISTENING 4000</pre>

Then type:
<pre>netstat -aon | findstr ":9051"</pre>

You should see '':9051 LISTENING'':
<pre> TCP 127.0.0.1:9051 0.0.0.0:0 LISTENING 4000</pre>

If you don't see these then the Tor service is not working properly and this issue may be related to Windows permissions on the folder you extracted. To fix it go to where you extracted the Tor Expert Bundle and check the top folder ''Properties > Security > Advanced'' and verify if in the Permissions tab you have ''SERVICE'' with ''Full Control'', if not click ''Add'', click on the link ''Select a Secure Entity and type ''SERVICE'' (all letters in UPPERCASE) then hit enter and select ''Full Control'' (Try to start the Tor service again in Windows Services, if it doesn't work, try adding ''SYSTEM'' and ''LOCAL SERVICE'' with ''Full Control'' on folder permissions and repeat the tests above).

If you want to see on BitcoinCore ''debug.log'' file what is happening on the communication with the Tor service, edit your ''bitcoin.conf'' file and add this line at the end ''debug=tor'', then restart BitcoinCore. If everything is ok, you should see something like that:
<pre>2022-06-13T21:45:32Z Config file arg: debug="tor"
2022-06-13T21:45:44Z torcontrol thread start
2022-06-13T21:45:44Z tor: Reading cached private key from C:\YourBitcoinFolder\onion_v3_private_key
2022-06-13T21:45:44Z tor: Successfully connected!
2022-06-13T21:45:44Z tor: Connected to Tor version 0.4.x.x
2022-06-13T21:45:44Z tor: Supported authentication method: COOKIE
2022-06-13T21:45:44Z tor: Supported authentication method: SAFECOOKIE
2022-06-13T21:45:44Z tor: Using SAFECOOKIE authentication, reading cookie authentication from C:\Windows\ServiceProfiles\LocalService\AppData\Roaming\tor\control_auth_cookie
2022-06-13T21:45:44Z Leaving InitialBlockDownload (latching to false)
2022-06-13T21:45:44Z tor: SAFECOOKIE authentication challenge successful
2022-06-13T21:45:44Z tor: AUTHCHALLENGE ServerHash xxxxx ServerNonce xxxxx
2022-06-13T21:45:44Z tor: Authentication successful</pre>

[[Category:Guides]]

Setting up a Tor hidden service

2022-06-17T20:52:22Z

Manu: Adding Windows instructions

If you use a Bitcoin [[full node]] over Tor, then usually it will only be able to make outgoing connections. Therefore, you will only get a maximum of 10 total connections. This is fine, and is not something you usually need to worry about, but if your computer is often online and you want to be a big help to the network, you can run a Tor hidden service in order to accept incoming connections over Tor.

Note that there is no need to forward port 8333 when using a Tor hidden service. The hidden service will cause most firewalls and NAT setups to be bypassed. For this reason, running a Tor hidden service is also a good idea if you want incoming connections but are for some reason unable to forward port 8333.

=== Prerequisites ===

These instructions are for Linux. It is possible to do on Windows, the instructions are presented at the end.

You need Tor (at least version 0.2.7.1). Figure out where your <tt>torrc</tt> file is (<tt>/etc/tor/torrc</tt> is one possibility). This guide assumes default Tor settings. This guide assumes that Tor is running under the user and group <tt>tor</tt>, which will usually be the case if you install Tor using your distro's package manager. Note that since version 22.0 Bitcoin '''does not''' support Tor hidden service version 2 (ie. short onion addresses), only support Tor version 3 hidden services (Tor v3, ie. long onion addresses).

You need Bitcoin Core (or similar). For method 1, you need at least version 0.12.0. Find <tt>bitcoin.conf</tt> in your [[data directory]].

=== Method 1 (recommended) ===

This sets up an automatic hidden service that is initiated by Bitcoin Core. On the first startup of <tt>bitcoind</tt> after configuring Bitcoin Core to use Tor ControlPort as follows, Bitcoin Core will generate a file called <tt>onion_private_key</tt> in the [[data directory]]. The file <tt>onion_private_key</tt> contains the private key needed to generate your unique <tt>XXXXXXX.onion</tt> address. KEEP THIS SAFE. If someone copies this file they can run a server with your .onion address. Also, if you delete this file, the next time bitcoind loads it will generate a new key file and <tt>xxxxxxxx.onion</tt> address. Note that while a malicious party cannot necessarily associate the server with you as a person, as long as your server has the same xxxx.onion address they will know it is run by the same person. For absolute security delete <tt>onion_private_key</tt> at each reboot or some frequent interval.

Add these lines to your <tt>torrc</tt>:

<pre>ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1</pre>

You need to figure out what user bitcoind or bitcoin-qt is running as. Run the following command while Bitcoin is running:
<pre>ps -eo user,group,comm |egrep 'bitcoind|bitcoin-qt' |awk '{print "Bitcoin user: " $1}'</pre>
Write down the reported user.

Run the following command as root, which adds your Bitcoin user to the tor group. Replace BITCOIN_USER with the actual user name found above:
<pre>usermod -a -G tor BITCOIN_USER</pre>

At this point your node will work over Tor without further configuartion. Bitcoin Core v0.12 and later automatically tries to connect to Tor via the ControlPort if <tt>listen=1</tt> is set in <tt>bitcoin.conf</tt>. By default Bitcoin Core will usually connect over the regular Internet as well as allow connections to and from the Tor hidden service. This will help other users who wish to submit transactions to the bitcoin network securely and obscurely, but transactions you submit could theoretically be traced back to your ip address. If you want Bitcoin Core to only connect via Tor (for anonymity), add these lines to bitcoin.conf:

<pre>proxy=127.0.0.1:9050
listen=1
bind=127.0.0.1</pre>

If you additionally want Bitcoin Core to only connect out to Tor ''hidden services'', also add this line (not particularly recommended):
<pre>onlynet=onion</pre>

Doing so will make your specific bitcoind node arguably more secure because it will never have an unencrypted connection to another node, but if everyone used <tt>onlynet=onion</tt> nobody on the onion bitcoin chain would be able to communicate with the clearnet chain. It is essential that some nodes access both clearnet and Tor. If you need to submit bitcoin transactions to the network with the highest level of obscurity, use <tt>onlynet=onion</tt>. If you only wish to give access to your node to other Tor users, do not use it.

Now restart Tor, and then Bitcoin Core. At some point during startup in <tt>~/.bitcoin/debug.log</tt> you will see
<pre>tor: Got service ID XXXXXXXXXXX, advertising service XXXXXXXXXXX.onion:8333</pre> This is the .onion address of your server. You should eventually get incoming connections via the hidden service.

=== Method 2 ===

This sets up a manual hidden service controlled by the tor daemon. The hidden service address (xxxx.onion). Note that as in method 1, your xxxxx.onion address will stay the same until you delete your key file. Someone tracking you can't necessarily associate the xxxx.onion with you, but they will know it is run by the same person or entity.

Add these lines to your <tt>torrc</tt>:
<pre>HiddenServiceDir /var/lib/tor/bitcoin-service/
HiddenServicePort 8333 127.0.0.1:8333</pre>

Restart Tor. As root, run <tt>cat /var/lib/tor/bitcoin-service/hostname</tt>. Your onion address will be reported. If it didn't work, then probably your distro's version of Tor doesn't actually use <tt>/var/lib/tor</tt> for this purpose. You should try to figure out the correct HiddenServiceDir location.

In the following steps, replace ONION_ADDR with the onion address reported above.

If you don't care about anonymity and are only looking to help the network, add the following lines to bitcoin.conf:
<pre>onion=127.0.0.1:9050
listen=1
externalip=ONION_ADDR
discover=1</pre>
This will allow you to accept connections both via your onion address and your IP address (if you have port 8333 forwarded), and Tor will only be used for connections to and from Tor hidden services.

If you care about anonymity, '''instead''' of the above, add the following lines to bitcoin.conf to use Tor for everything:
<pre>proxy=127.0.0.1:9050
listen=1
bind=127.0.0.1
externalip=ONION_ADDR</pre>

If you additionally want Bitcoin Core to only connect out to Tor ''hidden services'', also add this line (not particularly recommended):
<pre>onlynet=onion</pre>

Now restart Bitcoin Core. You should eventually get incoming connections via your hidden service.

=== Windows ===

First you need to download Tor, we recommend the Windows Expert Bundle that contains just Tor and nothing else. This version, without the browser, is located [https://www.torproject.org/download/tor/ here on torproject.org].

Then extract the contents on a folder in a place that your user can access, like ''%UserProfile%''.

On your Windows Explorer go to that folder and create a file called ''torrc''. Open it with Notepad, type the content below and save the file:
<pre>ControlPort 9051
CookieAuthentication 1</pre>

Open Windows PowerShell and navigate to the extracted folder (ex.: ''cd C:\Users\MyUserName\torExpertBundle''), and access the folder ''Tor'' (ie.: ''cd Tor''). Type ''dir'' you should see some files and ''tor.exe'' among them. So type the code below (remember to change the folder accordingly to where you extracted)

<pre>tor.exe --service install -options -f "C:\Users\MyUserName\torExpertBundle\Tor\torrc"</pre>

This will create an entry at Windows Services. Access Windows Services by pressing the Windows button and typing ''services'' then enter. You should see ''Tor Win32 Service (Provides an anonymous Internet communication system)'' on the list. Check if the status is ''Running'' and initialization type is ''Automatic''. To verify if it Tor is really working as a service, open Windows PowerShell then type:
<pre>netstat -aon | findstr ":9050"</pre>

You should see '':9050 LISTENING'':
<pre> TCP 127.0.0.1:9050 0.0.0.0:0 LISTENING 4000</pre>

Then type:
<pre>netstat -aon | findstr ":9051"</pre>

You should see '':9051 LISTENING'':
<pre> TCP 127.0.0.1:9051 0.0.0.0:0 LISTENING 4000</pre>

If you don't see these then the Tor service is not working properly and this issue may be related to Windows permissions on the folder you extracted. To fix it go to where you extracted the Tor Expert Bundle and check the top folder ''Properties > Security > Advanced'' and verify if in the Permissions tab you have ''SERVICE'' with ''Full Control'', if not click ''Add'', click on the link ''Select a Secure Entity and type ''SERVICE'' (all letters in UPPERCASE) then hit enter and select ''Full Control'' (Try to start the Tor service again in Windows Services, if it doesn't work, try adding ''SYSTEM'' and ''LOCAL SERVICE'' with ''Full Control'' on folder permissions and repeat the tests above).

If you want to see on BitcoinCore ''debug.log'' file what is happening on the communication with the Tor service, edit your ''bitcoin.conf'' file and add this line at the end ''debug=tor'', then restart BitcoinCore. If everything is ok, you should see something like that:
<pre>2022-06-13T21:45:32Z Config file arg: debug="tor"
2022-06-13T21:45:44Z torcontrol thread start
2022-06-13T21:45:44Z tor: Reading cached private key from C:\YourBitcoinFolder\onion_v3_private_key
2022-06-13T21:45:44Z tor: Successfully connected!
2022-06-13T21:45:44Z tor: Connected to Tor version 0.4.x.x
2022-06-13T21:45:44Z tor: Supported authentication method: COOKIE
2022-06-13T21:45:44Z tor: Supported authentication method: SAFECOOKIE
2022-06-13T21:45:44Z tor: Using SAFECOOKIE authentication, reading cookie authentication from C:\Windows\ServiceProfiles\LocalService\AppData\Roaming\tor\control_auth_cookie
2022-06-13T21:45:44Z Leaving InitialBlockDownload (latching to false)
2022-06-13T21:45:44Z tor: SAFECOOKIE authentication challenge successful
2022-06-13T21:45:44Z tor: AUTHCHALLENGE ServerHash xxxxx ServerNonce xxxxx
2022-06-13T21:45:44Z tor: Authentication successful</pre>

[[Category:Guides]]

Setting up a Tor hidden service

2022-06-17T19:01:23Z

Manu: Bitcoin since v22 only supports Tor v3 addresses

Setting up a Tor hidden service

2022-06-17T18:52:22Z

Manu: Changed max outgoing connections from 8 to 10 (two additional outbound connections since 0.19.0)

BIP 0032

2022-06-17T16:23:31Z

Manu: Fixed derivation.png image

{{bip}}
{{BipMoved|bip-0032.mediawiki}}

RECENT CHANGES:
* (16 Apr 2013) Added private derivation for i ≥ 0x80000000 (less risk of parent private key leakage)
* (30 Apr 2013) Switched from multiplication by IL to addition of IL (faster, easier implementation)
* (25 May 2013) Added test vectors
* (15 Jan 2014) Rename keys with index ≥ 0x80000000 to hardened keys, and add explicit conversion functions.
* (24 Feb 2017) Added test vectors for hardened derivation with leading zeros
* (4 Nov 2020) Added new test vectors for hardened derivation with leading zeros

<pre>
BIP: 32
Layer: Applications
Title: Hierarchical Deterministic Wallets
Author: Pieter Wuille <pieter.wuille@gmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0032
Status: Final
Type: Informational
Created: 2012-02-11
License: BSD-2-Clause
</pre>

==Abstract==

This document describes hierarchical deterministic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.

The specification is intended to set a standard for deterministic wallets that can be interchanged between different clients. Although the wallets described here have many features, not all are required by supporting clients.

The specification consists of two parts. In a first part, a system for deriving a tree of keypairs from a single seed is presented. The second part demonstrates how to build a wallet structure on top of such a tree.

==Copyright==

This BIP is licensed under the 2-clause BSD license.

==Motivation==

The Bitcoin reference client uses randomly generated keys. In order to avoid the necessity for a backup after every transaction, (by default) 100 keys are cached in a pool of reserve keys. Still, these wallets are not intended to be shared and used on several systems simultaneously. They support hiding their private keys by using the wallet encrypt feature and not sharing the password, but such "neutered" wallets lose the power to generate public keys as well.

Deterministic wallets do not require such frequent backups, and elliptic curve mathematics permit schemes where one can calculate the public keys without revealing the private keys. This permits for example a webshop business to let its webserver generate fresh addresses (public key hashes) for each order or for each customer, without giving the webserver access to the corresponding private keys (which are required for spending the received funds).

However, deterministic wallets typically consist of a single "chain" of keypairs. The fact that there is only one chain means that sharing a wallet happens on an all-or-nothing basis. However, in some cases one only wants some (public) keys to be shared and recoverable. In the example of a webshop, the webserver does not need access to all public keys of the merchant's wallet; only to those addresses which are used to receive customer's payments, and not for example the change addresses that are generated when the merchant spends money. Hierarchical deterministic wallets allow such selective sharing by supporting multiple keypair chains, derived from a single root.

==Specification: Key derivation==

===Conventions===

In the rest of this text we will assume the public key cryptography used in Bitcoin, namely elliptic curve cryptography using the field and curve parameters defined by secp256k1 (http://www.secg.org/sec2-v2.pdf). Variables below are either:
* Integers modulo the order of the curve (referred to as n).
* Coordinates of points on the curve.
* Byte sequences.

Addition (+) of two coordinate pair is defined as application of the EC group operation.
Concatenation (||) is the operation of appending one byte sequence onto another.

As standard conversion functions, we assume:
* point(p): returns the coordinate pair resulting from EC point multiplication (repeated application of the EC group operation) of the secp256k1 base point with the integer p.
* ser32(i): serialize a 32-bit unsigned integer i as a 4-byte sequence, most significant byte first.
* ser256(p): serializes the integer p as a 32-byte sequence, most significant byte first.
* serP(P): serializes the coordinate pair P = (x,y) as a byte sequence using SEC1's compressed form: (0x02 or 0x03) || ser256(x), where the header byte depends on the parity of the omitted y coordinate.
* parse256(p): interprets a 32-byte sequence as a 256-bit number, most significant byte first.

===Extended keys===

In what follows, we will define a function that derives a number of child keys from a parent key. In order to prevent these from depending solely on the key itself, we extend both private and public keys first with an extra 256 bits of entropy. This extension, called the chain code, is identical for corresponding private and public keys, and consists of 32 bytes.

We represent an extended private key as (k, c), with k the normal private key, and c the chain code. An extended public key is represented as (K, c), with K = point(k) and c the chain code.

Each extended key has 231 normal child keys, and 231 hardened child keys. Each of these child keys has an index. The normal child keys use indices 0 through 231-1. The hardened child keys use indices 231 through 232-1. To ease notation for hardened key indices, a number iH represents i+231.

===Child key derivation (CKD) functions===

Given a parent extended key and an index i, it is possible to compute the corresponding child extended key. The algorithm to do so depends on whether the child is a hardened key or not (or, equivalently, whether i ≥ 231), and whether we're talking about private or public keys.

====Private parent key → private child key====

The function CKDpriv((kpar, cpar), i) → (ki, ci) computes a child extended private key from the parent extended private key:
* Check whether i ≥ 231 (whether the child is a hardened key).
** If so (hardened child): let I = HMAC-SHA512(Key = cpar, Data = 0x00 || ser256(kpar) || ser32(i)). (Note: The 0x00 pads the private key to make it 33 bytes long.)
** If not (normal child): let I = HMAC-SHA512(Key = cpar, Data = serP(point(kpar)) || ser32(i)).
* Split I into two 32-byte sequences, IL and IR.
* The returned child key ki is parse256(IL) + kpar (mod n).
* The returned chain code ci is IR.
* In case parse256(IL) ≥ n or ki = 0, the resulting key is invalid, and one should proceed with the next value for i. (Note: this has probability lower than 1 in 2127.)

The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].

====Public parent key → public child key====

The function CKDpub((Kpar, cpar), i) → (Ki, ci) computes a child extended public key from the parent extended public key. It is only defined for non-hardened child keys.
* Check whether i ≥ 231 (whether the child is a hardened key).
** If so (hardened child): return failure
** If not (normal child): let I = HMAC-SHA512(Key = cpar, Data = serP(Kpar) || ser32(i)).
* Split I into two 32-byte sequences, IL and IR.
* The returned child key Ki is point(parse256(IL)) + Kpar.
* The returned chain code ci is IR.
* In case parse256(IL) ≥ n or Ki is the point at infinity, the resulting key is invalid, and one should proceed with the next value for i.

====Private parent key → public child key====

The function N((k, c)) → (K, c) computes the extended public key corresponding to an extended private key (the "neutered" version, as it removes the ability to sign transactions).
* The returned key K is point(k).
* The returned chain code c is just the passed chain code.

To compute the public child key of a parent private key:
* N(CKDpriv((kpar, cpar), i)) (works always).
* CKDpub(N(kpar, cpar), i) (works only for non-hardened child keys).
The fact that they are equivalent is what makes non-hardened keys useful (one can derive child public keys of a given parent key without knowing any private key), and also what distinguishes them from hardened keys. The reason for not always using non-hardened keys (which are more useful) is security; see further for more information.

====Public parent key → private child key====

This is not possible.

===The key tree===

The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKDpriv(m,i) for several values of i, we get a number of level-1 derived nodes. As each of these is again an extended key, CKDpriv can be applied to those as well.

To shorten notation, we will write CKDpriv(CKDpriv(CKDpriv(m,3H),2),5) as m/3H/2/5. Equivalently for public keys, we write CKDpub(CKDpub(CKDpub(M,3),2),5) as M/3/2/5. This results in the following identities:
* N(m/a/b/c) = N(m/a/b)/c = N(m/a)/b/c = N(m)/a/b/c = M/a/b/c.
* N(m/aH/b/c) = N(m/aH/b)/c = N(m/aH)/b/c.
However, N(m/aH) cannot be rewritten as N(m)/aH, as the latter is not possible.

Each leaf node in the tree corresponds to an actual key, while the internal nodes correspond to the collections of keys that descend from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is relevant. Because of this construction, knowing an extended private key allows reconstruction of all descendant private keys and public keys, and knowing an extended public key allows reconstruction of all descendant non-hardened public keys.

===Key identifiers===

Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized ECDSA public key K, ignoring the chain code. This corresponds exactly to the data used in traditional Bitcoin addresses. It is not advised to represent this data in base58 format though, as it may be interpreted as an address that way (and wallet software is not required to accept payment to the chain key itself).

The first 32 bits of the identifier are called the key fingerprint.

===Serialization format===

Extended public and private keys are serialized as follows:
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 derived keys, ....
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)
* 4 bytes: child number. This is ser32(i) for i in xi = xpar/i, with xi the key being serialized. (0x00000000 if master key)
* 32 bytes: the chain code
* 33 bytes: the public key or private key data (serP(K) for public keys, 0x00 || ser256(k) for private keys)

This 78 byte structure can be encoded like other Bitcoin data in Base58, by first adding 32 checksum bits (derived from the double SHA-256 checksum), and then converting to the Base58 representation. This results in a Base58-encoded string of up to 112 characters. Because of the choice of the version bytes, the Base58 representation will start with "xprv" or "xpub" on mainnet, "tprv" or "tpub" on testnet.

Note that the fingerprint of the parent only serves as a fast way to detect parent and child nodes in software, and software must be willing to deal with collisions. Internally, the full 160-bit identifier could be used.

When importing a serialized extended public key, implementations must verify whether the X coordinate in the public key data corresponds to a point on the curve. If not, the extended public key is invalid.

===Master key generation===

The total number of possible extended keypairs is almost 2512, but the produced keys are only 256 bits long, and offer about half of that in terms of security. Therefore, master keys are not generated directly, but instead from a potentially short seed value.

* Generate a seed byte sequence S of a chosen length (between 128 and 512 bits; 256 bits is advised) from a (P)RNG.
* Calculate I = HMAC-SHA512(Key = "Bitcoin seed", Data = S)
* Split I into two 32-byte sequences, IL and IR.
* Use parse256(IL) as master secret key, and IR as master chain code.
In case parse256(IL) is 0 or parse256(IL) ≥ n, the master key is invalid.

[[File:BIP32-derivation.png|700px]]

==Specification: Wallet structure==

The previous sections specified key trees and their nodes. The next step is imposing a wallet structure on this tree. The layout defined in this section is a default only, though clients are encouraged to mimic it for compatibility, even if not all features are supported.

===The default wallet layout===

An HDW is organized as several 'accounts'. Accounts are numbered, the default account ("") being number 0. Clients are not required to support more than one account - if not, they only use the default account.

Each account is composed of two keypair chains: an internal and an external one. The external keychain is used to generate new public addresses, while the internal keychain is used for all other operations (change addresses, generation addresses, ..., anything that doesn't need to be communicated). Clients that do not support separate keychains for these should use the external one for everything.
* m/iH/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.
* m/iH/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.

===Use cases===

====Full wallet sharing: m====

In cases where two systems need to access a single shared wallet, and both need to be able to perform spendings, one needs to share the master private extended key. Nodes can keep a pool of N look-ahead keys cached for external chains, to watch for incoming payments. The look-ahead for internal chains can be very small, as no gaps are to be expected here. An extra look-ahead could be active for the first unused account's chains - triggering the creation of a new account when used. Note that the name of the account will still need to be entered manually and cannot be synchronized via the block chain.

====Audits: N(m/*)====

In case an auditor needs full access to the list of incoming and outgoing payments, one can share all account public extended keys. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.

====Per-office balances: m/iH====

When a business has several independent offices, they can all use wallets derived from a single master. This will allow the headquarters to maintain a super-wallet that sees all incoming and outgoing transactions of all offices, and even permit moving money between the offices.

====Recurrent business-to-business transactions: N(m/iH/0)====

In case two business partners often transfer money, one can use the extended public key for the external chain of a specific account (M/i h/0) as a sort of "super address", allowing frequent transactions that cannot (easily) be associated, but without needing to request a new address for each payment.
Such a mechanism could also be used by mining pool operators as variable payout address.

====Unsecure money receiver: N(m/iH/0)====

When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that are used to receive payments. The webserver only needs to know the public extended key of the external chain of a single account. This means someone illegally obtaining access to the webserver can at most see all incoming payments but will not be able to steal the money, will not (trivially) be able to distinguish outgoing transactions, nor be able to see payments received by other webservers if there are several.

==Compatibility==

To comply with this standard, a client must at least be able to import an extended public or private key, to give access to its direct descendants as wallet keys. The wallet structure (master/account/chain/subchain) presented in the second part of the specification is advisory only, but is suggested as a minimal structure for easy compatibility - even when no separate accounts or distinction between internal and external chains is made. However, implementations may deviate from it for specific needs; more complex applications may call for a more complex tree structure.

==Security==

In addition to the expectations from the EC public-key cryptography itself:
* Given a public key K, an attacker cannot find the corresponding private key more efficiently than by solving the EC discrete logarithm problem (assumed to require 2128 group operations).
the intended security properties of this standard are:
* Given a child extended private key (ki,ci) and the integer i, an attacker cannot find the parent private key kpar more efficiently than a 2256 brute force of HMAC-SHA512.
* Given any number (2 ≤ N ≤ 232-1) of (index, extended private key) tuples (ij,(kij,cij)), with distinct ij's, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (kpar,cpar) such that for each j in (0..N-1) CKDpriv((kpar,cpar),ij)=(kij,cij)), cannot be done more efficiently than a 2256 brute force of HMAC-SHA512.
Note however that the following properties do not exist:
* Given a parent extended public key (Kpar,cpar) and a child public key (Ki), it is hard to find i.
* Given a parent extended public key (Kpar,cpar) and a non-hardened child private key (ki), it is hard to find kpar.

===Implications===

Private and public keys must be kept safe as usual. Leaking a private key means access to coins - leaking a public key can mean loss of privacy.

Somewhat more care must be taken regarding extended keys, as these correspond to an entire (sub)tree of keys.

One weakness that may not be immediately obvious, is that knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and thus every private and public key descending from it). This means that extended public keys must be treated more carefully than regular public keys.
It is also the reason for the existence of hardened keys, and why they are used for the account level in the tree. This way, a leak of account-specific (or below) private key never risks compromising the master or other accounts.

==Test Vectors==

===Test vector 1===

Seed (hex): 000102030405060708090a0b0c0d0e0f
* Chain m
** ext pub: xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8
** ext prv: xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi
* Chain m/0H
** ext pub: xpub68Gmy5EdvgibQVfPdqkBBCHxA5htiqg55crXYuXoQRKfDBFA1WEjWgP6LHhwBZeNK1VTsfTFUHCdrfp1bgwQ9xv5ski8PX9rL2dZXvgGDnw
** ext prv: xprv9uHRZZhk6KAJC1avXpDAp4MDc3sQKNxDiPvvkX8Br5ngLNv1TxvUxt4cV1rGL5hj6KCesnDYUhd7oWgT11eZG7XnxHrnYeSvkzY7d2bhkJ7
* Chain m/0H/1
** ext pub: xpub6ASuArnXKPbfEwhqN6e3mwBcDTgzisQN1wXN9BJcM47sSikHjJf3UFHKkNAWbWMiGj7Wf5uMash7SyYq527Hqck2AxYysAA7xmALppuCkwQ
** ext prv: xprv9wTYmMFdV23N2TdNG573QoEsfRrWKQgWeibmLntzniatZvR9BmLnvSxqu53Kw1UmYPxLgboyZQaXwTCg8MSY3H2EU4pWcQDnRnrVA1xe8fs
* Chain m/0H/1/2H
** ext pub: xpub6D4BDPcP2GT577Vvch3R8wDkScZWzQzMMUm3PWbmWvVJrZwQY4VUNgqFJPMM3No2dFDFGTsxxpG5uJh7n7epu4trkrX7x7DogT5Uv6fcLW5
** ext prv: xprv9z4pot5VBttmtdRTWfWQmoH1taj2axGVzFqSb8C9xaxKymcFzXBDptWmT7FwuEzG3ryjH4ktypQSAewRiNMjANTtpgP4mLTj34bhnZX7UiM
* Chain m/0H/1/2H/2
** ext pub: xpub6FHa3pjLCk84BayeJxFW2SP4XRrFd1JYnxeLeU8EqN3vDfZmbqBqaGJAyiLjTAwm6ZLRQUMv1ZACTj37sR62cfN7fe5JnJ7dh8zL4fiyLHV
** ext prv: xprvA2JDeKCSNNZky6uBCviVfJSKyQ1mDYahRjijr5idH2WwLsEd4Hsb2Tyh8RfQMuPh7f7RtyzTtdrbdqqsunu5Mm3wDvUAKRHSC34sJ7in334
* Chain m/0H/1/2H/2/1000000000
** ext pub: xpub6H1LXWLaKsWFhvm6RVpEL9P4KfRZSW7abD2ttkWP3SSQvnyA8FSVqNTEcYFgJS2UaFcxupHiYkro49S8yGasTvXEYBVPamhGW6cFJodrTHy
** ext prv: xprvA41z7zogVVwxVSgdKUHDy1SKmdb533PjDz7J6N6mV6uS3ze1ai8FHa8kmHScGpWmj4WggLyQjgPie1rFSruoUihUZREPSL39UNdE3BBDu76

===Test vector 2===

Seed (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542
* Chain m
** ext pub: xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB
** ext prv: xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U
* Chain m/0
** ext pub: xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH
** ext prv: xprv9vHkqa6EV4sPZHYqZznhT2NPtPCjKuDKGY38FBWLvgaDx45zo9WQRUT3dKYnjwih2yJD9mkrocEZXo1ex8G81dwSM1fwqWpWkeS3v86pgKt
* Chain m/0/2147483647H
** ext pub: xpub6ASAVgeehLbnwdqV6UKMHVzgqAG8Gr6riv3Fxxpj8ksbH9ebxaEyBLZ85ySDhKiLDBrQSARLq1uNRts8RuJiHjaDMBU4Zn9h8LZNnBC5y4a
** ext prv: xprv9wSp6B7kry3Vj9m1zSnLvN3xH8RdsPP1Mh7fAaR7aRLcQMKTR2vidYEeEg2mUCTAwCd6vnxVrcjfy2kRgVsFawNzmjuHc2YmYRmagcEPdU9
* Chain m/0/2147483647H/1
** ext pub: xpub6DF8uhdarytz3FWdA8TvFSvvAh8dP3283MY7p2V4SeE2wyWmG5mg5EwVvmdMVCQcoNJxGoWaU9DCWh89LojfZ537wTfunKau47EL2dhHKon
** ext prv: xprv9zFnWC6h2cLgpmSA46vutJzBcfJ8yaJGg8cX1e5StJh45BBciYTRXSd25UEPVuesF9yog62tGAQtHjXajPPdbRCHuWS6T8XA2ECKADdw4Ef
* Chain m/0/2147483647H/1/2147483646H
** ext pub: xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL
** ext prv: xprvA1RpRA33e1JQ7ifknakTFpgNXPmW2YvmhqLQYMmrj4xJXXWYpDPS3xz7iAxn8L39njGVyuoseXzU6rcxFLJ8HFsTjSyQbLYnMpCqE2VbFWc
* Chain m/0/2147483647H/1/2147483646H/2
** ext pub: xpub6FnCn6nSzZAw5Tw7cgR9bi15UV96gLZhjDstkXXxvCLsUXBGXPdSnLFbdpq8p9HmGsApME5hQTZ3emM2rnY5agb9rXpVGyy3bdW6EEgAtqt
** ext prv: xprvA2nrNbFZABcdryreWet9Ea4LvTJcGsqrMzxHx98MMrotbir7yrKCEXw7nadnHM8Dq38EGfSh6dqA9QWTyefMLEcBYJUuekgW4BYPJcr9E7j

===Test vector 3===

These vectors test for the retention of leading zeros. See [https://github.com/bitpay/bitcore-lib/issues/47 bitpay/bitcore-lib#47] and [https://github.com/iancoleman/bip39/issues/58 iancoleman/bip39#58] for more information.

Seed (hex): 4b381541583be4423346c643850da4b320e46a87ae3d2a4e6da11eba819cd4acba45d239319ac14f863b8d5ab5a0d0c64d2e8a1e7d1457df2e5a3c51c73235be
* Chain m
** ext pub: xpub661MyMwAqRbcEZVB4dScxMAdx6d4nFc9nvyvH3v4gJL378CSRZiYmhRoP7mBy6gSPSCYk6SzXPTf3ND1cZAceL7SfJ1Z3GC8vBgp2epUt13
** ext prv: xprv9s21ZrQH143K25QhxbucbDDuQ4naNntJRi4KUfWT7xo4EKsHt2QJDu7KXp1A3u7Bi1j8ph3EGsZ9Xvz9dGuVrtHHs7pXeTzjuxBrCmmhgC6
* Chain m/0H
** ext pub: xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y
** ext prv: xprv9uPDJpEQgRQfDcW7BkF7eTya6RPxXeJCqCJGHuCJ4GiRVLzkTXBAJMu2qaMWPrS7AANYqdq6vcBcBUdJCVVFceUvJFjaPdGZ2y9WACViL4L

===Test vector 4===

These vectors test for the retention of leading zeros. See [https://github.com/btcsuite/btcutil/issues/172 btcsuite/btcutil#172] for more information.

Seed (hex): 3ddd5602285899a946114506157c7997e5444528f3003f6134712147db19b678
* Chain m
** ext pub: xpub661MyMwAqRbcGczjuMoRm6dXaLDEhW1u34gKenbeYqAix21mdUKJyuyu5F1rzYGVxyL6tmgBUAEPrEz92mBXjByMRiJdba9wpnN37RLLAXa
** ext prv: xprv9s21ZrQH143K48vGoLGRPxgo2JNkJ3J3fqkirQC2zVdk5Dgd5w14S7fRDyHH4dWNHUgkvsvNDCkvAwcSHNAQwhwgNMgZhLtQC63zxwhQmRv
* Chain m/0H
** ext pub: xpub69AUMk3qDBi3uW1sXgjCmVjJ2G6WQoYSnNHyzkmdCHEhSZ4tBok37xfFEqHd2AddP56Tqp4o56AePAgCjYdvpW2PU2jbUPFKsav5ut6Ch1m
** ext prv: xprv9vB7xEWwNp9kh1wQRfCCQMnZUEG21LpbR9NPCNN1dwhiZkjjeGRnaALmPXCX7SgjFTiCTT6bXes17boXtjq3xLpcDjzEuGLQBM5ohqkao9G
* Chain m/0H/1H
** ext pub: xpub6BJA1jSqiukeaesWfxe6sNK9CCGaujFFSJLomWHprUL9DePQ4JDkM5d88n49sMGJxrhpjazuXYWdMf17C9T5XnxkopaeS7jGk1GyyVziaMt
** ext prv: xprv9xJocDuwtYCMNAo3Zw76WENQeAS6WGXQ55RCy7tDJ8oALr4FWkuVoHJeHVAcAqiZLE7Je3vZJHxspZdFHfnBEjHqU5hG1Jaj32dVoS6XLT1

===Test vector 5===

These vectors test that invalid extended keys are recognized as invalid.

* xpub661MyMwAqRbcEYS8w7XLSVeEsBXy79zSzH1J8vCdxAZningWLdN3zgtU6LBpB85b3D2yc8sfvZU521AAwdZafEz7mnzBBsz4wKY5fTtTQBm (pubkey version / prvkey mismatch)
* xprv9s21ZrQH143K24Mfq5zL5MhWK9hUhhGbd45hLXo2Pq2oqzMMo63oStZzFGTQQD3dC4H2D5GBj7vWvSQaaBv5cxi9gafk7NF3pnBju6dwKvH (prvkey version / pubkey mismatch)
* xpub661MyMwAqRbcEYS8w7XLSVeEsBXy79zSzH1J8vCdxAZningWLdN3zgtU6Txnt3siSujt9RCVYsx4qHZGc62TG4McvMGcAUjeuwZdduYEvFn (invalid pubkey prefix 04)
* xprv9s21ZrQH143K24Mfq5zL5MhWK9hUhhGbd45hLXo2Pq2oqzMMo63oStZzFGpWnsj83BHtEy5Zt8CcDr1UiRXuWCmTQLxEK9vbz5gPstX92JQ (invalid prvkey prefix 04)
* xpub661MyMwAqRbcEYS8w7XLSVeEsBXy79zSzH1J8vCdxAZningWLdN3zgtU6N8ZMMXctdiCjxTNq964yKkwrkBJJwpzZS4HS2fxvyYUA4q2Xe4 (invalid pubkey prefix 01)
* xprv9s21ZrQH143K24Mfq5zL5MhWK9hUhhGbd45hLXo2Pq2oqzMMo63oStZzFAzHGBP2UuGCqWLTAPLcMtD9y5gkZ6Eq3Rjuahrv17fEQ3Qen6J (invalid prvkey prefix 01)
* xprv9s2SPatNQ9Vc6GTbVMFPFo7jsaZySyzk7L8n2uqKXJen3KUmvQNTuLh3fhZMBoG3G4ZW1N2kZuHEPY53qmbZzCHshoQnNf4GvELZfqTUrcv (zero depth with non-zero parent fingerprint)
* xpub661no6RGEX3uJkY4bNnPcw4URcQTrSibUZ4NqJEw5eBkv7ovTwgiT91XX27VbEXGENhYRCf7hyEbWrR3FewATdCEebj6znwMfQkhRYHRLpJ (zero depth with non-zero parent fingerprint)
* xprv9s21ZrQH4r4TsiLvyLXqM9P7k1K3EYhA1kkD6xuquB5i39AU8KF42acDyL3qsDbU9NmZn6MsGSUYZEsuoePmjzsB3eFKSUEh3Gu1N3cqVUN (zero depth with non-zero index)
* xpub661MyMwAuDcm6CRQ5N4qiHKrJ39Xe1R1NyfouMKTTWcguwVcfrZJaNvhpebzGerh7gucBvzEQWRugZDuDXjNDRmXzSZe4c7mnTK97pTvGS8 (zero depth with non-zero index)
* DMwo58pR1QLEFihHiXPVykYB6fJmsTeHvyTp7hRThAtCX8CvYzgPcn8XnmdfHGMQzT7ayAmfo4z3gY5KfbrZWZ6St24UVf2Qgo6oujFktLHdHY4 (unknown extended key version)
* DMwo58pR1QLEFihHiXPVykYB6fJmsTeHvyTp7hRThAtCX8CvYzgPcn8XnmdfHPmHJiEDXkTiJTVV9rHEBUem2mwVbbNfvT2MTcAqj3nesx8uBf9 (unknown extended key version)
* xprv9s21ZrQH143K24Mfq5zL5MhWK9hUhhGbd45hLXo2Pq2oqzMMo63oStZzF93Y5wvzdUayhgkkFoicQZcP3y52uPPxFnfoLZB21Teqt1VvEHx (private key 0 not in 1..n-1)
* xprv9s21ZrQH143K24Mfq5zL5MhWK9hUhhGbd45hLXo2Pq2oqzMMo63oStZzFAzHGBP2UuGCqWLTAPLcMtD5SDKr24z3aiUvKr9bJpdrcLg1y3G (private key n not in 1..n-1)
* xpub661MyMwAqRbcEYS8w7XLSVeEsBXy79zSzH1J8vCdxAZningWLdN3zgtU6Q5JXayek4PRsn35jii4veMimro1xefsM58PgBMrvdYre8QyULY (invalid pubkey 020000000000000000000000000000000000000000000000000000000000000007)
* xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHL (invalid checksum)

==Acknowledgements==

* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.
* Eric Lombrozo for reviewing and revising this BIP.
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.