1  Bitcoin Core version 29.0 is now available from:
  2  
  3    <https://bitcoincore.org/bin/bitcoin-core-29.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  Compatibility
 29  ==============
 30  
 31  Bitcoin Core is supported and tested on operating systems using the
 32  Linux Kernel 3.17+, macOS 13+, and Windows 10+. Bitcoin
 33  Core should also work on most other Unix-like systems but is not as
 34  frequently tested on them. It is not recommended to use Bitcoin Core on
 35  unsupported systems.
 36  
 37  Notable changes
 38  ===============
 39  
 40  ### P2P and Network Changes
 41  
 42  - Support for UPnP was dropped. If you want to open a port automatically, consider using the `-natpmp`
 43  option instead, which uses PCP or NAT-PMP depending on router support. (#31130)
 44  
 45  - libnatpmp was replaced with a built-in implementation of PCP and NAT-PMP (still enabled using the `-natpmp` option). This supports automatic IPv4 port forwarding as well as IPv6 pinholing. (#30043)
 46  
 47  - When the `-port` configuration option is used, the default onion listening port will now
 48  be derived to be that port + 1 instead of being set to a fixed value (8334 on mainnet).
 49  This re-allows setups with multiple local nodes using different `-port` and not using `-bind`,
 50  which would lead to a startup failure in v28.0 due to a port collision.
 51  Note that a `HiddenServicePort` manually configured in `torrc` may need adjustment if used in
 52  connection with the `-port` option.
 53  For example, if you are using `-port=5555` with a non-standard value and not using `-bind=...=onion`,
 54  previously Bitcoin Core would listen for incoming Tor connections on `127.0.0.1:8334`.
 55  Now it would listen on `127.0.0.1:5556` (`-port` plus one). If you configured the hidden service manually
 56  in torrc now you have to change it from `HiddenServicePort 8333 127.0.0.1:8334` to `HiddenServicePort 8333
 57  127.0.0.1:5556`, or configure bitcoind with `-bind=127.0.0.1:8334=onion` to get the previous behavior.
 58  (#31223)
 59  
 60  - Upon receiving an orphan transaction (an unconfirmed transaction that spends unknown inputs), the node will attempt to download missing parents from all peers who announced the orphan. This change may increase bandwidth usage but make orphan-handling more reliable. (#31397)
 61  
 62  ### Mempool Policy and Mining Changes
 63  
 64  - Ephemeral dust is a new concept that allows a single
 65  dust output in a transaction, provided the transaction
 66  is zero fee. In order to spend any unconfirmed outputs
 67  from this transaction, the spender must also spend
 68  this dust in addition to any other desired outputs.
 69  In other words, this type of transaction
 70  should be created in a transaction package where
 71  the dust is both created and spent simultaneously. (#30239)
 72  
 73  - Due to a bug, the default block reserved weight (`4,000 WU`) for fixed-size block header, transactions count, and coinbase transaction was reserved twice and could not be lowered. As a result the total reserved weight was always `8,000 WU`, meaning that even when specifying a `-blockmaxweight` higher than the default (even to the max of `4,000,000 WU`), the actual block size will never exceed `3,992,000 WU`.
 74  The fix consolidates the reservation into a single place and introduces a new startup option, `-blockreservedweight` which specifies the reserved weight directly. The default value of `-blockreservedweight` is set to `8,000 WU` to ensure backward compatibility for users who relied on the previous behavior of `-blockmaxweight`.
 75  The minimum value of `-blockreservedweight` is set to `2,000 WU`. Users setting `-blockreservedweight` below the default should ensure that the total weight of their block header, transaction count, and coinbase transaction does not exceed the reduced value or they may risk mining an invalid block. (#31384)
 76  
 77  ### Updated RPCs
 78  
 79  - The RPC `testmempoolaccept` response now includes a `reject-details` field in some cases,
 80  similar to the complete error messages returned by `sendrawtransaction` (#28121)
 81  
 82  - Duplicate blocks submitted with `submitblock` will now persist their block data
 83  even if it was previously pruned. If pruning is activated, the data will be
 84  pruned again eventually once the block file it is persisted in is selected for
 85  pruning. This is consistent with the behaviour of `getblockfrompeer` where the
 86  block is persisted as well even when pruning. (#31175)
 87  
 88  - `getmininginfo` now returns `nBits` and the current target in the `target` field. It also returns a `next` object which specifies the `height`, `nBits`, `difficulty`, and `target` for the next block. (#31583)
 89  
 90  - `getblock` and `getblockheader` now return the current target in the `target` field (#31583)
 91  
 92  - `getblockchaininfo` and `getchainstates` now return `nBits` and the current target in the `target` field (#31583)
 93  
 94  - the `getblocktemplate` RPC `curtime` (BIP22) and `mintime` (BIP23) fields now
 95    account for the timewarp fix proposed in BIP94 on all networks. This ensures
 96    that, in the event a timewarp fix softfork activates on mainnet, un-upgraded
 97    miners will not accidentally violate the timewarp rule. (#31376, #31600)
 98  As a reminder, it's important that any software which uses the `getblocktemplate`
 99  RPC takes these values into account (either `curtime` or `mintime` is fine).
100  Relying only on a clock can lead to invalid blocks under some circumstances,
101  especially once a timewarp fix is deployed. (#31600)
102  
103  ### New RPCs
104  
105  - `getdescriptoractivity` can be used to find all spend/receive activity relevant to
106    a given set of descriptors within a set of specified blocks. This call can be used with
107    `scanblocks` to lessen the need for additional indexing programs. (#30708)
108  
109  ### Updated REST APIs
110  
111  - `GET /rest/block/<BLOCK-HASH>.json` and `GET /rest/headers/<BLOCK-HASH>.json` now return the current target in the `target` field
112  
113  ### Updated Settings
114  
115  - The maximum allowed value for the `-dbcache` configuration option has been
116    dropped due to recent UTXO set growth. Note that before this change, large `-dbcache`
117    values were automatically reduced to 16 GiB (1 GiB on 32 bit systems). (#28358)
118  
119  - Handling of negated `-noseednode`, `-nobind`, `-nowhitebind`, `-norpcbind`, `-norpcallowip`, `-norpcwhitelist`, `-notest`, `-noasmap`, `-norpcwallet`, `-noonlynet`, and `-noexternalip` options has changed. Previously negating these options had various confusing and undocumented side effects. Now negating them just resets the settings and restores default behaviors, as if the options were not specified.
120  
121  - Starting with v28.0, the `-mempoolfullrbf` startup option was set to
122  default to `1`. With widespread adoption of this policy, users no longer
123  benefit from disabling it, so the option has been removed, making full
124  replace-by-fee the standard behavior. (#30592)
125  
126  - Setting `-upnp` will now log a warning and be interpreted as `-natpmp`. Consider using `-natpmp` directly instead. (#31130, #31916)
127  
128  - As a safety check, Bitcoin core will **fail to start** when `-blockreservedweight` init parameter value is lower than `2000` weight units. Bitcoin Core will also **fail to start** if the `-blockmaxweight` or `-blockreservedweight` init parameter exceeds consensus limit of `4,000,000 WU`.
129  
130  - Passing `-debug=0` or `-debug=none` now behaves like `-nodebug`: previously set debug categories will be cleared, but subsequent `-debug` options will still be applied.
131  
132  - The default for `-rpcthreads` has been changed from 4 to 16, and the default for `-rpcworkqueue` has been changed from 16 to 64. (#31215).
133  
134  ### Build System
135  
136  The build system has been migrated from Autotools to CMake:
137  
138  1. The minimum required CMake version is 3.22.
139  2. In-source builds are not allowed. When using a subdirectory within the root source tree as a build directory, it is recommended that its name includes the substring "build".
140  3. CMake variables may be used to configure the build system. **Some defaults have changed.** For example, you will now need to add `-DWITH_ZMQ=ON` to build with zmq and `-DBUILD_GUI=ON` to build `bitcoin-qt`. See [Autotools to CMake Options Mapping](https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Autotools-to-CMake-Options-Mapping) for details.
141  4. For single-configuration generators, the default build configuration (`CMAKE_BUILD_TYPE`) is "RelWithDebInfo". However, for the "Release" configuration, CMake defaults to the compiler optimization flag `-O3`, which has not been extensively tested with Bitcoin Core. Therefore, the build system replaces it with `-O2`.
142  5. By default, the built executables and libraries are located in the `bin/` and `lib/` subdirectories of the build directory.
143  6. The build system supports component‐based installation. The names of the installable components coincide with the build target names. For example:
144  ```
145  cmake -B build
146  cmake --build build --target bitcoind
147  cmake --install build --component bitcoind
148  ```
149  
150  7. If any of the `CPPFLAGS`, `CFLAGS`, `CXXFLAGS` or `LDFLAGS` environment variables were used in your Autotools-based build process, you should instead use the corresponding CMake variables (`APPEND_CPPFLAGS`, `APPEND_CFLAGS`, `APPEND_CXXFLAGS` and `APPEND_LDFLAGS`). Alternatively, if you opt to use the dedicated `CMAKE_<...>_FLAGS` variables, you must ensure that the resulting compiler or linker invocations are as expected.
151  
152  For more detailed guidance on configuring and using CMake, please refer to the official [CMake documentation](https://cmake.org/cmake/help/latest/) and [CMake’s User Interaction Guide](https://cmake.org/cmake/help/latest/guide/user-interaction/index.html). Additionally, consult platform-specific `doc/build-*.md` build guides for instructions tailored to your operating system.
153  
154  ## Low-Level Changes
155  
156  ### Tools and Utilities
157  
158  - A new tool [`utxo_to_sqlite.py`](https://github.com/bitcoin/bitcoin/blob/v29.0/contrib/utxo-tools/utxo_to_sqlite.py)
159    converts a compact-serialized UTXO snapshot (as created with the
160    `dumptxoutset` RPC) to a SQLite3 database. Refer to the script's `--help`
161    output for more details. (#27432)
162  
163  ### Tests
164  
165  - The BIP94 timewarp attack mitigation (designed for testnet4) is no longer active on the regtest network. (#31156)
166  
167  ### Dependencies
168  
169  - MiniUPnPc and libnatpmp have been removed as dependencies (#31130, #30043).
170  
171  Credits
172  =======
173  
174  Thanks to everyone who directly contributed to this release:
175  
176  - 0xb10c
177  - Adlai Chandrasekhar
178  - Afanti
179  - Alfonso Roman Zubeldia
180  - am-sq
181  - Andre
182  - Andre Alves
183  - Anthony Towns
184  - Antoine Poinsot
185  - Ash Manning
186  - Ava Chow
187  - Boris Nagaev
188  - Brandon Odiwuor
189  - brunoerg
190  - Chris Stewart
191  - Cory Fields
192  - costcould
193  - Daniel Pfeifer
194  - Daniela Brozzoni
195  - David Gumberg
196  - dergoegge
197  - epysqyli
198  - espi3
199  - Eval EXEC
200  - Fabian Jahr
201  - fanquake
202  - furszy
203  - Gabriele Bocchi
204  - glozow
205  - Greg Sanders
206  - Gutflo
207  - Hennadii Stepanov
208  - Hodlinator
209  - i-am-yuvi
210  - ion-
211  - ismaelsadeeq
212  - Jadi
213  - James O'Beirne
214  - Jeremy Rand
215  - Jon Atack
216  - jurraca
217  - Kay
218  - kevkevinpal
219  - l0rinc
220  - laanwj
221  - Larry Ruane
222  - Lőrinc
223  - Maciej S. Szmigiero
224  - Mackain
225  - MarcoFalke
226  - marcofleon
227  - Marnix
228  - Martin Leitner-Ankerl
229  - Martin Saposnic
230  - Martin Zumsande
231  - Matthew Zipkin
232  - Max Edwards
233  - Michael Dietz
234  - naiyoma
235  - Nicola Leonardo Susca
236  - omahs
237  - pablomartin4btc
238  - Pieter Wuille
239  - Randall Naar
240  - RiceChuan
241  - rkrux
242  - Roman Zeyde
243  - Ryan Ofsky
244  - Sebastian Falbesoner
245  - secp512k2
246  - Sergi Delgado Segura
247  - Simon
248  - Sjors Provoost
249  - stickies-v
250  - Suhas Daftuar
251  - tdb3
252  - TheCharlatan
253  - tianzedavid
254  - Torkel Rogstad
255  - Vasil Dimov
256  - wgyt
257  - willcl-ark
258  - yancy
259  
260  As well as to everyone that helped with translations on
261  [Transifex](https://www.transifex.com/bitcoin/bitcoin/).