aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/bips.md2
-rw-r--r--doc/descriptors.md13
-rw-r--r--doc/release-notes-17056.md4
-rw-r--r--doc/release-notes.md318
-rw-r--r--doc/release-process.md20
5 files changed, 40 insertions, 317 deletions
diff --git a/doc/bips.md b/doc/bips.md
index 570244aeae..90d0e341df 100644
--- a/doc/bips.md
+++ b/doc/bips.md
@@ -35,6 +35,6 @@ BIPs that are implemented by Bitcoin Core (up-to-date up to **v0.19.0**):
* [`BIP 152`](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki): Compact block transfer and related optimizations are used as of **v0.13.0** ([PR 8068](https://github.com/bitcoin/bitcoin/pull/8068)).
- [`BIP 158`](https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki): Compact Block Filters for Light Clients can be indexed as of **v0.19.0** ([PR #14121](https://github.com/bitcoin/bitcoin/pull/14121)).
* [`BIP 159`](https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki): The NODE_NETWORK_LIMITED service bit is signalled as of **v0.16.0** ([PR 11740](https://github.com/bitcoin/bitcoin/pull/11740)), and such nodes are connected to as of **v0.17.0** ([PR 10387](https://github.com/bitcoin/bitcoin/pull/10387)).
-* [`BIP 173`](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki): Bech32 addresses for native Segregated Witness outputs are supported as of **v0.16.0** ([PR 11167](https://github.com/bitcoin/bitcoin/pull/11167)).
+* [`BIP 173`](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki): Bech32 addresses for native Segregated Witness outputs are supported as of **v0.16.0** ([PR 11167](https://github.com/bitcoin/bitcoin/pull/11167)). Bech32 addresses are generated by default as of **v0.20.0** ([PR 16884](https://github.com/bitcoin/bitcoin/pull/16884)).
* [`BIP 174`](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki): RPCs to operate on Partially Signed Bitcoin Transactions (PSBT) are present as of **v0.17.0** ([PR 13557](https://github.com/bitcoin/bitcoin/pull/13557)).
* [`BIP 176`](https://github.com/bitcoin/bips/blob/master/bip-0176.mediawiki): Bits Denomination [QT only] is supported as of **v0.16.0** ([PR 12035](https://github.com/bitcoin/bitcoin/pull/12035)).
diff --git a/doc/descriptors.md b/doc/descriptors.md
index dbdac2c5b6..a98f43737e 100644
--- a/doc/descriptors.md
+++ b/doc/descriptors.md
@@ -23,6 +23,7 @@ Output descriptors currently support:
- Pay-to-script-hash scripts (P2SH), through the `sh` function.
- Pay-to-witness-script-hash scripts (P2WSH), through the `wsh` function.
- Multisig scripts, through the `multi` function.
+- Multisig scripts where the public keys are sorted lexicographically, through the `sortedmulti` function.
- Any type of supported address through the `addr` function.
- Raw hex scripts through the `raw` function.
- Public keys (compressed and uncompressed) in hex notation, or BIP32 extended pubkeys with derivation paths.
@@ -37,12 +38,14 @@ Output descriptors currently support:
- `sh(wsh(pkh(02e493dbf1c10d80f3581e4904930b1404cc6c13900ee0758474fa94abe8c4cd13)))` describes an (overly complicated) P2SH-P2WSH-P2PKH output with the specified public key.
- `multi(1,022f8bde4d1a07209355b4a7250a5c5128e88b84bddc619ab7cba8d569b240efe4,025cbdf0646e5db4eaa398f365f2ea7a0e3d419b7e0330e39ce92bddedcac4f9bc)` describes a bare *1-of-2* multisig output with keys in the specified order.
- `sh(multi(2,022f01e5e15cca351daff3843fb70f3c2f0a1bdd05e5af888a67784ef3e10a2a01,03acd484e2f0c7f65309ad178a9f559abde09796974c57e714c35f110dfc27ccbe))` describes a P2SH *2-of-2* multisig output with keys in the specified order.
+- `sh(sortedmulti(2,03acd484e2f0c7f65309ad178a9f559abde09796974c57e714c35f110dfc27ccbe,022f01e5e15cca351daff3843fb70f3c2f0a1bdd05e5af888a67784ef3e10a2a01))` describes a P2SH *2-of-2* multisig output with keys sorted lexicographically in the resulting redeemScript.
- `wsh(multi(2,03a0434d9e47f3c86235477c7b1ae6ae5d3442d49b1943c2b752a68e2a47e247c7,03774ae7f858a9411e5ef4246b70c65aac5649980be5c17891bbec17895da008cb,03d01115d548e7561b15c38f004d734633687cf4419620095bc5b0f47070afe85a))` describes a P2WSH *2-of-3* multisig output with keys in the specified order.
- `sh(wsh(multi(1,03f28773c2d975288bc7d1d205c3748651b075fbc6610e58cddeeddf8f19405aa8,03499fdf9e895e719cfd64e67f07d38e3226aa7b63678949e6e49b241a60e823e4,02d7924d4f7d43ea965a465ae3095ff41131e5946f3c85f79e44adbcf8e27e080e)))` describes a P2SH-P2WSH *1-of-3* multisig output with keys in the specified order.
- `pk(xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8)` describes a P2PK output with the public key of the specified xpub.
- `pkh(xpub68Gmy5EdvgibQVfPdqkBBCHxA5htiqg55crXYuXoQRKfDBFA1WEjWgP6LHhwBZeNK1VTsfTFUHCdrfp1bgwQ9xv5ski8PX9rL2dZXvgGDnw/1'/2)` describes a P2PKH output with child key *1'/2* of the specified xpub.
- `pkh([d34db33f/44'/0'/0']xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/1/*)` describes a set of P2PKH outputs, but additionally specifies that the specified xpub is a child of a master with fingerprint `d34db33f`, and derived using path `44'/0'/0'`.
- `wsh(multi(1,xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/1/0/*,xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH/0/0/*))` describes a set of *1-of-2* P2WSH multisig outputs where the first multisig key is the *1/0/`i`* child of the first specified xpub and the second multisig key is the *0/0/`i`* child of the second specified xpub, and `i` is any number in a configurable range (`0-1000` by default).
+- `wsh(sortedmulti(1,xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/1/0/*,xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH/0/0/*))` describes a set of *1-of-2* P2WSH multisig outputs where one multisig key is the *1/0/`i`* child of the first specified xpub and the other multisig key is the *0/0/`i`* child of the second specified xpub, and `i` is any number in a configurable range (`0-1000` by default). The order of public keys in the resulting witnessScripts is determined by the lexicographic order of the public keys at that index.
## Reference
@@ -56,6 +59,7 @@ Descriptors consist of several types of expressions. The top level expression is
- `wpkh(KEY)` (not inside `wsh`): P2WPKH output for the given compressed pubkey.
- `combo(KEY)` (top level only): an alias for the collection of `pk(KEY)` and `pkh(KEY)`. If the key is compressed, it also includes `wpkh(KEY)` and `sh(wpkh(KEY))`.
- `multi(k,KEY_1,KEY_2,...,KEY_n)` (anywhere): k-of-n multisig script.
+- `sortedmulti(k,KEY_1,KEY_2,...,KEY_n)` (anywhere): k-of-n multisig script with keys sorted lexicographically in the resulting script.
- `addr(ADDR)` (top level only): the script which ADDR expands to.
- `raw(HEX)` (top level only): the script whose hex encoding is HEX.
@@ -101,11 +105,12 @@ not contain "p2" for brevity.
Several pieces of software use multi-signature (multisig) scripts based
on Bitcoin's OP_CHECKMULTISIG opcode. To support these, we introduce the
-`multi(k,key_1,key_2,...,key_n)` function. It represents a *k-of-n*
+`multi(k,key_1,key_2,...,key_n)` and `sortedmulti(k,key_1,key_2,...,key_n)`
+functions. They represent a *k-of-n*
multisig policy, where any *k* out of the *n* provided `KEY` expressions must
sign.
-Key order is significant. A `multi()` expression describes a multisig script
+Key order is significant for `multi()`. A `multi()` expression describes a multisig script
with keys in the specified order, and in a search for TXOs, it will not match
outputs with multisig scriptPubKeys that have the same keys in a different
order. Also, to prevent a combinatorial explosion of the search space, if more
@@ -114,6 +119,10 @@ or `*'`, the `multi()` expression only matches multisig scripts with the `i`th
child key from each wildcard path in lockstep, rather than scripts with any
combination of child keys from each wildcard path.
+Key order does not matter for `sortedmulti()`. `sortedmulti()` behaves in the same way
+as `multi()` does but the keys are reordered in the resulting script such that they
+are lexicographically ordered as described in BIP67.
+
### BIP32 derived keys and chains
Most modern wallet software and hardware uses keys that are derived using
diff --git a/doc/release-notes-17056.md b/doc/release-notes-17056.md
new file mode 100644
index 0000000000..23d5a8c8cd
--- /dev/null
+++ b/doc/release-notes-17056.md
@@ -0,0 +1,4 @@
+Low-level RPC Changes
+===
+
+- A new descriptor type `sortedmulti(...)` has been added to support multisig scripts where the public keys are sorted lexicographically in the resulting script.
diff --git a/doc/release-notes.md b/doc/release-notes.md
index 71dc40e66c..ea82962e75 100644
--- a/doc/release-notes.md
+++ b/doc/release-notes.md
@@ -39,7 +39,7 @@ installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
or `bitcoind`/`bitcoin-qt` (on Linux).
Upgrading directly from a version of Bitcoin Core that has reached its EOL is
-possible, but might take some time if the datadir needs to be migrated. Old
+possible, but it might take some time if the datadir needs to be migrated. Old
wallet versions of Bitcoin Core are generally supported.
Compatibility
@@ -52,340 +52,49 @@ to use Bitcoin Core on unsupported systems.
Bitcoin Core should also work on most other Unix-like systems but is not
as frequently tested on them.
-From 0.17.0 onwards, macOS <10.10 is no longer supported. 0.17.0 is
-built using Qt 5.9.x, which doesn't support versions of macOS older than
-10.10. Additionally, Bitcoin Core does not yet change appearance when
+From Bitcoin Core 0.17.0 onwards, macOS versions earlier than 10.10 are no
+longer supported, as Bitcoin Core is now built using Qt 5.9.x which requires
+macOS 10.10+. Additionally, Bitcoin Core does not yet change appearance when
macOS "dark mode" is activated.
-In addition to previously-supported CPU platforms, this release's
-pre-compiled distribution also provides binaries for the RISC-V
-platform.
+In addition to previously supported CPU platforms, this release's pre-compiled
+distribution provides binaries for the RISC-V platform.
Notable changes
===============
-New user documentation
-----------------------
-
-- [Reduce memory](https://github.com/bitcoin/bitcoin/blob/master/doc/reduce-memory.md)
- suggests configuration tweaks for running Bitcoin Core on systems with
- limited memory. (#16339)
-
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
- `getbalance`, `getunconfirmedbalance`, and the balance fields in
- `getwalletinfo`. These old calls and fields may be removed in a
- future version. (#15930, #16239)
-
-- `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)
-
-- `getblockfilter` gets the BIP158 filter for the specified block. This
- RPC is only enabled if block filters have been created using the
- `-blockfilterindex` configuration option. (#14121)
-
New settings
------------
-- `-blockfilterindex` enables the creation of BIP158 block filters for
- the entire blockchain. Filters will be created in the background and
- currently use about 4 GiB of space. Note: this version of Bitcoin
- Core does not serve block filters over the P2P network, although the
- local user may obtain block filters using the `getblockfilter` RPC.
- (#14121)
-
Updated settings
----------------
-- `whitebind` and `whitelist` now accept a list of permissions to
- provide peers connecting using the indicated interfaces or IP
- addresses. If no permissions are specified with an address or CIDR
- network, the implicit default permissions are the same as previous
- releases. See the `bitcoind -help` output for these two options for
- details about the available permissions. (#16248)
-
Updated RPCs
------------
Note: some low-level RPC changes mainly useful for testing are described in the
Low-level Changes section below.
-- `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)
-
-- `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)
-
-- RPCs which have an `include_watchonly` argument or `includeWatching` option now default to `true` for watch-only
- wallets. Affected RPCs are: `getbalance`, `listreceivedbyaddress`, `listreceivedbylabel`, `listtransactions`,
- `listsinceblock`, `gettransaction`, `walletcreatefundedpsbt`, and `fundrawtransaction`. (#16383)
-
-- `listunspent` now returns a "reused" bool for each output if the
- wallet flag "avoid_reuse" is enabled. (#13756)
-
-- `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)
-
-- `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)
-
-- `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)
-
-- `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)
-
-- `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)
-
-- `gettransaction` now accepts a third (boolean) argument `verbose`. If
- set to `true`, a new `decoded` field will be added to the response containing
- the decoded transaction. This field is equivalent to RPC `decoderawtransaction`,
- or RPC `getrawtransaction` when `verbose` is passed.
-
-- `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)
-
-- `getchaintxstats` RPC now returns the additional key of
- `window_final_block_height`.
-
-- `getmempoolentry` now provides a `weight` field containing the
- transaction weight as defined in BIP141. (#16647)
-
-- The `getnetworkinfo` and `getpeerinfo` commands now contain a new field with decoded network service flags.
-
-- `getdescriptorinfo` now returns an additional `checksum` field
- containing the checksum for the unmodified descriptor provided by the
- user (that is, before the descriptor is normalized for the
- `descriptor` field). (#15986)
-
-- `joinpsbts` will shuffle the order of the inputs and outputs of the resulting joined psbt.
- Previously inputs and outputs were added in the order that the PSBTs were provided which makes correlating inputs to outputs extremely easy.
-
-- `walletcreatefundedpsbt` now signals BIP125 Replace-by-Fee if the
- `-walletrbf` configuration option is set to true. (#15911)
-
GUI changes
-----------
-- Provides bech32 addresses by default. The user may change the address
- during invoice generation using a GUI toggle, or the default address
- type may be changed by the `-addresstype` configuration option.
- (#15711, #16497)
-
-- 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.
-- If you want compile Bitcoin Core with BIP70 support in the GUI, you can pass `--enable-bip70` to `./configure`.
-
-Deprecated or removed configuration options
--------------------------------------------
-
-- `-mempoolreplacement` is removed, although default node behavior
- remains the same. This option previously allowed the user to prevent
- the node from accepting or relaying BIP125 transaction replacements.
- This is different from the remaining configuration option
- `-walletrbf`. (#16171)
-
-Deprecated or removed RPCs
---------------------------
-
-- `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)
-
-- `generate` is now removed after being deprecated in Bitcoin Core 0.18.
- Use the `generatetoaddress` RPC instead. (#15492)
-
-P2P changes
------------
+Wallet
+------
-- 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. (#14054)
-
-- 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). (#15566)
+- The wallet now by default uses bech32 addresses when using RPC, and creates native segwit change outputs.
Low-level changes
=================
-RPC
----
-
-- `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 BIP9 deployments that are currently in active
- state). (#16060)
-
-- `getrpcinfo` now returns a `logpath` field with the path to
- `debug.log`. (#15483)
-
Tests
-----
-- 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
-------------
-
-- A setting specified in the default section but not also specified in a
- network-specific section (e.g. testnet) will now produce an 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`. (#15849)
-
-Network
--------
-
-- When fetching a transaction announced by multiple peers, previous versions of
- Bitcoin Core would sequentially attempt to download the transaction from each
- announcing peer until the transaction is received, in the order that those
- 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 could prevent a node from getting a transaction.
- (#14897, #15834)
-
-- If a Tor hidden service is being used, Bitcoin Core will be bound to
- the standard port 8333 even if a different port is configured for
- clearnet connections. This prevents leaking node identity through use
- of identical non-default port numbers. (#15651)
-
-Mempool and transaction relay
------------------------------
-
-- Allows one extra single-ancestor transaction per package. Previously,
- if a transaction in the mempool had 25 descendants, or it and all of
- its descendants were over 101,000 vbytes, any newly-received
- transaction that was also a descendant would be ignored. Now, one
- extra descendant will be allowed provided it is an immediate
- descendant (child) and the child's size is 10,000 vbytes or less.
- This makes it possible for two-party contract protocols such as
- Lightning Network to give each participant an output they can spend
- immediately for Child-Pays-For-Parent (CPFP) fee bumping without
- allowing one malicious participant to fill the entire package and thus
- prevent the other participant from spending their output. (#15681)
-
-- Transactions with outputs paying v1 to v16 witness versions (future
- segwit versions) are now accepted into the mempool, relayed, and
- mined. Attempting to spend those outputs remains forbidden by policy
- ("non-standard"). When this change has been widely deployed, wallets
- and services can accept any valid bech32 Bitcoin address without
- concern that transactions paying future segwit versions will become
- stuck in an unconfirmed state. (#15846)
-
-- Legacy transactions (transactions with no segwit inputs) must now be
- sent using the legacy encoding format, enforcing the rule specified in
- BIP144. (#14039)
-
-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 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.
- 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. 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 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`
- packages. Please note, on Debian this package is still vulnerable to
- [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). (#15993)
+- `-fallbackfee` was 0 (disabled) by default for the main chain, but 0.0002 by default for the test chains. Now it is 0
+ by default for all chains. Testnet and regtest users will have to add `fallbackfee=0.0002` to their configuration if
+ they weren't setting it and they want it to keep working like before. (#16524)
Credits
=======
@@ -393,4 +102,5 @@ Credits
Thanks to everyone who directly contributed to this release:
-As well as everyone that helped translating on [Transifex](https://www.transifex.com/bitcoin/bitcoin/).
+As well as to everyone that helped with translations on
+[Transifex](https://www.transifex.com/bitcoin/bitcoin/).
diff --git a/doc/release-process.md b/doc/release-process.md
index 551bde78a3..2c3c4e3869 100644
--- a/doc/release-process.md
+++ b/doc/release-process.md
@@ -14,19 +14,9 @@ Release Process
* Update [bips.md](bips.md) to account for changes since the last release (don't forget to bump the version number on the first line).
* Update version in `configure.ac` (don't forget to set `CLIENT_VERSION_RC` to `0`).
* Write release notes (see "Write the release notes" below).
-* Update `src/chainparams.cpp` nMinimumChainWork with information from the getblockchaininfo rpc.
-* Update `src/chainparams.cpp` defaultAssumeValid with information from the getblockhash rpc.
- - The selected value must not be orphaned so it may be useful to set the value two blocks back from the tip.
- - Testnet should be set some tens of thousands back from the tip due to reorgs there.
- - This update should be reviewed with a reindex-chainstate with assumevalid=0 to catch any defect
- that causes rejection of blocks in the past history.
### Before every major release
-* Update hardcoded [seeds](/contrib/seeds/README.md), see [this pull request](https://github.com/bitcoin/bitcoin/pull/7415) for an example.
-* Update [`src/chainparams.cpp`](/src/chainparams.cpp) m_assumed_blockchain_size and m_assumed_chain_state_size with the current size plus some overhead (see [this](#how-to-calculate-m_assumed_blockchain_size-and-m_assumed_chain_state_size) for information on how to calculate them).
-* Update `src/chainparams.cpp` chainTxData with statistics about the transaction count and rate. Use the output of the RPC `getchaintxstats`, see
- [this pull request](https://github.com/bitcoin/bitcoin/pull/17002) for an example. Reviewers can verify the results by running `getchaintxstats <window_block_count> <window_last_block_hash>` with the `window_block_count` and `window_last_block_hash` from your output.
* On both the master branch and the new release branch:
- update `CLIENT_VERSION_MINOR` in [`configure.ac`](../configure.ac)
- update `CLIENT_VERSION_MINOR`, `PACKAGE_VERSION`, and `PACKAGE_STRING` in [`build_msvc/bitcoin_config.h`](/build_msvc/bitcoin_config.h)
@@ -36,6 +26,16 @@ Release Process
#### Before branch-off
+* Update hardcoded [seeds](/contrib/seeds/README.md), see [this pull request](https://github.com/bitcoin/bitcoin/pull/7415) for an example.
+* Update [`src/chainparams.cpp`](/src/chainparams.cpp) m_assumed_blockchain_size and m_assumed_chain_state_size with the current size plus some overhead (see [this](#how-to-calculate-m_assumed_blockchain_size-and-m_assumed_chain_state_size) for information on how to calculate them).
+* Update `src/chainparams.cpp` chainTxData with statistics about the transaction count and rate. Use the output of the RPC `getchaintxstats`, see
+ [this pull request](https://github.com/bitcoin/bitcoin/pull/17002) for an example. Reviewers can verify the results by running `getchaintxstats <window_block_count> <window_last_block_hash>` with the `window_block_count` and `window_last_block_hash` from your output.
+* Update `src/chainparams.cpp` nMinimumChainWork with information from the getblockchaininfo rpc.
+* Update `src/chainparams.cpp` defaultAssumeValid with information from the getblockhash rpc.
+ - The selected value must not be orphaned so it may be useful to set the value two blocks back from the tip.
+ - Testnet should be set some tens of thousands back from the tip due to reorgs there.
+ - This update should be reviewed with a reindex-chainstate with assumevalid=0 to catch any defect
+ that causes rejection of blocks in the past history.
- Clear the release notes and move them to the wiki (see "Write the release notes" below).
#### After branch-off (on master)