Bitcoin Wiki - User contributions [en]

Wladimir van der Laan

2025-01-15T21:23:52Z

Darosior: My bad i mistook these dates for the dates he was maintainer

{{infobox person
|name=Wladimir van der Laan
|names=Wlad, laanwj
|active=2011–present
|residence=Eindhoven, The Netherlands
|knownfor=Contributions to [[Bitcoin Core]]
|notableworks=[[Visucore]]
|twitter=orionwl
}}'''Wladimir J. van der Laan''' is a past [[Core maintainer|maintainer]] of [[Bitcoin Core]].

On April 7, 2014, [[Gavin Andresen]] stepped down from the position of Core maintainer and nominated Laan as his successor.<ref>{{cite web|title=Bitcoin Core Maintainer: Wladimir van der Laan|work=[[Bitcoin Foundation]]|date=7 April 2014|url=https://bitcoinfoundation.org/2014/04/bitcoin-core-maintainer-wladimir-van-der-laan/|author=[[Gavin Andresen|Andresen, Gavin]]|accessdate=19 September 2014}}</ref>

On January 21st, 2021, Wlad announced that he would be delegating his tasks.<ref>[https://laanwj.github.io/2021/01/21/decentralize.html The Widening Gyre on Lannwj's blog]</ref>

Wladimir gradualy stepped down in the following 2 years. On February 2023 Wladimir removed his own merge privileges. <ref>[https://github.com/bitcoin/bitcoin/pull/27054 Bitcoin Core pull request #27054]</ref>

==References==
<references/>
{{s-start|Bitcoin [[Core maintainer]]|[[Gavin Andresen]]|2014–2022|No more "lead maintainer"}}
{{developers}}{{stub}}
[[Category:Core committers]]
[[Category:Core developers]]

Wladimir van der Laan

2025-01-15T21:22:12Z

Darosior:

{{infobox person
|name=Wladimir van der Laan
|names=Wlad, laanwj
|active=2011–2023
|residence=Eindhoven, The Netherlands
|knownfor=Contributions to [[Bitcoin Core]]
|notableworks=[[Visucore]]
|twitter=orionwl
}}'''Wladimir J. van der Laan''' is a past [[Core maintainer|maintainer]] of [[Bitcoin Core]].

On April 7, 2014, [[Gavin Andresen]] stepped down from the position of Core maintainer and nominated Laan as his successor.<ref>{{cite web|title=Bitcoin Core Maintainer: Wladimir van der Laan|work=[[Bitcoin Foundation]]|date=7 April 2014|url=https://bitcoinfoundation.org/2014/04/bitcoin-core-maintainer-wladimir-van-der-laan/|author=[[Gavin Andresen|Andresen, Gavin]]|accessdate=19 September 2014}}</ref>

On January 21st, 2021, Wlad announced that he would be delegating his tasks.<ref>[https://laanwj.github.io/2021/01/21/decentralize.html The Widening Gyre on Lannwj's blog]</ref>

Wladimir gradualy stepped down in the following 2 years. On February 2023 Wladimir removed his own merge privileges. <ref>[https://github.com/bitcoin/bitcoin/pull/27054 Bitcoin Core pull request #27054]</ref>

==References==
<references/>
{{s-start|Bitcoin [[Core maintainer]]|[[Gavin Andresen]]|2014–2022|No more "lead maintainer"}}
{{developers}}{{stub}}
[[Category:Core committers]]
[[Category:Core developers]]

Wladimir van der Laan

2023-12-22T15:59:10Z

Darosior: Wladimir stepped back from the lead maintainer role in 2022 and revoked their maintainership entirely in early 2023.

{{infobox person
|name=Wladimir van der Laan
|names=Wlad, laanwj
|active=2011–present
|residence=Eindhoven, The Netherlands
|knownfor=Contributions to [[Bitcoin Core]]
|notableworks=[[Visucore]]
|twitter=orionwl
}}'''Wladimir J. van der Laan''' is the current [[Core maintainer|maintainer]] of [[Bitcoin Core]].

On April 7, 2014, [[Gavin Andresen]] stepped down from the position of Core maintainer and nominated Laan as his successor.<ref>{{cite web|title=Bitcoin Core Maintainer: Wladimir van der Laan|work=[[Bitcoin Foundation]]|date=7 April 2014|url=https://bitcoinfoundation.org/2014/04/bitcoin-core-maintainer-wladimir-van-der-laan/|author=[[Gavin Andresen|Andresen, Gavin]]|accessdate=19 September 2014}}</ref>

On January 21st, 2021, Wlad announced that he would be delegating his tasks.<ref>[https://laanwj.github.io/2021/01/21/decentralize.html The Widening Gyre on Lannwj's blog]</ref>

Wladimir gradualy stepped down in the following 2 years. On February 2023 Wladimir revoked their merge privileges. <ref>[https://github.com/bitcoin/bitcoin/pull/27054 Bitcoin Core pull request #27054]</ref>

==References==
<references/>
{{s-start|Bitcoin [[Core maintainer]]|[[Gavin Andresen]]|2014–2022|No more "lead maintainer"}}
{{developers}}{{stub}}
[[Category:Core committers]]
[[Category:Core developers]]

Bech32 adoption

2023-04-08T15:53:28Z

Darosior: /* Software Wallets */

[[Bech32]] is a bitcoin [[address]] format specified by [[BIP 0173]]. It is used for the native segwit version 0 output types, P2WPKH and P2WSH. The upcoming [[Taproot]] softfork will add another output type called Pay to Taproot (P2TR). P2TR outputs and future native segwit versions will be using an updated variant of [[Bech32]], called [[Bech32m]] (specified by [[BIP 0350]]). This page tracks the adoption of [[Bech32]] and [[Bech32m]].

Ideally wallets and services would first support ''sending to'' new addresses. When most wallets and services support sending to the new address type, people are more likely to adopt it for receiving.

The amount of bech32 addresses on the blockchain is tracked on this website: https://p2sh.info/dashboard/db/bech32-statistics?orgId=1

{| 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}} || {{Evaluating|Dependent on BitcoinJ}} || {{Evaluating|??}} || 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}} || {{No}} || {{No}} || Tested as of v0.12.1-beta (October 2022). Tracking issue: https://github.com/breez/breezmobile/issues/946. As of April 2023, the issue is still open.
|-
| 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)
|-
| 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|??}} ||
|-
| 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}} || {{Evaluating|Support in iOS, but not Android}} || {{No}} ||
|-
| 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}} || {{Evaluating|??}} || 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}} || {{Planned}} || Work already in progress
|-
| Ballet + app || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| SeedSigner || {{Yes}} || {{Yes}} || {{Planned}} || {{Evaluating|??}} ||
|-
| 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
|}

=== 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
|-
| 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}} || {{Evaluating|??}} || {{Evaluating|??}} || https://anycoindirect.eu/en/news/details/segwit-activated
|-
| Binance || {{Yes}} || {{Yes}} || {{No}} || {{No}} || https://twitter.com/colemaktypo/status/1460337599499882502
|-
| Bitaroo || {{Yes}} || {{Yes}} || {{Yes}} || {{No}} ||
|-
| BitBargain.co.uk || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| Bitcoin.de || {{Yes}} || {{No}} || {{No}} || {{No}} || https://twitter.com/Ben_deWaal/status/1460464528181936130
|-
| Bitfinex || {{Yes}} || {{No}} || {{Planned}} || {{No}} || https://twitter.com/paoloardoino/status/1460620727342796800
|-
| BitMEX || {{Yes}} || {{Yes}} || {{Yes}} || {{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}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/Bitso/status/1203784055340314624
|-
| Bitwage || {{Evaluating|??}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| Bitwala || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| 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}} || {{Yes}} || {{No}} ||
|-
| 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}} || {{Evaluating|??}} || {{Evaluating|??}} || https://coinmate.io/blog/important-coinmate-update/
|-
| Coinsbank.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| Coinygram || {{Yes}} || {{No}} || {{Evaluating|??}} || {{Evaluating|??}} ||
|-
| Flyp.me || {{Yes}} || {{No}} || {{Yes}} || {{Evaluating|??}} ||
|-
| FTX US Derivatives || {{Yes}} || {{Yes}} || {{Yes}} || {{Evaluating|??}} || Formerly LedgerX
|-
| 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}} || {{Yes}} || {{No}} || {{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}} || {{Planned|Planned}} || {{Evaluating|??}} || https://www.luno.com/blog/en/post/luno-launches-support-for-bech32-addresses
|-
| 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-
|-
| 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/
|-
| 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}} || {{No}} || {{No}} || https://twitter.com/BTCBoromir/status/1460373287792521232
|-
| Swan || {{Yes}} || No deposits || {{Yes}} || No deposits || https://twitter.com/SwanBitcoin/status/1468318386916663298
|-
| TheRockTrading.com || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://twitter.com/TheRockTrading/status/976787499648512003
|-
| VBTC || {{Yes}} || {{Planned}} || {{Yes}} || {{Planned}} || https://twitter.com/VBTC_Vietnam/status/1460978196816416775
|-
| Walltime || {{Yes}} || {{Yes}} || {{Evaluating|??}} || {{Evaluating|??}} || https://walltime.info
|-
| 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)}} || {{Planned}} || {{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
|}

=== 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]
|-
| [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}} || {{Acceptable|Supported but needs manual involvement}} || https://github.com/bitcoinjs/bitcoinjs-lib/issues/1522#issuecomment-887468902, https://twitter.com/junderwood4649/status/1459006392086372355
|-
| [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]]

Taproot activation proposal 202102

2021-02-16T23:06:55Z

Darosior: Actually nickler is fine with LOT=true

Expected timeline:
* 2021 March 17-31: Full node software released with Taproot activation deployment.
* 2021 July 23: Economic majority has upgraded. Miner signalling begins to indicate preparedness to protect the economic minority who haven’t upgraded yet.
* 2 weeks after 90% of hashrate signals: Taproot activates. Economic majority enforces, while miners protect the economic minority until they upgrade as well.
* 2022 August 1: Entire economy has upgraded.

For explanations of the various parameters, see BIP 8.

* name=taproot
** Rationale: Already used in Bitcoin Core (for Signet and tests), no reason to change (BIP8’s “bipN” recommendation not applicable due to 2 Taproot BIPs)

* bit=2
** Rationale: Already used in Bitcoin Core (for tests), no reason to change
** Note: Bit 2 is unaffected by ongoing miner ASICBoost false-bit-spam.

* startheight=693504 (~2021 July 23rd)
** Rationale 1:
*** Earliest activation (MASF) takes 4 weeks, coinciding with Bitcoin Core 0.20 Maintenance End. Therefore, a backport of Taproot to 0.20 (complex and would need validation) can be avoided.
** Rationale 2:
*** ~26 weeks (6.5 months) between meeting and earliest activation.
*** 1.5 months to prepare and release activation + 5 months for the economic majority to upgrade.

* timeoutheight=745920 (~2022 July 22nd / 1 year after signalling begins)
** Rationale:
*** Plenty of time and community support.
*** Remaining economic minority can be expected to upgrade within a year.

* lockinontime= NO CONSENSUS WAS REACHED

* threshold=1815 (90%)
** Rationale 1:
*** High enough to ensure the Taproot chain always has a lead ahead of any invalid chains.
** Rationale 2:
*** Low enough to avoid a sudden malicious stall of activation by rented or unknown miners.
*** 90% of hashrate has already committed to work toward Taproot activation.

= <code>lockinontimeout</code> preferences =

This table summarizes wether each person is fine with setting <code>lockinontimeout</code> to <code>true</code>
or <code>false</code>. [https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c source]

This only concerns the first deployment, those in favor of a <code>true</code> should a first attempt to activate
with <code>false</code> fail are counted as <code>false</code> here.

Some may be fine with both choices.

{|
! Nickname
! <code>LOT=true</code>
! <code>LOT=false</code>
|-
| belcher
| X
| X
|-
| benthecarman
| X
| X
|-
| waxwing
| X
| X
|-
| hsjoberg
| X
|
|-
| fjahr
|
| X
|-
| devrandom
| X
| X
|-
| darosior
|
| X
|-
| andrewtoth
|
| X
|-
| luke-jr
| X
|
|-
| enzy
| X
| X
|-
| viaj3ro
| X
| X
|-
| achow101
|
| X
|-
| virtu
|
| X
|-
| proofofkeags
| X
| X
|-
| nickler
| X
| X
|-
| satosaurian
| X
|
|-
| eeb77f7f26eee
| X
|
|-
| gg34
| X
| X
|-
| harding
|
| X
|-
| jonatack
|
| X
|-
| pox
| X
| X
|-
| Billy
| X
| X
|-
| evankaloudis
| X
| X
|-
| virtu
|
| X
|-
| criley
| X
| X
|-
| prayank
| X
|
|-
| debit
|
| X
|-
| Murch
|
| X
|-
| ghost43
|
| X
|-
| roasbeef
|
| X
|-
| elichai2
| X
| X
|-
| '''TOTALS'''
| '''19'''
| '''26'''
|}

Taproot activation proposal 202102

2021-02-16T22:59:41Z

Darosior: Add Elichai Turkel opinion for ##taproot-activation : "23:51 <elichai2> achow101: feel free to also add me as prefer false but OK with both."

Expected timeline:
* 2021 March 17-31: Full node software released with Taproot activation deployment.
* 2021 July 23: Economic majority has upgraded. Miner signalling begins to indicate preparedness to protect the economic minority who haven’t upgraded yet.
* 2 weeks after 90% of hashrate signals: Taproot activates. Economic majority enforces, while miners protect the economic minority until they upgrade as well.
* 2022 August 1: Entire economy has upgraded.

For explanations of the various parameters, see BIP 8.

* name=taproot
** Rationale: Already used in Bitcoin Core (for Signet and tests), no reason to change (BIP8’s “bipN” recommendation not applicable due to 2 Taproot BIPs)

* bit=2
** Rationale: Already used in Bitcoin Core (for tests), no reason to change
** Note: Bit 2 is unaffected by ongoing miner ASICBoost false-bit-spam.

* startheight=693504 (~2021 July 23rd)
** Rationale 1:
*** Earliest activation (MASF) takes 4 weeks, coinciding with Bitcoin Core 0.20 Maintenance End. Therefore, a backport of Taproot to 0.20 (complex and would need validation) can be avoided.
** Rationale 2:
*** ~26 weeks (6.5 months) between meeting and earliest activation.
*** 1.5 months to prepare and release activation + 5 months for the economic majority to upgrade.

* timeoutheight=745920 (~2022 July 22nd / 1 year after signalling begins)
** Rationale:
*** Plenty of time and community support.
*** Remaining economic minority can be expected to upgrade within a year.

* lockinontime= NO CONSENSUS WAS REACHED

* threshold=1815 (90%)
** Rationale 1:
*** High enough to ensure the Taproot chain always has a lead ahead of any invalid chains.
** Rationale 2:
*** Low enough to avoid a sudden malicious stall of activation by rented or unknown miners.
*** 90% of hashrate has already committed to work toward Taproot activation.

= <code>lockinontimeout</code> preferences =

This table summarizes wether each person is fine with setting <code>lockinontimeout</code> to <code>true</code>
or <code>false</code>. [https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c source]

This only concerns the first deployment, those in favor of a <code>true</code> should a first attempt to activate
with <code>false</code> fail are counted as <code>false</code> here.

Some may be fine with both choices.

{|
! Nickname
! <code>LOT=true</code>
! <code>LOT=false</code>
|-
| belcher
| X
| X
|-
| benthecarman
| X
| X
|-
| waxwing
| X
| X
|-
| hsjoberg
| X
|
|-
| fjahr
|
| X
|-
| devrandom
| X
| X
|-
| darosior
|
| X
|-
| andrewtoth
|
| X
|-
| luke-jr
| X
|
|-
| enzy
| X
| X
|-
| viaj3ro
| X
| X
|-
| achow101
|
| X
|-
| virtu
|
| X
|-
| proofofkeags
| X
| X
|-
| nickler
|
| X
|-
| satosaurian
| X
|
|-
| eeb77f7f26eee
| X
|
|-
| gg34
| X
| X
|-
| harding
|
| X
|-
| jonatack
|
| X
|-
| pox
| X
| X
|-
| Billy
| X
| X
|-
| evankaloudis
| X
| X
|-
| virtu
|
| X
|-
| criley
| X
| X
|-
| prayank
| X
|
|-
| debit
|
| X
|-
| Murch
|
| X
|-
| ghost43
|
| X
|-
| roasbeef
|
| X
|-
| elichai2
| X
| X
|-
| '''TOTALS'''
| '''18'''
| '''26'''
|}

Taproot activation proposal 202102

2021-02-16T22:45:41Z

Darosior: Add roasbeef's opinion from ##taproot-activation : "23:20 <roasbeef> uasf is just deterrence, just having the option is enough"

Expected timeline:
* 2021 March 17-31: Full node software released with Taproot activation deployment.
* 2021 July 23: Economic majority has upgraded. Miner signalling begins to indicate preparedness to protect the economic minority who haven’t upgraded yet.
* 2 weeks after 90% of hashrate signals: Taproot activates. Economic majority enforces, while miners protect the economic minority until they upgrade as well.
* 2022 August 1: Entire economy has upgraded.

For explanations of the various parameters, see BIP 8.

* name=taproot
** Rationale: Already used in Bitcoin Core (for Signet and tests), no reason to change (BIP8’s “bipN” recommendation not applicable due to 2 Taproot BIPs)

* bit=2
** Rationale: Already used in Bitcoin Core (for tests), no reason to change
** Note: Bit 2 is unaffected by ongoing miner ASICBoost false-bit-spam.

* startheight=693504 (~2021 July 23rd)
** Rationale 1:
*** Earliest activation (MASF) takes 4 weeks, coinciding with Bitcoin Core 0.20 Maintenance End. Therefore, a backport of Taproot to 0.20 (complex and would need validation) can be avoided.
** Rationale 2:
*** ~26 weeks (6.5 months) between meeting and earliest activation.
*** 1.5 months to prepare and release activation + 5 months for the economic majority to upgrade.

* timeoutheight=745920 (~2022 July 22nd / 1 year after signalling begins)
** Rationale:
*** Plenty of time and community support.
*** Remaining economic minority can be expected to upgrade within a year.

* lockinontime= NO CONSENSUS WAS REACHED

* threshold=1815 (90%)
** Rationale 1:
*** High enough to ensure the Taproot chain always has a lead ahead of any invalid chains.
** Rationale 2:
*** Low enough to avoid a sudden malicious stall of activation by rented or unknown miners.
*** 90% of hashrate has already committed to work toward Taproot activation.

= <code>lockinontimeout</code> preferences =

This table summarizes wether each person is fine with setting <code>lockinontimeout</code> to <code>true</code>
or <code>false</code>. [https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c source]

This only concerns the first deployment, those in favor of a <code>true</code> should a first attempt to activate
with <code>false</code> fail are counted as <code>false</code> here.

Some may be fine with both choices.

{|
! Nickname
! <code>LOT=true</code>
! <code>LOT=false</code>
|-
| belcher
| X
| X
|-
| benthecarman
| X
| X
|-
| waxwing
| X
| X
|-
| hsjoberg
| X
|
|-
| fjahr
|
| X
|-
| devrandom
| X
| X
|-
| darosior
|
| X
|-
| andrewtoth
|
| X
|-
| luke-jr
| X
|
|-
| enzy
| X
| X
|-
| viaj3ro
| X
| X
|-
| achow101
|
| X
|-
| virtu
|
| X
|-
| proofofkeags
| X
| X
|-
| nickler
|
| X
|-
| satosaurian
| X
|
|-
| eeb77f7f26eee
| X
|
|-
| gg34
| X
| X
|-
| harding
|
| X
|-
| jonatack
|
| X
|-
| pox
| X
| X
|-
| Billy
| X
| X
|-
| evankaloudis
| X
| X
|-
| virtu
|
| X
|-
| criley
| X
| X
|-
| prayank
| X
|
|-
| debit
|
| X
|-
| Murch
|
| X
|-
| ghost43
|
| X
|-
| roasbeef
|
| X
|-
| '''TOTALS'''
| '''17'''
| '''25'''
|}

Taproot activation proposal 202102

2021-02-16T22:25:05Z

Darosior:

Expected timeline:
* 2021 March 17-31: Full node software released with Taproot activation deployment.
* 2021 July 23: Economic majority has upgraded. Miner signalling begins to indicate preparedness to protect the economic minority who haven’t upgraded yet.
* 2 weeks after 90% of hashrate signals: Taproot activates. Economic majority enforces, while miners protect the economic minority until they upgrade as well.
* 2022 August 1: Entire economy has upgraded.

For explanations of the various parameters, see BIP 8.

* name=taproot
** Rationale: Already used in Bitcoin Core (for Signet and tests), no reason to change (BIP8’s “bipN” recommendation not applicable due to 2 Taproot BIPs)

* bit=2
** Rationale: Already used in Bitcoin Core (for tests), no reason to change
** Note: Bit 2 is unaffected by ongoing miner ASICBoost false-bit-spam.

* startheight=693504 (~2021 July 23rd)
** Rationale 1:
*** Earliest activation (MASF) takes 4 weeks, coinciding with Bitcoin Core 0.20 Maintenance End. Therefore, a backport of Taproot to 0.20 (complex and would need validation) can be avoided.
** Rationale 2:
*** ~26 weeks (6.5 months) between meeting and earliest activation.
*** 1.5 months to prepare and release activation + 5 months for the economic majority to upgrade.

* timeoutheight=745920 (~2022 July 22nd / 1 year after signalling begins)
** Rationale:
*** Plenty of time and community support.
*** Remaining economic minority can be expected to upgrade within a year.

* lockinontime= NO CONSENSUS WAS REACHED

* threshold=1815 (90%)
** Rationale 1:
*** High enough to ensure the Taproot chain always has a lead ahead of any invalid chains.
** Rationale 2:
*** Low enough to avoid a sudden malicious stall of activation by rented or unknown miners.
*** 90% of hashrate has already committed to work toward Taproot activation.

= <code>lockinontimeout</code> preferences =

This table summarizes wether each person is fine with setting <code>lockinontimeout</code> to <code>true</code>
or <code>false</code>. [https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c source]

This only concerns the first deployment, those in favor of a <code>true</code> should a first attempt to activate
with <code>false</code> fail are counted as <code>false</code> here.

Some may be fine with both choices.

{|
! Nickname
! <code>LOT=true</code>
! <code>LOT=false</code>
|-
| belcher
| X
| X
|-
| benthecarman
| X
| X
|-
| waxwing
| X
| X
|-
| hsjoberg
| X
|
|-
| fjahr
|
| X
|-
| devrandom
| X
| X
|-
| darosior
|
| X
|-
| andrewtoth
|
| X
|-
| luke-jr
| X
|
|-
| enzy
| X
| X
|-
| viaj3ro
| X
| X
|-
| achow101
|
| X
|-
| virtu
|
| X
|-
| proofofkeags
| X
| X
|-
| nickler
|
| X
|-
| satosaurian
| X
|
|-
| eeb77f7f26eee
| X
|
|-
| gg34
| X
| X
|-
| harding
|
| X
|-
| jonatack
|
| X
|-
| pox
| X
| X
|-
| Billy
| X
| X
|-
| evankaloudis
| X
| X
|-
| virtu
|
| X
|-
| criley
| X
| X
|-
| prayank
| X
|
|-
| debit
|
| X
|-
| Murch
|
| X
|-
| ghost43
|
| X
|-
| '''TOTALS'''
| '''17'''
| '''24'''
|}

Taproot activation proposal 202102

2021-02-16T22:23:51Z

Darosior:

Expected timeline:
* 2021 March 17-31: Full node software released with Taproot activation deployment.
* 2021 July 23: Economic majority has upgraded. Miner signalling begins to indicate preparedness to protect the economic minority who haven’t upgraded yet.
* 2 weeks after 90% of hashrate signals: Taproot activates. Economic majority enforces, while miners protect the economic minority until they upgrade as well.
* 2022 August 1: Entire economy has upgraded.

For explanations of the various parameters, see BIP 8.

* name=taproot
** Rationale: Already used in Bitcoin Core (for Signet and tests), no reason to change (BIP8’s “bipN” recommendation not applicable due to 2 Taproot BIPs)

* bit=2
** Rationale: Already used in Bitcoin Core (for tests), no reason to change
** Note: Bit 2 is unaffected by ongoing miner ASICBoost false-bit-spam.

* startheight=693504 (~2021 July 23rd)
** Rationale 1:
*** Earliest activation (MASF) takes 4 weeks, coinciding with Bitcoin Core 0.20 Maintenance End. Therefore, a backport of Taproot to 0.20 (complex and would need validation) can be avoided.
** Rationale 2:
*** ~26 weeks (6.5 months) between meeting and earliest activation.
*** 1.5 months to prepare and release activation + 5 months for the economic majority to upgrade.

* timeoutheight=745920 (~2022 July 22nd / 1 year after signalling begins)
** Rationale:
*** Plenty of time and community support.
*** Remaining economic minority can be expected to upgrade within a year.

* lockinontime= NO CONSENSUS WAS REACHED

* threshold=1815 (90%)
** Rationale 1:
*** High enough to ensure the Taproot chain always has a lead ahead of any invalid chains.
** Rationale 2:
*** Low enough to avoid a sudden malicious stall of activation by rented or unknown miners.
*** 90% of hashrate has already committed to work toward Taproot activation.

= <code>lockinontimeout</code> preferences =

This table summarizes wether each person is fine with setting <code>lockinontimeout</code> to <code>true</code>
or <code>false</code>.

This only concerns the first deployment, those in favor of a <code>true</code> should a first attempt to activate
with <code>false</code> fail are counted as <code>false</code> here.

Some may be fine with both choices.

{|
! Nickname
! <code>LOT=true</code>
! <code>LOT=false</code>
|-
| belcher
| X
| X
|-
| benthecarman
| X
| X
|-
| waxwing
| X
| X
|-
| hsjoberg
| X
|
|-
| fjahr
|
| X
|-
| devrandom
| X
| X
|-
| darosior
|
| X
|-
| andrewtoth
|
| X
|-
| luke-jr
| X
|
|-
| enzy
| X
| X
|-
| viaj3ro
| X
| X
|-
| achow101
|
| X
|-
| virtu
|
| X
|-
| proofofkeags
| X
| X
|-
| nickler
|
| X
|-
| satosaurian
| X
|
|-
| eeb77f7f26eee
| X
|
|-
| gg34
| X
| X
|-
| harding
|
| X
|-
| jonatack
|
| X
|-
| pox
| X
| X
|-
| Billy
| X
| X
|-
| evankaloudis
| X
| X
|-
| virtu
|
| X
|-
| criley
| X
| X
|-
| prayank
| X
|
|-
| debit
|
| X
|-
| Murch
|
| X
|-
| ghost43
|
| X
|-
| '''TOTALS'''
| '''17'''
| '''24'''
|}

Taproot activation proposal 202102

2021-02-16T22:18:59Z

Darosior:

Expected timeline:
* 2021 March 17-31: Full node software released with Taproot activation deployment.
* 2021 July 23: Economic majority has upgraded. Miner signalling begins to indicate preparedness to protect the economic minority who haven’t upgraded yet.
* 2 weeks after 90% of hashrate signals: Taproot activates. Economic majority enforces, while miners protect the economic minority until they upgrade as well.
* 2022 August 1: Entire economy has upgraded.

For explanations of the various parameters, see BIP 8.

* name=taproot
** Rationale: Already used in Bitcoin Core (for Signet and tests), no reason to change (BIP8’s “bipN” recommendation not applicable due to 2 Taproot BIPs)

* bit=2
** Rationale: Already used in Bitcoin Core (for tests), no reason to change
** Note: Bit 2 is unaffected by ongoing miner ASICBoost false-bit-spam.

* startheight=693504 (~2021 July 23rd)
** Rationale 1:
*** Earliest activation (MASF) takes 4 weeks, coinciding with Bitcoin Core 0.20 Maintenance End. Therefore, a backport of Taproot to 0.20 (complex and would need validation) can be avoided.
** Rationale 2:
*** ~26 weeks (6.5 months) between meeting and earliest activation.
*** 1.5 months to prepare and release activation + 5 months for the economic majority to upgrade.

* timeoutheight=745920 (~2022 July 22nd / 1 year after signalling begins)
** Rationale:
*** Plenty of time and community support.
*** Remaining economic minority can be expected to upgrade within a year.

* lockinontime= NO CONSENSUS WAS REACHED

* threshold=1815 (90%)
** Rationale 1:
*** High enough to ensure the Taproot chain always has a lead ahead of any invalid chains.
** Rationale 2:
*** Low enough to avoid a sudden malicious stall of activation by rented or unknown miners.
*** 90% of hashrate has already committed to work toward Taproot activation.

== `lockinontimeout` preferences

{|
! Nickname
! <code>LOT=true</code>
! <code>LOT=false</code>
|-
| belcher
| X
| X
|-
| benthecarman
| X
| X
|-
| waxwing
| X
| X
|-
| hsjoberg
| X
|
|-
| fjahr
|
| X
|-
| devrandom
| X
| X
|-
| darosior
|
| X
|-
| andrewtoth
|
| X
|-
| luke-jr
| X
|
|-
| enzy
| X
| X
|-
| viaj3ro
| X
| X
|-
| achow101
|
| X
|-
| virtu
|
| X
|-
| proofofkeags
| X
| X
|-
| nickler
|
| X
|-
| satosaurian
| X
|
|-
| eeb77f7f26eee
| X
|
|-
| gg34
| X
| X
|-
| harding
|
| X
|-
| jonatack
|
| X
|-
| pox
| X
| X
|-
| Billy
| X
| X
|-
| evankaloudis
| X
| X
|-
| virtu
|
| X
|-
| criley
| X
| X
|-
| prayank
| X
|
|-
| debit
|
| X
|-
| Murch
|
| X
|-
| ghost43
|
| X
|-
| '''TOTALS'''
| '''17'''
| '''24'''
|}

Protocol documentation

2020-12-14T19:59:23Z

Darosior: /* version */ Add missing service flags. XTHIN was never really a thing, but listed for hysterical raisins.

This page ''describes'' the behavior of the [[Original Bitcoin client|reference client]]. The Bitcoin protocol is specified by the behavior of the reference client, not by this page. In particular, while this page is quite complete in describing the [[network]] protocol, it does not attempt to list all of the rules for block or transaction validity.

Type names used in this documentation are from the C99 standard.

For protocol used in mining, see [[getblocktemplate]].

==Common standards==

=== Hashes ===

Usually, when a hash is computed within bitcoin, it is computed twice. Most of the time [http://en.wikipedia.org/wiki/SHA-2 SHA-256] hashes are used, however [http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160] is also used when a shorter hash is desirable (for example when creating a bitcoin address).

Example of double-SHA-256 encoding of string "hello":

hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)

For bitcoin addresses (RIPEMD-160) this would give:

hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round is sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (with ripemd-160)

=== Merkle Trees ===

Merkle trees are binary trees of hashes. Merkle trees in bitcoin use a '''double''' SHA-256, the SHA-256 hash of the SHA-256 hash of something.

If, when forming a row in the tree (other than the root of the tree), it would have an odd number of elements, the final double-hash is duplicated to ensure that the row has an even number of hashes.

First form the bottom row of the tree with the ordered double-SHA-256 hashes of the byte streams of the transactions in the block.

Then the row above it consists of half that number of hashes. Each entry is the double-SHA-256 of the 64-byte concatenation of the corresponding two hashes below it in the tree.

This procedure repeats recursively until we reach a row consisting of just a single double-hash. This is the '''Merkle root''' of the tree.

For example, imagine a block with three transactions ''a'', ''b'' and ''c''. The Merkle tree is:

d1 = dhash(a)
d2 = dhash(b)
d3 = dhash(c)
d4 = dhash(c) # a, b, c are 3. that's an odd number, so we take the c twice

d5 = dhash(d1 concat d2)
d6 = dhash(d3 concat d4)

d7 = dhash(d5 concat d6)

where

dhash(a) = sha256(sha256(a))

''d7'' is the Merkle root of the 3 transactions in this block.

Note: Hashes in Merkle Tree displayed in the [[Block Explorer]] are of little-endian notation. For some implementations and [http://www.fileformat.info/tool/hash.htm calculations], the bytes need to be reversed before they are hashed, and again after the hashing operation.

=== Signatures ===

Bitcoin uses [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography Elliptic Curve] [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] ([http://en.wikipedia.org/wiki/Elliptic_Curve_DSA ECDSA]) to sign transactions.

For [[ECDSA]] the secp256k1 curve from http://www.secg.org/sec2-v2.pdf is used.

Public keys (in scripts) are given as 04 <x> <y> where ''x'' and ''y'' are 32 byte big-endian integers representing the coordinates of a point on the curve or in compressed form given as <sign> <x> where <sign> is 0x02 if ''y'' is even and 0x03 if ''y'' is odd.

Signatures use [http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER encoding] to pack the ''r'' and ''s'' components into a single byte stream (this is also what OpenSSL produces by default).

=== Transaction Verification ===
Transactions are cryptographically signed records that reassign ownership of Bitcoins to new addresses. Transactions have ''inputs'' - records which reference the funds from other previous transactions - and ''outputs'' - records which determine the new owner of the transferred Bitcoins, and which will be referenced as inputs in future transactions as those funds are respent.

Each ''input'' must have a cryptographic digital signature that unlocks the funds from the prior transaction. Only the person possessing the appropriate [[private key]] is able to create a satisfactory signature; this in effect ensures that funds can only be spent by their owners.

Each ''output'' determines which Bitcoin address (or other criteria, see [[Script]]) is the recipient of the funds.

In a transaction, the sum of all inputs must be equal to or greater than the sum of all outputs. If the inputs exceed the outputs, the difference is considered a [[transaction fee]], and is redeemable by whoever first includes the transaction into the block chain.

A special kind of transaction, called a [[coinbase transaction]], has no inputs. It is created by [[miners]], and there is one coinbase transaction per block. Because each block comes with a reward of newly created Bitcoins (e.g. 50 BTC for the first 210,000 blocks), the first transaction of a block is, with few exceptions, the transaction that grants those coins to their recipient (the miner). In addition to the newly created Bitcoins, the coinbase transaction is also used for assigning the recipient of any transaction fees that were paid within the other transactions being included in the same block. The coinbase transaction can assign the entire reward to a single Bitcoin address, or split it in portions among multiple addresses, just like any other transaction. Coinbase transactions always contain outputs totalling the sum of the block reward plus all transaction fees collected from the other transactions in the same block.

The [[coinbase transaction]] in block zero cannot be spent. This is due to a quirk of the reference client implementation that would open the potential for a block chain fork if some nodes accepted the spend and others did not<ref>[http://bitcointalk.org/index.php?topic=119645.msg1288552#msg1288552 Block 0 Network Fork]</ref>.

Most Bitcoin outputs encumber the newly transferred coins with a single ECDSA private key. The actual record saved with inputs and outputs isn't necessarily a key, but a ''script''. Bitcoin uses an interpreted scripting system to determine whether an output's criteria have been satisfied, with which more complex operations are possible, such as outputs that require two ECDSA signatures, or two-of-three-signature schemes. An output that references a single Bitcoin address is a ''typical'' output; an output actually contains this information in the form of a script that requires a single ECDSA signature (see [[OP_CHECKSIG]]). The output script specifies what must be provided to unlock the funds later, and when the time comes in the future to spend the transaction in another input, that input must provide all of the thing(s) that satisfy the requirements defined by the original output script.

=== Addresses ===

A bitcoin address is in fact the hash of a ECDSA public key, computed this way:

Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111
Key hash = Version concatenated with RIPEMD-160(SHA-256(public key))
Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash))
Bitcoin Address = Base58Encode(Key hash concatenated with Checksum)

The Base58 encoding used is home made, and has some differences. Especially, leading zeroes are kept as single zeroes when conversion happens.

== Common structures ==

Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.

=== Message structure ===

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || magic || uint32_t || Magic value indicating message origin network, and used to seek to next message when stream state is unknown
|-
| 12 || command || char[12] || ASCII string identifying the packet content, NULL padded (non-NULL padding results in packet rejected)
|-
| 4 || length || uint32_t || Length of payload in number of bytes
|-
| 4 || checksum || uint32_t || First 4 bytes of sha256(sha256(payload))
|-
| ? || payload || uchar[] || The actual data
|}

Known magic values:

{|class="wikitable"
! Network !! Magic value !! Sent over wire as
|-
| main || 0xD9B4BEF9 || F9 BE B4 D9
|-
| testnet/regtest || 0xDAB5BFFA || FA BF B5 DA
|-
| testnet3 || 0x0709110B || 0B 11 09 07
|-
| signet(default) || 0x40CF030A || 0A 03 CF 40
|-
| namecoin || 0xFEB4BEF9 || F9 BE B4 FE
|}

=== Variable length integer ===

Integer can be encoded depending on the represented value to save space.
Variable length integers always precede an array/vector of a type of data that may vary in length.
Longer numbers are encoded in little endian.

{|class="wikitable"
! Value !! Storage length !! Format
|-
| < 0xFD || 1 || uint8_t
|-
| <= 0xFFFF || 3 || 0xFD followed by the length as uint16_t
|-
| <= 0xFFFF FFFF || 5 || 0xFE followed by the length as uint32_t
|-
| - || 9 || 0xFF followed by the length as uint64_t
|}

If you're reading the Satoshi client code (BitcoinQT) it refers to this encoding as a "CompactSize". Modern Bitcoin Core also has the VARINT macro which implements an even more compact integer for the purpose of local storage (which is incompatible with "CompactSize" described here). VARINT is not a part of the protocol.

=== Variable length string ===

Variable length string can be stored using a variable length integer followed by the string itself.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || length || [[Protocol_documentation#Variable_length_integer|var_int]] || Length of the string
|-
| ? || string || char[] || The string itself (can be empty)
|}

=== Network address ===

When a network address is needed somewhere, this structure is used. Network addresses are not prefixed with a timestamp in the version message.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || time || uint32 || the Time (version >= 31402). '''Not present in version message.'''
|-
| 8 || services || uint64_t || same service(s) listed in [[#version|version]]
|-
| 16 || IPv6/4 || char[16] || IPv6 address. Network byte order. The original client only supported IPv4 and only read the last 4 bytes to get the IPv4 address. However, the IPv4 address is written into the message as a 16 byte [http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4-mapped IPv6 address]
(12 bytes ''00 00 00 00 00 00 00 00 00 00 FF FF'', followed by the 4 bytes of the IPv4 address).
|-
| 2 || port || uint16_t || port number, network byte order
|}

Hexdump example of Network address structure

<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK: see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:a00:1 or IPv4: 10.0.0.1
20 8D - Port 8333
</pre>

=== Inventory Vectors ===

Inventory vectors are used for notifying other nodes about objects they have or data which is being requested.

Inventory vectors consist of the following data format:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || Identifies the object type linked to this inventory
|-
| 32 || hash || char[32] || Hash of the object
|}

The object type is currently defined as one of the following possibilities:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || ERROR || Any data of with this number may be ignored
|-
| 1 || MSG_TX || Hash is related to a transaction
|-
| 2 || MSG_BLOCK || Hash is related to a data block
|-
| 3 || MSG_FILTERED_BLOCK || Hash of a block header; identical to MSG_BLOCK. Only to be used in getdata message. Indicates the reply should be a merkleblock message rather than a block message; this only works if a bloom filter has been set. See BIP 37 for more info.
|-
| 4 || MSG_CMPCT_BLOCK || Hash of a block header; identical to MSG_BLOCK. Only to be used in getdata message. Indicates the reply should be a cmpctblock message. See BIP 152 for more info.
|-
| 0x40000001 || MSG_WITNESS_TX || Hash of a transaction with witness data. See BIP 144 for more info.
|-
| 0x40000002 || MSG_WITNESS_BLOCK || Hash of a block with witness data. See BIP 144 for more info.
|-
| 0x40000003 || MSG_FILTERED_WITNESS_BLOCK || Hash of a block with witness data. Only to be used in getdata message. Indicates the reply should be a merkleblock message rather than a block message; this only works if a bloom filter has been set. See BIP 144 for more info.
|}

Other Data Type values are considered reserved for future implementations.

=== Block Headers ===

Block headers are sent in a headers packet in response to a getheaders message.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || int32_t || Block version information (note, this is signed)
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Will overflow in 2106<ref>https://en.wikipedia.org/wiki/Unix_time#Notable_events_in_Unix_time</ref>)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| 1+ || txn_count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of transaction entries, this value is always 0
|}

cf. [[Block hashing algorithm]]

=== Differential encoding ===
Several uses of CompactSize below are "differentially encoded". For these, instead of using raw indexes, the number encoded is the difference between the current index and the previous index, minus one. For example, a first index of 0 implies a real index of 0, a second index of 0 thereafter refers to a real index of 1, etc.

=== PrefilledTransaction ===

A PrefilledTransaction structure is used in HeaderAndShortIDs to provide a list of a few transactions explicitly.

{|class="wikitable"
! Field Name !! Type !! Size !! Encoding || Purpose
|-
| index || [[Protocol_documentation#Variable_length_integer|CompactSize]] || 1, 3 bytes || Compact Size, differentially encoded since the last PrefilledTransaction in a list || The index into the block at which this transaction is
|-
| tx || Transaction || variable || As encoded in [[Protocol_documentation#tx|tx messages]] || The transaction which is in the block at index index.
|}

See [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

=== HeaderAndShortIDs ===

A HeaderAndShortIDs structure is used to relay a block header, the short transactions IDs used for matching already-available transactions, and a select few transactions which we expect a peer may be missing.

{|class="wikitable"
! Field Name !! Type !! Size !! Encoding || Purpose
|-
| header || Block header || 80 bytes || First 80 bytes of the block as defined by the encoding used by "block" messages || The header of the block being provided
|-
| nonce || uint64_t || 8 bytes || Little Endian || A nonce for use in short transaction ID calculations
|-
| shortids_length || [[Protocol_documentation#Variable_length_integer|CompactSize]] || 1 or 3 bytes || As used to encode array lengths elsewhere || The number of short transaction IDs in shortids (ie block tx count - prefilledtxn_length)
|-
| shortids || List of 6-byte integers || 6*shortids_length bytes || Little Endian || The [[Protocol_documentation#Short_transaction_ID|short transaction IDs]] calculated from the transactions which were not provided explicitly in prefilledtxn
|-
| prefilledtxn_length || [[Protocol_documentation#Variable_length_integer|CompactSize]] || 1 or 3 bytes || As used to encode array lengths elsewhere || The number of prefilled transactions in prefilledtxn (ie block tx count - shortids_length)
|-
| prefilledtxn || List of PrefilledTransactions || variable size*prefilledtxn_length || As defined by [[Protocol_documentation#PrefilledTransaction|PrefilledTransaction]] definition, above || Used to provide the coinbase transaction and a select few which we expect a peer may be missing
|}

See [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

=== BlockTransactionsRequest ===

A BlockTransactionsRequest structure is used to list transaction indexes in a block being requested.

{|class="wikitable"
! Field Name !! Type !! Size !! Encoding || Purpose
|-
| blockhash || Binary blob || 32 bytes || The output from a double-SHA256 of the block header, as used elsewhere || The blockhash of the block which the transactions being requested are in
|-
| indexes_length || [[Protocol_documentation#Variable_length_integer|CompactSize]] || 1 or 3 bytes || As used to encode array lengths elsewhere || The number of transactions being requested
|-
| indexes || List of [[Protocol_documentation#Variable_length_integer|CompactSizes]] || 1 or 3 bytes*indexes_length || [[Protocol_documentation#Differential_encoding|Differentially encoded]] || The indexes of the transactions being requested in the block
|}

See [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

=== BlockTransactions ===

A BlockTransactions structure is used to provide some of the transactions in a block, as requested.

{|class="wikitable"
! Field Name !! Type !! Size !! Encoding || Purpose
|-
| blockhash || Binary blob || 32 bytes || The output from a double-SHA256 of the block header, as used elsewhere || The blockhash of the block which the transactions being provided are in
|-
| transactions_length || [[Protocol_documentation#Variable_length_integer|CompactSize]] || 1 or 3 bytes || As used to encode array lengths elsewhere || The number of transactions provided
|-
| transactions || List of Transactions || variable || As encoded in [[Protocol_documentation#tx|tx messages]] || The transactions provided
|}

See [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

=== Short transaction ID ===

Short transaction IDs are used to represent a transaction without sending a full 256-bit hash. They are calculated by:

# single-SHA256 hashing the block header with the nonce appended (in little-endian)
# Running SipHash-2-4 with the input being the transaction ID and the keys (k0/k1) set to the first two little-endian 64-bit integers from the above hash, respectively.
# Dropping the 2 most significant bytes from the SipHash output to make it 6 bytes.

See [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

== Message types ==

=== version ===

When a node creates an outgoing connection, it will immediately [[Version Handshake|advertise]] its version. The remote node will respond with its version. No further communication is possible until both peers have exchanged their version.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || int32_t || Identifies protocol version being used by the node
|-
| 8 || services || uint64_t || bitfield of features to be enabled for this connection
|-
| 8 || timestamp || int64_t || standard UNIX timestamp in seconds
|-
| 26 || addr_recv || [[#Network address|net_addr]] || The network address of the node receiving this message
|-
|colspan="4"| Fields below require version ≥ 106
|-
| 26 || addr_from || [[#Network address|net_addr]] || The network address of the node emitting this message
|-
| 8 || nonce || uint64_t || Node random nonce, randomly generated every time a version packet is sent. This nonce is used to detect connections to self.
|-
| ? || user_agent || [[#Variable length string|var_str]] || [https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki User Agent] (0x00 if string is 0 bytes long)
|-
| 4 || start_height || int32_t || The last block received by the emitting node
|-
|colspan="4"| Fields below require version ≥ 70001
|-
| 1 || relay || bool || Whether the remote peer should announce relayed transactions or not, see [https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki BIP 0037]
|}

A "verack" packet shall be sent if the version packet was accepted.

The following services are currently assigned:

{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.
|-
| 2 || NODE_GETUTXO || See [https://github.com/bitcoin/bips/blob/master/bip-0064.mediawiki BIP 0064]
|-
| 4 || NODE_BLOOM || See [https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki BIP 0111]
|-
| 8 || NODE_WITNESS || See [https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki BIP 0144]
|-
| 16 || NODE_XTHIN || Never formally proposed (as a BIP), and discontinued. Was historically sporadically seen on the network.
|-
| 64 || NODE_COMPACT_FILTERS || See [https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki BIP 0157]
|-
| 1024 || NODE_NETWORK_LIMITED || See [https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki BIP 0159]
|}

Hexdump example of version message (OBSOLETE EXAMPLE: This example lacks a checksum and user-agent):
<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 20 8D 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command
55 00 00 00 - Payload is 85 bytes long
- No checksum in version message until 20 February 2012. See https://bitcointalk.org/index.php?topic=55852.0
Version message:
9C 7C 00 00 - 31900 (version 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 20 8D - Recipient address info - see Network Address
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - Sender address info - see Network Address
DD 9D 20 2C 3A B4 57 13 - Node random unique ID
00 - "" sub-version string (string is 0 bytes long)
55 81 01 00 - Last block sending node has is block #98645
</pre>

And here's a modern (60002) protocol version client advertising itself to a local peer...

Newer protocol includes the checksum now, this is from a mainline (satoshi) client during
an outgoing connection to another local client, notice that it does not fill out the
address information at all when the source or destination is "unroutable".

<pre>

0000 f9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00 ....version.....
0010 64 00 00 00 35 8d 49 32 62 ea 00 00 01 00 00 00 d...5.I2b.......
0020 00 00 00 00 11 b2 d0 50 00 00 00 00 01 00 00 00 .......P........
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ................
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 00 00 00 00 ff ff 00 00 00 00 00 00 ................
0060 3b 2e b3 5d 8c e6 17 65 0f 2f 53 61 74 6f 73 68 ;..]...e./Satosh
0070 69 3a 30 2e 37 2e 32 2f c0 3e 03 00 i:0.7.2/.>..

Message Header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command
64 00 00 00 - Payload is 100 bytes long
35 8d 49 32 - payload checksum (little endian)

Version message:
62 EA 00 00 - 60002 (protocol version 60002)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
11 B2 D0 50 00 00 00 00 - Tue Dec 18 10:12:33 PST 2012
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Recipient address info - see Network Address
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Sender address info - see Network Address
3B 2E B3 5D 8C E6 17 65 - Node ID
0F 2F 53 61 74 6F 73 68 69 3A 30 2E 37 2E 32 2F - "/Satoshi:0.7.2/" sub-version string (string is 15 bytes long)
C0 3E 03 00 - Last block sending node has is block #212672
</pre>

=== verack ===

The ''verack'' message is sent in reply to ''[[#version|version]]''. This message consists of only a [[#Message structure|message header]] with the command string "verack".

Hexdump of the verack message:

<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 5D F6 E0 E2 ........

Message header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 61 63 6B 00 00 00 00 00 00 - "verack" command
00 00 00 00 - Payload is 0 bytes long
5D F6 E0 E2 - Checksum (little endian)
</pre>

=== addr ===

Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours

Payload:
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of address entries (max: 1000)
|-
| 30x? || addr_list || (uint32_t + [[#Network address|net_addr]])[] || Address of other nodes on the network. version < 209 will only read the first one. The uint32_t is a timestamp (see note below).
|}

'''Note''': Starting version 31402, addresses are prefixed with a timestamp. If no timestamp is present, the addresses should not be relayed to other peers, unless it is indeed confirmed they are up.

Hexdump example of ''addr'' message:
<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 ED 52 39 9B 01 E2 15 10 4D 01 00 00 .....R9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D ..... .

Message Header:
F9 BE B4 D9 - Main network magic bytes
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload is 31 bytes long
ED 52 39 9B - payload checksum (little endian)

Payload:
01 - 1 address in this message

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - port 8333
</pre>

=== inv ===

Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.

Payload (maximum 50,000 entries, which is just over 1.8 megabytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== getdata ===

getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements. It can be used to retrieve transactions, but only if they are in the memory pool or relay set - arbitrary access to transactions in the chain is not allowed to avoid having clients start to depend on nodes having full transaction indexes (which modern nodes do not).

Payload (maximum 50,000 entries, which is just over 1.8 megabytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== notfound ===

notfound is a response to a getdata, sent if any requested data items could not be relayed, for example, because the requested transaction was not in the memory pool or relay set.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== getblocks ===

Return an ''inv'' packet containing the list of blocks starting right after the last known hash in the block locator object, up to hash_stop or 500 blocks, whichever comes first.

The locator hashes are processed by a node in the order as they appear in the message. If a block hash is found in the node's main chain, the list of its children is returned back via the ''inv'' message and the remaining locators are ignored, no matter if the requested limit was reached, or not.

To receive the next blocks hashes, one needs to issue getblocks again with a new block locator object. Keep in mind that some clients may provide blocks which are invalid if the block locator object contains a hash on the invalid branch.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || the protocol version
|-
| 1+ || hash count || [[Protocol_documentation#Variable_length_integer|var_int]] || number of block locator hash entries
|-
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)
|-
| 32 || hash_stop || char[32] || hash of the last desired block; set to zero to get as many blocks as possible (500)
|}

To create the block locator hashes, keep pushing hashes until you go back to the genesis block. After pushing 10 hashes back, the step backwards doubles every loop:

<pre>
// From libbitcoin which is under AGPL
std::vector<size_t> block_locator_indexes(size_t top_height)
{
std::vector<size_t> indexes;

// Modify the step in the iteration.
int64_t step = 1;

// Start at the top of the chain and work backwards.
for (auto index = (int64_t)top_height; index > 0; index -= step)
{
// Push top 10 indexes first, then back off exponentially.
if (indexes.size() >= 10)
step *= 2;

indexes.push_back((size_t)index);
}

// Push the genesis block index.
indexes.push_back(0);
return indexes;
}
</pre>

Note that it is allowed to send in fewer known hashes down to a minimum of just one hash. However, the purpose of the block locator object is to detect a wrong branch in the caller's main chain. If the peer detects that you are off the main chain, it will send in block hashes which are earlier than your last known block. So if you just send in your last known hash and it is off the main chain, the peer starts over at block #1.

=== getheaders ===

Return a ''headers'' packet containing the headers of blocks starting right after the last known hash in the block locator object, up to hash_stop or 2000 blocks, whichever comes first. To receive the next block headers, one needs to issue getheaders again with a new block locator object. Keep in mind that some clients may provide headers of blocks which are invalid if the block locator object contains a hash on the invalid branch.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || the protocol version
|-
| 1+ || hash count || [[Protocol_documentation#Variable_length_integer|var_int]] || number of block locator hash entries
|-
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)
|-
| 32 || hash_stop || char[32] || hash of the last desired block header; set to zero to get as many blocks as possible (2000)
|}

For the block locator object in this packet, the same rules apply as for the [[Protocol_documentation#getblocks|getblocks]] packet.

=== tx ===

''tx'' describes a bitcoin transaction, in reply to ''[[#getdata|getdata]]''. When a bloom filter is applied ''tx'' objects are sent automatically for matching transactions following the <code>merkleblock</code>.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || int32_t || Transaction data format version (note, this is signed)
|-
| 0 or 2 || flag || optional uint8_t[2] || If present, always 0001, and indicates the presence of witness data
|-
| 1+ || tx_in count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of Transaction inputs (never zero)
|-
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins
|-
| 1+ || tx_out count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of Transaction outputs
|-
| 9+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins
|-
| 0+ || tx_witnesses || tx_witness[] || A list of witnesses, one for each input; omitted if ''flag'' is omitted above
|-
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is unlocked:
{|class="wikitable"
! Value !! Description
|-
| 0 || Not locked
|-
| < 500000000 || Block number at which this transaction is unlocked
|-
| >= 500000000 || UNIX timestamp at which this transaction is unlocked
|}
If all TxIn inputs have final (0xffffffff) sequence numbers then lock_time is irrelevant. Otherwise, the transaction may not be added to a block until after lock_time (see [[NLockTime]]).

|}

TxIn consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure
|-
| 1+ || script length || [[Protocol_documentation#Variable_length_integer|var_int]] || The length of the signature script
|-
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization
|-
| 4 || [http://bitcoin.stackexchange.com/q/2025/323 sequence] || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.
|}

The OutPoint structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || The hash of the referenced transaction.
|-
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.
|}

The Script structure consists of a series of pieces of information and operations related to the value of the transaction.

(Structure to be expanded in the future… see script.h and script.cpp and [[Script]] for more information)

The TxOut structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || int64_t || Transaction Value
|-
| 1+ || pk_script length || [[Protocol_documentation#Variable_length_integer|var_int]] || Length of the pk_script
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

The TxWitness structure consists of a [[Protocol_documentation#Variable_length_integer|var_int]] count of witness data components, followed by (for each witness data component) a [[Protocol_documentation#Variable_length_integer|var_int]] length of the component and the raw component data itself.

Example ''tx'' message:
<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - main network magic bytes
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command
02 01 00 00 - payload is 258 bytes long
E2 93 CD BE - payload checksum (little endian)

Transaction:
01 00 00 00 - version

Inputs:
01 - number of transaction inputs

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - script is 139 bytes long

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 2 Output Transactions

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script is 25 bytes long

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script is 25 bytes long

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || int32_t || Block version information (note, this is signed)
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A Unix timestamp recording when this block was created (Currently limited to dates before the year 2106!)
|-
| 4 || bits || uint32_t || The calculated [[Difficulty|difficulty target]] being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| 1+ || txn_count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of transaction entries
|-
| ? || txns || tx[] || Block transactions, in format of "tx" command
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.
See [[Block hashing algorithm]] for details and an example.

=== headers ===

The ''headers'' packet returns block headers in response to a ''getheaders'' packet.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of block headers
|-
| 81x? || headers || [[Protocol_documentation#Block_Headers|block_header]][] || [[Protocol_documentation#Block_Headers|Block headers]]
|}

Note that the block headers in this packet include a transaction count (a var_int, so there can be more than 81 bytes per header) as opposed to the block headers that are hashed by miners.

=== getaddr ===

The getaddr message sends a request to a node asking for information about known active peers to help with finding potential nodes in the network. The response to receiving this message is to transmit one or more addr messages with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.

No additional data is transmitted with this message.

=== mempool ===

The mempool message sends a request to a node asking for information about transactions it has verified but which have not yet confirmed. The response to receiving this message is an inv message containing the transaction hashes for all the transactions in the node's mempool.

No additional data is transmitted with this message.

It is specified in [https://github.com/bitcoin/bips/blob/master/bip-0035.mediawiki BIP 35]. Since [https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki BIP 37], if a [[Protocol_documentation#filterload.2C_filteradd.2C_filterclear.2C_merkleblock|bloom filter]] is loaded, only transactions matching the filter are replied.

=== checkorder ===

This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.

=== submitorder ===

This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.

=== reply ===

This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || nonce || uint64_t || random nonce
|}

=== pong ===

The ''pong'' message is sent in response to a ''ping'' message. In modern protocol versions, a ''pong'' response is generated using a nonce included in the ping.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || nonce || uint64_t || nonce from ping
|}

=== reject===

The ''reject'' message is sent when messages are rejected.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || message || var_str || type of message rejected
|-
| 1 || ccode || char || code relating to rejected message
|-
| 1+ || reason || var_str || text version of reason for rejection
|-
| 0+ || data || char || Optional extra data provided by some errors. Currently, all errors which provide this field fill it with the TXID or block header hash of the object being rejected, so the field is 32 bytes.
|}

CCodes

{|class="wikitable"
! Value !! Name !! Description
|-
| 0x01 || REJECT_MALFORMED||
|-
| 0x10 || REJECT_INVALID ||
|-
| 0x11 || REJECT_OBSOLETE ||
|-
| 0x12 || REJECT_DUPLICATE ||
|-
| 0x40 || REJECT_NONSTANDARD ||
|-
| 0x41 || REJECT_DUST ||
|-
| 0x42 || REJECT_INSUFFICIENTFEE ||
|-
| 0x43 || REJECT_CHECKPOINT ||
|}

=== filterload, filteradd, filterclear, merkleblock ===

These messages are related to Bloom filtering of connections and are defined in [https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki BIP 0037].

The <code>filterload</code> command is defined as follows:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || filter || uint8_t[] || The filter itself is simply a bit field of arbitrary byte-aligned size. The maximum size is 36,000 bytes.
|-
| 4 || nHashFuncs || uint32_t || The number of hash functions to use in this filter. The maximum value allowed in this field is 50.
|-
| 4 || nTweak || uint32_t || A random value to add to the seed value in the hash function used by the bloom filter.
|-
| 1 || nFlags || uint8_t || A set of flags that control how matched items are added to the filter.
|}

See below for a description of the Bloom filter algorithm and how to select nHashFuncs and filter size for a desired false positive rate.

Upon receiving a <code>filterload</code> command, the remote peer will immediately restrict the broadcast transactions it announces (in inv packets) to transactions matching the filter, where the matching algorithm is specified below. The flags control the update behaviour of the matching algorithm.

The <code>filteradd</code> command is defined as follows:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || data || uint8_t[] || The data element to add to the current filter.
|}

The data field must be smaller than or equal to 520 bytes in size (the maximum size of any potentially matched object).

The given data element will be added to the Bloom filter. A filter must have been previously provided using <code>filterload</code>. This command is useful if a new key or script is added to a clients wallet whilst it has connections to the network open, it avoids the need to re-calculate and send an entirely new filter to every peer (though doing so is usually advisable to maintain anonymity).

The <code>filterclear</code> command has no arguments at all.

After a filter has been set, nodes don't merely stop announcing non-matching transactions, they can also serve filtered blocks. A filtered block is defined by the <code>merkleblock</code> message and is defined like this:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || int32_t || Block version information, based upon the software version creating this block (note, this is signed)
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| 4 || total_transactions || uint32_t || Number of transactions in the block (including unmatched ones)
|-
| 1+ || hash_count || [[Protocol_documentation#Variable_length_integer|var_int]] || The number of hashes to follow
|-
| 32x? || hashes || char[32] || Hashes in depth-first order
|-
| 1+ || flag_bytes || [[Protocol_documentation#Variable_length_integer|var_int]] || The size of flags (in bytes) to follow
|-
| ? || flags || byte[] || Flag bits, packed per 8 in a byte, least significant bit first. Extra 0 bits are padded on to reach full byte size.
|}

After a <code>merkleblock</code>, transactions matching the bloom filter are automatically sent in ''[[#tx|tx]]'' messages.

A guide to creating a bloom filter, loading a merkle block, and parsing a partial merkle block tree can be found in the [https://bitcoin.org/en/developer-examples#creating-a-bloom-filter Developer Examples].

=== alert ===

'''Note:''' Support for [[Alert system|alert messages]] has been removed from bitcoin core in March 2016. Read more [https://bitcoin.org/en/alert/2016-11-01-alert-retirement here]

An [[Alert system|'''alert''']] is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Alert format:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || payload || uchar[] || Serialized alert payload
|-
| ? || signature || uchar[] || An ECDSA signature of the message
|}

The developers of Satoshi's client use this public key for signing alerts:
04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

The payload is serialized into a uchar[] to ensure that versions using incompatible alert formats can still relay alerts among one another. The current alert payload format is:
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || Version || int32_t || Alert format version
|-
| 8 || RelayUntil || int64_t || The timestamp beyond which nodes should stop relaying this alert
|-
| 8 || Expiration || int64_t || The timestamp beyond which this alert is no longer in effect and should be ignored
|-
| 4 || ID || int32_t || A unique ID number for this alert
|-
| 4 || Cancel || int32_t || All alerts with an ID number less than or equal to this number should be cancelled: deleted and not accepted in the future
|-
| ? || setCancel || set<int32_t> || All alert IDs contained in this set should be cancelled as above
|-
| 4 || MinVer || int32_t || This alert only applies to versions greater than or equal to this version. Other versions should still relay it.
|-
| 4 || MaxVer || int32_t || This alert only applies to versions less than or equal to this version. Other versions should still relay it.
|-
| ? || setSubVer || set<string> || If this set contains any elements, then only nodes that have their subVer contained in this set are affected by the alert. Other versions should still relay it.
|-
| 4 || Priority || int32_t || Relative priority compared to other alerts
|-
| ? || Comment || string || A comment on the alert that is not displayed
|-
| ? || StatusBar || string || The alert message that is displayed to the user
|-
| ? || Reserved || string || Reserved
|}

Note: '''set<''type''>''' in the table above is a [[#Variable length integer | variable length integer]] followed by the number of fields of the given ''type'' (either int32_t or [[#Variable length string | variable length string]])

Sample alert (no message header):
73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee0000
0064000000004653656520626974636f696e2e6f72672f666562323020696620796f75206861
76652074726f75626c6520636f6e6e656374696e672061667465722032302046656272756172
79004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b
53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1

Version: 1
RelayUntil: 1329620535
Expiration: 1329792435
ID: 1010
Cancel: 1009
setCancel: <empty>
MinVer: 10000
MaxVer: 61000
setSubVer: <empty>
Priority: 100
Comment: <empty>
StatusBar: "See bitcoin.org/feb20 if you have trouble connecting after 20 February"
Reserved: <empty>

=== sendheaders ===

Request for Direct headers announcement.

Upon receipt of this message, the node is be permitted, but not required, to announce new blocks by '''headers''' command (instead of '''inv''' command).

This message is supported by the protocol version >= 70012 or Bitcoin Core version >= 0.12.0.

See [https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki BIP 130] for more information.

No additional data is transmitted with this message.

=== feefilter ===

The payload is always 8 bytes long and it encodes 64 bit integer value (LSB / little endian) of '''feerate'''.
The value represents a minimal fee and is expressed in satoshis per 1000 bytes.

Upon receipt of a "feefilter" message, the node will be permitted, but not required, to filter transaction invs for transactions that fall below the feerate provided in the feefilter message interpreted as satoshis per kilobyte.

The fee filter is additive with a bloom filter for transactions so if an SPV client were to load a bloom filter and send a feefilter message, transactions would only be relayed if they passed both filters.

Inv's generated from a mempool message are also subject to a fee filter if it exists.

Feature discovery is enabled by checking protocol version >= 70013

See [https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki BIP 133] for more information.

=== sendcmpct ===

# The sendcmpct message is defined as a message containing a 1-byte integer followed by a 8-byte integer where pchCommand == "sendcmpct".
# The first integer SHALL be interpreted as a boolean (and MUST have a value of either 1 or 0)
# The second integer SHALL be interpreted as a little-endian version number. Nodes sending a sendcmpct message MUST currently set this value to 1.
# Upon receipt of a "sendcmpct" message with the first and second integers set to 1, the node SHOULD announce new blocks by sending a cmpctblock message.
# Upon receipt of a "sendcmpct" message with the first integer set to 0, the node SHOULD NOT announce new blocks by sending a cmpctblock message, but SHOULD announce new blocks by sending invs or headers, as defined by BIP130.
# Upon receipt of a "sendcmpct" message with the second integer set to something other than 1, nodes MUST treat the peer as if they had not received the message (as it indicates the peer will provide an unexpected encoding in
# cmpctblock, and/or other, messages). This allows future versions to send duplicate sendcmpct messages with different versions as a part of a version handshake for future versions.
# Nodes SHOULD check for a protocol version of >= 70014 before sending sendcmpct messages.
# Nodes MUST NOT send a request for a MSG_CMPCT_BLOCK object to a peer before having received a sendcmpct message from that peer.

This message is only supported by protocol version >= 70014

See [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

=== cmpctblock ===

# The cmpctblock message is defined as as a message containing a serialized [[Protocol_documentation#HeaderAndShortIDs|HeaderAndShortIDs]] message and pchCommand == "cmpctblock".
# Upon receipt of a cmpctblock message after sending a sendcmpct message, nodes SHOULD calculate the [[Protocol_documentation#Short_transaction_ID|short transaction ID]] for each unconfirmed transaction they have available (ie in their mempool) and compare each to each short transaction ID in the cmpctblock message.
# After finding already-available transactions, nodes which do not have all transactions available to reconstruct the full block SHOULD request the missing transactions using a getblocktxn message.
# A node MUST NOT send a cmpctblock message unless they are able to respond to a getblocktxn message which requests every transaction in the block.
# A node MUST NOT send a cmpctblock message without having validated that the header properly commits to each transaction in the block, and properly builds on top of the existing chain with a valid proof-of-work. A node MAY send a cmpctblock before validating that each transaction in the block validly spends existing [[UTXO]] set entries.

This message is only supported by protocol version >= 70014

See [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

=== getblocktxn ===

# The getblocktxn message is defined as as a message containing a serialized [[Protocol_documentation#BlockTransactionsRequest|BlockTransactionsRequest]] message and pchCommand == "getblocktxn".
# Upon receipt of a properly-formatted getblocktxnmessage, nodes which recently provided the sender of such a message a cmpctblock for the block hash identified in this message MUST respond with an appropriate [[Protocol_documentation#blocktxn|blocktxn]] message. Such a blocktxn message MUST contain exactly and only each transaction which is present in the appropriate block at the index specified in the getblocktxn indexes list, in the order requested.

This message is only supported by protocol version >= 70014

See [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

=== blocktxn ===

# The blocktxn message is defined as as a message containing a serialized [[Protocol_documentation#BlockTransactions|BlockTransactions]] message and pchCommand == "blocktxn".
# Upon receipt of a properly-formatted requested blocktxn message, nodes SHOULD attempt to reconstruct the full block by:
# Taking the prefilledtxn transactions from the original [[Protocol_documentation#cmpctblock|cmpctblock]] and placing them in the marked positions.
# For each short transaction ID from the original [[Protocol_documentation#cmpctblock|cmpctblock]], in order, find the corresponding transaction either from the blocktxn message or from other sources and place it in the first available position in the block.
# Once the block has been reconstructed, it shall be processed as normal, keeping in mind that short transaction IDs are expected to occasionally collide, and that nodes MUST NOT be penalized for such collisions, wherever they appear.

This message is only supported by protocol version >= 70014

See [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

== Scripting ==

See [[script]].

==See Also==

* [[Network]]
* [[Protocol rules]]
* [[Hardfork Wishlist]]
* [https://bitcoin.org/en/developer-documentation Developer Documentation on bitcoin.org]
* Bitcoin dissectors for Wireshark: https://github.com/lbotsch/wireshark-bitcoin https://github.com/op-sig/bitcoin-wireshark-dissector

==References==
<references />

[[zh-cn:协议说明]]
[[Category:Technical]]
[[Category:Developer]]

{{Bitcoin Core documentation}}

Signet

2020-09-22T11:03:10Z

Darosior: "Bitcoin's block chain" is often interpreted as the mainnet's one. Signet uses a different one.

Signet ([[BIP 0325]]) is a proposed new test network for Bitcoin which adds an additional signature requirement to block validation. Signet is similar in nature to [[testnet]], but more reliable and centrally controlled. There is a default signet network ("Signet Global Test Net VI" as of this writing), but anyone can run their own signet network at their whim.

Run bitcoind with the <code>-signet</code> flag to use the default global signet (or put <code>signet=1</code> in the <code>bitcoin.conf</code> file). If you wish to use a [[#Custom Signet|custom signet]], you need to provide the block challenge (aka the block script) using <code>-signetchallenge=<hex></code>, and preferably also at least one seed node using <code>-signetseednode=<host>[:<port>]</code>.

==Differences==

* Default Bitcoin network protocol listen port is 38333 (instead of 8333)
* Default RPC connection port is 38332 (instead of 8332)
* A different value of ADDRESSVERSION field ensures no signet Bitcoin addresses will work on the production network. (0x6F rather than 0x00)
* The protocol message header bytes are *dynamically generated* based on the block challenge, i.e. every signet is different; the header for the current default signet is <code>0x0A03CF40</code> (that is reversed e.g. in Rust variables) (instead of <code>0xF9BEB4D9</code>), but see [[#Genesis_Block_and_Message_Header]]
* Genesis block has timestamp 1598918400, nonce 52613770, and difficulty 0x1e0377ae.
* Segwit is always enabled
* Additional consensus requirement that the coinbase witness commitment contains an extended signet commitment, which is a script satisfying the block script (usually a k-of-n multisig)

==Why run Signet?==

* You are an Instructor, and want to run a controlled Bitcoin network environment for teaching purposes.
* You are a Software Developer, and want to test your software.
* You want to try out experimental changes that you want to implement in Bitcoin.
* You want to test long-term running software and don't want to deal with tens of thousands of block reorgs, or days of no blocks being mined, as is the case with Testnet.
* You want an easy way to test double spends (signet plans to include support for automated double spends, where you provide two conflicting transactions and they are mined in order, with a reorg happening between them).

==Genesis Block and Message Header==

All signet networks share the same genesis block, but have a different message header. The message header is the 4 first bytes of the sha256d-hash of the block challenge, as a single script push operation. I.e. if the block challenge is 37 bytes, the message start would be sha256d(0x25 || challenge)[0..3].

==Getting Started==

===Fetch and compile signet===

<pre>
$ git clone https://github.com/kallewoof/bitcoin.git signet
$ cd signet
$ git checkout signet
$ ./autogen.sh
$ ./configure
$ make -j5
</pre>

===Create bitcoin.conf file and start up the daemon===

<pre>
$ cd src
$ mkdir signet
$ echo "signet=1
daemon=1" > signet/bitcoin.conf
$ ./bitcoind -datadir=signet
</pre>

===Verify that you're connected===

<pre>
$ ./bitcoin-cli -datadir=signet getconnectioncount
***SHOULD BE MORE THAN ZERO***
$ ./bitcoin-cli -datadir=signet getblockcount
***SHOULD BE MORE THAN ZERO***
</pre>

===Get some coins===

There is a command line tool you can use to get coins directly to your instance of Signet, assuming you are on the default network. You can also use the faucet online with an address of yours.

====Using online faucet====

You first need an address

<pre>
$ ./bitcoin-cli -datadir=signet getnewaddress
</pre>

Then go to a faucet, e.g. https://signet.bc-2.jp and enter your address.

====Using the command line tool====

The tool is in <code>contrib/signet</code> and is called <code>getcoins.sh</code>. You can optionally provide a path to <code>bitcoin-cli</code> using <code>--cmd=[path]</code> and a compatible faucet using <code>--faucet=[url]</code> followed by any number of arguments to <code>bitcoin-cli</code>. The script attempts to autodetect these if left out.

<pre>
$ cd ../contrib/signet
$ ./getcoins.sh -datadir=../../src/signet
Payment of 10.00000000 BTC sent with txid c0bfa...
</pre>

===Check that you received the coins===

Check your faucet transaction confirming at e.g. https://explorer.bc-2.jp and then send coins around to people and/or use signet for testing your wallet/etc.

You can immediately see the amount using <code>getunconfirmedbalance</code> i.e.

<pre>
$ cd ../../src # if you were in contrib/signet
$ ./bitcoin-cli -datadir=signet getunconfirmedbalance
</pre>

You can also see info about the transaction that the faucet gave you.

<pre>
$ ./bitcoin-cli -datadir=signet gettransaction THETXID
</pre>

Once it has confirmed, you should see it in <code>getbalance</code>.

<pre>
$ ./bitcoin-cli -datadir=signet getbalance
</pre>

==External links==

* [https://github.com/bitcoin/bitcoin/pull/18267 Pull request #18267 to Bitcoin Core]
* [https://github.com/rust-bitcoin/rust-bitcoin/pull/291 Pull request #291 to Rust-Bitcoin]
* [https://gist.github.com/kallewoof/98b6d8dbe126d2b6f47da0ddccd2aa5a Github gist explaining how to get started]

===Faucets===

* https://signet.bc-2.jp/

Can also ping @kallewoof on IRC (freenode)/Twitter.

Faucet source code, if you want your own:

* https://github.com/kallewoof/bitcoin-faucet.git (node.js and mongodb)
* https://github.com/stepansnigirev/tinyfaucet.git (python)

===Block explorers===

* https://explorer.bc-2.jp/

==Custom Signet==

Creating your own signet involves a couple of steps: generate keys used for signing, define the block script, start up a node running on the new signet, and import the private key in order to sign blocks.

===Generating keys used for signing a block===

The most straightforward way is to simply start up a regtest node and then generating a new key from there.

<pre>
$ cd PATHTOBITCOIN/bitcoin/src
$ ./bitcoind -regtest -daemon
$ ADDR=$(./bitcoin-cli -regtest getnewaddress)
$ PRIVKEY=$(./bitcoin-cli -regtest dumpprivkey $ADDR)
$ ./bitcoin-cli -regtest getaddressinfo $ADDR | grep pubkey
"pubkey": "02c60c3940e5REDACTEDbd0148cd",
</pre>

We need to jot down the privkey (<code>echo $PRIVKEY</code>) and the pubkey (here <code>02c60...</code>).

===Defining the block script===

The block script is just like any old Bitcoin script, but the most common type is a k-of-n multisig. Here we will do a 1-of-1 multisig with our single pubkey above. Our script becomes
* <code>51</code> "1" (signature count)
* <code>21</code> Push 0x21=33 bytes (the length of our pubkey above)
* <code>02c60c3940e5REDACTEDbd0148cd</code> (our pubkey)
* <code>51</code> "1" (pubkey count)
* <code>ae</code> <code>OP_CHECKMULTISIG</code> opcode

Put together, our <code>-signetchallenge</code> value becomes <code>512102c60c3940e5REDACTEDbd0148cd51ae</code>.

===Start up a node (issuer)===

For the network to be useful, it needs to be generating blocks at decent intervals, so let's start up a node that does that (it may be useful to also use that node as a seed node for other peers).

Note that we are importing <code>$PRIVKEY</code> at the end; any node that needs to issue blocks must import the privkey we generated above, or it will fail to sign blocks.

<pre>
$ ./bitcoin-cli -signet stop
$ datadir=$HOME/signet-custom
$ mkdir $datadir
$ echo "signet=1
[signet]
daemon=1
signetchallenge=512102c60c3940e5REDACTEDbd0148cd51ae" > $datadir/bitcoin.conf
$ ./bitcoind -datadir=$datadir
$ ./bitcoin-cli -datadir=$datadir importprivkey $PRIVKEY
</pre>

Note: if you run into errors above, you may have a different signet running, which is blocking the ports. Either stop that, or set port and rpcport in the <code>$datadir/bitcoin.conf</code> file under the <code>[signet]</code> section and try again from the <code>bitcoind</code> part above.

===Run issuer===

Lastly, we start the issuer script located in <code>contrib/signet</code>.

<pre>
$ cd ../contrib/signet
$ ./issuer.sh 540 ../../src/bitcoin-cli -datadir=$datadir
- checking node status
- 23:51:01: node OK with 0 connection(s)
- 23:51:01: mining at maximum capacity with 540 second delay between each block
- 23:51:01: hit ^C to stop
- 23:51:01: generating next block
- 23:51:08: mined block 1 0000321422407052c06fef1eacbee402571787c9828051981adfbb5d50a2330a to 0 peer(s); idling for 540 seconds
</pre>

This script will keep on mining blocks every 540 seconds (actually it will take about 60 seconds to generate a block after the difficulty has stabilized, so you should be seeing one block every 600 seconds) until you hit ctrl-C. It may be a good idea to run this in a screen, so you can check back on it occasionally.

You may also want to run the issuer with a lower idle time initially, so you get some mature coinbase outputs faster.

Next is to have your friends/colleagues/etc join the network by setting the <code>signetchallenge</code> to the same as above, and connecting to your node.

[[Category:Technical]]
[[Category:Developer]]

{{Bitcoin Core documentation}}

Script

2020-07-25T20:53:07Z

Darosior: Add a link to Miniscript description on Sipa's website

Bitcoin uses a scripting system for [[transactions]]. [[Wikipedia:FORTH|Forth]]-like, '''Script''' is simple, stack-based, and processed from left to right. It is intentionally not Turing-complete, with no loops.

A script is essentially a list of instructions recorded with each transaction that describe how the next person wanting to spend the Bitcoins being transferred can gain access to them. The script for a typical Bitcoin transfer to destination Bitcoin address D simply encumbers future spending of the bitcoins with two things: the spender must provide
# a public key that, when hashed, yields destination address D embedded in the script, and
# a signature to prove ownership of the private key corresponding to the public key just provided.

Scripting provides the flexibility to change the parameters of what's needed to spend transferred Bitcoins. For example, the scripting system could be used to require two private keys, or a combination of several keys, or even no keys at all.

A transaction is valid if nothing in the combined script triggers failure and the top stack item is True (non-zero) when the script exits. The party that originally ''sent'' the Bitcoins now being spent dictates the script operations that will occur ''last'' in order to release them for use in another transaction. The party wanting to spend them must provide the input(s) to the previously recorded script that results in the combined script completing execution with a true value on the top of the stack.

This document is for information purposes only. De facto, Bitcoin script is defined by the code run by the network to check the validity of blocks.

The stacks hold byte vectors.
When used as numbers, byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer.
Thus 0x81 represents -1.
0x80 is another representation of zero (so called negative 0).
Positive 0 is represented by a null-length vector.
Byte vectors are interpreted as Booleans where False is represented by any representation of zero and True is represented by any representation of non-zero.

Leading zeros in an integer and negative zero are allowed in blocks but get rejected by the stricter requirements which standard full nodes put on transactions before retransmitting them.
Byte vectors on the stack are not allowed to be more than 520 bytes long. Opcodes which take integers and bools off the stack require that they be no more than 4 bytes long, but addition and subtraction can overflow and result in a 5 byte integer being put on the stack.

== Opcodes ==
This is a list of all Script words, also known as opcodes, commands, or functions.

There are some words which existed in very early versions of Bitcoin but were removed out of concern that the client might have a bug in their implementation. This fear was motivated by a bug found in OP_LSHIFT that could crash any Bitcoin node if exploited and by other bugs that allowed anyone to spend anyone's bitcoins. The removed opcodes are sometimes said to be "disabled", but this is something of a misnomer because there is ''absolutely no way'' for anyone using Bitcoin to use these opcodes (they simply ''do not exist anymore'' in the protocol), and there are also no solid plans to ever re-enable all of these opcodes. They are listed here for historical interest only.

New opcodes can be added by means of a carefully designed and executed [[softfork]] using OP_NOP1-OP_NOP10.

False is zero or negative zero (using any number of bytes) or an empty array, and True is anything else.

=== Constants ===
When talking about scripts, these value-pushing words are usually omitted.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_0, OP_FALSE
|0
|0x00
|Nothing.
|(empty value)
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)
|-
|N/A
|1-75
|0x01-0x4b
|(special)
|data
|The next ''opcode'' bytes is data to be pushed onto the stack
|-
|OP_PUSHDATA1
|76
|0x4c
|(special)
|data
|The next byte contains the number of bytes to be pushed onto the stack.
|-
|OP_PUSHDATA2
|77
|0x4d
|(special)
|data
|The next two bytes contain the number of bytes to be pushed onto the stack in little endian order.
|-
|OP_PUSHDATA4
|78
|0x4e
|(special)
|data
|The next four bytes contain the number of bytes to be pushed onto the stack in little endian order.
|-
|OP_1NEGATE
|79
|0x4f
|Nothing.
| -1
|The number -1 is pushed onto the stack.
|-
|OP_1, OP_TRUE
|81
|0x51
|Nothing.
|1
|The number 1 is pushed onto the stack.
|-
|OP_2-OP_16
|82-96
|0x52-0x60
|Nothing.
|2-16
|The number in the word name (2-16) is pushed onto the stack.
|}

=== Flow control ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_NOP
|97
|0x61
|Nothing
|Nothing
|Does nothing.
|-
|OP_IF
|99
|0x63
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|If the top stack value is not False, the statements are executed. The top stack value is removed.
|-
|OP_NOTIF
|100
|0x64
| colspan="2"|<expression> notif [statements] [else [statements]]* endif
|If the top stack value is False, the statements are executed. The top stack value is removed.
|-
|OP_ELSE
|103
|0x67
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|If the preceding OP_IF or OP_NOTIF or OP_ELSE was not executed then these statements are and if the preceding OP_IF or OP_NOTIF or OP_ELSE was executed then these statements are not.
|-
|OP_ENDIF
|104
|0x68
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|Ends an if/else block. All blocks must end, or the transaction is '''invalid'''. An OP_ENDIF without OP_IF earlier is also '''invalid'''.
|-
|OP_VERIFY
|105
|0x69
|True / false
|Nothing / ''fail''
|'''Marks transaction as invalid''' if top stack value is not true. The top stack value is removed.
|-
|[[OP_RETURN]]
|106
|0x6a
|Nothing
|''fail''
|'''Marks transaction as invalid'''. Since bitcoin 0.9, a standard way of attaching extra data to transactions is to add a zero-value output with a scriptPubKey consisting of OP_RETURN followed by data. Such outputs are provably unspendable and specially discarded from storage in the UTXO set, reducing their cost to the network. Since [https://bitcoin.org/en/release/v0.12.0#relay-any-sequence-of-pushdatas-in-opreturn-outputs-now-allowed 0.12], standard relay rules allow a single output with OP_RETURN, that contains any sequence of push statements (or OP_RESERVED<ref>see code for IsPushOnly [https://github.com/bitcoin/bitcoin/blob/bccb4d29a8080bf1ecda1fc235415a11d903a680/src/script/script.cpp#L232]</ref>) after the OP_RETURN provided the total scriptPubKey length is at most 83 bytes.
|}

=== Stack ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_TOALTSTACK
|107
|0x6b
|x1
|(alt)x1
|Puts the input onto the top of the alt stack. Removes it from the main stack.
|-
|OP_FROMALTSTACK
|108
|0x6c
|(alt)x1
|x1
|Puts the input onto the top of the main stack. Removes it from the alt stack.
|-
|OP_IFDUP
|115
|0x73
|x
|x / x x
|If the top stack value is not 0, duplicate it.
|-
|OP_DEPTH
|116
|0x74
|Nothing
|<Stack size>
|Puts the number of stack items onto the stack.
|-
|OP_DROP
|117
|0x75
|x
|Nothing
|Removes the top stack item.
|-
|OP_DUP
|118
|0x76
|x
|x x
|Duplicates the top stack item.
|-
|OP_NIP
|119
|0x77
|x1 x2
|x2
|Removes the second-to-top stack item.
|-
|OP_OVER
|120
|0x78
|x1 x2
|x1 x2 x1
|Copies the second-to-top stack item to the top.
|-
|OP_PICK
|121
|0x79
|xn ... x2 x1 x0 <n>
|xn ... x2 x1 x0 xn
|The item ''n'' back in the stack is copied to the top.
|-
|OP_ROLL
|122
|0x7a
|xn ... x2 x1 x0 <n>
|... x2 x1 x0 xn
|The item ''n'' back in the stack is moved to the top.
|-
|OP_ROT
|123
|0x7b
|x1 x2 x3
|x2 x3 x1
|The top three items on the stack are rotated to the left.
|-
|OP_SWAP
|124
|0x7c
|x1 x2
|x2 x1
|The top two items on the stack are swapped.
|-
|OP_TUCK
|125
|0x7d
|x1 x2
|x2 x1 x2
|The item at the top of the stack is copied and inserted before the second-to-top item.
|-
|OP_2DROP
|109
|0x6d
|x1 x2
|Nothing
|Removes the top two stack items.
|-
|OP_2DUP
|110
|0x6e
|x1 x2
|x1 x2 x1 x2
|Duplicates the top two stack items.
|-
|OP_3DUP
|111
|0x6f
|x1 x2 x3
|x1 x2 x3 x1 x2 x3
|Duplicates the top three stack items.
|-
|OP_2OVER
|112
|0x70
|x1 x2 x3 x4
|x1 x2 x3 x4 x1 x2
|Copies the pair of items two spaces back in the stack to the front.
|-
|OP_2ROT
|113
|0x71
|x1 x2 x3 x4 x5 x6
|x3 x4 x5 x6 x1 x2
|The fifth and sixth items back are moved to the top of the stack.
|-
|OP_2SWAP
|114
|0x72
|x1 x2 x3 x4
|x3 x4 x1 x2
|Swaps the top two pairs of items.
|}

=== Splice ===

If any opcode marked as disabled is present in a script, it must abort and fail.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_CAT
|126
|0x7e
|x1 x2
|out
|style="background:#D97171;"|Concatenates two strings. ''disabled.''
|-
|OP_SUBSTR
|127
|0x7f
|in begin size
|out
|style="background:#D97171;"|Returns a section of a string. ''disabled.''
|-
|OP_LEFT
|128
|0x80
|in size
|out
|style="background:#D97171;"|Keeps only characters left of the specified point in a string. ''disabled.''
|-
|OP_RIGHT
|129
|0x81
|in size
|out
|style="background:#D97171;"|Keeps only characters right of the specified point in a string. ''disabled.''
|-
|OP_SIZE
|130
|0x82
|in
|in size
|Pushes the string length of the top element of the stack (without popping it).
|}

=== Bitwise logic ===

If any opcode marked as disabled is present in a script, it must abort and fail.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_INVERT
|131
|0x83
|in
|out
|style="background:#D97171;"|Flips all of the bits in the input. ''disabled.''
|-
|OP_AND
|132
|0x84
|x1 x2
|out
|style="background:#D97171;"|Boolean ''and'' between each bit in the inputs. ''disabled.''
|-
|OP_OR
|133
|0x85
|x1 x2
|out
|style="background:#D97171;"|Boolean ''or'' between each bit in the inputs. ''disabled.''
|-
|OP_XOR
|134
|0x86
|x1 x2
|out
|style="background:#D97171;"|Boolean ''exclusive or'' between each bit in the inputs. ''disabled.''
|-
|OP_EQUAL
|135
|0x87
|x1 x2
|True / false
|Returns 1 if the inputs are exactly equal, 0 otherwise.
|-
|OP_EQUALVERIFY
|136
|0x88
|x1 x2
|Nothing / ''fail''
|Same as OP_EQUAL, but runs OP_VERIFY afterward.
|}

=== Arithmetic ===

Note: Arithmetic inputs are limited to signed 32-bit integers, but may overflow their output.

If any input value for any of these commands is longer than 4 bytes, the script must abort and fail.
If any opcode marked as ''disabled'' is present in a script - it must also abort and fail.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_1ADD
|139
|0x8b
|in
|out
|1 is added to the input.
|-
|OP_1SUB
|140
|0x8c
|in
|out
|1 is subtracted from the input.
|-
|OP_2MUL
|141
|0x8d
|in
|out
|style="background:#D97171;"|The input is multiplied by 2. ''disabled.''
|-
|OP_2DIV
|142
|0x8e
|in
|out
|style="background:#D97171;"|The input is divided by 2. ''disabled.''
|-
|OP_NEGATE
|143
|0x8f
|in
|out
|The sign of the input is flipped.
|-
|OP_ABS
|144
|0x90
|in
|out
|The input is made positive.
|-
|OP_NOT
|145
|0x91
|in
|out
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.
|-
|OP_0NOTEQUAL
|146
|0x92
|in
|out
|Returns 0 if the input is 0. 1 otherwise.
|-
|OP_ADD
|147
|0x93
|a b
|out
|a is added to b.
|-
|OP_SUB
|148
|0x94
|a b
|out
|b is subtracted from a.
|-
|OP_MUL
|149
|0x95
|a b
|out
|style="background:#D97171;"|a is multiplied by b. ''disabled.''
|-
|OP_DIV
|150
|0x96
|a b
|out
|style="background:#D97171;"|a is divided by b. ''disabled.''
|-
|OP_MOD
|151
|0x97
|a b
|out
|style="background:#D97171;"|Returns the remainder after dividing a by b. ''disabled.''
|-
|OP_LSHIFT
|152
|0x98
|a b
|out
|style="background:#D97171;"|Shifts a left b bits, preserving sign. ''disabled.''
|-
|OP_RSHIFT
|153
|0x99
|a b
|out
|style="background:#D97171;"|Shifts a right b bits, preserving sign. ''disabled.''
|-
|OP_BOOLAND
|154
|0x9a
|a b
|out
|If both a and b are not 0, the output is 1. Otherwise 0.
|-
|OP_BOOLOR
|155
|0x9b
|a b
|out
|If a or b is not 0, the output is 1. Otherwise 0.
|-
|OP_NUMEQUAL
|156
|0x9c
|a b
|out
|Returns 1 if the numbers are equal, 0 otherwise.
|-
|OP_NUMEQUALVERIFY
|157
|0x9d
|a b
|Nothing / ''fail''
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.
|-
|OP_NUMNOTEQUAL
|158
|0x9e
|a b
|out
|Returns 1 if the numbers are not equal, 0 otherwise.
|-
|OP_LESSTHAN
|159
|0x9f
|a b
|out
|Returns 1 if a is less than b, 0 otherwise.
|-
|OP_GREATERTHAN
|160
|0xa0
|a b
|out
|Returns 1 if a is greater than b, 0 otherwise.
|-
|OP_LESSTHANOREQUAL
|161
|0xa1
|a b
|out
|Returns 1 if a is less than or equal to b, 0 otherwise.
|-
|OP_GREATERTHANOREQUAL
|162
|0xa2
|a b
|out
|Returns 1 if a is greater than or equal to b, 0 otherwise.
|-
|OP_MIN
|163
|0xa3
|a b
|out
|Returns the smaller of a and b.
|-
|OP_MAX
|164
|0xa4
|a b
|out
|Returns the larger of a and b.
|-
|OP_WITHIN
|165
|0xa5
|x min max
|out
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.
|}

=== Crypto ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_RIPEMD160
|166
|0xa6
|in
|hash
|The input is hashed using RIPEMD-160.
|-
|OP_SHA1
|167
|0xa7
|in
|hash
|The input is hashed using SHA-1.
|-
|OP_SHA256
|168
|0xa8
|in
|hash
|The input is hashed using SHA-256.
|-
|OP_HASH160
|169
|0xa9
|in
|hash
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.
|-
|OP_HASH256
|170
|0xaa
|in
|hash
|The input is hashed two times with SHA-256.
|-
|OP_CODESEPARATOR
|171
|0xab
|Nothing
|Nothing
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.
|-
|[[OP_CHECKSIG]]
|172
|0xac
|sig pubkey
|True / false
|The entire transaction's outputs, inputs, and script (from the most recently-executed OP_CODESEPARATOR to the end) are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If it is, 1 is returned, 0 otherwise.
|-
|OP_CHECKSIGVERIFY
|173
|0xad
|sig pubkey
|Nothing / ''fail''
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.
|-
|OP_CHECKMULTISIG
|174
|0xae
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys>
|True / False
|Compares the first signature against each public key until it finds an ECDSA match. Starting with the subsequent public key, it compares the second signature against each remaining public key until it finds an ECDSA match. The process is repeated until all signatures have been checked or not enough public keys remain to produce a successful result. All signatures need to match a public key. Because public keys are not checked again if they fail any signature comparison, signatures must be placed in the scriptSig using the same order as their corresponding public keys were placed in the scriptPubKey or redeemScript. If all signatures are valid, 1 is returned, 0 otherwise. Due to a bug, one extra unused value is removed from the stack.
|-
|OP_CHECKMULTISIGVERIFY
|175
|0xaf
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys>
|Nothing / ''fail''
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.
|}

=== Locktime ===
{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_CHECKLOCKTIMEVERIFY (previously OP_NOP2)
|177
|0xb1
|x
|x / ''fail''
|'''Marks transaction as invalid''' if the top stack item is greater than the transaction's nLockTime field, otherwise script evaluation continues as though an OP_NOP was executed. Transaction is also invalid if 1. the stack is empty; or 2. the top stack item is negative; or 3. the top stack item is greater than or equal to 500000000 while the transaction's nLockTime field is less than 500000000, or vice versa; or 4. the input's nSequence field is equal to 0xffffffff. The precise semantics are described in [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 0065].
|-
|OP_CHECKSEQUENCEVERIFY (previously OP_NOP3)
|178
|0xb2
|x
|x / ''fail''
|'''Marks transaction as invalid''' if the relative lock time of the input (enforced by [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 0068] with nSequence) is not equal to or longer than the value of the top stack item. The precise semantics are described in [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP 0112].
|}

===Pseudo-words===
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.
{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Description
|-
|OP_PUBKEYHASH
|253
|0xfd
|Represents a public key hashed with OP_HASH160.
|-
|OP_PUBKEY
|254
|0xfe
|Represents a public key compatible with OP_CHECKSIG.
|-
|OP_INVALIDOPCODE
|255
|0xff
|Matches any opcode that is not yet assigned.
|}

=== Reserved words ===
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction '''invalid'''.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!When used...
|-
|OP_RESERVED
|80
|0x50
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|OP_VER
|98
|0x62
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|OP_VERIF
|101
|0x65
|'''Transaction is invalid even when occuring in an unexecuted OP_IF branch'''
|-
|OP_VERNOTIF
|102
|0x66
|'''Transaction is invalid even when occuring in an unexecuted OP_IF branch'''
|-
|OP_RESERVED1
|137
|0x89
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|OP_RESERVED2
|138
|0x8a
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|OP_NOP1, OP_NOP4-OP_NOP10
|176, 179-185
|0xb0, 0xb3-0xb9
|The word is ignored. Does not mark transaction as invalid.
|}

== Script examples ==
The following is a list of interesting scripts.
When notating scripts, data to be pushed to the stack is generally enclosed in angle brackets
and data push commands are omitted.
Non-bracketed words are opcodes.
These examples include the “OP_” prefix, but it is permissible to omit it.
Thus
“<pubkey1> <pubkey2> OP_2 OP_CHECKMULTISIG”
may be abbreviated to
“<pubkey1> <pubkey2> 2 CHECKMULTISIG”.
Note that there is a small number of standard script forms that are relayed from node to node;
non-standard scripts are accepted if they are in a block, but nodes will not relay them.

=== Standard Transaction to Bitcoin address (pay-to-pubkey-hash) ===

scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

To demonstrate how scripts look on the wire, here is a raw scriptPubKey:
<pre> 76 A9 14
OP_DUP OP_HASH160 Bytes to push

89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA 88 AC
Data to push OP_EQUALVERIFY OP_CHECKSIG</pre>

Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.

Here is how each word is processed:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Constants are added to the stack.
|-
|<sig> <pubKey> <pubKey>
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is duplicated.
|-
|<sig> <pubKey> <pubHashA>
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is hashed.
|-
|<sig> <pubKey> <pubHashA> <pubKeyHash>
|OP_EQUALVERIFY OP_CHECKSIG
| Constant added.
|-
|<sig> <pubKey>
|OP_CHECKSIG
| Equality is checked between the top two stack items.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

=== Obsolete pay-to-pubkey transaction ===

OP_CHECKSIG is used directly without first hashing the public key.
This was used by early versions of Bitcoin where people paid directly to IP addresses, before Bitcoin addresses were introduced.
scriptPubKeys of this transaction form are still recognized as payments to user by Bitcoin Core.
The disadvantage of this transaction form is that the whole public key needs to be known in advance, implying longer payment addresses, and that it provides less protection in the event of a break in the ECDSA signature algorithm.

scriptPubKey: <pubKey> OP_CHECKSIG
scriptSig: <sig>

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
|<sig> <pubKey> OP_CHECKSIG
|scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_CHECKSIG
|Constants are added to the stack.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

=== Provably Unspendable/Prunable Outputs ===

The standard way to mark a transaction as provably unspendable is with a scriptPubKey of the following form:

scriptPubKey: OP_RETURN {zero or more ops}

OP_RETURN immediately marks the script as invalid, guaranteeing that no scriptSig exists that could possibly spend that output. Thus the output can be immediately pruned from the [[UTXO|UTXO set]] even if it has not been spent. [http://blockexplorer.com/tx/eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29 eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29] is an example: it has a single output of zero value, thus giving the full 0.125BTC fee to the miner who mined the transaction without adding an entry to the UTXO set. You can also use OP_RETURN to add data to a transaction without the data ever appearing in the UTXO set, as seen in 1a2e22a717d626fc5db363582007c46924ae6b28319f07cb1b907776bd8293fc; [[P2Pool]] does this with the share chain hash txout in the coinbase of blocks it creates.

=== Freezing funds until a time in the future ===

Using OP_CHECKLOCKTIMEVERIFY it is possible to make funds provably unspendable until a certain point in the future.

scriptPubKey: <expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> <expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey> <expiry time>
| OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Constants are added to the stack.
|-
|<sig> <pubKey> <expiry time>
| OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is checked against the current time or block height.
|-
|<sig> <pubKey>
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is removed.
|-
|<sig> <pubKey> <pubKey>
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is duplicated.
|-
|<sig> <pubKey> <pubHashA>
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is hashed.
|-
|<sig> <pubKey> <pubHashA> <pubKeyHash>
|OP_EQUALVERIFY OP_CHECKSIG
| Constant added.
|-
|<sig> <pubKey>
|OP_CHECKSIG
| Equality is checked between the top two stack items.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

=== Transaction puzzle ===

Transaction a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b is an interesting puzzle.

scriptPubKey: OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL
scriptSig: <data>

To spend the transaction you need to come up with some data such that hashing the data twice results in the given hash.

{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
|<data> OP_HASH256 <given_hash> OP_EQUAL
|
|-
|<data>
|OP_HASH256 <given_hash> OP_EQUAL
|scriptSig added to the stack.
|-
|<data_hash>
|<given_hash> OP_EQUAL
|The data is hashed.
|-
|<data_hash> <given_hash>
|OP_EQUAL
|The given hash is pushed to the stack.
|-
|true
|Empty.
|The hashes are compared, leaving true on the stack.
|}

This transaction was successfully spent by 09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1. The required data happened to be the [[Genesis block]], and the given hash in the script was the genesis block header hashed twice with SHA-256. Note that while transactions like this are fun, they are not secure, because they do not contain any signatures and thus any transaction attempting to spend them can be replaced with a different transaction sending the funds somewhere else.

=== Incentivized finding of hash collisions ===

In 2013 Peter Todd created scripts that result in true if a hash collision is found. Bitcoin addresses resulting from these scripts can have money sent to them. If someone finds a hash collision they can spend the bitcoins on that address, so this setup acts as an incentive for somebody to do so.

For example the SHA1 script:

scriptPubKey: OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_SHA1 OP_SWAP OP_SHA1 OP_EQUAL
scriptSig: <preimage1> <preimage2>

See the bitcointalk thread <ref>[https://bitcointalk.org/index.php?topic=293382.0 bitcointalk forum thread on the hash collision bounties]</ref> and reddit thread<ref>https://www.reddit.com/r/Bitcoin/comments/1mavh9/trustless_bitcoin_bounty_for_sha1_sha256_etc/</ref> for more details.

In February 2017 the SHA1 bounty worth 2.48 bitcoins was claimed.

==See Also==

* [[Transactions]]
* [[Contracts]]

== External Links ==
*[https://bitcoin.sipa.be/miniscript] - Miniscript: a language for writing (a subset of) Bitcoin Scripts in a structured way, enabling analysis, composition, generic signing and more.
*[https://github.com/siminchen/bitcoinIDE Bitcoin IDE] – Bitcoin Script for dummies
*[https://webbtc.com/script Bitcoin Debug Script Execution] – web tool which executes a script opcode-by-opcode
*[http://www.crmarsh.com/script-playground/ Script Playground] — convert Script to JavaScript
*[https://bitauth.com/ide BitAuth IDE] — an Integrated Development Environment for Bitcoin Authentication
(cf. "[http://bitcoin.stackexchange.com/q/42576/4334 Online Bitcoin Script simulator or debugger?]")

==References==
<references />

[[Category:Technical]]
[[Category:Vocabulary]]

{{Bitcoin Core documentation}}

Testnet

2019-10-31T22:27:22Z

Darosior: Correct a typo about the executable name

The '''testnet''' is an alternative Bitcoin [[block chain]], to be used for testing. Testnet coins are separate and distinct from actual bitcoins, and are never supposed to have any value. This allows application developers or bitcoin testers to experiment, without having to use real bitcoins or worrying about breaking the main bitcoin chain.

Run bitcoin-qt or bitcoind with the -testnet flag to use the testnet (or put testnet=1 in the bitcoin.conf file).

There have been three generations of testnet. Testnet2 was just the first testnet reset with a different genesis block, because people were starting to trade testnet coins for real money. '''Testnet3''' is the current test network. It was introduced with the 0.7 release, introduced a third genesis block, a new rule to avoid the "difficulty was too high, is now too low, and transactions take too long to verify" problem, and contains blocks with edge-case transactions designed to test implementation compatibility. On the December 21 of 2015 SegNet was deployed, to test the Wuille's Segregated Witness proposal.

==Differences==
* Default Bitcoin network protocol listen port is 18333 (instead of 8333)
* Default RPC connection port is 18332 (instead of 8332)
* Bootstrapping uses different DNS seeds.
* A different value of ADDRESSVERSION field ensures no testnet Bitcoin addresses will work on the production network. (0x6F rather than 0x00)
* The protocol message header bytes are 0x0B110907 (instead of 0xF9BEB4D9)
* Minimum [[difficulty]] of 1.0 on testnet is equal to difficulty of 0.5 on mainnet. This means that the mainnet-equivalent of any testnet difficulty is half the testnet difficulty. In addition, if no block has been found in 20 minutes, the difficulty automatically resets back to the minimum for a single block, after which it returns to its previous value.
* A new genesis block
* The IsStandard() check is disabled so that non-standard transactions can be experimented with.

==Genesis Block==

Testnet uses a different genesis block to the main network. You can find it [https://www.biteasy.com/testnet/blocks/000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943 here] or [http://blockexplorer.com/testnet/b/0 here].
The testnet was [https://github.com/gavinandresen/bitcoin-git/commit/feeb761ba07af74a7cd78b8c8f7c2a961fd9ea1c reset with a new genesis block] for the 0.7 bitcoin release.

==Size==
Testnet receives less transactions than the main block chain and is typically much smaller in size. As of January 2018 the size of the data on disk was 14GB, containing data for about 6 years worth of testnet activity. Downloading this data required about 12GB of network activity peaking at 2MB/s rate of transfer.

==External links==

* [https://bitcointalk.org/?topic=4483.0 Testnet in a box forum topic]
* [https://sourceforge.net/projects/bitcoin/files/Bitcoin/testnet-in-a-box/ Testnet-In-A-Box self-contained testnet]
* [https://github.com/freewil/bitcoin-testnet-box Forked/Updated testnet-box]

===Wallets===

Online testnet wallets to help you test your application.

* [http://testnetwallet.com/ TestnetWallet.com]
* [https://CoPay.io/ CoPay.io] wallet supports TestNet accounts

===Faucets===

Once you're done with your test coins, it is a nice gesture to send them back to the faucets, so they become available to other developers.
* [http://tbtc.bitaps.com bitaps.com Testnet Faucet + double spend test tool]
* [http://bitcoinfaucet.uo1.net/ UO1 Testnet Faucet]
* [https://play.google.com/store/apps/details?id=com.mycelium.testnetwallet Mycelium Testnet Wallet for Android with integrated Testnet "faucet" function (Local Trader)]
* [https://testnet-faucet.mempool.co mempool.co testnet3 Faucet]

Offline (2018-09-06):

* [http://tpfaucet.appspot.com/ TP's TestNet Faucet]
* [http://kuttler.eu/bitcoin/btc/faucet/ nkuttler's Bitcoin Testnet Faucet], transactions are made through Joinmarket, a [[CoinJoin]] implementation
* [https://testnet.manu.backend.hamburg/faucet flyingkiwi's TestNet Faucet]

Offline (2016-08-07):

* [http://faucet.luis.im/ luis.im Mojocoin Testnet3 Faucet]
* [https://accounts.blockcypher.com/testnet-faucet BlockCypher Testnet Faucet], also provided as a [http://dev.blockcypher.com/#faucets Testnet faucet API] for test automation

===Block explorers===
* [http://tbtc.bitaps.com/ Bitcoin Testnet Explorer on bitaps.com]
* [https://www.biteasy.com/testnet/blocks Biteasy.com Testnet Blockexplorer]
* [http://testnet.blockchain.info Blockchain.info Testnet Explorer]
* [http://tbtc.blockr.io/ Bitcoin Testnet on Blockr.io]
* [https://test-insight.bitpay.com/ Bitcoin Testnet on insight.bitpay.com]
* [https://www.blocktrail.com/tBTC BlockTrail Testnet Explorer, Testnet API and Testnet Faucet]
* [https://live.blockcypher.com/btc-testnet/ BlockCypher Testnet Explorer]
[[Category:Technical]]
[[Category:Developer]]

{{Bitcoin Core documentation}}

Hash Time Locked Contracts

2019-09-23T18:02:29Z

Darosior:

A '''Hash Time Locked Contract''' or '''HTLC''' is a class of payments that use [[hashlock]]s and [[timelock]]s to require that the receiver of a payment either acknowledge receiving the payment prior to a deadline by generating cryptographic proof of payment or forfeit the ability to claim the payment, returning it to the payer.<ref name="russell_htlc" />

The cryptographic proof of payment the receiver generates can then be used to trigger other actions in other payments, making HTLCs a powerful technique for producing
conditional payments in Bitcoin.

== HTLCs in cross-chain atomic swaps ==

[[Atomic cross-chain trading]] allows some amount of one cryptocurrency (such as bitcoin on [[mainnet]]) to be traded for some amount of cryptocurrency on another block chain (such as bitcoin on a [[sidechain]]).

Descriptions of cross-chain atomic swaps are probably the origin of the technique now called HTLCs.{{citation needed}}

== HTLCs in payment channels ==

[[Payment channels]] already use timelocks, and it can be relatively simple conceptually to extend them with hashlocks. This provides the useful benefit of making payments routable across two or more payment channels, as done in the Lightning Network <ref name="lightning_network_htlc"/>.

=== Example ===

# Alice opens a payment channel to Bob, and Bob opens a payment channel to Charlie.
# Alice wants to buy something from Charlie for 1000 satoshis.
# Charlie generates a random number and generates its SHA256 hash. Charlie gives that hash to Alice.
# Alice uses her payment channel to Bob to pay him 1,000 satoshis, but she adds the hash Charlie gave her to the payment along with an extra condition: in order for Bob to claim the payment, he has to provide the data which was used to produce that hash.
# Bob uses his payment channel to Charlie to pay Charlie 1,000 satoshis, and Bob adds a copy of the same condition that Alice put on the payment she gave Bob.
# Charlie has the original data that was used to produce the hash (called a pre-image), so Charlie can use it to finalize his payment and fully receive the payment from Bob. By doing so, Charlie necessarily makes the pre-image available to Bob.
# Bob uses the pre-image to finalize his payment from Alice

== References ==
<references>
<ref name="russell_htlc">[https://rusty.ozlabs.org/?p=462 Lightning Networks Part II: Hashed Timelock Contracts (HTLCs)]</ref>
<ref name="lightning_network_htlc">[https://lightning.network/lightning-network-paper.pdf#page=30 Hashed Timelock Contract (HTLC) in the Lightning Network paper]</ref>
</references>

[[Category:Technical]]

Hash Time Locked Contracts

2019-09-23T17:59:45Z

Darosior: Add a reference to the Lightning Network paper

A '''Hash Time Locked Contract''' or '''HTLC''' is a class of payments that use [[hashlock]]s and [[timelock]]s to require that the receiver of a payment either acknowledge receiving the payment prior to a deadline by generating cryptographic proof of payment or forfeit the ability to claim the payment, returning it to the payer.<ref name="russell_htlc" />

The cryptographic proof of payment the receiver generates can then be used to trigger other actions in other payments, making HTLCs a powerful technique for producing
conditional payments in Bitcoin.

== HTLCs in cross-chain atomic swaps ==

[[Atomic cross-chain trading]] allows some amount of one cryptocurrency (such as bitcoin on [[mainnet]]) to be traded for some amount of cryptocurrency on another block chain (such as bitcoin on a [[sidechain]]).

Descriptions of cross-chain atomic swaps are probably the origin of the technique now called HTLCs.{{citation needed}}

== HTLCs in payment channels ==

[[Payment channels]] already use timelocks, and it can be relatively simple conceptually to extend them with hashlocks. This provides the useful benefit of making payments routable across two or more payment channels.

=== Example ===

# Alice opens a payment channel to Bob, and Bob opens a payment channel to Charlie.
# Alice wants to buy something from Charlie for 1000 satoshis.
# Charlie generates a random number and generates its SHA256 hash. Charlie gives that hash to Alice.
# Alice uses her payment channel to Bob to pay him 1,000 satoshis, but she adds the hash Charlie gave her to the payment along with an extra condition: in order for Bob to claim the payment, he has to provide the data which was used to produce that hash.
# Bob uses his payment channel to Charlie to pay Charlie 1,000 satoshis, and Bob adds a copy of the same condition that Alice put on the payment she gave Bob.
# Charlie has the original data that was used to produce the hash (called a pre-image), so Charlie can use it to finalize his payment and fully receive the payment from Bob. By doing so, Charlie necessarily makes the pre-image available to Bob.
# Bob uses the pre-image to finalize his payment from Alice

== References ==
<references>
<ref name="russell_htlc">[https://rusty.ozlabs.org/?p=462 Lightning Networks Part II: Hashed Timelock Contracts (HTLCs)]</ref>
<ref name="lightning_network_htlc">[https://lightning.network/lightning-network-paper.pdf#page=30]</ref>
</references>

[[Category:Technical]]

NLockTime

2019-09-23T13:00:58Z

Darosior: Add more details about the lock time interpretation.

{{stub}}

'''nLockTime''' is a parameter of a transaction, that, if any input indicates so (by having nSequence not equal to UINT_MAX), mandates a minimal time (specified in either unix time or block height), before which the transaction cannot be accepted into a block. If all inputs in a transaction have nSequence equal to UINT_MAX, then nLockTime is ignored.

Since [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68], the lock time can either be absolute or relative. Given a transaction,
* If the most significant bit (<code>1<<31</code>) of the '''nLockTime''' field is set (if the lock time is absolute)
** If <code>nLockTime < 500000000</code>
*** Specifies the block number at which this transaction can be spent
** Otherwise
*** Specifies the UNIX timestamp at which this transaction can be spent
* Otherwise (if the lock time is relative)
** If the 23rd bit (<code>1<<22</code>) is not set
*** The last 16 bits of the '''nLockTime''' field specify a relative time in units of 512 seconds. The transaction can only be included in a block if <code>spending_tx_block_time > spent_tx_block_time + nLockTime * 512</code>.
** Otherwise
*** The last 16 bits of the '''nLockTime''' field specify a relative block height before which the transaction can not be included in a block. In other words it can be included if <code>spending_tx_block_height > spent_tx_block_height + nLockTime</code>

==See Also==
* lock_time in [[Protocol_specification#tx|the protocol specification]]
* [[Timelock]]
* [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68]
* The CHECKLOCKTIMEVERIFY opcode in [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65]
* The CHECKSEQUENCEVERIFY opcode in [https://github.com/bitcoin/bips/blob/master/bip-00112.mediawiki BIP112]

[[Category:Technical]]
{{lowercase}}

NLockTime

2019-09-23T12:49:59Z

Darosior: Correct the BIP68 additions

{{stub}}

'''nLockTime''' is a parameter of a transaction, that, if any input indicates so (by having nSequence not equal to UINT_MAX), mandates a minimal time (specified in either unix time or block height), before which the transaction cannot be accepted into a block. If all inputs in a transaction have nSequence equal to UINT_MAX, then nLockTime is ignored.

Since [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68], the '''nLockTime''' can specify a relative lock time. Given a transaction,
* If the most significant bit (1<<31) is not set
** If the 23rd bit (1<<22) is set
*** The last 16 bits of the '''nLockTime''' field specify a relative time in units of 512 seconds. The transaction can only be included in a block if <code>spending_tx_block_time > spent_tx_block_time + nLockTime * 512</code>.
** Otherwise
*** The last 16 bits of the '''nLockTime''' field specify a relative block height before which the transaction can not be included in a block. In other words it can be included if <code>spending_tx_block_height > spent_tx_block_height + nLockTime</code>
* Otherwise
** the transaction can be included in any block

==See Also==
* lock_time in [[Protocol_specification#tx|the protocol specification]]
* [[Timelock]]
* [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68]
* The CHECKLOCKTIMEVERIFY opcode in [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65]
* The CHECKSEQUENCEVERIFY opcode in [https://github.com/bitcoin/bips/blob/master/bip-00112.mediawiki BIP112]

[[Category:Technical]]
{{lowercase}}

NLockTime

2019-09-23T11:47:03Z

Darosior: Updated the page to reflect the actual consensus meaning of the `nLockTime` field.

{{stub}}

'''nLockTime''' is a parameter of a transaction, that, if any input indicates so (by having nSequence not equal to UINT_MAX), mandates a minimal time (specified in either unix time or block height), before which the transaction cannot be accepted into a block. If all inputs in a transaction have nSequence equal to UINT_MAX, then nLockTime is ignored.

Since [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68], a new meaning has been given to the '''nLockTime''' and '''nSequence''' fields. Given a transaction,
* If the most significant bit (1<<31) is set
** If the 23rd bit (1<<22) is set
*** Specifies a time in units of 512 seconds. The transaction can only be included in a block if <code>block_time > nLockTime * 512</code>.
** Otherwise
*** Specifies a block height before which the transaction can not be included in a block.
* Otherwise
** the transaction can be included in any block

==See Also==
* lock_time in [[Protocol_specification#tx|the protocol specification]]
* [[Timelock]]
* [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68]
* The CHECKLOCKTIMEVERIFY opcode in [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65]
* The CHECKSEQUENCEVERIFY opcode in [https://github.com/bitcoin/bips/blob/master/bip-00112.mediawiki BIP112]

[[Category:Technical]]
{{lowercase}}

Bech32 adoption

2019-09-19T16:02:09Z

Darosior: /* Exchanges */

[[Bech32]] is a new bitcoin [[address]] format specified by [[BIP 0173]]. This page tracks the adoption of [[Bech32]].

Ideally wallets and services would first support ''sending to'' bech32 addresses. After almost everything can send to, then people may be willing to adopt bech32 widely 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 !! Create/receive !! Notes
|-
| Bitcoin Core || {{Yes}} || {{Yes}} ||
|-
| Bitcoin Knots || {{Yes}} || {{Yes}} ||
|-
| Electrum || {{Yes}} || {{Yes}} ||
|-
| Armory || {{Yes}} || {{No}} ||
|-
| JoinMarket || {{Yes}} || {{No}} ||
|-
| GreenAddress || {{Yes}} || {{Yes}} ||
|-
| Breadwallet || {{Yes}} || {{No}} || https://twitter.com/udiWertheimer/status/975810157941796864
|-
| Samourai Wallet || {{Yes}} || {{Yes}} ||
|-
| Coinomi || {{Yes}} || {{Yes}} || [https://www.reddit.com/r/Bitcoin/comments/865qn1/coinomi_wallet_beta_has_segwit_support/ reddit source]
|-
| BTC.com || {{Yes}} || {{No}} ||
|-
| Casa || {{Yes}} || {{No}} ||
|-
| Mycelium || {{Yes}} || {{Yes}} ||
|-
| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Bitcoin Wallet for Android] || {{Yes}} || {{Yes}} ||
|-
| Wasabi Wallet || {{Yes}} || {{Yes}} ||
|-
| Trust Wallet || {{Yes}} || {{Yes}} || [https://trustwallet.com/blog/trust-wallet-adds-support-for-btc-ltc-bch official blog]
|-
|}

=== 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 !! Create/receive !! Notes
|-
| Trezor web wallet || {{Acceptable|PR Merged}} || {{No}} ||
|-
| Ledger chrome app || {{No}} || {{No}} ||
|-
| Ledger Live (desktop app) || {{Yes}} || {{Yes}} || Experimental feature
|-
| KeepKey chrome app || {{No}} || {{No}} ||
|-
| BitBox Desktop app || {{Yes}} || {{Yes}} ||
|-
| Trezor + Electrum || {{Yes}} || {{Yes}} ||
|-
| Ledger + Electrum || {{Yes}} || {{Yes}} ||
|-
| BitBox + Electrum || {{Yes}} || {{Yes}} ||
|-
| KeepKey + Electrum || {{Yes}} || {{Yes}} ||
|-
| Archos + Electrum || {{Yes}} || {{Yes}} ||
|-
| Coldcard + Electrum || {{Yes}} || {{Yes}} ||
|}

=== Web Wallets ===

{| class="wikitable sortable"
|-
! Name !! Send to !! Create/receive !! Notes
|-
| Coinapult || {{Evaluating|??}} || {{No}} ||
|-
| Coin.Space || {{Evaluating|??}} || {{No}} ||
|-
| BitGo || {{Yes}} || {{Yes}} || Full support on v2 platform, no plans to add support on v1 platform. Also see: https://blog.bitgo.com/native-segwit-addresses-via-bitgos-api-4946f2007be9
|-
| blockchain.info web wallet || {{Yes}} || {{No}} || https://twitter.com/provoost/status/1037802325874761728
|-
| HolyTransaction || {{Yes}} || {{No}} ||
|-
| [https://coinb.in Coinb.in] || {{Yes}} || {{Yes}} || open source JavaScript implementation
|}

=== Exchanges ===



{| class="wikitable sortable"
|-
! Name !! Send to !! Create/receive !! Notes
|-
| 1Fox || {{Yes}} || {{No}} || https://1fox.com/?c=en/content/blog&id=12
|-
| Anycoin Direct || {{Yes}} || {{No}} || https://anycoindirect.eu/en/news/details/segwit-activated
|-
| BitBargain.co.uk || {{Yes}} || {{No}} ||
|-
| Bitcoin.de || {{Yes}} || {{No}} || https://bitcoinblog.de/2018/08/10/bitcoin-de-aktiviert-segwit-kunden-sparen-gebuehren/
|-
| Bitfinex || {{No}} || {{No}} ||
|-
| BitMEX || {{Evaluating|??}} || {{No}} ||
|-
| Bittylicious || {{Yes}} || {{No}} || https://twitter.com/Bittylicious_/status/998881327347888128
|-
| Bitstamp || {{No}} || {{No}} ||
|-
| Bitwage || {{Evaluating|??}} || {{No}} ||
|-
| Bisq || {{No}} || {{No}} || https://github.com/bisq-network/bisq-desktop/issues/1139 https://bisq.community/t/bech32-address-support/6521
|-
| Coinbase.com || {{Yes}} || {{No}} || https://twitter.com/diogorsergio/status/983052769262292992 (Note that Coinbase commerce does not support sending to bech32)
|-
| CoinFalcon || {{Yes}} || {{No}} ||
|-
| Coinfloor || {{Evaluating|??}} || {{No}} ||
|-
| Coinsbank.com || {{Yes}} || {{Yes}} ||
|-
| Flyp.me || {{Yes}} || {{No}} ||
|-
| GDax || {{Yes}} || {{No}} || https://www.reddit.com/r/Bitcoin/comments/8c738k/coinbase_gdax_already_allows_sending_to_bc1/
|-
| Gemini || {{Yes}} || {{Yes}} || https://np.reddit.com/r/Bitcoin/comments/b66n0v/psa_gemini_is_full_on_with_native_segwit_and_uses/
|-
| Genesis || {{Evaluating|??}} || {{No}} ||
|-
| HitBTC || {{Yes}} || {{No}} ||
|-
| Hodl Hodl || {{Yes}} || {{Yes}} || https://medium.com/@hodlhodl/hodl-hodl-segwit-compatible-exchange-a2231968ac56
|-
| Itbit || {{Evaluating|??}} || {{No}} ||
|-
| Kraken || {{Yes}} || {{No}} || https://twitter.com/krakenfx/status/1060306827848470528
|-
| Liberalcoins || {{Yes}} || {{Yes}} || https://liberalcoins.com
|-
| Localbitcoins.com || {{No}} || {{No}} ||
|-
| Paxful.com || {{Evaluating|??}} || {{No}} ||
|-
| Poloniex.com || {{Yes}} || {{No}} || https://www.reddit.com/r/Bitcoin/comments/a3jhcf/you_can_now_withdraw_from_poloniex_to_bech32/
|-
| TheRockTrading.com || {{Yes}} || {{Yes}} || https://twitter.com/TheRockTrading/status/976787499648512003
|-
| Walltime || {{Yes}} || {{Yes}} || https://walltime.info
|}

=== 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 !! Create/receive !! Notes
|-
| GenesisCoin || {{No}} || {{No}} ||
|-
| General Bytes || {{No}} || {{No}} ||
|-
| Lamassu Douro || {{No}} || {{No}} ||
|}

=== Blockchain Explorers ===

For trying these out you can use mainnet TXIDs <code>4ef47f6eb681d5d9fa2f7e16336cd629303c635e8da51e425b76088be9c8744c</code> and <code>514a33f1d46179b89e1fea7bbb07b682ab14083a276979f91038369d1a8d689b</code>. And 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.

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

{| class="wikitable sortable"
|-
! Name !! Display !! Index !! Notes
|-
| Apirone.com || {{Yes}} || {{Yes}} || Bitcoin Block Explorer with SegWit support https://apirone.com
|-
| bitaps.com || {{Yes}} || {{Yes}} || https://bitaps.com
|-
| Bitflyer || {{Yes}} || {{Yes}} || https://chainflyer.bitflyer.jp/
|-
| Bitupper Explorer || {{Yes}} || {{Yes}} || https://bitupper.com/en/explorer/bitcoin
|-
| blockchain.info || {{Yes}} || {{No}} ||
|-
| Blockchair || {{Yes}} || {{Yes}} || https://blockchair.com/
|-
| Blockcypher || {{No}} || {{No}} || https://live.blockcypher.com/btc
|-
| Blockonomics || {{Yes}} || {{Yes}} || https://www.blockonomics.co
|-
| Blockpath || {{Yes}} || {{Yes}} || https://blockpath.com
|-
| BTC.com || {{Yes}} || {{Yes}} || https://BTC.com
|-
| Esplora || {{Yes}} || {{Yes}} || Open source explorer, instances are https://blockstream.info/ and https://www.localbitcoinschain.com/
|-
| chaindex || {{Yes}} || {{Yes}} || https://chaindex.com/blockchain/
|-
| Insight || {{No}} || {{No}} || Open source explorer, instances include https://insight.bitpay.com/
|-
| OXT || {{Yes}} || {{Yes}} || https://oxt.me/
|-
| Tradeblock || {{No}} || {{No}} || https://tradeblock.com/bitcoin
|}

=== Payment Processors ===



{| class="wikitable sortable"
|-
! Name !! Invoice addresses !! Withdrawal addresses !! Notes
|-
| [https://apirone.com Apirone] || {{Yes}} || {{Yes}} || Payment notifications, Merchant dashboard, Bitcoin plugins for Magento, WooCommerce, OpenCart 2, Opencart 3.x, Virtuemart etc.
|-
| [https://bitaps.com Bitaps] || {{Yes}} || {{Yes}} || Payment forwarding API, Wallet API, fault tolerance callback.
|-
| [https://coingate.com CoinGate] || {{No}} || {{Yes}} ||
|-
| [https://cryptochill.com CryptoChill] || {{Yes}} || {{Yes}} || Highly customizable Bitcoin and Lightning Network payment gateway. Multi-sig, HD wallets, API, SDK.
|}

=== Mining Pools ===

{| class="wikitable sortable"
|-
! Name !! Payout !! Notes
|-
| [https://pool.btc.com/ BTC.com Pool] || {{No}} ||
|-
| [http://ckpool.org/ Ckpool] || {{Yes}} ||
|-
| [https://kano.is/ KanoPool] || {{No}} ||
|-
| [http://poolin.com/ Poolin] || {{Yes}} || [https://bitcointalk.org/index.php?topic=5169994.msg52184844#msg52184844 bitcointalk source]
|-
| [https://slushpool.com/ Slush Pool] || {{Yes}} ||
|-
| [https://ukrpool.com/ Ukr Pool] || {{Yes}} || [https://bitcointalk.org/index.php?topic=5124825.msg51358033#msg51358033 bitcointalk source]
|-
| [https://pool.viabtc.com/ ViaBTC Pool] || {{No}} ||
|}

=== Other Services ===

Casinos, marketplaces, etc that let users withdraw money

{| class="wikitable sortable"
|-
! Name !! Withdrawals !! Notes
|-
| 1Broker || {{Yes}} ||
|-
| Crypto-Games.net || {{Yes}} || [https://bitcointalk.org/index.php?topic=750760.msg31421151#msg31421151 bitcointalk source]
|-
| YOLOdice || {{Yes}} ||
|}

=== References ===

[[Category:Software]]

Bech32 adoption

2019-09-16T15:44:29Z

Darosior: Add that armory supports sending to bech32 addresses : https://bitcointalk.org/index.php?topic=5088934.0.

[[Bech32]] is a new bitcoin [[address]] format specified by [[BIP 0173]]. This page tracks the adoption of [[Bech32]].

Ideally wallets and services would first support ''sending to'' bech32 addresses. After almost everything can send to, then people may be willing to adopt bech32 widely 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 !! Create/receive !! Notes
|-
| Bitcoin Core || {{Yes}} || {{Yes}} ||
|-
| Bitcoin Knots || {{Yes}} || {{Yes}} ||
|-
| Electrum || {{Yes}} || {{Yes}} ||
|-
| Armory || {{Yes}} || {{No}} ||
|-
| JoinMarket || {{Yes}} || {{No}} ||
|-
| GreenAddress || {{Yes}} || {{Yes}} ||
|-
| Breadwallet || {{Yes}} || {{No}} || https://twitter.com/udiWertheimer/status/975810157941796864
|-
| Samourai Wallet || {{Yes}} || {{Yes}} ||
|-
| Coinomi || {{Yes}} || {{Yes}} || [https://www.reddit.com/r/Bitcoin/comments/865qn1/coinomi_wallet_beta_has_segwit_support/ reddit source]
|-
| BTC.com || {{Yes}} || {{No}} ||
|-
| Casa || {{Yes}} || {{No}} ||
|-
| Mycelium || {{Yes}} || {{Yes}} ||
|-
| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Bitcoin Wallet for Android] || {{Yes}} || {{Yes}} ||
|-
| Wasabi Wallet || {{Yes}} || {{Yes}} ||
|-
| Trust Wallet || {{Yes}} || {{Yes}} || [https://trustwallet.com/blog/trust-wallet-adds-support-for-btc-ltc-bch official blog]
|-
|}

=== 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 !! Create/receive !! Notes
|-
| Trezor web wallet || {{Acceptable|PR Merged}} || {{No}} ||
|-
| Ledger chrome app || {{No}} || {{No}} ||
|-
| Ledger Live (desktop app) || {{Yes}} || {{Yes}} || Experimental feature
|-
| KeepKey chrome app || {{No}} || {{No}} ||
|-
| BitBox Desktop app || {{Yes}} || {{Yes}} ||
|-
| Trezor + Electrum || {{Yes}} || {{Yes}} ||
|-
| Ledger + Electrum || {{Yes}} || {{Yes}} ||
|-
| BitBox + Electrum || {{Yes}} || {{Yes}} ||
|-
| KeepKey + Electrum || {{Yes}} || {{Yes}} ||
|-
| Archos + Electrum || {{Yes}} || {{Yes}} ||
|-
| Coldcard + Electrum || {{Yes}} || {{Yes}} ||
|}

=== Web Wallets ===

{| class="wikitable sortable"
|-
! Name !! Send to !! Create/receive !! Notes
|-
| Coinapult || {{Evaluating|??}} || {{No}} ||
|-
| Coin.Space || {{Evaluating|??}} || {{No}} ||
|-
| BitGo || {{Yes}} || {{Yes}} || Full support on v2 platform, no plans to add support on v1 platform. Also see: https://blog.bitgo.com/native-segwit-addresses-via-bitgos-api-4946f2007be9
|-
| blockchain.info web wallet || {{Yes}} || {{No}} || https://twitter.com/provoost/status/1037802325874761728
|-
| HolyTransaction || {{Yes}} || {{No}} ||
|-
| [https://coinb.in Coinb.in] || {{Yes}} || {{Yes}} || open source JavaScript implementation
|}

=== Exchanges ===



{| class="wikitable sortable"
|-
! Name !! Send to !! Create/receive !! Notes
|-
| 1Fox || {{Yes}} || {{No}} || https://1fox.com/?c=en/content/blog&id=12
|-
| Anycoin Direct || {{Yes}} || {{No}} || https://anycoindirect.eu/en/news/details/segwit-activated
|-
| BitBargain.co.uk || {{Yes}} || {{No}} ||
|-
| Bitcoin.de || {{Yes}} || {{No}} || https://bitcoinblog.de/2018/08/10/bitcoin-de-aktiviert-segwit-kunden-sparen-gebuehren/
|-
| Bitfinex || {{No}} || {{No}} ||
|-
| BitMEX || {{Evaluating|??}} || {{No}} ||
|-
| Bittylicious || {{Yes}} || {{No}} || https://twitter.com/Bittylicious_/status/998881327347888128
|-
| Bitstamp || {{No}} || {{No}} ||
|-
| Bitwage || {{Evaluating|??}} || {{No}} ||
|-
| Bisq || {{No}} || {{No}} || https://github.com/bisq-network/bisq-desktop/issues/1139 https://bisq.community/t/bech32-address-support/6521
|-
| Coinbase.com || {{Yes}} || {{No}} || https://twitter.com/diogorsergio/status/983052769262292992
|-
| CoinFalcon || {{Yes}} || {{No}} ||
|-
| Coinfloor || {{Evaluating|??}} || {{No}} ||
|-
| Coinsbank.com || {{Yes}} || {{Yes}} ||
|-
| Flyp.me || {{Yes}} || {{No}} ||
|-
| GDax || {{Yes}} || {{No}} || https://www.reddit.com/r/Bitcoin/comments/8c738k/coinbase_gdax_already_allows_sending_to_bc1/
|-
| Gemini || {{Yes}} || {{Yes}} || https://np.reddit.com/r/Bitcoin/comments/b66n0v/psa_gemini_is_full_on_with_native_segwit_and_uses/
|-
| Genesis || {{Evaluating|??}} || {{No}} ||
|-
| HitBTC || {{Yes}} || {{No}} ||
|-
| Hodl Hodl || {{Yes}} || {{Yes}} || https://medium.com/@hodlhodl/hodl-hodl-segwit-compatible-exchange-a2231968ac56
|-
| Itbit || {{Evaluating|??}} || {{No}} ||
|-
| Kraken || {{Yes}} || {{No}} || https://twitter.com/krakenfx/status/1060306827848470528
|-
| Liberalcoins || {{Yes}} || {{Yes}} || https://liberalcoins.com
|-
| Localbitcoins.com || {{No}} || {{No}} ||
|-
| Paxful.com || {{Evaluating|??}} || {{No}} ||
|-
| Poloniex.com || {{Yes}} || {{No}} || https://www.reddit.com/r/Bitcoin/comments/a3jhcf/you_can_now_withdraw_from_poloniex_to_bech32/
|-
| TheRockTrading.com || {{Yes}} || {{Yes}} || https://twitter.com/TheRockTrading/status/976787499648512003
|-
| Walltime || {{Yes}} || {{Yes}} || https://walltime.info
|}

=== 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 !! Create/receive !! Notes
|-
| GenesisCoin || {{No}} || {{No}} ||
|-
| General Bytes || {{No}} || {{No}} ||
|-
| Lamassu Douro || {{No}} || {{No}} ||
|}

=== Blockchain Explorers ===

For trying these out you can use mainnet TXIDs <code>4ef47f6eb681d5d9fa2f7e16336cd629303c635e8da51e425b76088be9c8744c</code> and <code>514a33f1d46179b89e1fea7bbb07b682ab14083a276979f91038369d1a8d689b</code>. And 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.

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

{| class="wikitable sortable"
|-
! Name !! Display !! Index !! Notes
|-
| Apirone.com || {{Yes}} || {{Yes}} || Bitcoin Block Explorer with SegWit support https://apirone.com
|-
| bitaps.com || {{Yes}} || {{Yes}} || https://bitaps.com
|-
| Bitflyer || {{Yes}} || {{Yes}} || https://chainflyer.bitflyer.jp/
|-
| Bitupper Explorer || {{Yes}} || {{Yes}} || https://bitupper.com/en/explorer/bitcoin
|-
| blockchain.info || {{Yes}} || {{No}} ||
|-
| Blockchair || {{Yes}} || {{Yes}} || https://blockchair.com/
|-
| Blockcypher || {{No}} || {{No}} || https://live.blockcypher.com/btc
|-
| Blockonomics || {{Yes}} || {{Yes}} || https://www.blockonomics.co
|-
| Blockpath || {{Yes}} || {{Yes}} || https://blockpath.com
|-
| BTC.com || {{Yes}} || {{Yes}} || https://BTC.com
|-
| Esplora || {{Yes}} || {{Yes}} || Open source explorer, instances are https://blockstream.info/ and https://www.localbitcoinschain.com/
|-
| chaindex || {{Yes}} || {{Yes}} || https://chaindex.com/blockchain/
|-
| Insight || {{No}} || {{No}} || Open source explorer, instances include https://insight.bitpay.com/
|-
| OXT || {{Yes}} || {{Yes}} || https://oxt.me/
|-
| Tradeblock || {{No}} || {{No}} || https://tradeblock.com/bitcoin
|}

=== Payment Processors ===



{| class="wikitable sortable"
|-
! Name !! Invoice addresses !! Withdrawal addresses !! Notes
|-
| [https://apirone.com Apirone] || {{Yes}} || {{Yes}} || Payment notifications, Merchant dashboard, Bitcoin plugins for Magento, WooCommerce, OpenCart 2, Opencart 3.x, Virtuemart etc.
|-
| [https://bitaps.com Bitaps] || {{Yes}} || {{Yes}} || Payment forwarding API, Wallet API, fault tolerance callback.
|-
| [https://coingate.com CoinGate] || {{No}} || {{Yes}} ||
|-
| [https://cryptochill.com CryptoChill] || {{Yes}} || {{Yes}} || Highly customizable Bitcoin and Lightning Network payment gateway. Multi-sig, HD wallets, API, SDK.
|}

=== Mining Pools ===

{| class="wikitable sortable"
|-
! Name !! Payout !! Notes
|-
| [https://pool.btc.com/ BTC.com Pool] || {{No}} ||
|-
| [http://ckpool.org/ Ckpool] || {{Yes}} ||
|-
| [https://kano.is/ KanoPool] || {{No}} ||
|-
| [http://poolin.com/ Poolin] || {{Yes}} || [https://bitcointalk.org/index.php?topic=5169994.msg52184844#msg52184844 bitcointalk source]
|-
| [https://slushpool.com/ Slush Pool] || {{Yes}} ||
|-
| [https://ukrpool.com/ Ukr Pool] || {{Yes}} || [https://bitcointalk.org/index.php?topic=5124825.msg51358033#msg51358033 bitcointalk source]
|-
| [https://pool.viabtc.com/ ViaBTC Pool] || {{No}} ||
|}

=== Other Services ===

Casinos, marketplaces, etc that let users withdraw money

{| class="wikitable sortable"
|-
! Name !! Withdrawals !! Notes
|-
| 1Broker || {{Yes}} ||
|-
| Crypto-Games.net || {{Yes}} || [https://bitcointalk.org/index.php?topic=750760.msg31421151#msg31421151 bitcointalk source]
|-
| YOLOdice || {{Yes}} ||
|}

=== References ===

[[Category:Software]]

Lightning Network

2019-07-19T09:41:05Z

Darosior: Corrected a typo

'''Lightning Network''' is a proposed implementation of [[Hashed Timelock Contracts]] (HTLCs) with bi-directional [[payment channels]] which allows payments to be securely routed across multiple peer-to-peer payment channels.<ref name="ln_pdf">[https://lightning.network/lightning-network-paper.pdf Lightning Network paper, v0.5.9.1] Joseph Poon & Thaddeus Dryja ''Retrieved 2016-04-10''</ref> This allows the formation of a network where any peer on the network can pay any other peer even if they don't directly have a channel open between each other. As of March 2019, there were more than 37,000 channels carrying more than 764 bitcoins.<ref name="p2sh_data">[https://p2sh.info/dashboard/db/lightning-network?orgId=1&from=1514764800000&to=1550915801588 Lightning Network - Sum of channels value] Lightning Network - Sum of channels value ''Retrieved 2019-03-08''</ref>

== Key features ==
Key features of the Lightning Network proposal include,

* '''Rapid payments:''' payments within an established channel can be made almost as fast as data can travel over the Internet between the two peers.
* '''No third-party trust:''' the two peers in a channel pay each other directly using regular Bitcoin transactions (of which only one is broadcast) so at no point does any third party control their funds.
* '''Reduced blockchain load:''' only channel open transactions, channel close transactions, and (hopefully infrequent) anti-fraud respends need to be committed to the blockchain, allowing all other payments within Lightning Network channels to remain uncommitted. This allows Lightning Network users to make frequent payments secured by Bitcoin without placing excessive load on full nodes which must process every transaction on the blockchain.
* '''Channels can stay open indefinitely:''' as long as the two parties in the channel continue to cooperate with each other, the channel can stay open indefinitely -- there is no mandatory timeout period. This can further reduce the load on the blockchain as well as allow the fees for opening and closing the channel to be amortized over a longer period of time.
* '''Rapid cooperative closes:''' if both parties cooperate, a channel can be closed immediately (with the parties likely wanting to wait for one or more confirmations to ensure the channel closed in the correct state). Non-cooperative closes (such as when one party disappears) are also possible but they take longer.
* '''Outsourceable enforcement:''' if one party closes a channel in an old state in an attempt to steal money, the other party has to act within a defined period of time to block the attempted theft. This function can be outsourced to a third-party without giving them control over any funds, allowing wallets to safely go offline for periods longer than the defined period.
* '''Onion-style routing:''' payment routing information can be encrypted in a nested fashion so that intermediary nodes only know who they received a routable payment from and who to send it to next, preventing those intermediary nodes from knowing who the originator or destination is (provided the intermediaries didn't compare records).
* '''Multisignature capable:''' each party can require that their payments into the channel be signed by multiple keys<ref name="poon_multisig">[https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-January/000403.html 2-of-3 Instant Escrow, or How to Do "2-of-3 Multisig Contract" Equivalent on Lightning] Joseph Poon ''Retrieved 2016-04-11''</ref>, giving them access to additional security techniques.
* '''Securely cross blockchains:''' payments can be routed across more than one blockchain (including altcoins and sidechains) as long as all the chains support the same hash function to use for the hash lock, as well as the ability to create time locks.
* '''Sub-satoshi payments:''' payments can be made conditional upon the outcome of a random event, allowing probabilistic payments.<ref name="dryja_directed_graph"/> For example, Alice can pay Bob 0.1 satoshi by creating a 1-satoshi payment with 10-to-1 odds so that 90% of the time she does this she pays him 0 satoshis and 10% of the time she pays him 1 satoshi for an average payment of 0.1 satoshis.
* '''Single-funded channels:''' when Alice needs to send a payment to Bob and doesn't currently have a way to pay him through the Lightning Network (whether because she can't reach him or because she doesn't have enough money in an existing channel), she can make a regular on-chain payment that establishes a channel without Bob needing to add any of his funds to the channel. Alice only uses 12 bytes more than she would for a non-Lightning direct payment and Bob would only need about 25 more [[segwit]] virtual bytes to close the channel than he would had he received a non-Lightning direct payment.<ref name="dryja_directed_graph"/>

== Glossary ==

This section attempts to document the most frequently used terms found in Lightning Network literature that may not be familiar to a general technical audience, including both the new terms created by Lightning Network designers as well as pre-existing terms that may not be well known from Bitcoin, cryptography, network routing, and other fields.

The list below should be in alphabetical order. Any commonly-used synonyms or analogs for a term are placed in parenthesis after the term.

* '''Bi-directional payment channel:'''<ref name="ln_pdf"/> a payment channel where payments can flow both directions, from Alice to Bob and back to Alice. This is contrasted with Spillman-style and CLTV-style payment channels where payments can only go one direction and once Alice has paid Bob all of the bitcoins she deposited in the channel funding transaction, the channel is no longer useful and so will be closed.
* '''Breach Remedy Transaction:'''<ref name="ln_pdf"/> the transaction Alice creates when Mallory attempts to steal her money by having an old version of the channel state committed to the blockchain. Alice's breach remedy transaction spends all the money that Mallory received but which Mallory can't spend yet because his unilateral spend is still locked by a relative locktime using <code>OP_CSV</code>. This is the third of the maximum of three on-chain transactions needed to maintain a Lightning channel; it only needs to be used in the case of attempted fraud (contract breach).
* '''Channel''' (Lightning channel<ref name="ln_pdf"/>, payment channel<ref name="spillman_channel">[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html Anti DoS for tx replacement] Jeremy Spillman Retrieved 2016-04-17</ref>) a communication channel that allows two parties to make many secure payments between each other in exchange for making only a few transactions on the blockchain.
* '''Commitment Transaction:'''<ref name="ln_pdf"/> a transaction created collaboratively by Alice and Bob each time they update the state of the channel; it records their current balances within the channel. The '''Initial Commitment Transaction'''<ref name="ln_pdf"/> is the first of these transactions; it records the initial balances within the channel. This is the second of the maximum of three on-chain transactions needed to maintain a Lightning channel; it can be combined with a ''funding transaction'' for a new channel under the cooperative conditions necessary to create an ''exercise settlement transaction''.
* '''Contract:'''<ref name="szabo_smart_contracts">[http://szabo.best.vwh.net/smart_contracts_idea.html The Idea of Smart Contracts] Nick Szabo Retrieved 2016-04-17</ref> an agreement between two or more entities to use Bitcoin transactions in a certain way, usually a way that allows Bitcoin's automated consensus to enforce some or all terms in the contract. Often called a ''smart contract''.
* '''CSV:''' (<code>OP_CheckSequenceVerify</code>, <code>OP_CSV</code>)<ref name="bip68"/> a opcode that allows an output to conditionally specify how long it must be part of the blockchain before an input spending it may be added to the blockchain. See ''relative locktime.''
* '''Delivery Transaction:'''<ref name="ln_pdf"/> not really a transaction but rather the name for the outputs in the ''commitment transaction'' which Alice and Bob receive if one of them closes the channel unilaterally in the correct (current) state. If the channel is closed in an old state (indicating possible fraud), a ''breach remedy transaction'' will be generated from the output that would have paid the party closing the channel. If the channel is closed cooperatively, they'll create an ''exercise settlement transaction'' instead.
* '''Dispute period:''' (dispute resolution period<ref name="poon_time_bitcoin_ln">[https://lightning.network/lightning-network-presentation-time-2015-07-06.pdf Time, Bitcoin, and the Lightning Network] Joseph Poon Retrieved 2016-04-17</ref>) the period of time that Alice has to get her ''breach remedy transaction'' added to the blockchain after Mallory has an old ''commitment transaction'' added to the blockchain. If the dispute period ends without a breach remedy transaction being added to the blockchain, Mallory can spend the funds he received from the old commitment transaction.
* '''Dual-funded channel:'''<ref name="dryja_directed_graph">[https://docs.google.com/presentation/d/1G4xchDGcO37DJ2lPC_XYyZIUkJc2khnLrCaZXgvDN0U/edit?pref=2&pli=1#slide=id.g85f425098_0_2 LN as a Directed Graph: Single-Funded Channel Topology] Thaddeus Dryja Retrieved 2016-04-17</ref> a channel opened by a ''funding transaction'' containing inputs from both Alice and Bob. Compare to a ''single-funded channel'' where only Alice's inputs contribute to the balance of the channel.
* '''Encumbrance:'''<ref>[http://chimera.labs.oreilly.com/books/1234000001802/ch02.html Mastering Bitcoin, Chapter 2: How Bitcoin Works] Andreas Antonopoulos Retrieved 2016-04-17</ref> a generic name for any conditions that must be satisfied before a bitcoin output may be spent. Early Bitcoin transactions placed all their conditions in the scriptPubKey; later the introduction of P2SH allowed conditions to be added in a redeemScript which the scriptPubKey committed to; the introduction of soft fork [[segwit]] will add a similar mechanism for detached conditions that the scriptPubKey commits to; in addition, there are even more novel ways to add conditions to outputs that are discussed but rarely used. The term "encumbrance" allows specifying what the conditions do without fussing over exactly where the conditions appear in a serialized transaction.
* '''Exercise Settlement Transaction:'''<ref name="ln_pdf"/> a form of the ''commitment transaction'' created cooperatively by Alice and Bob when they want to close their channel together. Unlike a regular commitment transaction, none of the outputs on an exercise settlement transaction are time locked, allowing them to be immediately respent.
* '''Exhausted:'''<ref name="dryja_directed_graph"/> (exhausted channel) a payment channel where no additional payments can be made in one direction (such as from Alice to Bob). The person controlling the exhausted side of a Lightning channel loses nothing from fraudulently trying to commit an old channel state, so allowing a channel to become exhausted (or too near to being exhausted) is unpreferable. (Exception: channels can be securely started in an exhausted state, such as a ''single-funded channel.''
* '''Full push:'''<ref name="dryja_directed_graph"/> when Alice pays the full amount of the channel to Bob in the ''initial commitment transaction'', which ''exhausts'' the channel without incentivizing fraud because Alice doesn't have a previous ''commitment transaction'' that she can broadcast. This term is used in the context of a ''single-funded transaction'' and stands in contrast to an ''overpayment'' where Alice deposits more than she pays Bob in that initial payment so that she can continue to use the channel without needing to ''rebalance''.
* '''Funding Transaction:'''<ref name="ln_pdf"/> (deposit transaction) a transaction created collaboratively by Alice and Bob to open a Lightning channel. In a single-funded channel, Alice provides all the funding;<ref name="dryja_directed_graph"/> in a dual-funded channel, Alice and Bob both provide some funding. This is the first of the maximum of three on-chain transactions needed to maintain a Lightning channel; it can be combined with a commitment transaction from a previous channel being closed under cooperative conditions.
* '''Half-signed:'''<ref name="ln_pdf"/> a transaction input which requires two signatures to be added to the blockchain but which only has one signature attached. (More generally, this could be any input that has fewer signatures attached than it needs to be added to the blockchain.)
* '''Hash lock:'''<ref>[https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg05135.html BIP - Hash Locked Transaction] Tier Nolan Retrieved 2016-04-17</ref> an encumbrance to a transaction output that requires the pre-image used to generate a particular hash be provided in order to spend the output. In Lightning, this is used to allow payments to be routable without needing to trust the intermediaries.
* '''HTLC:''' (Hashed Timelocked Contract<ref name="russell_deployable_lightning">[https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf Reaching the Ground with Lightning] Rusty Russell Retrieved 2016-04-17</ref>) a contract such as that used in a Lightning Channel where both a ''hash lock'' and a ''time lock'' are used, the hash lock being used to allow Alice to route payments to Bob even through a Mallory that neither of them trust, and the time lock being used to prevent Mallory from stealing back any payments he made to Alice within the channel (provided Alice enforces the contract).
* '''Intermediary:'''<ref name="ln_pdf"/> When Bob has one channel open with Alice and another channel open with Charlie, Bob can serve as an intermediary for transferring payments between Alice and Charlie. With Lightning payments being secured with a ''hash lock,'' Bob can't steal the payment from Alice to Charlie when it travels through Bob's node. Lightning payments can securely travel through a theoretically unlimited number of intermediaries.
* '''Limbo channel:'''<ref name="dryja_directed_graph"/> an optional special state for a Lightning channel where it cannot be immediately closed by one or both of the parties unilaterally (it can still be immediately closed cooperatively). This is used in particular for ''PLIPPs.''
* '''Multisig:'''<ref name="bitcoin_0_1_code"/> (multisignature, m-of-n multisig) a transaction output that requires signatures from at least one of a set of two or more different private keys. Used in Lightning to give both Alice and Bob control over their individual funds within a channel by requiring both of them sign ''commitment transactions''.
* '''Node:''' (Lightning node<ref name="ln_pdf"/>) a wallet with one or more open Lightning channels. This should not be confused with a Bitcoin [[full node]] that validates Bitcoin blocks, although a full node's wallet may also be simultaneously used as a Lightning node to the advantage of the Lightning network user.
* '''Overfunding:'''<ref name="dryja_directed_graph"/> in a ''single-funded channel,'' Alice deposits more bitcoins into the channel than she pays Bob in the initial payment, allowing her to make additional payments through the Lightning network. This stands in contrast to a ''full push'' where Alice only deposits enough to pay Bob in the initial payment.
* '''PILPP:''' (Pre-Image Length Probabilistic Payments<ref name="dryja_directed_graph"/>) a specific type of ''probabilistic payment'' within a payment channel where Alice creates string with a random length and Bob guesses the length; if he guesses correctly, Alice has to pay him; if he guesses incorrectly, Alice gets to keep her money.
* '''Pre-image:'''<ref>[https://en.wikipedia.org/wiki/Image_%28mathematics%29#Inverse_image Image (mathematics)] English Wikipedia contributors Retrieved 2016-04-17</ref> (R<ref name="ln_pdf"/>) data input into a hash function, which produces a hash of the pre-image. Inputting the same pre-image into the same hash function will always produce the same hash; Lightning uses this feature to create ''hash locks''.
* '''Probabilistic Payment:'''<ref>[[Nanopayments]] Bitcoin Wiki contributors Retrieved 2016-04-17</ref> a payment where Alice only pays Bob if some event outside of Alice's and Bob's control occurs in Bob's favor. Probabilistic payments are usually proposed for scenarios where payments can't conveniently be made small enough for technical reasons (such as not being able to pay less than 1 satoshi) or economic reasons (such as having to pay a transaction fee for every on-chain payment, making small payments uneconomical). See ''PLIPP'' for a specific type of probabilistic payment possible within a Lightning channel.
* '''R:''' the variable commonly used<ref name="ln_pdf"/> in formulas to represent a ''pre-image''.
* '''Rebalance:'''<ref>[https://blockstream.com/2015/09/01/lightning-network/ The Lightning Network: What Is It and What's Happening?] Rusty Russell Retrieved 2016-04-17</ref> a cooperative process between Alice and Bob when they adjust their balances within the channel. This happens with every payment in a Lightning channel and is only noteworthy because single-directional channels (such as Spillman-style and CLTV-style channels) are unable to rebalance and so must close as soon as Alices has paid Bob all the bitcoins she deposited into the channel. See ''bi-directional payment channels.''
* '''Relative locktime:'''<ref name="bip68"/> the ability to specify when a transaction output may be spent relative to the block that included that transaction output. Enabled by BIP68 and made scriptable by BIP112. Lightning uses relative locktime to ensure ''breach remedy transactions'' may be broadcast within a time period starting from when an old ''commitment transaction'' is added to the blockchain; by making this a relative locktime (instead of an absolute date or block height), Lightning channels don't have a hard deadline for when they need to close and so can stay open indefinitely as long as the participants continue to cooperate.
* '''Revocable Sequence Maturity Contract (RSMC):'''<ref name="ln_pdf"/> a ''contract'' used in Lightning to revoke the previous ''commitment transaction''. This is allowed through mutual consent in Lightning by both parties signing a new commitment transaction and releasing the data necessary to create ''breach remedy transactions'' for the previous commitment transaction. This property allows Lightning to support ''bi-directional payment channels'', recover from failed ''HTLC'' routing attempts without needing to commit to the blockchain, as well as provide advanced features such as ''PILPPs.''
* '''Single-funded channel:'''<ref name="dryja_directed_graph"/> a channel opened by a ''funding transaction'' containing only inputs from Alice. Compare to a ''dual-funded channel'' where Alice and Bob both contribute inputs to the initial balance of the channel.
* '''Timelock:'''<ref>[http://rusty.ozlabs.org/?p=450 Lightning Networks Part I: Revocable Transactions] Rusty Russell 2016-04-17</ref> either an encumbrance to a transaction that prevents that transaction from being added to the blockchain before a particular time or block height (as is the case with [[nLockTime]], or an encumbrance that prevents a spend from a transaction output from being added to the blockchain before a particular time or block height (as is the case of OP_CLTV, consensus enforced sequence number relative locktime, and OP_CSV). In Lightning, this is used to prevent malicious intermediaries from holding other users' funds hostages as well as to allow victims of attempted theft to submit breach remedy transactions before the thief can respend the funds he stole.
* '''TTL:''' (Time To Live<ref>[http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000019.html Re: Routing on the Lightning Network?] Rusty Russell Retrieved 2016-04-17</ref>) when Alice pays Bob with a ''hash locked'' in-channel payment that's ultimately intended for Charlie, she specifies how long Bob has to deliver the payment (its time to live) before the payment becomes invalid. When Bob pays Charlie with his own in-channel payment that has the same hash lock, Bob specifies a slightly shorter amount of time that Charlie has to reveal the pre-image that unlocks the hash lock before Bob's payment becomes invalid. This ensures that either Bob receives the data necessary to remove the hash lock from the payment he received from Alice or the payment he made to Charlie is invalidated; Alice gets the same guarantee that either the payment she made to Bob ultimate goes through to Charlie or her payment to Bob is invalidated.
* '''Unilateral:'''<ref name="ln_pdf"/> any action performed by only one of the participants in a channel without requesting or needing permission from the other participant. Lightning allows channels to be closed unilaterally (so Alice can close the channel by herself if Bob becomes unresponsive) and attempted fraud can be penalized unilaterally (so Alice can take any bitcoins Mallory tried to steal when he broadcast an old ''commitment transaction'').
* '''UTXO:'''<ref>[https://bitcoin.org/en/glossary/unspent-transaction-output Unspent Transaction Output (UTXO)] Bitcoin.org Developer Glossary Retrieved 2016-04-17</ref> (Unspent Transaction Output) spendable bitcoins. A transaction output lists a bitcoin amount and the conditions (called an ''encumbrance'') that need to be fulfilled in order to spend those bitcoins. Once those bitcoins have been spent on the blockchain, no other transaction in the same blockchain can spend the same bitcoins, so an Uspent Transaction Output (UTXO) is bitcoins that can be spent.

== See Also ==

* [[Payment channels]]
* [[Hashed Timelock Contracts]]
* [[Off-Chain Transactions]]
* [http://dev.lightning.community/resources/index.html Lightning Lab's list of resources]
* [https://github.com/dan-da/lightning-nodes/blob/master/README.md List of network nodes].
* [https://www.reddit.com/r/Bitcoin/comments/7pwna9/lightning_network_megathread/ Lightning Network Megathread on Reddit]

== References ==
<references>
<ref name="bitcoin_0_1_code">[http://satoshi.nakamotoinstitute.org/code/ Bitcoin 0.1 code] Satoshi Nakamoto Retrieved 2016-04-11</ref>
<ref name="bip68">[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Relative lock-time using consensus-enforced sequence numbers] Mark Friedenbach, BtcDrak, Nicolas Dorier, and kinoshitajona Retrieved 2016-04-12</ref>
<references/>

[[Category:Technical]]
[[Category:Scalability]]
[[Category:Privacy]]