/ doc / release-notes / release-notes-0.21.1.md
release-notes-0.21.1.md
  1  0.21.1 Release Notes
  2  ====================
  3  
  4  Bitcoin Core version 0.21.1 is now available from:
  5  
  6    <https://bitcoincore.org/bin/bitcoin-core-0.21.1/>
  7  
  8  This minor release includes various bug fixes and performance
  9  improvements, as well as updated translations.
 10  
 11  Please report bugs using the issue tracker at GitHub:
 12  
 13    <https://github.com/bitcoin/bitcoin/issues>
 14  
 15  To receive security and update notifications, please subscribe to:
 16  
 17    <https://bitcoincore.org/en/list/announcements/join/>
 18  
 19  How to Upgrade
 20  ==============
 21  
 22  If you are running an older version, shut it down. Wait until it has completely
 23  shut down (which might take a few minutes in some cases), then run the
 24  installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
 25  or `bitcoind`/`bitcoin-qt` (on Linux).
 26  
 27  Upgrading directly from a version of Bitcoin Core that has reached its EOL is
 28  possible, but it might take some time if the data directory needs to be migrated. Old
 29  wallet versions of Bitcoin Core are generally supported.
 30  
 31  Compatibility
 32  ==============
 33  
 34  Bitcoin Core is supported and extensively tested on operating systems
 35  using the Linux kernel, macOS 10.12+, and Windows 7 and newer.  Bitcoin
 36  Core should also work on most other Unix-like systems but is not as
 37  frequently tested on them.  It is not recommended to use Bitcoin Core on
 38  unsupported systems.
 39  
 40  From Bitcoin Core 0.20.0 onwards, macOS versions earlier than 10.12 are no
 41  longer supported. Additionally, Bitcoin Core does not yet change appearance
 42  when macOS "dark mode" is activated.
 43  
 44  Notable changes
 45  ===============
 46  
 47  ## Taproot Soft Fork
 48  
 49  Included in this release are the mainnet and testnet activation
 50  parameters for the taproot soft fork (BIP341) which also adds support
 51  for schnorr signatures (BIP340) and tapscript (BIP342).
 52  
 53  If activated, these improvements will allow users of single-signature
 54  scripts, multisignature scripts, and complex contracts to all use
 55  identical-appearing commitments that enhance their privacy and the
 56  fungibility of all bitcoins. Spenders will enjoy lower fees and the
 57  ability to resolve many multisig scripts and complex contracts with the
 58  same efficiency, low fees, and large anonymity set as single-sig users.
 59  Taproot and schnorr also include efficiency improvements for full nodes
 60  such as the ability to batch signature verification.  Together, the
 61  improvements lay the groundwork for future potential
 62  upgrades that may improve efficiency, privacy, and fungibility further.
 63  
 64  Activation for taproot is being managed using a variation of BIP9
 65  versionbits called Speedy Trial (described in BIP341). Taproot's
 66  versionbit is bit 2, and nodes will begin tracking which blocks signal
 67  support for taproot at the beginning of the first retarget period after
 68  taproot’s start date of 24 April 2021.  If 90% of blocks within a
 69  2,016-block retarget period (about two weeks) signal support for taproot
 70  prior to the first retarget period beginning after the time of 11 August
 71  2021, the soft fork will be locked in, and taproot will then be active
 72  as of block 709632 (expected in early or mid November).
 73  
 74  Should taproot not be locked in via Speedy Trial activation, it is
 75  expected that a follow-up activation mechanism will be deployed, with
 76  changes to address the reasons the Speedy Trial method failed.
 77  
 78  This release includes the ability to pay taproot addresses, although
 79  payments to such addresses are not secure until taproot activates.
 80  It also includes the ability to relay and mine taproot transactions
 81  after activation.  Beyond those two basic capabilities, this release
 82  does not include any code that allows anyone to directly use taproot.
 83  The addition of taproot-related features to Bitcoin Core's wallet is
 84  expected in later releases once taproot activation is assured.
 85  
 86  All users, businesses, and miners are encouraged to upgrade to this
 87  release (or a subsequent compatible release) unless they object to
 88  activation of taproot.  If taproot is locked in, then upgrading before
 89  block 709632 is highly recommended to help enforce taproot's new rules
 90  and to avoid the unlikely case of seeing falsely confirmed transactions.
 91  
 92  Miners who want to activate Taproot should preferably use this release
 93  to control their signaling.  The `getblocktemplate` RPC results will
 94  automatically be updated to signal once the appropriate start has been
 95  reached and continue signaling until the timeout occurs or taproot
 96  activates.  Alternatively, miners may manually start signaling on bit 2
 97  at any time; if taproot activates, they will need to ensure they update
 98  their nodes before block 709632 or non-upgraded nodes could cause them to mine on
 99  an invalid chain.  See the [versionbits
100  FAQ](https://bitcoincore.org/en/2016/06/08/version-bits-miners-faq/) for
101  details.
102  
103  
104  For more information about taproot, please see the following resources:
105  
106  - Technical specifications
107    - [BIP340 Schnorr signatures for secp256k1](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki) 
108    - [BIP341 Taproot: SegWit version 1 spending rules](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki)
109    - [BIP342 Validation of Taproot scripts](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki)
110  
111  - Popular articles;
112    - [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)
113    - [What do Schnorr Signatures Mean for Bitcoin?](https://academy.binance.com/en/articles/what-do-schnorr-signatures-mean-for-bitcoin)
114    - [The Schnorr Signature & Taproot Softfork Proposal](https://blog.bitmex.com/the-schnorr-signature-taproot-softfork-proposal/)
115  
116  - Development history overview
117    - [Taproot](https://bitcoinops.org/en/topics/taproot/)
118    - [Schnorr signatures](https://bitcoinops.org/en/topics/schnorr-signatures/)
119    - [Tapscript](https://bitcoinops.org/en/topics/tapscript/)
120    - [Soft fork activation](https://bitcoinops.org/en/topics/soft-fork-activation/)
121  
122  - Other
123    - [Questions and answers related to taproot](https://bitcoin.stackexchange.com/questions/tagged/taproot)
124    - [Taproot review](https://github.com/ajtowns/taproot-review)
125  
126  Updated RPCs
127  ------------
128  
129  - Due to [BIP 350](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki)
130    being implemented, behavior for all RPCs that accept addresses is changed when
131    a native witness version 1 (or higher) is passed. These now require a Bech32m
132    encoding instead of a Bech32 one, and Bech32m encoding will be used for such
133    addresses in RPC output as well. No version 1 addresses should be created
134    for mainnet until consensus rules are adopted that give them meaning
135    (e.g. through [BIP 341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki)).
136    Once that happens, Bech32m is expected to be used for them, so this shouldn't
137    affect any production systems, but may be observed on other networks where such
138    addresses already have meaning (like signet).
139  
140  0.21.1 change log
141  =================
142  
143  ### Consensus
144  - #21377 Speedy trial support for versionbits (ajtowns)
145  - #21686 Speedy trial activation parameters for Taproot (achow101)
146  
147  ### P2P protocol and network code
148  - #20852 allow CSubNet of non-IP networks (vasild)
149  - #21043 Avoid UBSan warning in ProcessMessage(…) (practicalswift)
150  
151  ### Wallet
152  - #21166 Introduce DeferredSignatureChecker and have SignatureExtractorClass subclass it (achow101)
153  - #21083 Avoid requesting fee rates multiple times during coin selection (achow101)
154  
155  ### RPC and other APIs
156  - #21201 Disallow sendtoaddress and sendmany when private keys disabled (achow101)
157  
158  ### Build system
159  - #21486 link against -lsocket if required for `*ifaddrs` (fanquake)
160  - #20983 Fix MSVC build after gui#176 (hebasto)
161  
162  ### Tests and QA
163  - #21380 Add fuzzing harness for versionbits (ajtowns)
164  - #20812 fuzz: Bump FuzzedDataProvider.h (MarcoFalke)
165  - #20740 fuzz: Update FuzzedDataProvider.h from upstream (LLVM) (practicalswift)
166  - #21446 Update vcpkg checkout commit (sipsorcery)
167  - #21397 fuzz: Bump FuzzedDataProvider.h (MarcoFalke)
168  - #21081 Fix the unreachable code at `feature_taproot` (brunoerg)
169  - #20562 Test that a fully signed tx given to signrawtx is unchanged (achow101)
170  - #21571 Make sure non-IP peers get discouraged and disconnected (vasild, MarcoFalke)
171  - #21489 fuzz: cleanups for versionbits fuzzer (ajtowns)
172  
173  ### Miscellaneous
174  - #20861 BIP 350: Implement Bech32m and use it for v1+ segwit addresses (sipa)
175  
176  ### Documentation
177  - #21384 add signet to bitcoin.conf documentation (jonatack)
178  - #21342 Remove outdated comment (hebasto)
179  
180  Credits
181  =======
182  
183  Thanks to everyone who directly contributed to this release:
184  
185  - Aaron Clauson
186  - Andrew Chow
187  - Anthony Towns
188  - Bruno Garcia
189  - Fabian Jahr
190  - fanquake
191  - Hennadii Stepanov
192  - Jon Atack
193  - Luke Dashjr
194  - MarcoFalke
195  - Pieter Wuille
196  - practicalswift
197  - randymcmillan
198  - Sjors Provoost
199  - Vasil Dimov
200  - W. J. van der Laan
201  
202  As well as to everyone that helped with translations on
203  [Transifex](https://www.transifex.com/bitcoin/bitcoin/).