Skip to content

Commit 4746e76

Browse files
author
Joel Torres
committed
Add v29.0 release
1 parent 23cb5da commit 4746e76

File tree

1 file changed

+307
-0
lines changed

1 file changed

+307
-0
lines changed

_releases/v29.0.md

Lines changed: 307 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,307 @@
1+
---
2+
# This file is licensed under the MIT License (MIT) available on
3+
# http://opensource.org/licenses/MIT.
4+
# Text originally from Bitcoin Core project
5+
# Metadata and small formatting changes from Bitcoin.org project
6+
7+
required_version: 29.0
8+
title: Bitcoin Core 29.0
9+
id: en-release-29.0
10+
name: release-29.0
11+
permalink: /en/releases/29.0/
12+
excerpt: Bitcoin Core version 29.0 is now available
13+
date: 2025-04-14
14+
15+
## Use a YAML array for the version number to allow other parts of the
16+
## site to correctly sort in "natural sort of version numbers".
17+
## Use the same number of elements as decimal places, e.g. "0.1.2 => [0,
18+
## 1, 2]" versus "1.2 => [1, 2]"
19+
release: [29, 0]
20+
21+
## Optional magnet link. To get it, open the torrent in a good BitTorrent client
22+
## and View Details, or install the transmission-cli Debian/Ubuntu package
23+
## and run: transmission-show -m <torrent file>
24+
#
25+
## Link should be enclosed in quotes and start with: "magnet:?
26+
optional_magnetlink: "magnet:?xt=urn:btih:c2ebe360dc7e85d9850196ea57712c8ddffbcd59&dn=bitcoin-core-29.0&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969&ws=http%3A%2F%2Fbitcoincore.org%2Fbin%2F"
27+
28+
# Note: it is recommended to check all links to ensure they use
29+
# absolute urls (https://github.com/bitcoin/bitcoin/doc/foo)
30+
# rather than relative urls (/bitcoin/bitcoin/doc/foo).
31+
---
32+
33+
<div class="post-content" markdown="1">
34+
35+
{% githubify https://github.com/bitcoin/bitcoin %}
36+
29.0 Release Notes
37+
==================
38+
Bitcoin Core version 29.0 is now available from:
39+
40+
<https://bitcoincore.org/bin/bitcoin-core-29.0/>
41+
42+
This release includes new features, various bug fixes and performance
43+
improvements, as well as updated translations.
44+
45+
Please report bugs using the issue tracker at GitHub:
46+
47+
<https://github.com/bitcoin/bitcoin/issues>
48+
49+
To receive security and update notifications, please subscribe to:
50+
51+
<https://bitcoincore.org/en/list/announcements/join/>
52+
53+
How to Upgrade
54+
==============
55+
56+
If you are running an older version, shut it down. Wait until it has completely
57+
shut down (which might take a few minutes in some cases), then run the
58+
installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on macOS)
59+
or `bitcoind`/`bitcoin-qt` (on Linux).
60+
61+
Upgrading directly from a version of Bitcoin Core that has reached its EOL is
62+
possible, but it might take some time if the data directory needs to be migrated. Old
63+
wallet versions of Bitcoin Core are generally supported.
64+
65+
Compatibility
66+
==============
67+
68+
Bitcoin Core is supported and tested on operating systems using the
69+
Linux Kernel 3.17+, macOS 13+, and Windows 10+. Bitcoin
70+
Core should also work on most other Unix-like systems but is not as
71+
frequently tested on them. It is not recommended to use Bitcoin Core on
72+
unsupported systems.
73+
74+
Notable changes
75+
===============
76+
77+
### P2P and Network Changes
78+
79+
- Support for UPnP was dropped. If you want to open a port automatically, consider using the `-natpmp`
80+
option instead, which uses PCP or NAT-PMP depending on router support. (#31130)
81+
82+
- 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)
83+
84+
- When the `-port` configuration option is used, the default onion listening port will now
85+
be derived to be that port + 1 instead of being set to a fixed value (8334 on mainnet).
86+
This re-allows setups with multiple local nodes using different `-port` and not using `-bind`,
87+
which would lead to a startup failure in v28.0 due to a port collision.
88+
Note that a `HiddenServicePort` manually configured in `torrc` may need adjustment if used in
89+
connection with the `-port` option.
90+
For example, if you are using `-port=5555` with a non-standard value and not using `-bind=...=onion`,
91+
previously Bitcoin Core would listen for incoming Tor connections on `127.0.0.1:8334`.
92+
Now it would listen on `127.0.0.1:5556` (`-port` plus one). If you configured the hidden service manually
93+
in torrc now you have to change it from `HiddenServicePort 8333 127.0.0.1:8334` to `HiddenServicePort 8333
94+
127.0.0.1:5556`, or configure bitcoind with `-bind=127.0.0.1:8334=onion` to get the previous behavior.
95+
(#31223)
96+
97+
- 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)
98+
99+
### Mempool Policy and Mining Changes
100+
101+
- Ephemeral dust is a new concept that allows a single
102+
dust output in a transaction, provided the transaction
103+
is zero fee. In order to spend any unconfirmed outputs
104+
from this transaction, the spender must also spend
105+
this dust in addition to any other desired outputs.
106+
In other words, this type of transaction
107+
should be created in a transaction package where
108+
the dust is both created and spent simultaneously. (#30239)
109+
110+
- 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`.
111+
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`.
112+
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)
113+
114+
### Updated RPCs
115+
116+
- The RPC `testmempoolaccept` response now includes a `reject-details` field in some cases,
117+
similar to the complete error messages returned by `sendrawtransaction` (#28121)
118+
119+
- Duplicate blocks submitted with `submitblock` will now persist their block data
120+
even if it was previously pruned. If pruning is activated, the data will be
121+
pruned again eventually once the block file it is persisted in is selected for
122+
pruning. This is consistent with the behaviour of `getblockfrompeer` where the
123+
block is persisted as well even when pruning. (#31175)
124+
125+
- `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)
126+
127+
- `getblock` and `getblockheader` now return the current target in the `target` field (#31583)
128+
129+
- `getblockchaininfo` and `getchainstates` now return `nBits` and the current target in the `target` field (#31583)
130+
131+
- the `getblocktemplate` RPC `curtime` (BIP22) and `mintime` (BIP23) fields now
132+
account for the timewarp fix proposed in BIP94 on all networks. This ensures
133+
that, in the event a timewarp fix softfork activates on mainnet, un-upgraded
134+
miners will not accidentally violate the timewarp rule. (#31376, #31600)
135+
As a reminder, it's important that any software which uses the `getblocktemplate`
136+
RPC takes these values into account (either `curtime` or `mintime` is fine).
137+
Relying only on a clock can lead to invalid blocks under some circumstances,
138+
especially once a timewarp fix is deployed. (#31600)
139+
140+
### New RPCs
141+
142+
- `getdescriptoractivity` can be used to find all spend/receive activity relevant to
143+
a given set of descriptors within a set of specified blocks. This call can be used with
144+
`scanblocks` to lessen the need for additional indexing programs. (#30708)
145+
146+
### Updated REST APIs
147+
148+
- `GET /rest/block/<BLOCK-HASH>.json` and `GET /rest/headers/<BLOCK-HASH>.json` now return the current target in the `target` field
149+
150+
### Updated Settings
151+
152+
- The maximum allowed value for the `-dbcache` configuration option has been
153+
dropped due to recent UTXO set growth. Note that before this change, large `-dbcache`
154+
values were automatically reduced to 16 GiB (1 GiB on 32 bit systems). (#28358)
155+
156+
- 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.
157+
158+
- Starting with v28.0, the `-mempoolfullrbf` startup option was set to
159+
default to `1`. With widespread adoption of this policy, users no longer
160+
benefit from disabling it, so the option has been removed, making full
161+
replace-by-fee the standard behavior. (#30592)
162+
163+
- Setting `-upnp` will now log a warning and be interpreted as `-natpmp`. Consider using `-natpmp` directly instead. (#31130, #31916)
164+
165+
- 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`.
166+
167+
- 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.
168+
169+
- The default for `-rpcthreads` has been changed from 4 to 16, and the default for `-rpcworkqueue` has been changed from 16 to 64. (#31215).
170+
171+
### Build System
172+
173+
The build system has been migrated from Autotools to CMake:
174+
175+
- The minimum required CMake version is 3.22.
176+
177+
- 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".
178+
179+
- 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.
180+
181+
- 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`.
182+
183+
- By default, the built executables and libraries are located in the `bin/` and `lib/` subdirectories of the build directory.
184+
185+
- The build system supports component‐based installation. The names of the installable components coincide with the build target names. For example:
186+
187+
```
188+
cmake -B build
189+
cmake --build build --target bitcoind
190+
cmake --install build --component bitcoind
191+
```
192+
193+
- 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.
194+
195+
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.
196+
197+
## Low-Level Changes
198+
199+
### Tools and Utilities
200+
201+
- A new tool [`utxo_to_sqlite.py`](https://github.com/bitcoin/bitcoin/blob/v29.0/contrib/utxo-tools/utxo_to_sqlite.py)
202+
converts a compact-serialized UTXO snapshot (as created with the
203+
`dumptxoutset` RPC) to a SQLite3 database. Refer to the script's `--help`
204+
output for more details. (#27432)
205+
206+
### Tests
207+
208+
- The BIP94 timewarp attack mitigation (designed for testnet4) is no longer active on the regtest network. (#31156)
209+
210+
### Dependencies
211+
212+
- MiniUPnPc and libnatpmp have been removed as dependencies (#31130, #30043).
213+
214+
Credits
215+
=======
216+
217+
Thanks to everyone who directly contributed to this release:
218+
219+
- 0xb10c
220+
- Adlai Chandrasekhar
221+
- Afanti
222+
- Alfonso Roman Zubeldia
223+
- am-sq
224+
- Andre
225+
- Andre Alves
226+
- Anthony Towns
227+
- Antoine Poinsot
228+
- Ash Manning
229+
- Ava Chow
230+
- Boris Nagaev
231+
- Brandon Odiwuor
232+
- brunoerg
233+
- Chris Stewart
234+
- Cory Fields
235+
- costcould
236+
- Daniel Pfeifer
237+
- Daniela Brozzoni
238+
- David Gumberg
239+
- dergoegge
240+
- epysqyli
241+
- espi3
242+
- Eval EXEC
243+
- Fabian Jahr
244+
- fanquake
245+
- furszy
246+
- Gabriele Bocchi
247+
- glozow
248+
- Greg Sanders
249+
- Gutflo
250+
- Hennadii Stepanov
251+
- Hodlinator
252+
- i-am-yuvi
253+
- ion-
254+
- ismaelsadeeq
255+
- Jadi
256+
- James O'Beirne
257+
- Jeremy Rand
258+
- Jon Atack
259+
- jurraca
260+
- Kay
261+
- kevkevinpal
262+
- l0rinc
263+
- laanwj
264+
- Larry Ruane
265+
- Lőrinc
266+
- Maciej S. Szmigiero
267+
- Mackain
268+
- MarcoFalke
269+
- marcofleon
270+
- Marnix
271+
- Martin Leitner-Ankerl
272+
- Martin Saposnic
273+
- Martin Zumsande
274+
- Matthew Zipkin
275+
- Max Edwards
276+
- Michael Dietz
277+
- naiyoma
278+
- Nicola Leonardo Susca
279+
- omahs
280+
- pablomartin4btc
281+
- Pieter Wuille
282+
- Randall Naar
283+
- RiceChuan
284+
- rkrux
285+
- Roman Zeyde
286+
- Ryan Ofsky
287+
- Sebastian Falbesoner
288+
- secp512k2
289+
- Sergi Delgado Segura
290+
- Simon
291+
- Sjors Provoost
292+
- stickies-v
293+
- Suhas Daftuar
294+
- tdb3
295+
- TheCharlatan
296+
- tianzedavid
297+
- Torkel Rogstad
298+
- Vasil Dimov
299+
- wgyt
300+
- willcl-ark
301+
- yancy
302+
303+
As well as to everyone that helped with translations on
304+
[Transifex](https://www.transifex.com/bitcoin/bitcoin/).
305+
{% endgithubify %}
306+
307+
</div>

0 commit comments

Comments
 (0)