diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/benchmarking.md | 2 | ||||
| -rw-r--r-- | doc/bips.md | 11 | ||||
| -rw-r--r-- | doc/descriptors.md | 13 | ||||
| -rw-r--r-- | doc/man/bitcoin-qt.1 | 4 | ||||
| -rw-r--r-- | doc/man/bitcoind.1 | 4 | ||||
| -rw-r--r-- | doc/release-notes-15437.md | 34 | ||||
| -rw-r--r-- | doc/release-notes-15584.md | 4 | ||||
| -rw-r--r-- | doc/release-notes-16185.md | 6 | ||||
| -rw-r--r-- | doc/release-notes-16512.md | 4 | ||||
| -rw-r--r-- | doc/release-notes-16695.md | 5 | ||||
| -rw-r--r-- | doc/release-notes-16787.md | 3 | ||||
| -rw-r--r-- | doc/release-notes-17056.md | 4 | ||||
| -rw-r--r-- | doc/release-notes.md | 298 | ||||
| -rw-r--r-- | doc/release-process.md | 42 | ||||
| -rw-r--r-- | doc/translation_process.md | 2 |
15 files changed, 102 insertions, 334 deletions
diff --git a/doc/benchmarking.md b/doc/benchmarking.md index 8e3d88ab7a..b1a06009b5 100644 --- a/doc/benchmarking.md +++ b/doc/benchmarking.md @@ -11,7 +11,7 @@ Running For benchmarks purposes you only need to compile `bitcoin_bench`. Beware of configuring without `--enable-debug` as this would impact benchmarking by unlatching log printers and lock analysis. - make -C src bench_bitcoin + make -C src bitcoin_bench After compiling bitcoin-core, the benchmarks can be run with: diff --git a/doc/bips.md b/doc/bips.md index 3085fa424b..90d0e341df 100644 --- a/doc/bips.md +++ b/doc/bips.md @@ -1,4 +1,4 @@ -BIPs that are implemented by Bitcoin Core (up-to-date up to **v0.18.0**): +BIPs that are implemented by Bitcoin Core (up-to-date up to **v0.19.0**): * [`BIP 9`](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki): The changes allowing multiple soft-forks to be deployed in parallel have been implemented since **v0.12.1** ([PR #7575](https://github.com/bitcoin/bitcoin/pull/7575)) * [`BIP 11`](https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki): Multisig outputs are standard since **v0.6.0** ([PR #669](https://github.com/bitcoin/bitcoin/pull/669)). @@ -15,16 +15,16 @@ BIPs that are implemented by Bitcoin Core (up-to-date up to **v0.18.0**): * [`BIP 35`](https://github.com/bitcoin/bips/blob/master/bip-0035.mediawiki): The 'mempool' protocol message (and the protocol version bump to 60002) has been implemented since **v0.7.0** ([PR #1641](https://github.com/bitcoin/bitcoin/pull/1641)). As of **v0.13.0**, this is only available for `NODE_BLOOM` (BIP 111) peers. * [`BIP 37`](https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki): The bloom filtering for transaction relaying, partial Merkle trees for blocks, and the protocol version bump to 70001 (enabling low-bandwidth SPV clients) has been implemented since **v0.8.0** ([PR #1795](https://github.com/bitcoin/bitcoin/pull/1795)). Disabled by default since **v0.19.0**, can be enabled by the `-peerbloomfilters` option. * [`BIP 42`](https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki): The bug that would have caused the subsidy schedule to resume after block 13440000 was fixed in **v0.9.2** ([PR #3842](https://github.com/bitcoin/bitcoin/pull/3842)). -* [`BIP 61`](https://github.com/bitcoin/bips/blob/master/bip-0061.mediawiki): The 'reject' protocol message (and the protocol version bump to 70002) was added in **v0.9.0** ([PR #3185](https://github.com/bitcoin/bitcoin/pull/3185)). Starting **v0.17.0**, whether to send reject messages can be configured with the `-enablebip61` option, and support is deprecated as of **v0.18.0**. +* [`BIP 61`](https://github.com/bitcoin/bips/blob/master/bip-0061.mediawiki): The 'reject' protocol message (and the protocol version bump to 70002) was added in **v0.9.0** ([PR #3185](https://github.com/bitcoin/bitcoin/pull/3185)). Starting **v0.17.0**, whether to send reject messages can be configured with the `-enablebip61` option, and support is deprecated (disabled by default) as of **v0.18.0**. Support was removed in **v0.20.0** ([PR #15437](https://github.com/bitcoin/bitcoin/pull/15437)). * [`BIP 65`](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki): The CHECKLOCKTIMEVERIFY softfork was merged in **v0.12.0** ([PR #6351](https://github.com/bitcoin/bitcoin/pull/6351)), and backported to **v0.11.2** and **v0.10.4**. Mempool-only CLTV was added in [PR #6124](https://github.com/bitcoin/bitcoin/pull/6124). * [`BIP 66`](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki): The strict DER rules and associated version 3 blocks have been implemented since **v0.10.0** ([PR #5713](https://github.com/bitcoin/bitcoin/pull/5713)). * [`BIP 68`](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki): Sequence locks have been implemented as of **v0.12.1** ([PR #7184](https://github.com/bitcoin/bitcoin/pull/7184)), and have been activated since *block 419328*. -* [`BIP 70`](https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki) [`71`](https://github.com/bitcoin/bips/blob/master/bip-0071.mediawiki) [`72`](https://github.com/bitcoin/bips/blob/master/bip-0072.mediawiki): Payment Protocol support has been available in Bitcoin Core GUI since **v0.9.0** ([PR #5216](https://github.com/bitcoin/bitcoin/pull/5216)). Support can be optionally disabled at build time since **v0.18.0** ([PR 14451](https://github.com/bitcoin/bitcoin/pull/14451)). +* [`BIP 70`](https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki) [`71`](https://github.com/bitcoin/bips/blob/master/bip-0071.mediawiki) [`72`](https://github.com/bitcoin/bips/blob/master/bip-0072.mediawiki): Payment Protocol support has been available in Bitcoin Core GUI since **v0.9.0** ([PR #5216](https://github.com/bitcoin/bitcoin/pull/5216)). Support can be optionally disabled at build time since **v0.18.0** ([PR 14451](https://github.com/bitcoin/bitcoin/pull/14451)), and is disabled by default at build time since **v0.19.0** ([PR #15584](https://github.com/bitcoin/bitcoin/pull/15584)). * [`BIP 90`](https://github.com/bitcoin/bips/blob/master/bip-0090.mediawiki): Trigger mechanism for activation of BIPs 34, 65, and 66 has been simplified to block height checks since **v0.14.0** ([PR #8391](https://github.com/bitcoin/bitcoin/pull/8391)). * [`BIP 111`](https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki): `NODE_BLOOM` service bit added, and enforced for all peer versions as of **v0.13.0** ([PR #6579](https://github.com/bitcoin/bitcoin/pull/6579) and [PR #6641](https://github.com/bitcoin/bitcoin/pull/6641)). * [`BIP 112`](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki): The CHECKSEQUENCEVERIFY opcode has been implemented since **v0.12.1** ([PR #7524](https://github.com/bitcoin/bitcoin/pull/7524)) and has been activated since *block 419328*. * [`BIP 113`](https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki): Median time past lock-time calculations have been implemented since **v0.12.1** ([PR #6566](https://github.com/bitcoin/bitcoin/pull/6566)) and have been activated since *block 419328*. -* [`BIP 125`](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki): Opt-in full replace-by-fee signaling honoured in mempool and mining as of **v0.12.0** ([PR 6871](https://github.com/bitcoin/bitcoin/pull/6871)). +* [`BIP 125`](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki): Opt-in full replace-by-fee signaling honoured in mempool and mining as of **v0.12.0** ([PR 6871](https://github.com/bitcoin/bitcoin/pull/6871)). Enabled by default in the wallet GUI as of **v0.18.1** ([PR #11605](https://github.com/bitcoin/bitcoin/pull/11605)) * [`BIP 130`](https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki): direct headers announcement is negotiated with peer versions `>=70012` as of **v0.12.0** ([PR 6494](https://github.com/bitcoin/bitcoin/pull/6494)). * [`BIP 133`](https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki): feefilter messages are respected and sent for peer versions `>=70013` as of **v0.13.0** ([PR 7542](https://github.com/bitcoin/bitcoin/pull/7542)). * [`BIP 141`](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki): Segregated Witness (Consensus Layer) as of **v0.13.0** ([PR 8149](https://github.com/bitcoin/bitcoin/pull/8149)), and defined for mainnet as of **v0.13.1** ([PR 8937](https://github.com/bitcoin/bitcoin/pull/8937)). @@ -33,7 +33,8 @@ BIPs that are implemented by Bitcoin Core (up-to-date up to **v0.18.0**): * [`BIP 145`](https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki): getblocktemplate updates for Segregated Witness as of **v0.13.0** ([PR 8149](https://github.com/bitcoin/bitcoin/pull/8149)). * [`BIP 147`](https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki): NULLDUMMY softfork as of **v0.13.1** ([PR 8636](https://github.com/bitcoin/bitcoin/pull/8636) and [PR 8937](https://github.com/bitcoin/bitcoin/pull/8937)). * [`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/man/bitcoin-qt.1 b/doc/man/bitcoin-qt.1 index 1e8443b1d3..1957fb736e 100644 --- a/doc/man/bitcoin-qt.1 +++ b/doc/man/bitcoin-qt.1 @@ -179,10 +179,6 @@ Allow DNS lookups for \fB\-addnode\fR, \fB\-seednode\fR and \fB\-connect\fR (def Query for peer addresses via DNS lookup, if low on addresses (default: 1 unless \fB\-connect\fR used) .HP -\fB\-enablebip61\fR -.IP -Send reject messages per BIP61 (default: 0) -.HP \fB\-externalip=\fR<ip> .IP Specify your own public address diff --git a/doc/man/bitcoind.1 b/doc/man/bitcoind.1 index 2a79b6cb46..b0aff99ca2 100644 --- a/doc/man/bitcoind.1 +++ b/doc/man/bitcoind.1 @@ -179,10 +179,6 @@ Allow DNS lookups for \fB\-addnode\fR, \fB\-seednode\fR and \fB\-connect\fR (def Query for peer addresses via DNS lookup, if low on addresses (default: 1 unless \fB\-connect\fR used) .HP -\fB\-enablebip61\fR -.IP -Send reject messages per BIP61 (default: 0) -.HP \fB\-externalip=\fR<ip> .IP Specify your own public address diff --git a/doc/release-notes-15437.md b/doc/release-notes-15437.md new file mode 100644 index 0000000000..031e90ccd2 --- /dev/null +++ b/doc/release-notes-15437.md @@ -0,0 +1,34 @@ +P2P and network changes +----------------------- + +#### Removal of reject network messages from Bitcoin Core (BIP61) + +The command line option to enable BIP61 (`-enablebip61`) has been removed. + +This feature has been disabled by default since Bitcoin Core version 0.18.0. +Nodes on the network can not generally be trusted to send valid ("reject") +messages, so this should only ever be used when connected to a trusted node. +Please use the recommended alternatives if you rely on this deprecated feature: + +* Testing or debugging of implementations of the Bitcoin P2P network protocol + should be done by inspecting the log messages that are produced by a recent + version of Bitcoin Core. Bitcoin Core logs debug messages + (`-debug=<category>`) to a stream (`-printtoconsole`) or to a file + (`-debuglogfile=<debug.log>`). + +* Testing the validity of a block can be achieved by specific RPCs: + - `submitblock` + - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with + potentially invalid POW + +* Testing the validity of a transaction can be achieved by specific RPCs: + - `sendrawtransaction` + - `testmempoolaccept` + +* Wallets should not use the absence of "reject" messages to indicate a + transaction has propagated the network, nor should wallets use "reject" + messages to set transaction fees. Wallets should rather use fee estimation + to determine transaction fees and set replace-by-fee if desired. Thus, they + could wait until the transaction has confirmed (taking into account the fee + target they set (compare the RPC `estimatesmartfee`)) or listen for the + transaction announcement by other network peers to check for propagation. diff --git a/doc/release-notes-15584.md b/doc/release-notes-15584.md deleted file mode 100644 index 3d9b1cc903..0000000000 --- a/doc/release-notes-15584.md +++ /dev/null @@ -1,4 +0,0 @@ -GUI Changes ------------ -- 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`.
\ No newline at end of file diff --git a/doc/release-notes-16185.md b/doc/release-notes-16185.md deleted file mode 100644 index 2567ebea40..0000000000 --- a/doc/release-notes-16185.md +++ /dev/null @@ -1,6 +0,0 @@ -RPC changes ------------ -The `gettransaction` RPC 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. diff --git a/doc/release-notes-16512.md b/doc/release-notes-16512.md deleted file mode 100644 index 9aa9cf36f9..0000000000 --- a/doc/release-notes-16512.md +++ /dev/null @@ -1,4 +0,0 @@ -RPC changes ------------ -The RPC `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. diff --git a/doc/release-notes-16695.md b/doc/release-notes-16695.md deleted file mode 100644 index 7acf1dcf97..0000000000 --- a/doc/release-notes-16695.md +++ /dev/null @@ -1,5 +0,0 @@ -Updated RPCs ------------- - -- The `getchaintxstats` RPC now returns the additional key of - `window_final_block_height`. diff --git a/doc/release-notes-16787.md b/doc/release-notes-16787.md deleted file mode 100644 index c42b7a5803..0000000000 --- a/doc/release-notes-16787.md +++ /dev/null @@ -1,3 +0,0 @@ -RPC changes ------------ -The `getnetworkinfo` and `getpeerinfo` commands now contain a new field with decoded network service flags. 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 04aab56a72..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,320 +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) - -- `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) - -- `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 BIP141. (#16647) - -- `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) - -- `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) - -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 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`. (#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 ======= @@ -373,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 480b09ee11..2c3c4e3869 100644 --- a/doc/release-process.md +++ b/doc/release-process.md @@ -11,22 +11,12 @@ Release Process ### Before every major and minor release -* Update [bips.md](bips.md) to account for changes since the last release. +* 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. -* 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/12270) 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) @@ -369,3 +369,23 @@ bitcoin.org (see below for bitcoin.org update instructions). - Optionally twitter, reddit /r/Bitcoin, ... but this will usually sort out itself - Celebrate + +### Additional information + +#### How to calculate `m_assumed_blockchain_size` and `m_assumed_chain_state_size` + +Both variables are used as a guideline for how much space the user needs on their drive in total, not just strictly for the blockchain. +Note that all values should be taken from a **fully synced** node and have an overhead of 5-10% added on top of its base value. + +To calculate `m_assumed_blockchain_size`: +- For `mainnet` -> Take the size of the data directory, excluding `/regtest` and `/testnet3` directories. +- For `testnet` -> Take the size of the `/testnet3` directory. + + +To calculate `m_assumed_chain_state_size`: +- For `mainnet` -> Take the size of the `/chainstate` directory. +- For `testnet` -> Take the size of the `/testnet3/chainstate` directory. + +Notes: +- When taking the size for `m_assumed_blockchain_size`, there's no need to exclude the `/chainstate` directory since it's a guideline value and an overhead will be added anyway. +- The expected overhead for growth may change over time, so it may not be the same value as last release; pay attention to that when changing the variables. diff --git a/doc/translation_process.md b/doc/translation_process.md index 14774eec43..39f878cea3 100644 --- a/doc/translation_process.md +++ b/doc/translation_process.md @@ -73,7 +73,7 @@ To assist in updating translations, a helper script is available in the [maintai ```bash git ls-files src/qt/locale/*ts|xargs -n1 basename|sed 's/\(bitcoin_\(.*\)\).ts/ <file alias="\2">locale\/\1.qm<\/file>/' ``` -4. Update `src/Makefile.qt.include` manually or via +4. Update `src/Makefile.qt_locale.include` manually or via ```bash git ls-files src/qt/locale/*ts|xargs -n1 basename|sed 's/\(bitcoin_\(.*\)\).ts/ qt\/locale\/\1.ts \\/' ``` |