Inside Bitcoin

1v30.0 Release Notes
2===================
3
4Bitcoin Core version v30.0 is now available from:
5
6  <https://bitcoincore.org/bin/bitcoin-core-30.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 macOS)
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 tested on operating systems using the
35Linux Kernel 3.17+, macOS 13+, and Windows 10+. 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
43Policy
44------
45
46- The maximum number of potentially executed legacy signature operations in a
47  single standard transaction is now limited to 2500. Signature operations in all
48  previous output scripts, in all input scripts, as well as all P2SH redeem
49  scripts (if there are any) are counted toward the limit. The new limit is
50  assumed to not affect any known typically formed standard transactions. The
51  change was done to prepare for a possible BIP54 deployment in the future. (#32521)
52
53- `-datacarriersize` is increased to 100,000 by default, which effectively uncaps
54  the limit (as the maximum transaction size limit will be hit first). It can be
55  overridden with `-datacarriersize=83` to revert to the limit enforced in previous
56  versions. (#32406)
57
58- Multiple data carrier (OP_RETURN) outputs in a transaction are now permitted for
59  relay and mining. The `-datacarriersize` limit applies to the aggregate size of
60  the scriptPubKeys across all such outputs in a transaction, not including the
61  scriptPubKey size itself. (#32406)
62
63- The minimum block feerate (`-blockmintxfee`) has been changed to 0.001 satoshi per
64  vB. It can still be changed using the configuration option. This option can be used
65  by miners to set a minimum feerate on packages added to block templates. (#33106)
66
67- The default minimum relay feerate (`-minrelaytxfee`) and incremental relay feerate
68  (`-incrementalrelayfee`) have been changed to 0.1 satoshis per vB. They can still
69  be changed using their respective configuration options, but it is recommended to
70  change both together if you decide to do so. (#33106)
71
72  Other minimum feerates (e.g. the dust feerate, the minimum returned by the fee
73  estimator, and all feerates used by the wallet) remain unchanged. The mempool minimum
74  feerate still changes in response to high volume.
75
76  Note that unless these lower defaults are widely adopted across the network, transactions
77  created with lower fee rates are not guaranteed to propagate or confirm. The wallet
78  feerates remain unchanged; `-mintxfee` must be changed before attempting to create
79  transactions with lower feerates using the wallet. (#33106)
80
81P2P and network changes
82-----------------------
83
84- Opportunistic 1-parent-1-child package relay has been improved to handle
85  situations when the child already has unconfirmed parent(s) in the mempool.
86  This means that 1p1c packages can be accepted and propagate, even if they are
87  connected to broader topologies: multi-parent-1-child (where only 1 parent
88  requires fee-bumping), grandparent-parent-child (where only parent requires
89  fee-bumping) etc. (#31385)
90
91- The transaction orphanage, which holds transactions with missing inputs temporarily
92  while the node attempts to fetch its parents, now has improved Denial of Service protections.
93  Previously, it enforced a maximum number of unique transactions (default 100,
94  configurable using `-maxorphantx`). Now, its limits are as follows: the number of
95  entries (unique by wtxid and peer), plus each unique transaction's input count divided
96  by 10, must not exceed 3,000. The total weight of unique transactions must not exceed
97  `404,000` Wu multiplied by the number of peers. (#31829)
98
99- The `-maxorphantx` option no longer has any effect, since the orphanage no longer
100  limits the number of unique transactions. Users should remove this configuration
101  option if they were using it, as the setting will cause an error in future versions
102  when it is no longer recognized. (#31829)
103
104New `bitcoin` command
105---------------------
106
107- A new `bitcoin` command line tool has been added to make features more discoverable
108  and convenient to use. The `bitcoin` tool just calls other executables and does not
109  implement any functionality on its own. Specifically `bitcoin node` is a synonym for
110  `bitcoind`, `bitcoin gui` is a synonym for `bitcoin-qt`, and `bitcoin rpc` is a synonym
111  for `bitcoin-cli -named`. Other commands and options can be listed with `bitcoin help`.
112  The new `bitcoin` command is an alternative to calling other commands directly, but it
113  doesn't replace them, and there are no plans to deprecate existing commands. (#31375)
114
115External Signing
116----------------
117
118- Support for external signing on Windows has been re-enabled. (#29868)
119
120IPC Mining Interface
121--------------------
122
123- The new `bitcoin` command does support one new feature: an (experimental) IPC Mining
124  Interface that allows the node to work with Stratum v2 or other mining client software,
125  see (#31098). When the node is started with `bitcoin -m node -ipcbind=unix` it will
126  listen on a unix socket for IPC client connections, allowing clients to request block
127  templates and submit mined blocks. The `-m` option launches a new internal binary
128  (`bitcoin-node` instead of `bitcoind`) and is currently required but will become optional
129  in the future (with [#33229](https://github.com/bitcoin/bitcoin/pull/33229)).
130
131- IPC connectivity introduces new dependencies (see [multiprocess.md](https://github.com/bitcoin/bitcoin/blob/master/doc/multiprocess.md)),
132  which can be turned off with the `-DENABLE_IPC=OFF` build option if you do not intend
133  to use IPC. (#31802)
134
135Install changes
136---------------
137
138- The `test_bitcoin` executable is now installed in `libexec/` instead of `bin/`.
139  It can still be executed directly, or accessed through the new `bitcoin` command
140  as `bitcoin test`. The `libexec/` directory also contains new `bitcoin-node` and
141  `bitcoin-gui` binaries which support IPC features and are called through the
142  `bitcoin` tool. In source builds only, `test_bitcoin-qt`, `bench_bitcoin`, and
143  `bitcoin-chainstate` are also now installed to `libexec/` instead of `bin/` and
144  can be accessed through the new `bitcoin` command. See `bitcoin help` output for
145  details. (#31679)
146
147- On Windows, the installer no longer adds a “(64-bit)” suffix to entries in the
148  Start Menu (#32132), and it now automatically removes obsolete artifacts during
149  upgrades (#33422).
150
151Indexes
152-------
153
154- The implementation of coinstatsindex was changed to prevent an overflow bug that
155  could already be observed on the default Signet. The new version of the index will
156  need to be synced from scratch when starting the upgraded node for the first time.
157
158  The new version is stored in `/indexes/coinstatsindex/` in contrast to the old version
159  which was stored at `/indexes/coinstats/`. The old version of the index is not deleted
160  by the upgraded node in case the user chooses to downgrade their node in the future.
161  If the user does not plan to downgrade it is safe for them to remove `/indexes/coinstats/`
162  from their datadir. A future release of Bitcoin Core may remove the old version of the
163  index automatically. (#30469)
164
165Logging
166-------
167- Unconditional logging to disk is now rate limited by giving each source location
168  a quota of 1MiB per hour. Unconditional logging is any logging with a log level
169  higher than debug, that is `info`, `warning`, and `error`. All logs will be
170  prefixed with `[*]` if there is at least one source location that is currently
171  being suppressed. (#32604)
172
173- When `-logsourcelocations` is enabled, the log output now contains the entire
174  function signature instead of just the function name. (#32604)
175
176Updated RPCs
177------------
178
179- The `-paytxfee` startup option and the `settxfee` RPC are now deprecated and
180  will be removed in Bitcoin Core 31.0. They allowed the user to set a static fee
181  rate for wallet transactions, which could potentially lead to overpaying or underpaying.
182  Users should instead rely on fee estimation or specify a fee rate per transaction
183  using the `fee_rate` argument in RPCs such as `fundrawtransaction`, `sendtoaddress`,
184  `send`, `sendall`, and `sendmany`. (#31278)
185
186- Any RPC in which one of the parameters is a descriptor will throw an error
187  if the provided descriptor contains a whitespace at the beginning or the end
188  of the public key within a fragment - e.g. `pk( KEY)` or `pk(KEY )`. (#31603)
189
190- The `submitpackage` RPC, which allows submissions of child-with-parents
191  packages, no longer requires that all unconfirmed parents be present. The
192  package may contain other in-mempool ancestors as well. (#31385)
193
194- The `waitfornewblock` RPC now takes an optional `current_tip` argument. It
195  is also no longer hidden. (#30635)
196
197- The `waitforblock` and `waitforblockheight` RPCs are no longer hidden.  (#30635)
198
199- The `psbtbumpfee` and `bumpfee` RPCs allow a replacement under fullrbf and no
200  longer require BIP-125 signalling. (#31953)
201
202- Transaction Script validation errors used to return the reason for the error
203  prefixed by either `mandatory-script-verify-flag-failed` if it was a consensus
204  error, or `non-mandatory-script-verify-flag` (without "-failed") if it was a
205  standardness error. This has been changed to `block-script-verify-flag-failed`
206  and `mempool-script-verify-flag-failed` for all block and mempool errors
207  respectively. (#33183)
208
209- The `getmininginfo` RPC now returns "blockmintxfee" result specifying the value of
210  `-blockmintxfee` configuration. (#33189)
211
212- The `getmempoolinfo` RPC now returns an additional "permitbaremultisig" and
213  "maxdatacarriersize" field, reflecting the `-permitbaremultisig` and `-datacarriersize`
214  config values. (#29954)
215
216Changes to wallet-related RPCs can be found in the Wallet section below.
217
218New RPCs
219--------
220
221- A new REST API endpoint (`/rest/spenttxouts/BLOCKHASH`) has been introduced for
222  efficiently fetching spent transaction outputs using the block's undo data (#32540).
223
224Build System
225------------
226
227Updated settings
228----------------
229
230- The `-maxmempool` and `-dbcache` startup parameters are now capped on 32-bit systems
231  to 500MB and 1GiB respectively. (#32530)
232
233- The `-natpmp` option is now set to `1` by default. This means nodes with `-listen`
234  enabled (the default) but running behind a firewall, such as a local network router,
235  will be reachable if the firewall/router supports any of the `PCP` or `NAT-PMP`
236  protocols. (#33004)
237
238- The `-upnp` setting has now been fully removed. Use `-natpmp` instead. (#32500)
239
240- Previously, `-proxy` specified the proxy for all networks (except I2P which
241  uses `-i2psam`) and only the Tor proxy could have been specified separately
242  via `-onion`. Now, the syntax of `-proxy` has been extended and it is possible
243  to specify separately the proxy for IPv4, IPv6, Tor and CJDNS by appending `=`
244  followed by the network name, for example `-proxy=127.0.0.1:5555=ipv6`
245  configures a proxy only for IPv6. The `-proxy` option can be used multiple
246  times to define different proxies for different networks, such as
247  `-proxy=127.0.0.1:4444=ipv4 -proxy=10.0.0.1:6666=ipv6`. Later settings
248  override earlier ones for the same network; this can be used to remove an
249  earlier all-networks proxy and use direct connections only for a given
250  network, for example `-proxy=127.0.0.1:5555 -proxy=0=cjdns`. (#32425)