Inside Bitcoin

123.0 Release Notes
2==================
3
4Bitcoin Core version 23.0 is now available from:
5
6  <https://bitcoincore.org/bin/bitcoin-core-23.0/>
7
8This release includes new features, various bug fixes and performance
9improvements, as well as updated translations.
10
11Please report bugs using the issue tracker at GitHub:
12
13  <https://github.com/bitcoin/bitcoin/issues>
14
15To receive security and update notifications, please subscribe to:
16
17  <https://bitcoincore.org/en/list/announcements/join/>
18
19How to Upgrade
20==============
21
22If you are running an older version, shut it down. Wait until it has completely
23shut down (which might take a few minutes in some cases), then run the
24installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
25or `bitcoind`/`bitcoin-qt` (on Linux).
26
27Upgrading directly from a version of Bitcoin Core that has reached its EOL is
28possible, but it might take some time if the data directory needs to be migrated. Old
29wallet versions of Bitcoin Core are generally supported.
30
31Compatibility
32==============
33
34Bitcoin Core is supported and extensively tested on operating systems
35using the Linux kernel, macOS 10.15+, and Windows 7 and newer.  Bitcoin
36Core should also work on most other Unix-like systems but is not as
37frequently tested on them.  It is not recommended to use Bitcoin Core on
38unsupported systems.
39
40Notable changes
41===============
42
43P2P and network changes
44-----------------------
45
46- A bitcoind node will no longer rumour addresses to inbound peers by default.
47  They will become eligible for address gossip after sending an ADDR, ADDRV2,
48  or GETADDR message. (#21528)
49
50- Before this release, Bitcoin Core had a strong preference to try to connect only to peers that listen on port 8333. As a result of that, Bitcoin nodes listening on non-standard ports would likely not get any Bitcoin Core peers connecting to them. This preference has been removed. (#23542)
51
52- Full support has been added for the CJDNS network. See the new option `-cjdnsreachable` and [doc/cjdns.md](https://github.com/bitcoin/bitcoin/tree/23.x/doc/cjdns.md) (#23077)
53
54Fee estimation changes
55----------------------
56
57- Fee estimation now takes the feerate of replacement (RBF) transactions into
58  account. (#22539)
59
60Rescan startup parameter removed
61--------------------------------
62
63The `-rescan` startup parameter has been removed. Wallets which require
64rescanning due to corruption will still be rescanned on startup.
65Otherwise, please use the `rescanblockchain` RPC to trigger a rescan. (#23123)
66
67Tracepoints and Userspace, Statically Defined Tracing support
68-------------------------------------------------------------
69
70Bitcoin Core release binaries for Linux now include experimental tracepoints which
71act as an interface for process-internal events. These can be used for review,
72debugging, monitoring, and more. The tracepoint API is semi-stable. While the API
73is tested, process internals might change between releases requiring changes to the
74tracepoints. Information about the existing tracepoints can be found under
75[doc/tracing.md](https://github.com/bitcoin/bitcoin/blob/23.x/doc/tracing.md) and
76usage examples are provided in [contrib/tracing/](https://github.com/bitcoin/bitcoin/tree/23.x/contrib/tracing).
77
78Updated RPCs
79------------
80
81- The `validateaddress` RPC now returns an `error_locations` array for invalid
82  addresses, with the indices of invalid character locations in the address (if
83  known). For example, this will attempt to locate up to two Bech32 errors, and
84  return their locations if successful. Success and correctness are only guaranteed
85  if fewer than two substitution errors have been made.
86  The error message returned in the `error` field now also returns more specific
87  errors when decoding fails. (#16807)
88
89- The `-deprecatedrpc=addresses` configuration option has been removed.  RPCs
90  `gettxout`, `getrawtransaction`, `decoderawtransaction`, `decodescript`,
91  `gettransaction verbose=true` and REST endpoints `/rest/tx`, `/rest/getutxos`,
92  `/rest/block` no longer return the `addresses` and `reqSigs` fields, which
93  were previously deprecated in 22.0. (#22650)
94- The `getblock` RPC command now supports verbosity level 3 containing transaction inputs'
95  `prevout` information.  The existing `/rest/block/` REST endpoint is modified to contain
96  this information too. Every `vin` field will contain an additional `prevout` subfield
97  describing the spent output. `prevout` contains the following keys:
98  - `generated` - true if the spent coins was a coinbase.
99  - `height`
100  - `value`
101  - `scriptPubKey`
102
103- The top-level fee fields `fee`, `modifiedfee`, `ancestorfees` and `descendantfees`
104  returned by RPCs `getmempoolentry`,`getrawmempool(verbose=true)`,
105  `getmempoolancestors(verbose=true)` and `getmempooldescendants(verbose=true)`
106  are deprecated and will be removed in the next major version (use
107  `-deprecated=fees` if needed in this version). The same fee fields can be accessed
108  through the `fees` object in the result. WARNING: deprecated
109  fields `ancestorfees` and `descendantfees` are denominated in sats, whereas all
110  fields in the `fees` object are denominated in BTC. (#22689)
111
112- Both `createmultisig` and `addmultisigaddress` now include a `warnings`
113  field, which will show a warning if a non-legacy address type is requested
114  when using uncompressed public keys. (#23113)
115
116Changes to wallet related RPCs can be found in the Wallet section below.
117
118New RPCs
119--------
120
121- Information on soft fork status has been moved from `getblockchaininfo`
122  to the new `getdeploymentinfo` RPC which allows querying soft fork status at any
123  block, rather than just at the chain tip. Inclusion of soft fork
124  status in `getblockchaininfo` can currently be restored using the
125  configuration `-deprecatedrpc=softforks`, but this will be removed in
126  a future release. Note that in either case, the `status` field
127  now reflects the status of the current block rather than the next
128  block. (#23508)
129
130Files
131-----
132
133* On startup, the list of banned hosts and networks (via `setban` RPC) in
134  `banlist.dat` is ignored and only `banlist.json` is considered. Bitcoin Core
135  version 22.x is the only version that can read `banlist.dat` and also write
136  it to `banlist.json`. If `banlist.json` already exists, version 22.x will not
137  try to translate the `banlist.dat` into json. After an upgrade, `listbanned`
138  can be used to double check the parsed entries. (#22570)
139
140Updated settings
141----------------
142
143- In previous releases, the meaning of the command line option
144  `-persistmempool` (without a value provided) incorrectly disabled mempool
145  persistence.  `-persistmempool` is now treated like other boolean options to
146  mean `-persistmempool=1`. Passing `-persistmempool=0`, `-persistmempool=1`
147  and `-nopersistmempool` is unaffected. (#23061)
148
149- `-maxuploadtarget` now allows human readable byte units [k|K|m|M|g|G|t|T].
150  E.g. `-maxuploadtarget=500g`. No whitespace, +- or fractions allowed.
151  Default is `M` if no suffix provided. (#23249)
152
153- If `-proxy=` is given together with `-noonion` then the provided proxy will
154  not be set as a proxy for reaching the Tor network. So it will not be
155  possible to open manual connections to the Tor network for example with the
156  `addnode` RPC. To mimic the old behavior use `-proxy=` together with
157  `-onlynet=` listing all relevant networks except `onion`. (#22834)
158
159Tools and Utilities
160-------------------
161
162- Update `-getinfo` to return data in a user-friendly format that also reduces vertical space. (#21832)
163
164- CLI `-addrinfo` now returns a single field for the number of `onion` addresses
165  known to the node instead of separate `torv2` and `torv3` fields, as support
166  for Tor V2 addresses was removed from Bitcoin Core in 22.0. (#22544)
167
168Wallet
169------
170
171- Descriptor wallets are now the default wallet type. Newly created wallets
172  will use descriptors unless `descriptors=false` is set during `createwallet`, or
173  the `Descriptor wallet` checkbox is unchecked in the GUI.
174
175  Note that wallet RPC commands like `importmulti` and `dumpprivkey` cannot be
176  used with descriptor wallets, so if your client code relies on these commands
177  without specifying `descriptors=false` during wallet creation, you will need
178  to update your code.
179
180- Newly created descriptor wallets will contain an automatically generated `tr()`
181  descriptor which allows for creating single key Taproot receiving addresses.
182
183- `upgradewallet` will now automatically flush the keypool if upgrading
184  from a non-HD wallet to an HD wallet, to immediately start using the
185  newly-generated HD keys. (#23093)
186
187- a new RPC `newkeypool` has been added, which will flush (entirely
188  clear and refill) the keypool. (#23093)
189
190- `listunspent` now includes `ancestorcount`, `ancestorsize`, and
191  `ancestorfees` for each transaction output that is still in the mempool.
192  (#12677)
193
194- `lockunspent` now optionally takes a third parameter, `persistent`, which
195  causes the lock to be written persistently to the wallet database. This
196  allows UTXOs to remain locked even after node restarts or crashes. (#23065)
197
198- `receivedby` RPCs now include coinbase transactions. Previously, the
199  following wallet RPCs excluded coinbase transactions: `getreceivedbyaddress`,
200  `getreceivedbylabel`, `listreceivedbyaddress`, `listreceivedbylabel`. This
201  release changes this behaviour and returns results accounting for received
202  coins from coinbase outputs. The previous behaviour can be restored using the
203  configuration `-deprecatedrpc=exclude_coinbase`, but may be removed in a
204  future release. (#14707)
205
206- A new option in the same `receivedby` RPCs, `include_immature_coinbase`
207  (default=`false`), determines whether to account for immature coinbase
208  transactions. Immature coinbase transactions are coinbase transactions that
209  have 100 or fewer confirmations, and are not spendable. (#14707)
210
211GUI changes
212-----------
213
214- UTXOs which are locked via the GUI are now stored persistently in the
215  wallet database, so are not lost on node shutdown or crash. (#23065)
216
217- The Bech32 checkbox has been replaced with a dropdown for all address types, including the new Bech32m (BIP-350) standard for Taproot enabled wallets.
218
219Low-level changes
220=================
221
222RPC
223---
224
225- `getblockchaininfo` now returns a new `time` field, that provides the chain tip time. (#22407)
226
227Tests
228-----
229
230- For the `regtest` network the activation heights of several softforks were
231  set to block height 1. They can be changed by the runtime setting
232  `-testactivationheight=name@height`. (#22818)
233
234Credits
235=======
236
237Thanks to everyone who directly contributed to this release:
238
239- 0xb10c
240- 0xree
241- Aaron Clauson
242- Adrian-Stefan Mares
243- agroce
244- aitorjs
245- Alex Groce
246- amadeuszpawlik
247- Amiti Uttarwar
248- Andrew Chow
249- Andrew Poelstra
250- Andrew Toth