Release notes: edit previously-detached notes
This commit is contained in:
parent
e7415a5a95
commit
7e1634a927
1 changed files with 112 additions and 121 deletions
|
@ -70,10 +70,14 @@ New RPCs
|
|||
- `getbalances` returns an object with all balances (`mine`,
|
||||
`untrusted_pending` and `immature`). Please refer to the RPC help of
|
||||
`getbalances` for details. The new RPC is intended to replace
|
||||
`getunconfirmedbalance` and the balance fields in `getwalletinfo`, as well as
|
||||
`getbalance`. The old calls may be removed in a future version.
|
||||
`getbalance`, `getunconfirmedbalance`, and the balance fields in
|
||||
`getwalletinfo`. These old calls and fields may be removed in a
|
||||
future version. (#15930, #16239)
|
||||
|
||||
- A new `setwalletflag` RPC sets/unsets flags for an existing wallet.
|
||||
- `setwalletflag` sets and unsets wallet flags that enable or disable
|
||||
features specific to that existing wallet, such as the new
|
||||
`avoid_reuse` feature documented elsewhere in these release notes.
|
||||
(#13756)
|
||||
|
||||
Updated RPCs
|
||||
------------
|
||||
|
@ -81,82 +85,68 @@ Updated RPCs
|
|||
Note: some low-level RPC changes mainly useful for testing are described in the
|
||||
Low-level Changes section below.
|
||||
|
||||
- The `sendmany` RPC had an argument `minconf` that was not well specified and
|
||||
would lead to RPC errors even when the wallet's coin selection would succeed.
|
||||
The `sendtoaddress` RPC never had this check, so to normalize the behavior,
|
||||
`minconf` is now ignored in `sendmany`. If the coin selection does not
|
||||
succeed due to missing coins, it will still throw an RPC error. Be reminded
|
||||
that coin selection is influenced by the `-spendzeroconfchange`,
|
||||
`-limitancestorcount`, `-limitdescendantcount` and `-walletrejectlongchains`
|
||||
command line arguments.
|
||||
- `sendmany` no longer has a `minconf` argument. This argument was not
|
||||
well specified and would lead to RPC errors even when the wallet's
|
||||
coin selection succeeded. Users who want to influence coin selection
|
||||
can use the existing `-spendzeroconfchange`, `-limitancestorcount`,
|
||||
`-limitdescendantcount` and `-walletrejectlongchains` configuration
|
||||
arguments. (#15596)
|
||||
|
||||
- Several RPCs have been updated to include an "avoid_reuse" flag, used
|
||||
to control whether already used addresses should be left out or
|
||||
included in the operation. These include:
|
||||
- `getbalance` and `sendtoaddress`, plus the new RPCs `getbalances` and
|
||||
`createwallet`, now accept an "avoid_reuse" parameter that controls
|
||||
whether already used addresses should be included in the operation.
|
||||
Additionally, `sendtoaddress` will avoid partial spends when
|
||||
`avoid_reuse` is enabled even if this feature is not already enabled
|
||||
via the `-avoidpartialspends` command line flag because not doing so
|
||||
would risk using up the "wrong" UTXO for an address reuse case.
|
||||
(#13756)
|
||||
|
||||
- createwallet
|
||||
- getbalance
|
||||
- getbalances
|
||||
- sendtoaddress
|
||||
- `listunspent` now returns a "reused" bool for each output if the
|
||||
wallet flag "avoid_reuse" is enabled. (#13756)
|
||||
|
||||
In addition, `sendtoaddress` has been changed to avoid partial spends
|
||||
when `avoid_reuse` is enabled (if not already enabled via the
|
||||
`-avoidpartialspends` command line flag), as it would otherwise risk
|
||||
using up the "wrong" UTXO for an address reuse case.
|
||||
- `getblockstats` now uses BlockUndo data instead of the transaction
|
||||
index, making it much faster, no longer dependent on the `-txindex`
|
||||
configuration option, and functional for all non-pruned blocks.
|
||||
(#14802)
|
||||
|
||||
The listunspent RPC has also been updated to now include a "reused"
|
||||
bool, for nodes with "avoid_reuse" enabled.
|
||||
- `utxoupdatepsbt` now accepts a `descriptors` parameter that will fill
|
||||
out input and output scripts and keys when known. P2SH-witness inputs
|
||||
will be filled in from the UTXO set when a descriptor is provided that
|
||||
shows they're spending segwit outputs. See the RPC help text for full
|
||||
details. (#15427)
|
||||
|
||||
- The `getblockstats` RPC is faster for fee calculation by using
|
||||
BlockUndo data. Also , `-txindex` is no longer required and
|
||||
`getblockstats` works for all non-pruned blocks.
|
||||
- `sendrawtransaction` and `testmempoolaccept` no longer accept a
|
||||
`allowhighfees` parameter to fail mempool acceptance if the
|
||||
transaction fee exceedes the value of the configuration option
|
||||
`-maxtxfee`. Now there is a hardcoded default maximum feerate that
|
||||
can be changed when calling either RPC using a `maxfeerate` parameter.
|
||||
(#15620)
|
||||
|
||||
- `createwallet` can now create encrypted wallets if a non-empty
|
||||
passphrase is specified.
|
||||
- `getmempoolancestors`, `getmempooldescendants`, `getmempoolentry`, and
|
||||
`getrawmempool` no longer return a `size` field unless the
|
||||
configuration option `-deprecatedrpc=size` is used. Instead a new
|
||||
`vsize` field is returned with the transaction's virtual size
|
||||
(consistent with other RPCs such as `getrawtransaction`). (#15637)
|
||||
|
||||
- The `utxoupdatepsbt` RPC method has been updated to take a
|
||||
`descriptors` argument. When provided, input and output scripts and
|
||||
keys will be filled in when known, and P2SH-witness inputs will be
|
||||
filled in from the UTXO set when a descriptor is provided that shows
|
||||
they're spending segwit outputs.
|
||||
- `getwalletinfo` now includes a `scanning` field that is either `false`
|
||||
(no scanning) or an object with information about the duration and
|
||||
progress of the wallet's scanning historical blocks for transactions
|
||||
affecting its balances. (#15730)
|
||||
|
||||
See the RPC help text for full details.
|
||||
|
||||
- The -maxtxfee setting no longer has any effect on non-wallet RPCs.
|
||||
|
||||
The `sendrawtransaction` and `testmempoolaccept` RPC methods previously
|
||||
accepted an `allowhighfees` parameter to fail the mempool acceptance in case
|
||||
the transaction's fee would exceed the value of the command line argument
|
||||
`-maxtxfee`. To uncouple the RPCs from the global option, they now have a
|
||||
hardcoded default for the maximum transaction fee, that can be changed for
|
||||
both RPCs on a per-call basis with the `maxfeerate` parameter. The
|
||||
`allowhighfees` boolean option has been removed and replaced by the
|
||||
`maxfeerate` numeric option.
|
||||
|
||||
- In getmempoolancestors, getmempooldescendants, getmempoolentry and
|
||||
getrawmempool RPCs, to be consistent with the returned value and other
|
||||
RPCs such as getrawtransaction, vsize has been added and size is now
|
||||
deprecated. size will only be returned if bitcoind is started with
|
||||
`-deprecatedrpc=size`.
|
||||
|
||||
- The RPC `getwalletinfo` response now includes the `scanning` key with
|
||||
an object if there is a scanning in progress or `false` otherwise.
|
||||
Currently the object has the scanning duration and progress.
|
||||
|
||||
- `createwallet` now returns a warning if an empty string is used as an
|
||||
encryption password, and does not encrypt the wallet, instead of
|
||||
raising an error. This makes it easier to disable encryption but also
|
||||
specify other options when using the `bitcoin-cli` tool.
|
||||
- `createwallet` accepts a new `passphrase` parameter. If set, this
|
||||
will create the new wallet encrypted with the given passphrase. If
|
||||
unset (the default) or set to an empty string, no encryption will be
|
||||
used. (#16394)
|
||||
|
||||
- `getmempoolentry` now provides a `weight` field containing the
|
||||
transaction weight as defined in BIP 141.
|
||||
transaction weight as defined in BIP141. (#16647)
|
||||
|
||||
Deprecated or removed RPCs
|
||||
--------------------------
|
||||
|
||||
- The `totalFee` option of the `bumpfee` RPC has been deprecated and will be
|
||||
removed in 0.20. To continue using this option start with
|
||||
`-deprecatedrpc=totalFee`. See the `bumpfee` RPC help text for more details.
|
||||
- `bumpfee` no longer accepts a `totalFee` option unless the
|
||||
configuration parameter `deprecatedrpc=totalFee` is specified. This
|
||||
parameter will be fully removed in a subsequent release. (#15996)
|
||||
|
||||
P2P changes
|
||||
-----------
|
||||
|
@ -164,23 +154,31 @@ P2P changes
|
|||
- BIP 61 reject messages were deprecated in v0.18. They are now disabled
|
||||
by default, but can be enabled by setting the `-enablebip61` command
|
||||
line option. BIP 61 reject messages will be removed entirely in a
|
||||
future version of Bitcoin Core.
|
||||
future version of Bitcoin Core. (#14054)
|
||||
|
||||
- The default value for the -peerbloomfilters configuration option (and,
|
||||
thus, NODE_BLOOM support) has been changed to false. This resolves
|
||||
well-known DoS vectors in Bitcoin Core, especially for nodes with
|
||||
spinning disks. It is not anticipated that this will result in a
|
||||
significant lack of availability of NODE_BLOOM-enabled nodes in the
|
||||
coming years, however, clients which rely on the availability of
|
||||
NODE_BLOOM-supporting nodes on the P2P network should consider the
|
||||
process of migrating to a more modern (and less trustful and
|
||||
privacy-violating) alternative over the coming years.
|
||||
- To eliminate well-known denial-of-service vectors in Bitcoin Core,
|
||||
especially for nodes with spinning disks, the default value for the
|
||||
`-peerbloomfilters` configuration option has been changed to false.
|
||||
This prevents Bitcoin Core from sending the BIP111 NODE_BLOOM service
|
||||
flag, accepting BIP37 bloom filters, or serving merkle blocks or
|
||||
transactions matching a bloom filter. Users who still want to provide
|
||||
bloom filter support may either set the configuration option to true
|
||||
to re-enable both BIP111 and BIP37 support or enable just BIP37
|
||||
support for specific peers using the updated `-whitelist` and
|
||||
`-whitebind` configuration options described elsewhere in these
|
||||
release notes. For the near future, lightweight clients using public
|
||||
BIP111/BIP37 nodes should still be able to connect to older versions
|
||||
of Bitcoin Core and nodes that have manually enabled BIP37 support,
|
||||
but developers of such software should consider migrating to either
|
||||
using specific BIP37 nodes or an alternative transaction filtering
|
||||
system. (#16152)
|
||||
|
||||
Miscellaneous CLI Changes
|
||||
-------------------------
|
||||
|
||||
- The `testnet` field in `bitcoin-cli -getinfo` has been renamed to
|
||||
`chain` and now returns the current network name as defined in BIP70
|
||||
(main, test, regtest).
|
||||
(main, test, regtest). (#15566)
|
||||
|
||||
Low-level changes
|
||||
=================
|
||||
|
@ -188,43 +186,39 @@ Low-level changes
|
|||
RPC
|
||||
---
|
||||
|
||||
- Soft fork reporting in the `getblockchaininfo` return object has been
|
||||
updated. For full details, see the RPC help text. In summary:
|
||||
|
||||
- The `bip9_softforks` sub-object is no longer returned
|
||||
- The `softforks` sub-object now returns an object keyed by soft fork name,
|
||||
rather than an array
|
||||
- Each softfork object in the `softforks` object contains a `type`
|
||||
value which is either `buried` (for soft fork deployments where the
|
||||
activation height is hard-coded into the client implementation), or
|
||||
`bip9` (for soft fork deployments where activation is controlled by
|
||||
BIP 9 signaling).
|
||||
- `getblockchaininfo` no longer returns a `bip9_softforks` object.
|
||||
Instead, information has been moved into the `softforks` object and
|
||||
an additional `type` field describes how Bitcoin Core determines
|
||||
whether that soft fork is active (e.g. BIP9 or BIP90). See the RPC
|
||||
help for details. (#16060)
|
||||
|
||||
- `getblocktemplate` no longer returns a `rules` array containing `CSV`
|
||||
and `segwit` (the BIP 9 deployments that are currently in active
|
||||
state).
|
||||
and `segwit` (the BIP9 deployments that are currently in active
|
||||
state). (#16060)
|
||||
|
||||
Tests
|
||||
-----
|
||||
|
||||
- The regression test chain, that can be enabled by the `-regtest` command line
|
||||
flag, now requires transactions to not violate standard policy by default.
|
||||
Making the default the same as for mainnet, makes it easier to test mainnet
|
||||
behavior on regtest. Be reminded that the testnet still allows non-standard
|
||||
txs by default and that the policy can be locally adjusted with the
|
||||
`-acceptnonstdtxn` command line flag for both test chains.
|
||||
- The regression test chain enabled by the `-regtest` command line flag
|
||||
now requires transactions to not violate standard policy by default.
|
||||
This is the same default used for mainnet and makes it easier to test
|
||||
mainnet behavior on regtest. Note that the testnet still allows
|
||||
non-standard txs by default and that the policy can be locally
|
||||
adjusted with the `-acceptnonstdtxn` command line flag for both test
|
||||
chains. (#15891)
|
||||
|
||||
Configuration
|
||||
------------
|
||||
|
||||
- An error is issued where previously a warning was issued when a setting in
|
||||
the config file was specified in the default section, but not overridden for
|
||||
the selected network. This change takes only effect if the selected network
|
||||
is not mainnet.
|
||||
- A setting specified in the default section but not also specified in a
|
||||
network-specific section (e.g. testnet) will now produce a error
|
||||
preventing startup instead of just a warning unless the network is
|
||||
mainnet. This prevents settings intended for mainnet from being
|
||||
applied to testnet or regtest. (#15629)
|
||||
|
||||
- On platforms supporting `thread_local`, log lines can be prefixed with
|
||||
the name of the thread that caused the log. To enable this behavior,
|
||||
use `-logthreadnames=1`.
|
||||
use `-logthreadnames=1`. (#15849)
|
||||
|
||||
Network
|
||||
-------
|
||||
|
@ -235,44 +229,41 @@ Network
|
|||
peers' announcements were received. In this release, the download logic has
|
||||
changed to randomize the fetch order across peers and to prefer sending
|
||||
download requests to outbound peers over inbound peers. This fixes an issue
|
||||
where inbound peers can prevent a node from getting a transaction.
|
||||
where inbound peers could prevent a node from getting a transaction.
|
||||
(#14897, #15834)
|
||||
|
||||
Wallet
|
||||
------
|
||||
|
||||
- When in pruned mode, a rescan that was triggered by an `importwallet`,
|
||||
`importpubkey`, `importaddress`, or `importprivkey` RPC will only fail when
|
||||
blocks have been pruned. Previously it would fail when `-prune` has been set.
|
||||
This change allows to set `-prune` to a high value (e.g. the disk size) and
|
||||
the calls to any of the import RPCs would fail when the first block is
|
||||
pruned.
|
||||
`importpubkey`, `importaddress`, or `importprivkey` RPC will only fail
|
||||
when blocks have been pruned. Previously it would fail when `-prune`
|
||||
has been set. This change allows setting `-prune` to a high value
|
||||
(e.g. the disk size) without the calls to any of the import RPCs
|
||||
failing until the first block is pruned. (#15870)
|
||||
|
||||
- When creating a transaction with a fee above `-maxtxfee` (default 0.1
|
||||
BTC), the RPC commands `walletcreatefundedpsbt` and
|
||||
`fundrawtransaction` will now fail instead of rounding down the fee.
|
||||
Beware that the `feeRate` argument is specified in BTC per kilobyte,
|
||||
not satoshi per byte.
|
||||
Be aware that the `feeRate` argument is specified in BTC per 1,000
|
||||
vbytes, not satoshi per vbyte. (#16257)
|
||||
|
||||
- A new wallet flag `avoid_reuse` has been added (default off). When
|
||||
enabled, a wallet will distinguish between used and unused addresses,
|
||||
and default to not use the former in coin selection.
|
||||
|
||||
Rescanning the blockchain is required, to correctly mark previously
|
||||
used destinations.
|
||||
|
||||
Together with "avoid partial spends" (present as of Bitcoin v0.17),
|
||||
this addresses a serious privacy issue where a malicious user can
|
||||
track spends by peppering a previously paid to address with near-dust
|
||||
outputs, which would then be inadvertently included in future
|
||||
payments.
|
||||
and default to not use the former in coin selection. When setting
|
||||
this flag on an existing wallet, rescanning the blockchain is required
|
||||
to correctly mark previously used destinations. Together with "avoid
|
||||
partial spends" (added in Bitcoin Core v0.17.0), this can eliminate a
|
||||
serious privacy issue where a malicious user can track spends by
|
||||
sending small payments to a previously-paid address that would then
|
||||
be included with unrelated inputs in future payments. (#13756)
|
||||
|
||||
Build system changes
|
||||
--------------------
|
||||
|
||||
- Python >=3.5 is now required by all aspects of the project. This
|
||||
includes the build systems, test framework and linters. The previously
|
||||
supported minimum (3.4), was E OL in March 2019. See #14954 for more
|
||||
details.
|
||||
supported minimum (3.4), was EOL in March 2019. (#14954)
|
||||
|
||||
- The minimum supported miniUPnPc API version is set to 10. This keeps
|
||||
compatibility with Ubuntu 16.04 LTS and Debian 8 `libminiupnpc-dev`
|
||||
|
@ -280,7 +271,7 @@ Build system changes
|
|||
[CVE-2017-8798](https://security-tracker.debian.org/tracker/CVE-2017-8798)
|
||||
(in jessie only) and
|
||||
[CVE-2017-1000494](https://security-tracker.debian.org/tracker/CVE-2017-1000494)
|
||||
(both in jessie and in stretch).
|
||||
(both in jessie and in stretch). (#15993)
|
||||
|
||||
Credits
|
||||
=======
|
||||
|
|
Loading…
Reference in a new issue