You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
`listsinceblock`, `gettransaction`, `walletcreatefundedpsbt`, and `fundrawtransaction`. (#16383)
138
-
139
-
-`listunspent` now returns a "reused" bool for each output if the
140
-
wallet flag "avoid_reuse" is enabled. (#13756)
141
-
142
-
-`getblockstats` now uses BlockUndo data instead of the transaction
143
-
index, making it much faster, no longer dependent on the `-txindex`
144
-
configuration option, and functional for all non-pruned blocks.
145
-
(#14802)
146
-
147
-
-`utxoupdatepsbt` now accepts a `descriptors` parameter that will fill
148
-
out input and output scripts and keys when known. P2SH-witness inputs
149
-
will be filled in from the UTXO set when a descriptor is provided that
150
-
shows they're spending segwit outputs. See the RPC help text for full
151
-
details. (#15427)
152
-
153
-
-`sendrawtransaction` and `testmempoolaccept` no longer accept a
154
-
`allowhighfees` parameter to fail mempool acceptance if the
155
-
transaction fee exceedes the value of the configuration option
156
-
`-maxtxfee`. Now there is a hardcoded default maximum feerate that
157
-
can be changed when calling either RPC using a `maxfeerate` parameter.
158
-
(#15620)
159
-
160
-
-`getmempoolancestors`, `getmempooldescendants`, `getmempoolentry`, and
161
-
`getrawmempool` no longer return a `size` field unless the
162
-
configuration option `-deprecatedrpc=size` is used. Instead a new
163
-
`vsize` field is returned with the transaction's virtual size
164
-
(consistent with other RPCs such as `getrawtransaction`). (#15637)
165
-
166
-
-`getwalletinfo` now includes a `scanning` field that is either `false`
167
-
(no scanning) or an object with information about the duration and
168
-
progress of the wallet's scanning historical blocks for transactions
169
-
affecting its balances. (#15730)
170
-
171
-
-`gettransaction` now accepts a third (boolean) argument `verbose`. If
172
-
set to `true`, a new `decoded` field will be added to the response containing
173
-
the decoded transaction. This field is equivalent to RPC `decoderawtransaction`,
174
-
or RPC `getrawtransaction` when `verbose` is passed.
175
-
176
-
-`createwallet` accepts a new `passphrase` parameter. If set, this
177
-
will create the new wallet encrypted with the given passphrase. If
178
-
unset (the default) or set to an empty string, no encryption will be
179
-
used. (#16394)
180
-
181
-
-`getchaintxstats` RPC now returns the additional key of
182
-
`window_final_block_height`.
183
-
184
-
-`getmempoolentry` now provides a `weight` field containing the
185
-
transaction weight as defined in BIP141. (#16647)
186
-
187
-
- The `getnetworkinfo` and `getpeerinfo` commands now contain a new field with decoded network service flags.
188
-
189
-
-`getdescriptorinfo` now returns an additional `checksum` field
190
-
containing the checksum for the unmodified descriptor provided by the
191
-
user (that is, before the descriptor is normalized for the
192
-
`descriptor` field). (#15986)
193
-
194
-
-`joinpsbts` will shuffle the order of the inputs and outputs of the resulting joined psbt.
195
-
Previously inputs and outputs were added in the order that the PSBTs were provided which makes correlating inputs to outputs extremely easy.
196
-
197
-
-`walletcreatefundedpsbt` now signals BIP125 Replace-by-Fee if the
198
-
`-walletrbf` configuration option is set to true. (#15911)
199
-
200
-
GUI changes
201
-
-----------
202
-
203
-
- Provides bech32 addresses by default. The user may change the address
204
-
during invoice generation using a GUI toggle, or the default address
205
-
type may be changed by the `-addresstype` configuration option.
206
-
(#15711, #16497)
207
-
208
-
- In 0.18.0 a `./configure` flag was introduced to allow disabling BIP70 support in the GUI (support was enabled by default). In 0.19.0 this flag is now __disabled__ by default.
209
-
- If you want compile Bitcoin Core with BIP70 support in the GUI, you can pass `--enable-bip70` to `./configure`.
210
-
211
-
Deprecated or removed configuration options
212
-
-------------------------------------------
213
-
214
-
-`-mempoolreplacement` is removed, although default node behavior
215
-
remains the same. This option previously allowed the user to prevent
216
-
the node from accepting or relaying BIP125 transaction replacements.
217
-
This is different from the remaining configuration option
218
-
`-walletrbf`. (#16171)
219
-
220
-
Deprecated or removed RPCs
221
-
--------------------------
222
-
223
-
-`bumpfee` no longer accepts a `totalFee` option unless the
224
-
configuration parameter `deprecatedrpc=totalFee` is specified. This
225
-
parameter will be fully removed in a subsequent release. (#15996)
226
-
227
-
-`generate` is now removed after being deprecated in Bitcoin Core 0.18.
228
-
Use the `generatetoaddress` RPC instead. (#15492)
229
-
230
-
P2P changes
231
-
-----------
232
-
233
-
- BIP 61 reject messages were deprecated in v0.18. They are now disabled
234
-
by default, but can be enabled by setting the `-enablebip61` command
235
-
line option. BIP 61 reject messages will be removed entirely in a
236
-
future version of Bitcoin Core. (#14054)
237
-
238
-
- To eliminate well-known denial-of-service vectors in Bitcoin Core,
239
-
especially for nodes with spinning disks, the default value for the
240
-
`-peerbloomfilters` configuration option has been changed to false.
241
-
This prevents Bitcoin Core from sending the BIP111 NODE_BLOOM service
242
-
flag, accepting BIP37 bloom filters, or serving merkle blocks or
243
-
transactions matching a bloom filter. Users who still want to provide
244
-
bloom filter support may either set the configuration option to true
245
-
to re-enable both BIP111 and BIP37 support or enable just BIP37
246
-
support for specific peers using the updated `-whitelist` and
247
-
`-whitebind` configuration options described elsewhere in these
248
-
release notes. For the near future, lightweight clients using public
249
-
BIP111/BIP37 nodes should still be able to connect to older versions
250
-
of Bitcoin Core and nodes that have manually enabled BIP37 support,
251
-
but developers of such software should consider migrating to either
252
-
using specific BIP37 nodes or an alternative transaction filtering
253
-
system. (#16152)
254
-
255
-
Miscellaneous CLI Changes
256
-
-------------------------
257
-
258
-
- The `testnet` field in `bitcoin-cli -getinfo` has been renamed to
259
-
`chain` and now returns the current network name as defined in BIP70
260
-
(main, test, regtest). (#15566)
261
-
262
-
Low-level changes
263
-
=================
264
-
265
-
RPC
266
-
---
267
-
268
-
-`getblockchaininfo` no longer returns a `bip9_softforks` object.
269
-
Instead, information has been moved into the `softforks` object and
270
-
an additional `type` field describes how Bitcoin Core determines
271
-
whether that soft fork is active (e.g. BIP9 or BIP90). See the RPC
272
-
help for details. (#16060)
273
-
274
-
-`getblocktemplate` no longer returns a `rules` array containing `CSV`
275
-
and `segwit` (the BIP9 deployments that are currently in active
276
-
state). (#16060)
277
-
278
-
-`getrpcinfo` now returns a `logpath` field with the path to
279
-
`debug.log`. (#15483)
280
-
281
-
Tests
282
-
-----
283
-
284
-
- The regression test chain enabled by the `-regtest` command line flag
285
-
now requires transactions to not violate standard policy by default.
286
-
This is the same default used for mainnet and makes it easier to test
287
-
mainnet behavior on regtest. Note that the testnet still allows
288
-
non-standard txs by default and that the policy can be locally
289
-
adjusted with the `-acceptnonstdtxn` command line flag for both test
290
-
chains. (#15891)
291
-
292
-
Configuration
293
-
------------
294
-
295
-
- A setting specified in the default section but not also specified in a
296
-
network-specific section (e.g. testnet) will now produce an error
297
-
preventing startup instead of just a warning unless the network is
298
-
mainnet. This prevents settings intended for mainnet from being
299
-
applied to testnet or regtest. (#15629)
300
-
301
-
- On platforms supporting `thread_local`, log lines can be prefixed with
302
-
the name of the thread that caused the log. To enable this behavior,
303
-
use `-logthreadnames=1`. (#15849)
304
-
305
-
Network
306
-
-------
307
-
308
-
- When fetching a transaction announced by multiple peers, previous versions of
309
-
Bitcoin Core would sequentially attempt to download the transaction from each
310
-
announcing peer until the transaction is received, in the order that those
311
-
peers' announcements were received. In this release, the download logic has
312
-
changed to randomize the fetch order across peers and to prefer sending
313
-
download requests to outbound peers over inbound peers. This fixes an issue
314
-
where inbound peers could prevent a node from getting a transaction.
315
-
(#14897, #15834)
316
-
317
-
- If a Tor hidden service is being used, Bitcoin Core will be bound to
318
-
the standard port 8333 even if a different port is configured for
319
-
clearnet connections. This prevents leaking node identity through use
320
-
of identical non-default port numbers. (#15651)
321
-
322
-
Mempool and transaction relay
323
-
-----------------------------
324
-
325
-
- Allows one extra single-ancestor transaction per package. Previously,
326
-
if a transaction in the mempool had 25 descendants, or it and all of
327
-
its descendants were over 101,000 vbytes, any newly-received
328
-
transaction that was also a descendant would be ignored. Now, one
329
-
extra descendant will be allowed provided it is an immediate
330
-
descendant (child) and the child's size is 10,000 vbytes or less.
331
-
This makes it possible for two-party contract protocols such as
332
-
Lightning Network to give each participant an output they can spend
333
-
immediately for Child-Pays-For-Parent (CPFP) fee bumping without
334
-
allowing one malicious participant to fill the entire package and thus
335
-
prevent the other participant from spending their output. (#15681)
336
-
337
-
- Transactions with outputs paying v1 to v16 witness versions (future
338
-
segwit versions) are now accepted into the mempool, relayed, and
339
-
mined. Attempting to spend those outputs remains forbidden by policy
340
-
("non-standard"). When this change has been widely deployed, wallets
341
-
and services can accept any valid bech32 Bitcoin address without
342
-
concern that transactions paying future segwit versions will become
343
-
stuck in an unconfirmed state. (#15846)
344
-
345
-
- Legacy transactions (transactions with no segwit inputs) must now be
346
-
sent using the legacy encoding format, enforcing the rule specified in
347
-
BIP144. (#14039)
348
-
349
-
Wallet
350
-
------
351
-
352
-
- When in pruned mode, a rescan that was triggered by an `importwallet`,
353
-
`importpubkey`, `importaddress`, or `importprivkey` RPC will only fail
354
-
when blocks have been pruned. Previously it would fail when `-prune`
355
-
has been set. This change allows setting `-prune` to a high value
356
-
(e.g. the disk size) without the calls to any of the import RPCs
357
-
failing until the first block is pruned. (#15870)
358
-
359
-
- When creating a transaction with a fee above `-maxtxfee` (default 0.1
360
-
BTC), the RPC commands `walletcreatefundedpsbt` and
361
-
`fundrawtransaction` will now fail instead of rounding down the fee.
362
-
Be aware that the `feeRate` argument is specified in BTC per 1,000
363
-
vbytes, not satoshi per vbyte. (#16257)
364
-
365
-
- A new wallet flag `avoid_reuse` has been added (default off). When
366
-
enabled, a wallet will distinguish between used and unused addresses,
367
-
and default to not use the former in coin selection. When setting
368
-
this flag on an existing wallet, rescanning the blockchain is required
369
-
to correctly mark previously used destinations. Together with "avoid
370
-
partial spends" (added in Bitcoin Core v0.17.0), this can eliminate a
371
-
serious privacy issue where a malicious user can track spends by
372
-
sending small payments to a previously-paid address that would then
373
-
be included with unrelated inputs in future payments. (#13756)
374
-
375
-
Build system changes
376
-
--------------------
377
-
378
-
- Python >=3.5 is now required by all aspects of the project. This
379
-
includes the build systems, test framework and linters. The previously
380
-
supported minimum (3.4), was EOL in March 2019. (#14954)
381
-
382
-
- The minimum supported miniUPnPc API version is set to 10. This keeps
383
-
compatibility with Ubuntu 16.04 LTS and Debian 8 `libminiupnpc-dev`
384
-
packages. Please note, on Debian this package is still vulnerable to
0 commit comments