Skip to content

Commit fab53ea

Browse files
author
MarcoFalke
committed
doc: Add doc/release-notes/release-notes-0.21.1.md
1 parent d22e7ee commit fab53ea

File tree

1 file changed

+203
-0
lines changed

1 file changed

+203
-0
lines changed
+203
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,203 @@
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/).

0 commit comments

Comments
 (0)