/ doc / release-notes / release-notes-28.0.md
release-notes-28.0.md
  1  Bitcoin Core version 28.0 is now available from:
  2  
  3    <https://bitcoincore.org/bin/bitcoin-core-28.0/>
  4  
  5  This release includes new features, various bug fixes and performance
  6  improvements, as well as updated translations.
  7  
  8  Please report bugs using the issue tracker at GitHub:
  9  
 10    <https://github.com/bitcoin/bitcoin/issues>
 11  
 12  To receive security and update notifications, please subscribe to:
 13  
 14    <https://bitcoincore.org/en/list/announcements/join/>
 15  
 16  How to Upgrade
 17  ==============
 18  
 19  If you are running an older version, shut it down. Wait until it has completely
 20  shut down (which might take a few minutes in some cases), then run the
 21  installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on macOS)
 22  or `bitcoind`/`bitcoin-qt` (on Linux).
 23  
 24  Upgrading directly from a version of Bitcoin Core that has reached its EOL is
 25  possible, but it might take some time if the data directory needs to be migrated. Old
 26  wallet versions of Bitcoin Core are generally supported.
 27  
 28  Running Bitcoin Core binaries on macOS requires self signing.
 29  ```
 30  cd /path/to/bitcoin-28.0/bin
 31  xattr -d com.apple.quarantine bitcoin-cli bitcoin-qt bitcoin-tx bitcoin-util bitcoin-wallet bitcoind test_bitcoin
 32  codesign -s - bitcoin-cli bitcoin-qt bitcoin-tx bitcoin-util bitcoin-wallet bitcoind test_bitcoin
 33  ```
 34  
 35  Compatibility
 36  ==============
 37  
 38  Bitcoin Core is supported and extensively tested on operating systems
 39  using the Linux Kernel 3.17+, macOS 11.0+, and Windows 7 and newer. Bitcoin
 40  Core should also work on most other UNIX-like systems but is not as
 41  frequently tested on them. It is not recommended to use Bitcoin Core on
 42  unsupported systems.
 43  
 44  Notable changes
 45  ===============
 46  
 47  Testnet4/BIP94 support
 48  -----
 49  
 50  Support for Testnet4 as specified in [BIP94](https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki)
 51  has been added. The network can be selected with the `-testnet4` option and
 52  the section header is also named `[testnet4]`.
 53  
 54  While the intention is to phase out support for Testnet3 in an upcoming
 55  version, support for it is still available via the known options in this
 56  release. (#29775)
 57  
 58  Windows Data Directory
 59  ----------------------
 60  
 61  The default data directory on Windows has been moved from `C:\Users\Username\AppData\Roaming\Bitcoin`
 62  to `C:\Users\Username\AppData\Local\Bitcoin`. Bitcoin Core will check the existence
 63  of the old directory first and continue to use that directory for backwards
 64  compatibility if it is present. (#27064)
 65  
 66  JSON-RPC 2.0 Support
 67  --------------------
 68  
 69  The JSON-RPC server now recognizes JSON-RPC 2.0 requests and responds with
 70  strict adherence to the [specification](https://www.jsonrpc.org/specification).
 71  See [JSON-RPC-interface.md](https://github.com/bitcoin/bitcoin/blob/master/doc/JSON-RPC-interface.md#json-rpc-11-vs-20) for details. (#27101)
 72  
 73  JSON-RPC clients may need to be updated to be compatible with the JSON-RPC server.
 74  Please open an issue on GitHub if any compatibility issues are found.
 75  
 76  libbitcoinconsensus Removal
 77  ---------------------------
 78  
 79  The libbitcoin-consensus library was deprecated in 27.0 and is now completely removed. (#29648)
 80  
 81  P2P and Network Changes
 82  -----------------------
 83  
 84  - Previously if Bitcoin Core was listening for P2P connections, either using
 85    default settings or via `bind=addr:port` it would always also bind to
 86    `127.0.0.1:8334` to listen for Tor connections. It was not possible to switch
 87    this off, even if the node didn't use Tor. This has been changed and now
 88    `bind=addr:port` results in binding on `addr:port` only. The default behavior
 89    of binding to `0.0.0.0:8333` and `127.0.0.1:8334` has not been changed.
 90  
 91    If you are using a `bind=...` configuration without `bind=...=onion` and rely
 92    on the previous implied behavior to accept incoming Tor connections at
 93    `127.0.0.1:8334`, you need to now make this explicit by using
 94    `bind=... bind=127.0.0.1:8334=onion`. (#22729)
 95  
 96  - Bitcoin Core will now fail to start up if any of its P2P binds fail, rather
 97    than the previous behaviour where it would only abort startup if all P2P
 98    binds had failed. (#22729)
 99  
100  - UNIX domain sockets can now be used for proxy connections. Set `-onion` or `-proxy`
101    to the local socket path with the prefix `unix:` (e.g. `-onion=unix:/home/me/torsocket`).
102    (#27375)
103  
104  - UNIX socket paths are now accepted for `-zmqpubrawblock` and `-zmqpubrawtx` with
105    the format `-zmqpubrawtx=unix:/path/to/file` (#27679)
106  
107  - Additional "in" and "out" flags have been added to `-whitelist` to control whether
108    permissions apply to inbound connections and/or manual ones (default: inbound only). (#27114)
109  
110  - Transactions having a feerate that is too low will be opportunistically paired with
111    their child transactions and submitted as a package, thus enabling the node to download
112    1-parent-1-child packages using the existing transaction relay protocol. Combined with
113    other mempool policies, this change allows limited "package relay" when a parent transaction
114    is below the mempool minimum feerate. Topologically Restricted Until Confirmation (TRUC)
115    parents are additionally allowed to be below the minimum relay feerate (i.e., pay 0 fees).
116    Use the `submitpackage` RPC to submit packages directly to the node. Warning: this P2P
117    feature is limited (unlike the `submitpackage` interface, a child with multiple unconfirmed
118    parents is not supported) and not yet reliable under adversarial conditions. (#28970)
119  
120  Mempool Policy Changes
121  ----------------------
122  
123  - Transactions with version number set to 3 are now treated as standard on all networks (#29496),
124    subject to opt-in Topologically Restricted Until Confirmation (TRUC) transaction policy as
125    described in [BIP 431](https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki).  The
126    policy includes limits on spending unconfirmed outputs (#28948), eviction of a previous descendant
127    if a more incentive-compatible one is submitted (#29306), and a maximum transaction size of 10,000vB
128    (#29873). These restrictions simplify the assessment of incentive compatibility of accepting or
129    replacing TRUC transactions, thus ensuring any replacements are more profitable for the node and
130    making fee-bumping more reliable.
131  
132  - Pay To Anchor (P2A) is a new standard witness output type for spending,
133    a newly recognised output template. This allows for key-less anchor
134    outputs, with compact spending conditions for additional efficiencies on
135    top of an equivalent `sh(OP_TRUE)` output, in addition to the txid stability
136    of the spending transaction.
137    N.B. propagation of this output spending on the network will be limited
138    until a sufficient number of nodes on the network adopt this upgrade. (#30352)
139  
140  - Limited package RBF is now enabled, where the proposed conflicting package would result in
141    a connected component, aka cluster, of size 2 in the mempool. All clusters being conflicted
142    against must be of size 2 or lower. (#28984)
143  
144  - The default value of the `-mempoolfullrbf` configuration option has been changed from 0 to 1,
145    i.e. `mempoolfullrbf=1`. (#30493)
146  
147  Updated RPCs
148  ------------
149  
150  - The `dumptxoutset` RPC now returns the UTXO set dump in a new and
151    improved format. Correspondingly, the `loadtxoutset` RPC now expects
152    this new format in the dumps it tries to load. Dumps with the old
153    format are no longer supported and need to be recreated using the
154    new format to be usable. (#29612)
155  
156  - AssumeUTXO mainnet parameters have been added for height 840,000.
157    This means the `loadtxoutset` RPC can now be used on mainnet with
158    the matching UTXO set from that height. (#28553)
159  
160  - The `warnings` field in `getblockchaininfo`, `getmininginfo` and
161    `getnetworkinfo` now returns all the active node warnings as an array
162    of strings, instead of a single warning. The current behaviour
163    can be temporarily restored by running Bitcoin Core with the configuration
164    option `-deprecatedrpc=warnings`. (#29845)
165  
166  - Previously when using the `sendrawtransaction` RPC and specifying outputs
167    that are already in the UTXO set, an RPC error code of `-27` with the
168    message "Transaction already in block chain" was returned in response.
169    The error message has been changed to "Transaction outputs already in utxo set"
170    to more accurately describe the source of the issue. (#30212)
171  
172  - The default mode for the `estimatesmartfee` RPC has been updated from `conservative` to `economical`,
173    which is expected to reduce over-estimation for many users, particularly if Replace-by-Fee is an option.
174    For users that require high confidence in their fee estimates at the cost of potentially over-estimating,
175    the `conservative` mode remains available. (#30275)
176  
177  - RPC `scantxoutset` now returns 2 new fields in the "unspents" JSON array: `blockhash` and `confirmations`.
178    See the scantxoutset help for details. (#30515)
179  
180  - RPC `submitpackage` now allows 2 new arguments to be passed: `maxfeerate` and `maxburnamount`. See the
181    subtmitpackage help for details. (#28950)
182  
183  Changes to wallet-related RPCs can be found in the Wallet section below.
184  
185  Updated REST APIs
186  -----------------
187  - Parameter validation for `/rest/getutxos` has been improved by rejecting
188    truncated or overly large txids and malformed outpoint indices via raising
189    an HTTP_BAD_REQUEST "Parse error". These requests were previously handled
190    silently. (#30482, #30444)
191  
192  Build System
193  ------------
194  
195  - GCC 11.1 or later, or Clang 16.0 or later,
196  are now required to compile Bitcoin Core. (#29091, #30263)
197  
198  - The minimum required glibc to run Bitcoin Core is now
199  2.31. This means that RHEL 8 and Ubuntu 18.04 (Bionic)
200  are no-longer supported. (#29987)
201  
202  - `--enable-lcov-branch-coverage` has been removed, given
203  incompatibilities between lcov version 1 & 2. `LCOV_OPTS`
204  should be used to set any options instead. (#30192)
205  
206  Updated Settings
207  ----------------
208  
209  - When running with `-alertnotify`, an alert can now be raised multiple
210  times instead of just once. Previously, it was only raised when unknown
211  new consensus rules were activated. Its scope has now been increased to
212  include all kernel warnings. Specifically, alerts will now also be raised
213  when an invalid chain with a large amount of work has been detected.
214  Additional warnings may be added in the future. (#30058)
215  
216  Changes to GUI or wallet related settings can be found in the GUI or Wallet section below.
217  
218  Wallet
219  ------
220  
221  - The wallet now detects when wallet transactions conflict with the mempool. Mempool-conflicting
222    transactions can be seen in the `"mempoolconflicts"` field of `gettransaction`. The inputs
223    of mempool-conflicted transactions can now be respent without manually abandoning the
224    transactions when the parent transaction is dropped from the mempool, which can cause wallet
225    balances to appear higher. (#27307)
226  
227  - A new `max_tx_weight` option has been added to the RPCs `fundrawtransaction`, `walletcreatefundedpsbt`, and `send`.
228  It specifies the maximum transaction weight. If the limit is exceeded during funding, the transaction will not be built.
229  The default value is 4,000,000 WU. (#29523)
230  
231  - A new `createwalletdescriptor` RPC allows users to add new automatically generated
232    descriptors to their wallet. This can be used to upgrade wallets created prior to the
233    introduction of a new standard descriptor, such as taproot. (#29130)
234  
235  - A new RPC `gethdkeys` lists all of the BIP32 HD keys in use by all of the descriptors in the wallet.
236    These keys can be used in conjunction with `createwalletdescriptor` to create and add single key
237    descriptors to the wallet for a particular key that the wallet already knows. (#29130)
238  
239  - The `sendall` RPC can now spend unconfirmed change and will include additional fees as necessary
240    for the resulting transaction to bump the unconfirmed transactions' feerates to the specified feerate. (#28979)
241  
242  - In RPC `bumpfee`, if a `fee_rate` is specified, the feerate is no longer restricted
243    to following the wallet's incremental feerate of 5 sat/vb. The feerate must still be
244    at least the sum of the original fee and the mempool's incremental feerate. (#27969)
245  
246  GUI Changes
247  -----------
248  
249  - The "Migrate Wallet" menu allows users to migrate any legacy wallet in their wallet
250  directory, regardless of the wallets loaded. (gui#824)
251  
252  - The "Information" window now displays the maximum mempool size along with the
253  mempool usage. (gui#825)
254  
255  Low-level Changes
256  =================
257  
258  Tests
259  -----
260  
261  - The BIP94 timewarp attack mitigation is now active on the `regtest` network. (#30681)
262  
263  - A new `-testdatadir` option has been added to `test_bitcoin` to allow specifying the
264    location of unit test data directories. (#26564)
265  
266  Blockstorage
267  ------------
268  
269  - Block files are now XOR'd by default with a key stored in the blocksdir.
270  Previous releases of Bitcoin Core or previous external software will not be able to read the blocksdir with a non-zero XOR-key.
271  Refer to the `-blocksxor` help for more details. (#28052)
272  
273  Chainstate
274  ----------
275  
276  - The chainstate database flushes that occur when blocks are pruned will no longer
277  empty the database cache. The cache will remain populated longer, which significantly
278  reduces the time for initial block download to complete. (#28280)
279  
280  Dependencies
281  ------------
282  
283  - The dependency on Boost.Process has been replaced with cpp-subprocess, which is contained in source.
284  Builders will no longer need Boost.Process to build with external signer support. (#28981)
285  
286  Credits
287  =======
288  
289  Thanks to everyone who directly contributed to this release:
290  - 0xb10c
291  - Alfonso Roman Zubeldia
292  - Andrew Toth
293  - AngusP
294  - Anthony Towns
295  - Antoine Poinsot
296  - Anton A
297  - Ava Chow
298  - Ayush Singh
299  - Ben Westgate
300  - Brandon Odiwuor
301  - brunoerg
302  - bstin
303  - Charlie
304  - Christopher Bergqvist
305  - Cory Fields
306  - crazeteam
307  - Daniela Brozzoni
308  - David Gumberg
309  - dergoegge
310  - Edil Medeiros
311  - Epic Curious
312  - Fabian Jahr
313  - fanquake
314  - furszy
315  - glozow
316  - Greg Sanders
317  - hanmz
318  - Hennadii Stepanov
319  - Hernan Marino
320  - Hodlinator
321  - ishaanam
322  - ismaelsadeeq
323  - Jadi
324  - Jon Atack
325  - josibake
326  - jrakibi
327  - kevkevin
328  - kevkevinpal
329  - Konstantin Akimov
330  - laanwj
331  - Larry Ruane
332  - Lőrinc
333  - Luis Schwab
334  - Luke Dashjr
335  - MarcoFalke
336  - marcofleon
337  - Marnix
338  - Martin Saposnic
339  - Martin Zumsande
340  - Matt Corallo
341  - Matthew Zipkin
342  - Matt Whitlock
343  - Max Edwards
344  - Michael Dietz
345  - Murch
346  - nanlour
347  - pablomartin4btc
348  - Peter Todd
349  - Pieter Wuille
350  - @RandyMcMillan
351  - RoboSchmied
352  - Roman Zeyde
353  - Ryan Ofsky
354  - Sebastian Falbesoner
355  - Sergi Delgado Segura
356  - Sjors Provoost
357  - spicyzboss
358  - StevenMia
359  - stickies-v
360  - stratospher
361  - Suhas Daftuar
362  - sunerok
363  - tdb3
364  - TheCharlatan
365  - umiumi
366  - Vasil Dimov
367  - virtu
368  - willcl-ark
369  
370  As well as to everyone that helped with translations on
371  [Transifex](https://www.transifex.com/bitcoin/bitcoin/).