diff options
| -rw-r--r-- | build_msvc/bitcoin_config.h | 6 | ||||
| -rw-r--r-- | configure.ac | 2 | ||||
| -rw-r--r-- | doc/release-notes.md | 339 |
3 files changed, 12 insertions, 335 deletions
diff --git a/build_msvc/bitcoin_config.h b/build_msvc/bitcoin_config.h index 66cc1208a1..2fe489239d 100644 --- a/build_msvc/bitcoin_config.h +++ b/build_msvc/bitcoin_config.h @@ -14,7 +14,7 @@ #define CLIENT_VERSION_MAJOR 0 /* Minor version */ -#define CLIENT_VERSION_MINOR 18 +#define CLIENT_VERSION_MINOR 19 /* Build revision */ #define CLIENT_VERSION_REVISION 99 @@ -346,7 +346,7 @@ #define PACKAGE_NAME "Bitcoin Core" /* Define to the full name and version of this package. */ -#define PACKAGE_STRING "Bitcoin Core 0.18.99" +#define PACKAGE_STRING "Bitcoin Core 0.19.99" /* Define to the one symbol short name of this package. */ #define PACKAGE_TARNAME "bitcoin" @@ -355,7 +355,7 @@ #define PACKAGE_URL "https://bitcoincore.org/" /* Define to the version of this package. */ -#define PACKAGE_VERSION "0.18.99" +#define PACKAGE_VERSION "0.19.99" /* Define to necessary symbol if this constant uses a non-standard name on your system. */ diff --git a/configure.ac b/configure.ac index 2445b72683..8af9a986d2 100644 --- a/configure.ac +++ b/configure.ac @@ -1,7 +1,7 @@ dnl require autoconf 2.60 (AS_ECHO/AS_ECHO_N) AC_PREREQ([2.60]) define(_CLIENT_VERSION_MAJOR, 0) -define(_CLIENT_VERSION_MINOR, 18) +define(_CLIENT_VERSION_MINOR, 19) define(_CLIENT_VERSION_REVISION, 99) define(_CLIENT_VERSION_BUILD, 0) define(_CLIENT_VERSION_RC, 0) diff --git a/doc/release-notes.md b/doc/release-notes.md index 71dc40e66c..db5aa0d8a7 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,345 +52,22 @@ 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 ------------ - -- 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) - -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) - 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/). |