mirror of
https://github.com/bitcoin/bitcoin.git
synced 2026-01-19 14:53:43 +01:00
doc: Merge release notes fragment, merge taproot description from wiki
Co-authored-by: David A. Harding <dave@dtrt.org> Co-authored-by: Jon Atack <jon@atack.com> Co-authored-by: Pieter Wuille <pieter@wuille.net> Tree-SHA512: dd9ac416ff22276833111198445d76cf8417012a6faad0c3560276f1dcf24586ff41c65ac3430fbf1e840aaa563d3dd101671cff306b0fd92aa2ee03bb7f926b
This commit is contained in:
@@ -1,13 +0,0 @@
|
||||
Updated RPCs
|
||||
------------
|
||||
|
||||
- Due to [BIP 350](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki)
|
||||
being implemented, behavior for all RPCs that accept addresses is changed when
|
||||
a native witness version 1 (or higher) is passed. These now require a Bech32m
|
||||
encoding instead of a Bech32 one, and Bech32m encoding will be used for such
|
||||
addresses in RPC output as well. No version 1 addresses should be created
|
||||
for mainnet until consensus rules are adopted that give them meaning
|
||||
(e.g. through [BIP 341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki)).
|
||||
Once that happens, Bech32m is expected to be used for them, so this shouldn't
|
||||
affect any production systems, but may be observed on other networks where such
|
||||
addresses already have meaning (like signet).
|
||||
@@ -44,9 +44,98 @@ when macOS "dark mode" is activated.
|
||||
Notable changes
|
||||
===============
|
||||
|
||||
RPC
|
||||
---
|
||||
## Taproot Soft Fork
|
||||
|
||||
Included in this release are the mainnet and testnet activation
|
||||
parameters for the taproot soft fork (BIP341) which also adds support
|
||||
for schnorr signatures (BIP340) and tapscript (BIP342).
|
||||
|
||||
If activated, these improvements will allow users of single-signature
|
||||
scripts, multisignature scripts, and complex contracts to all use
|
||||
identical-appearing commitments that enhance their privacy and the
|
||||
fungibility of all bitcoins. Spenders will enjoy lower fees and the
|
||||
ability to resolve many multisig scripts and complex contracts with the
|
||||
same efficiency, low fees, and large anonymity set as single-sig users.
|
||||
Taproot and schnorr also include efficiency improvements for full nodes
|
||||
such as the ability to batch signature verification. Together, the
|
||||
improvements lay the groundwork for future potential
|
||||
upgrades that may improve efficiency, privacy, and fungibility further.
|
||||
|
||||
Activation for taproot is being managed using a variation of BIP9
|
||||
versionbits called Speedy Trial (described in BIP341). Taproot's
|
||||
versionbit is bit 2, and nodes will begin tracking which blocks signal
|
||||
support for taproot at the beginning of the first retarget period after
|
||||
taproot’s start date of 24 April 2021. If 90% of blocks within a
|
||||
2,016-block retarget period (about two weeks) signal support for taproot
|
||||
prior to the first retarget period beginning after the time of 11 August
|
||||
2021, the soft fork will be locked in, and taproot will then be active
|
||||
as of block 709632 (expected in early or mid November).
|
||||
|
||||
Should taproot not be locked in via Speedy Trial activation, it is
|
||||
expected that a follow-up activation mechanism will be deployed, with
|
||||
changes to address the reasons the Speedy Trial method failed.
|
||||
|
||||
This release includes the ability to pay taproot addresses, although
|
||||
payments to such addresses are not secure until taproot activates.
|
||||
It also includes the ability to relay and mine taproot transactions
|
||||
after activation. Beyond those two basic capabilities, this release
|
||||
does not include any code that allows anyone to directly use taproot.
|
||||
The addition of taproot-related features to Bitcoin Core's wallet is
|
||||
expected in later releases once taproot activation is assured.
|
||||
|
||||
All users, businesses, and miners are encouraged to upgrade to this
|
||||
release (or a subsequent compatible release) unless they object to
|
||||
activation of taproot. If taproot is locked in, then upgrading before
|
||||
block 709632 is highly recommended to help enforce taproot's new rules
|
||||
and to avoid the unlikely case of seeing falsely confirmed transactions.
|
||||
|
||||
Miners who want to activate Taproot should preferably use this release
|
||||
to control their signaling. The `getblocktemplate` RPC results will
|
||||
automatically be updated to signal once the appropriate start has been
|
||||
reached and continue signaling until the timeout occurs or taproot
|
||||
activates. Alternatively, miners may manually start signaling on bit 2
|
||||
at any time; if taproot activates, they will need to ensure they update
|
||||
their nodes before block 709632 or non-upgraded nodes could cause them to mine on
|
||||
an invalid chain. See the [versionbits
|
||||
FAQ](https://bitcoincore.org/en/2016/06/08/version-bits-miners-faq/) for
|
||||
details.
|
||||
|
||||
|
||||
For more information about taproot, please see the following resources:
|
||||
|
||||
- Technical specifications
|
||||
- [BIP340 Schnorr signatures for secp256k1](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki)
|
||||
- [BIP341 Taproot: SegWit version 1 spending rules](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki)
|
||||
- [BIP342 Validation of Taproot scripts](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki)
|
||||
|
||||
- Popular articles;
|
||||
- [Taproot Is Coming: What It Is, and How It Will Benefit Bitcoin](https://bitcoinmagazine.com/technical/taproot-coming-what-it-and-how-it-will-benefit-bitcoin)
|
||||
- [What do Schnorr Signatures Mean for Bitcoin?](https://academy.binance.com/en/articles/what-do-schnorr-signatures-mean-for-bitcoin)
|
||||
- [The Schnorr Signature & Taproot Softfork Proposal](https://blog.bitmex.com/the-schnorr-signature-taproot-softfork-proposal/)
|
||||
|
||||
- Development history overview
|
||||
- [Taproot](https://bitcoinops.org/en/topics/taproot/)
|
||||
- [Schnorr signatures](https://bitcoinops.org/en/topics/schnorr-signatures/)
|
||||
- [Tapscript](https://bitcoinops.org/en/topics/tapscript/)
|
||||
- [Soft fork activation](https://bitcoinops.org/en/topics/soft-fork-activation/)
|
||||
|
||||
- Other
|
||||
- [Questions and answers related to taproot](https://bitcoin.stackexchange.com/questions/tagged/taproot)
|
||||
- [Taproot review](https://github.com/ajtowns/taproot-review)
|
||||
|
||||
Updated RPCs
|
||||
------------
|
||||
|
||||
- Due to [BIP 350](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki)
|
||||
being implemented, behavior for all RPCs that accept addresses is changed when
|
||||
a native witness version 1 (or higher) is passed. These now require a Bech32m
|
||||
encoding instead of a Bech32 one, and Bech32m encoding will be used for such
|
||||
addresses in RPC output as well. No version 1 addresses should be created
|
||||
for mainnet until consensus rules are adopted that give them meaning
|
||||
(e.g. through [BIP 341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki)).
|
||||
Once that happens, Bech32m is expected to be used for them, so this shouldn't
|
||||
affect any production systems, but may be observed on other networks where such
|
||||
addresses already have meaning (like signet).
|
||||
|
||||
0.21.1 change log
|
||||
=================
|
||||
|
||||
Reference in New Issue
Block a user