path: root/67/f874bbf8050d50a25fa562d8fd57a8fabe72e5

Delivery-date: Mon, 14 Apr 2025 18:13:28 -0700
Received: from mail-yb1-f192.google.com ([209.85.219.192])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDP4LF7X2AKRBLHF627QMGQEO5AQIZA@googlegroups.com>)
	id 1u4Ure-0004mc-RL
	for bitcoindev@gnusha.org; Mon, 14 Apr 2025 18:13:28 -0700
Received: by mail-yb1-f192.google.com with SMTP id 3f1490d57ef6-e6def57fbb0sf7848057276.1
        for <bitcoindev@gnusha.org>; Mon, 14 Apr 2025 18:13:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1744679601; x=1745284401; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:message-id:to:from:date:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Eb1uSe1MVUn5K1D1QowK2bFF5hBLEk+lnFTDMLnognk=;
        b=KwsVwArULqDwc9/v5bAgItiVZRUbv+t1P42/cQnK27klgf+0nnsGvuoOMg/SxkyhS0
         NgzyPJpZmWpBmLUyUWC3wQMhM8+W3rgRsZYJ2SFaLrbbzcjvQVgUXC8B993/wf8dGWEx
         cKWH/zZOmA2snHo3MoaBm453TL+JcYiAF3YFKqI7fODC2D7iedKdbU8Hhz6rD3cjj9aP
         TIBnpJfNh+vnN/GXHJbbYvO4e+yiVqC+qy3xJmAfVPymI+yMyaTSmO7kGb2P3UUjJn9N
         EMGmsBzqK9r1AAEKSxFvA+CNbJcUnjrjpfVzwX3yXzHQwcB+bvvrpvQpJXiKjiAQVLZT
         vSgw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1744679601; x=1745284401; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:message-id:to:from:date:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Eb1uSe1MVUn5K1D1QowK2bFF5hBLEk+lnFTDMLnognk=;
        b=D15vwf+unPzeH75eTBK63kIngfBh8dnueatHPscfgu4+501vi5965thzB7hPHFpI3/
         0nNDqPsRwh13gUMItCyzCjyT1yPuAQ6lfbdT9y0/6Rakh1fLghrVVmLULjDLCn1xBw/k
         HA8reqJPJsHP6Zb/3+NahS+GzdWgsdQl1lO7p+y7ctuO+Gw+9v9Y7ImkeRtkAB5Rz9Fe
         2SnC4qJs6cr2KqG2/Q8czKHddNjl9smnlaJWZHPSRAMEGueweHyTSWH6KOlTWvgPu2m6
         IrceOZIWfh0memhLAz5F8wvmSEfrqGSo2NVF+N3nqwow9X7BMfJa/7DRVmoxfzYk+uw4
         pMQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1744679601; x=1745284401;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:message-id:to:from:date:x-beenthere:x-gm-message-state
         :sender:from:to:cc:subject:date:message-id:reply-to;
        bh=Eb1uSe1MVUn5K1D1QowK2bFF5hBLEk+lnFTDMLnognk=;
        b=a6JIy6I7QV7wyX+hVg0wa8eZxIQuqsV309kfUkqVSfrdo/xn0tEEkIMUKNNkWRyLLU
         bDaD5ccey19udm6TAbqXaVTcUsthIfAjD0DhuRQIV/APit+hsNlE3lyiqtzD2uURFR1a
         fO3SRK6d/JjeeVRoP8L78IXG5jn0Zfc+Mn8+aarvV1y+Obnbvnt6Th/Fq0SdWiGyCOUj
         pMgezCpPNkpaIE4ArihIl1x6Dd2jA7UyaoXrswno+5w81zKjNBNP//PXRdfMnzKLJo5c
         tYQq+nv/qpOoyoLg6LmqzRpem0tzoy72VT71Tug3wLtBFU/zKAS6MvLeTHGYHrSrTioB
         j5rw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCUsSz6m18nrUwdnlhWpnTPen1rqhE65Oy0lRpHYWSHPP2hkmHk6FcHkKmlHp9p8Msh36uuMVqcsdaFK@gnusha.org
X-Gm-Message-State: AOJu0YyEpu8EI9VoXuZV0Y8iMSoy+OTp3mqR+HRCH+ikv1BQn/xC6IlA
	BCNKmIV+IYfrJD0AbbhHDdMEz7S2LlJsmpVucneGBgLQrxDgIIJ/
X-Google-Smtp-Source: AGHT+IEQiwOxIxUOQtqg2YG+jkCsHZTfjX2fvK+n0CUKGiRlFrE4Z24hOjknx5UdGKcJSPRLjaBxqQ==
X-Received: by 2002:a05:6902:1281:b0:e6d:eb74:25e with SMTP id 3f1490d57ef6-e704deb96fbmr22083562276.25.1744679600767;
        Mon, 14 Apr 2025 18:13:20 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAL04RdOTd3ZRJx7wjuz6PtE0TxqzTCSQiVkI9W6J7qv9w==
Received: by 2002:a25:d601:0:b0:e5b:3877:6d59 with SMTP id 3f1490d57ef6-e70814e9e78ls1427662276.0.-pod-prod-05-us;
 Mon, 14 Apr 2025 18:13:16 -0700 (PDT)
X-Received: by 2002:a05:690c:6182:b0:6e3:323f:d8fb with SMTP id 00721157ae682-705599c981fmr236507017b3.14.1744679595855;
        Mon, 14 Apr 2025 18:13:15 -0700 (PDT)
Received: by 2002:a05:690c:7109:b0:6ef:590d:3213 with SMTP id 00721157ae682-70558729d77ms7b3;
        Mon, 14 Apr 2025 18:03:50 -0700 (PDT)
X-Received: by 2002:a05:690c:7348:b0:6ff:1fac:c4f2 with SMTP id 00721157ae682-70559a99205mr225812457b3.33.1744679028681;
        Mon, 14 Apr 2025 18:03:48 -0700 (PDT)
Date: Mon, 14 Apr 2025 18:03:48 -0700 (PDT)
From: Gloria Zhao <gloriajzhao@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <7897498c-88ec-4c0f-b457-8410944e0ce1n@googlegroups.com>
Subject: [bitcoindev] Bitcoin Core 29.0 Released
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_5654_529336910.1744679028150"
X-Original-Sender: gloriajzhao@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_Part_5654_529336910.1744679028150
Content-Type: multipart/alternative; 
	boundary="----=_Part_5655_34867969.1744679028150"

------=_Part_5655_34867969.1744679028150
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Bitcoin Core version 29.0 is now available from:

  <https://bitcoincore.org/bin/bitcoin-core-29.0/>

This release includes new features, various bug fixes and performance
improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  <https://github.com/bitcoin/bitcoin/issues>

To receive security and update notifications, please subscribe to:

  <https://bitcoincore.org/en/list/announcements/join/>

How to Upgrade
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

If you are running an older version, shut it down. Wait until it has=20
completely
shut down (which might take a few minutes in some cases), then run the
installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on=20
macOS)
or `bitcoind`/`bitcoin-qt` (on Linux).

Upgrading directly from a version of Bitcoin Core that has reached its EOL=
=20
is
possible, but it might take some time if the data directory needs to be=20
migrated. Old
wallet versions of Bitcoin Core are generally supported.

Compatibility
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Bitcoin Core is supported and tested on operating systems using the
Linux Kernel 3.17+, macOS 13+, and Windows 10+. Bitcoin
Core should also work on most other Unix-like systems but is not as
frequently tested on them. It is not recommended to use Bitcoin Core on
unsupported systems.

Notable changes
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

### P2P and Network Changes

- Support for UPnP was dropped. If you want to open a port automatically,
  consider using the `-natpmp` option instead, which uses PCP or NAT-PMP
depending on router support. (#31130)

- libnatpmp was replaced with a built-in implementation of PCP and NAT-PMP
  (still enabled using the `-natpmp` option). This supports automatic IPv4=
=20
port
forwarding as well as IPv6 pinholing. (#30043)

- When the `-port` configuration option is used, the default onion listenin=
g
  port will now be derived to be that port + 1 instead of being set to a=20
fixed
value (8334 on mainnet).  This re-allows setups with multiple local nodes=
=20
using
different `-port` and not using `-bind`, which would lead to a startup=20
failure
in v28.0 due to a port collision.  Note that a `HiddenServicePort` manually
configured in `torrc` may need adjustment if used in connection with the=20
`-port`
option.  For example, if you are using `-port=3D5555` with a non-standard=
=20
value
and not using `-bind=3D...=3Donion`, previously Bitcoin Core would listen f=
or
incoming Tor connections on `127.0.0.1:8334`.  Now it would listen on
`127.0.0.1:5556` (`-port` plus one). If you configured the hidden service
manually in torrc now you have to change it from `HiddenServicePort 8333
127.0.0.1:8334` to `HiddenServicePort 8333 127.0.0.1:5556`, or configure
bitcoind with `-bind=3D127.0.0.1:8334=3Donion` to get the previous behavior=
.
(#31223)

- Upon receiving an orphan transaction (an unconfirmed transaction that=20
spends
  unknown inputs), the node will attempt to download missing parents from=
=20
all
peers who announced the orphan. This change may increase bandwidth usage bu=
t
make orphan-handling more reliable. (#31397)

### Mempool Policy and Mining Changes

- Ephemeral dust is a new concept that allows a single dust output in a
  transaction, provided the transaction is zero fee. In order to spend any
unconfirmed outputs from this transaction, the spender must also spend this=
=20
dust
in addition to any other desired outputs.  In other words, this type of
transaction should be created in a transaction package where the dust is=20
both
created and spent simultaneously. (#30239)

- Due to a bug, the default block reserved weight (`4,000 WU`) for=20
fixed-size
  block header, transactions count, and coinbase transaction was reserved=
=20
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=20
than
the default (even to the max of `4,000,000 WU`), the actual block size will
never exceed `3,992,000 WU`.  The fix consolidates the reservation into a=
=20
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=20
compatibility for
users who relied on the previous behavior of `-blockmaxweight`.  The minimu=
m
value of `-blockreservedweight` is set to `2,000 WU`. Users setting
`-blockreservedweight` below the default should ensure that the total=20
weight of
their block header, transaction count, and coinbase transaction does not=20
exceed
the reduced value or they may risk mining an invalid block. (#31384)

### Updated RPCs

- The RPC `testmempoolaccept` response now includes a `reject-details`=20
field in
  some cases, similar to the complete error messages returned by
`sendrawtransaction` (#28121)

- Duplicate blocks submitted with `submitblock` will now persist their bloc=
k
  data even if it was previously pruned. If pruning is activated, the data=
=20
will
be pruned again eventually once the block file it is persisted in is=20
selected
for pruning. This is consistent with the behaviour of `getblockfrompeer`=20
where
the block is persisted as well even when pruning. (#31175)

- `getmininginfo` now returns `nBits` and the current target in the `target=
`
  field. It also returns a `next` object which specifies the `height`,=20
`nBits`,
`difficulty`, and `target` for the next block. (#31583)

- `getblock` and `getblockheader` now return the current target in the=20
`target`
  field (#31583)

- `getblockchaininfo` and `getchainstates` now return `nBits` and the=20
current
  target in the `target` field (#31583)

- the `getblocktemplate` RPC `curtime` (BIP22) and `mintime` (BIP23) fields=
=20
now
  account for the timewarp fix proposed in BIP94 on all networks. This=20
ensures
that, in the event a timewarp fix softfork activates on mainnet, un-upgrade=
d
miners will not accidentally violate the timewarp rule. (#31376, #31600) As=
=20
a
reminder, it's important that any software which uses the=20
`getblocktemplate` RPC
takes these values into account (either `curtime` or `mintime` is fine).
Relying only on a clock can lead to invalid blocks under some circumstances=
,
especially once a timewarp fix is deployed. (#31600)

### New RPCs

- `getdescriptoractivity` can be used to find all spend/receive activity
  relevant to a given set of descriptors within a set of specified blocks.=
=20
This
call can be used with `scanblocks` to lessen the need for additional=20
indexing
programs. (#30708)

### Updated REST APIs

- `GET /rest/block/<BLOCK-HASH>.json` and `GET=20
/rest/headers/<BLOCK-HASH>.json`
  now return the current target in the `target` field

### Updated Settings

- The maximum allowed value for the `-dbcache` configuration option has bee=
n
  dropped due to recent UTXO set growth. Note that before this change, larg=
e
`-dbcache` values were automatically reduced to 16 GiB (1 GiB on 32 bit
systems). (#28358)

- Handling of negated `-noseednode`, `-nobind`, `-nowhitebind`,=20
`-norpcbind`,
  `-norpcallowip`, `-norpcwhitelist`, `-notest`, `-noasmap`, `-norpcwallet`=
,
`-noonlynet`, and `-noexternalip` options has changed. Previously negating=
=20
these
options had various confusing and undocumented side effects. Now negating=
=20
them
just resets the settings and restores default behaviors, as if the options=
=20
were
not specified.

- Starting with v28.0, the `-mempoolfullrbf` startup option was set to=20
default
  to `1`. With widespread adoption of this policy, users no longer benefit=
=20
from
disabling it, so the option has been removed, making full replace-by-fee th=
e
standard behavior. (#30592)

- Setting `-upnp` will now log a warning and be interpreted as `-natpmp`.
  Consider using `-natpmp` directly instead. (#31130, #31916)

- As a safety check, Bitcoin core will **fail to start** when
  `-blockreservedweight` init parameter value is lower than `2000` weight=
=20
units.
Bitcoin Core will also **fail to start** if the `-blockmaxweight` or
`-blockreservedweight` init parameter exceeds consensus limit of `4,000,000=
=20
WU`.

- Passing `-debug=3D0` or `-debug=3Dnone` now behaves like `-nodebug`:=20
previously
  set debug categories will be cleared, but subsequent `-debug` options wil=
l
still be applied.

- The default for `-rpcthreads` has been changed from 4 to 16, and the=20
default
  for `-rpcworkqueue` has been changed from 16 to 64. (#31215).

### Build System

The build system has been migrated from Autotools to CMake:

1. The minimum required CMake version is 3.22.
2. In-source builds are not allowed. When using a subdirectory within the=
=20
root
source tree as a build directory, it is recommended that its name includes=
=20
the
substring "build".
3. CMake variables may be used to configure the build system. **Some=20
defaults
have changed.** For example, you will now need to add `-DWITH_ZMQ=3DON` to=
=20
build
with zmq and `-DBUILD_GUI=3DON` to build `bitcoin-qt`. See [Autotools to CM=
ake
Options
Mapping](https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Autotools-to-=
CMake-Options-Mapping)
for details.
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`,=20
which has
not been extensively tested with Bitcoin Core. Therefore, the build system
replaces it with `-O2`.
5. By default, the built executables and libraries are located in the=20
`bin/` and
`lib/` subdirectories of the build directory.
6. The build system supports component=E2=80=90based installation. The name=
s of the
installable components coincide with the build target names. For example:=
=20
```
cmake -B build cmake --build build --target bitcoind cmake --install build
--component bitcoind ```

7. If any of the `CPPFLAGS`, `CFLAGS`, `CXXFLAGS` or `LDFLAGS` environment
variables were used in your Autotools-based build process, you should=20
instead
use the corresponding CMake variables (`APPEND_CPPFLAGS`, `APPEND_CFLAGS`,
`APPEND_CXXFLAGS` and `APPEND_LDFLAGS`). Alternatively, if you opt to use=
=20
the
dedicated `CMAKE_<...>_FLAGS` variables, you must ensure that the resulting
compiler or linker invocations are as expected.

For more detailed guidance on configuring and using CMake, please refer to=
=20
the
official [CMake documentation](https://cmake.org/cmake/help/latest/) and
[CMake=E2=80=99s User Interaction
Guide](https://cmake.org/cmake/help/latest/guide/user-interaction/index.htm=
l).
Additionally, consult platform-specific `doc/build-*.md` build guides for
instructions tailored to your operating system.

## Low-Level Changes

### Tools and Utilities

- A new tool
 =20
[`utxo_to_sqlite.py`](https://github.com/bitcoin/bitcoin/blob/v29.0/contrib=
/utxo-tools/utxo_to_sqlite.py)
converts a compact-serialized UTXO snapshot (as created with the=20
`dumptxoutset`
RPC) to a SQLite3 database. Refer to the script's `--help` output for more
details. (#27432)

### Tests

- The BIP94 timewarp attack mitigation (designed for testnet4) is no longer
  active on the regtest network. (#31156)

### Dependencies

- MiniUPnPc and libnatpmp have been removed as dependencies (#31130,=20
#30043).

Credits =3D=3D=3D=3D=3D=3D=3D

Thanks to everyone who directly contributed to this release:

- 0xb10c
- Adlai Chandrasekhar
- Afanti
- Alfonso Roman Zubeldia
- am-sq
- Andre
- Andre Alves
- Anthony Towns
- Antoine Poinsot
- Ash Manning
- Ava Chow
- Boris Nagaev
- Brandon Odiwuor
- brunoerg
- Chris Stewart
- Cory Fields
- costcould
- Daniel Pfeifer
- Daniela Brozzoni
- David Gumberg
- dergoegge
- epysqyli
- espi3
- Eval EXEC
- Fabian Jahr
- fanquake
- furszy
- Gabriele Bocchi
- glozow
- Greg Sanders
- Gutflo
- Hennadii Stepanov
- Hodlinator
- i-am-yuvi
- ion-
- ismaelsadeeq
- Jadi
- James O'Beirne
- Jeremy Rand
- Jon Atack
- jurraca
- Kay
- kevkevinpal
- l0rinc
- laanwj
- Larry Ruane
- L=C5=91rinc
- Maciej S. Szmigiero
- Mackain
- MarcoFalke
- marcofleon
- Marnix
- Martin Leitner-Ankerl
- Martin Saposnic
- Martin Zumsande
- Matthew Zipkin
- Max Edwards
- Michael Dietz
- naiyoma
- Nicola Leonardo Susca
- omahs
- pablomartin4btc
- Pieter Wuille
- Randall Naar
- RiceChuan
- rkrux
- Roman Zeyde
- Ryan Ofsky
- Sebastian Falbesoner
- secp512k2
- Sergi Delgado Segura
- Simon
- Sjors Provoost
- stickies-v
- Suhas Daftuar
- tdb3
- TheCharlatan
- tianzedavid
- Torkel Rogstad
- Vasil Dimov
- wgyt
- willcl-ark
- yancy

As well as to everyone that helped with translations on
[Transifex](https://www.transifex.com/bitcoin/bitcoin/).

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
7897498c-88ec-4c0f-b457-8410944e0ce1n%40googlegroups.com.

------=_Part_5655_34867969.1744679028150
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Bitcoin Core version 29.0 is now available from:<br /><br />=C2=A0 &lt;http=
s://bitcoincore.org/bin/bitcoin-core-29.0/&gt;<br /><br />This release incl=
udes new features, various bug fixes and performance<br />improvements, as =
well as updated translations.<br /><br />Please report bugs using the issue=
 tracker at GitHub:<br /><br />=C2=A0 &lt;https://github.com/bitcoin/bitcoi=
n/issues&gt;<br /><br />To receive security and update notifications, pleas=
e subscribe to:<br /><br />=C2=A0 &lt;https://bitcoincore.org/en/list/annou=
ncements/join/&gt;<br /><br />How to Upgrade<br />=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D<br /><br />If you are running an older version, shut it =
down. Wait until it has completely<br />shut down (which might take a few m=
inutes in some cases), then run the<br />installer (on Windows) or just cop=
y over `/Applications/Bitcoin-Qt` (on macOS)<br />or `bitcoind`/`bitcoin-qt=
` (on Linux).<br /><br />Upgrading directly from a version of Bitcoin Core =
that has reached its EOL is<br />possible, but it might take some time if t=
he data directory needs to be migrated. Old<br />wallet versions of Bitcoin=
 Core are generally supported.<br /><br />Compatibility<br />=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br /><br />Bitcoin Core is supported and tes=
ted on operating systems using the<br />Linux Kernel 3.17+, macOS 13+, and =
Windows 10+. Bitcoin<br />Core should also work on most other Unix-like sys=
tems but is not as<br />frequently tested on them. It is not recommended to=
 use Bitcoin Core on<br />unsupported systems.<br /><br />Notable changes<b=
r />=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br /><br />### P2P and Ne=
twork Changes<br /><br />- Support for UPnP was dropped. If you want to ope=
n a port automatically,<br />=C2=A0 consider using the `-natpmp` option ins=
tead, which uses PCP or NAT-PMP<br />depending on router support. (#31130)<=
br /><br />- libnatpmp was replaced with a built-in implementation of PCP a=
nd NAT-PMP<br />=C2=A0 (still enabled using the `-natpmp` option). This sup=
ports automatic IPv4 port<br />forwarding as well as IPv6 pinholing. (#3004=
3)<br /><br />- When the `-port` configuration option is used, the default =
onion listening<br />=C2=A0 port will now be derived to be that port + 1 in=
stead of being set to a fixed<br />value (8334 on mainnet). =C2=A0This re-a=
llows setups with multiple local nodes using<br />different `-port` and not=
 using `-bind`, which would lead to a startup failure<br />in v28.0 due to =
a port collision. =C2=A0Note that a `HiddenServicePort` manually<br />confi=
gured in `torrc` may need adjustment if used in connection with the `-port`=
<br />option. =C2=A0For example, if you are using `-port=3D5555` with a non=
-standard value<br />and not using `-bind=3D...=3Donion`, previously Bitcoi=
n Core would listen for<br />incoming Tor connections on `127.0.0.1:8334`. =
=C2=A0Now it would listen on<br />`127.0.0.1:5556` (`-port` plus one). If y=
ou configured the hidden service<br />manually in torrc now you have to cha=
nge it from `HiddenServicePort 8333<br />127.0.0.1:8334` to `HiddenServiceP=
ort 8333 127.0.0.1:5556`, or configure<br />bitcoind with `-bind=3D127.0.0.=
1:8334=3Donion` to get the previous behavior.<br />(#31223)<br /><br />- Up=
on receiving an orphan transaction (an unconfirmed transaction that spends<=
br />=C2=A0 unknown inputs), the node will attempt to download missing pare=
nts from all<br />peers who announced the orphan. This change may increase =
bandwidth usage but<br />make orphan-handling more reliable. (#31397)<br />=
<br />### Mempool Policy and Mining Changes<br /><br />- Ephemeral dust is =
a new concept that allows a single dust output in a<br />=C2=A0 transaction=
, provided the transaction is zero fee. In order to spend any<br />unconfir=
med outputs from this transaction, the spender must also spend this dust<br=
 />in addition to any other desired outputs. =C2=A0In other words, this typ=
e of<br />transaction should be created in a transaction package where the =
dust is both<br />created and spent simultaneously. (#30239)<br /><br />- D=
ue to a bug, the default block reserved weight (`4,000 WU`) for fixed-size<=
br />=C2=A0 block header, transactions count, and coinbase transaction was =
reserved twice<br />and could not be lowered. As a result the total reserve=
d weight was always<br />`8,000 WU`, meaning that even when specifying a `-=
blockmaxweight` higher than<br />the default (even to the max of `4,000,000=
 WU`), the actual block size will<br />never exceed `3,992,000 WU`. =C2=A0T=
he fix consolidates the reservation into a single<br />place and introduces=
 a new startup option, `-blockreservedweight` which<br />specifies the rese=
rved weight directly. The default value of<br />`-blockreservedweight` is s=
et to `8,000 WU` to ensure backward compatibility for<br />users who relied=
 on the previous behavior of `-blockmaxweight`. =C2=A0The minimum<br />valu=
e of `-blockreservedweight` is set to `2,000 WU`. Users setting<br />`-bloc=
kreservedweight` below the default should ensure that the total weight of<b=
r />their block header, transaction count, and coinbase transaction does no=
t exceed<br />the reduced value or they may risk mining an invalid block. (=
#31384)<br /><br />### Updated RPCs<br /><br />- The RPC `testmempoolaccept=
` response now includes a `reject-details` field in<br />=C2=A0 some cases,=
 similar to the complete error messages returned by<br />`sendrawtransactio=
n` (#28121)<br /><br />- Duplicate blocks submitted with `submitblock` will=
 now persist their block<br />=C2=A0 data even if it was previously pruned.=
 If pruning is activated, the data will<br />be pruned again eventually onc=
e the block file it is persisted in is selected<br />for pruning. This is c=
onsistent with the behaviour of `getblockfrompeer` where<br />the block is =
persisted as well even when pruning. (#31175)<br /><br />- `getmininginfo` =
now returns `nBits` and the current target in the `target`<br />=C2=A0 fiel=
d. It also returns a `next` object which specifies the `height`, `nBits`,<b=
r />`difficulty`, and `target` for the next block. (#31583)<br /><br />- `g=
etblock` and `getblockheader` now return the current target in the `target`=
<br />=C2=A0 field (#31583)<br /><br />- `getblockchaininfo` and `getchains=
tates` now return `nBits` and the current<br />=C2=A0 target in the `target=
` field (#31583)<br /><br />- the `getblocktemplate` RPC `curtime` (BIP22) =
and `mintime` (BIP23) fields now<br />=C2=A0 account for the timewarp fix p=
roposed in BIP94 on all networks. This ensures<br />that, in the event a ti=
mewarp fix softfork activates on mainnet, un-upgraded<br />miners will not =
accidentally violate the timewarp rule. (#31376, #31600) As a<br />reminder=
, it's important that any software which uses the `getblocktemplate` RPC<br=
 />takes these values into account (either `curtime` or `mintime` is fine).=
<br />Relying only on a clock can lead to invalid blocks under some circums=
tances,<br />especially once a timewarp fix is deployed. (#31600)<br /><br =
/>### New RPCs<br /><br />- `getdescriptoractivity` can be used to find all=
 spend/receive activity<br />=C2=A0 relevant to a given set of descriptors =
within a set of specified blocks. This<br />call can be used with `scanbloc=
ks` to lessen the need for additional indexing<br />programs. (#30708)<br /=
><br />### Updated REST APIs<br /><br />- `GET /rest/block/&lt;BLOCK-HASH&g=
t;.json` and `GET /rest/headers/&lt;BLOCK-HASH&gt;.json`<br />=C2=A0 now re=
turn the current target in the `target` field<br /><br />### Updated Settin=
gs<br /><br />- The maximum allowed value for the `-dbcache` configuration =
option has been<br />=C2=A0 dropped due to recent UTXO set growth. Note tha=
t before this change, large<br />`-dbcache` values were automatically reduc=
ed to 16 GiB (1 GiB on 32 bit<br />systems). (#28358)<br /><br />- Handling=
 of negated `-noseednode`, `-nobind`, `-nowhitebind`, `-norpcbind`,<br />=
=C2=A0 `-norpcallowip`, `-norpcwhitelist`, `-notest`, `-noasmap`, `-norpcwa=
llet`,<br />`-noonlynet`, and `-noexternalip` options has changed. Previous=
ly negating these<br />options had various confusing and undocumented side =
effects. Now negating them<br />just resets the settings and restores defau=
lt behaviors, as if the options were<br />not specified.<br /><br />- Start=
ing with v28.0, the `-mempoolfullrbf` startup option was set to default<br =
/>=C2=A0 to `1`. With widespread adoption of this policy, users no longer b=
enefit from<br />disabling it, so the option has been removed, making full =
replace-by-fee the<br />standard behavior. (#30592)<br /><br />- Setting `-=
upnp` will now log a warning and be interpreted as `-natpmp`.<br />=C2=A0 C=
onsider using `-natpmp` directly instead. (#31130, #31916)<br /><br />- As =
a safety check, Bitcoin core will **fail to start** when<br />=C2=A0 `-bloc=
kreservedweight` init parameter value is lower than `2000` weight units.<br=
 />Bitcoin Core will also **fail to start** if the `-blockmaxweight` or<br =
/>`-blockreservedweight` init parameter exceeds consensus limit of `4,000,0=
00 WU`.<br /><br />- Passing `-debug=3D0` or `-debug=3Dnone` now behaves li=
ke `-nodebug`: previously<br />=C2=A0 set debug categories will be cleared,=
 but subsequent `-debug` options will<br />still be applied.<br /><br />- T=
he default for `-rpcthreads` has been changed from 4 to 16, and the default=
<br />=C2=A0 for `-rpcworkqueue` has been changed from 16 to 64. (#31215).<=
br /><br />### Build System<br /><br />The build system has been migrated f=
rom Autotools to CMake:<br /><br />1. The minimum required CMake version is=
 3.22.<br />2. In-source builds are not allowed. When using a subdirectory =
within the root<br />source tree as a build directory, it is recommended th=
at its name includes the<br />substring "build".<br />3. CMake variables ma=
y be used to configure the build system. **Some defaults<br />have changed.=
** For example, you will now need to add `-DWITH_ZMQ=3DON` to build<br />wi=
th zmq and `-DBUILD_GUI=3DON` to build `bitcoin-qt`. See [Autotools to CMak=
e<br />Options<br />Mapping](https://github.com/bitcoin-core/bitcoin-devwik=
i/wiki/Autotools-to-CMake-Options-Mapping)<br />for details.<br />4. For si=
ngle-configuration generators, the default build configuration<br />(`CMAKE=
_BUILD_TYPE`) is "RelWithDebInfo". However, for the "Release"<br />configur=
ation, CMake defaults to the compiler optimization flag `-O3`, which has<br=
 />not been extensively tested with Bitcoin Core. Therefore, the build syst=
em<br />replaces it with `-O2`.<br />5. By default, the built executables a=
nd libraries are located in the `bin/` and<br />`lib/` subdirectories of th=
e build directory.<br />6. The build system supports component=E2=80=90base=
d installation. The names of the<br />installable components coincide with =
the build target names. For example: ```<br />cmake -B build cmake --build =
build --target bitcoind cmake --install build<br />--component bitcoind ```=
<br /><br />7. If any of the `CPPFLAGS`, `CFLAGS`, `CXXFLAGS` or `LDFLAGS` =
environment<br />variables were used in your Autotools-based build process,=
 you should instead<br />use the corresponding CMake variables (`APPEND_CPP=
FLAGS`, `APPEND_CFLAGS`,<br />`APPEND_CXXFLAGS` and `APPEND_LDFLAGS`). Alte=
rnatively, if you opt to use the<br />dedicated `CMAKE_&lt;...&gt;_FLAGS` v=
ariables, you must ensure that the resulting<br />compiler or linker invoca=
tions are as expected.<br /><br />For more detailed guidance on configuring=
 and using CMake, please refer to the<br />official [CMake documentation](h=
ttps://cmake.org/cmake/help/latest/) and<br />[CMake=E2=80=99s User Interac=
tion<br />Guide](https://cmake.org/cmake/help/latest/guide/user-interaction=
/index.html).<br />Additionally, consult platform-specific `doc/build-*.md`=
 build guides for<br />instructions tailored to your operating system.<br /=
><br />## Low-Level Changes<br /><br />### Tools and Utilities<br /><br />-=
 A new tool<br />=C2=A0 [`utxo_to_sqlite.py`](https://github.com/bitcoin/bi=
tcoin/blob/v29.0/contrib/utxo-tools/utxo_to_sqlite.py)<br />converts a comp=
act-serialized UTXO snapshot (as created with the `dumptxoutset`<br />RPC) =
to a SQLite3 database. Refer to the script's `--help` output for more<br />=
details. (#27432)<br /><br />### Tests<br /><br />- The BIP94 timewarp atta=
ck mitigation (designed for testnet4) is no longer<br />=C2=A0 active on th=
e regtest network. (#31156)<br /><br />### Dependencies<br /><br />- MiniUP=
nPc and libnatpmp have been removed as dependencies (#31130, #30043).<br />=
<br />Credits =3D=3D=3D=3D=3D=3D=3D<br /><br />Thanks to everyone who direc=
tly contributed to this release:<br /><br />- 0xb10c<br />- Adlai Chandrase=
khar<br />- Afanti<br />- Alfonso Roman Zubeldia<br />- am-sq<br />- Andre<=
br />- Andre Alves<br />- Anthony Towns<br />- Antoine Poinsot<br />- Ash M=
anning<br />- Ava Chow<br />- Boris Nagaev<br />- Brandon Odiwuor<br />- br=
unoerg<br />- Chris Stewart<br />- Cory Fields<br />- costcould<br />- Dani=
el Pfeifer<br />- Daniela Brozzoni<br />- David Gumberg<br />- dergoegge<br=
 />- epysqyli<br />- espi3<br />- Eval EXEC<br />- Fabian Jahr<br />- fanqu=
ake<br />- furszy<br />- Gabriele Bocchi<br />- glozow<br />- Greg Sanders<=
br />- Gutflo<br />- Hennadii Stepanov<br />- Hodlinator<br />- i-am-yuvi<b=
r />- ion-<br />- ismaelsadeeq<br />- Jadi<br />- James O'Beirne<br />- Jer=
emy Rand<br />- Jon Atack<br />- jurraca<br />- Kay<br />- kevkevinpal<br /=
>- l0rinc<br />- laanwj<br />- Larry Ruane<br />- L=C5=91rinc<br />- Maciej=
 S. Szmigiero<br />- Mackain<br />- MarcoFalke<br />- marcofleon<br />- Mar=
nix<br />- Martin Leitner-Ankerl<br />- Martin Saposnic<br />- Martin Zumsa=
nde<br />- Matthew Zipkin<br />- Max Edwards<br />- Michael Dietz<br />- na=
iyoma<br />- Nicola Leonardo Susca<br />- omahs<br />- pablomartin4btc<br /=
>- Pieter Wuille<br />- Randall Naar<br />- RiceChuan<br />- rkrux<br />- R=
oman Zeyde<br />- Ryan Ofsky<br />- Sebastian Falbesoner<br />- secp512k2<b=
r />- Sergi Delgado Segura<br />- Simon<br />- Sjors Provoost<br />- sticki=
es-v<br />- Suhas Daftuar<br />- tdb3<br />- TheCharlatan<br />- tianzedavi=
d<br />- Torkel Rogstad<br />- Vasil Dimov<br />- wgyt<br />- willcl-ark<br=
 />- yancy<br /><br />As well as to everyone that helped with translations =
on<br />[Transifex](https://www.transifex.com/bitcoin/bitcoin/).

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/7897498c-88ec-4c0f-b457-8410944e0ce1n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/7897498c-88ec-4c0f-b457-8410944e0ce1n%40googlegroups.com</a>.<br />

------=_Part_5655_34867969.1744679028150--

------=_Part_5654_529336910.1744679028150--