|
According to the Bitcoin Core development team’s plan, version 0.18.0 of the Bitcoin Core software will be officially released around April 3. As of press time, the code base has reached 96% completion. The following is the release draft of version 0.18.0. Readers can learn about the updated content of this version of the software in advance. (Screenshot from github) (Note: This is just a temporary description, the official release may be slightly different) Readers can access the Bitcoin Core 0.18.0 client code repository: https://bitcoincore.org/bin/bitcoin-core-0.18.0/ This is a major update to Bitcoin, which includes new features, various bug fixes, performance improvements, and transaction updates. Developers can report bugs using GitHub's issue tracker: https://github.com/bitcoin/bitcoin/issues To receive security and update notifications, please subscribe: https://bitcoincore.org/en/list/announcements/join/ How to Update If you are running an older version of the client, close it, wait until it is completely shut down (older versions may take several minutes), then run the installer (Windows) or copy and overwrite to /Applications/Bitcoin-Qt (Mac system) or bitcoind/bitcoin-qt (Linux system). When you first run a 0.15.0 or newer client, your chain database will be converted to a new format, which can take anywhere from a few minutes to half an hour, depending on the speed of your machine. Note that the block database format has also changed in version 0.8.0, and there is no automatic upgrade code for clients before version 0.8 to version 0.15.0. In clients 0.7.x or earlier, direct upgrade is not possible (need to re-download the blockchain). However, as usual, older versions of wallets are still supported. compatibility The Bitcoin Core client has been extensively tested on multiple operating systems, including Linux kernel operating systems, macOS 10.10+, Windows 7 and newer. It is not recommended to use the Bitcoin Core client on unsupported systems. Bitcoin Core also works on other Unix-like OSes, but they are less tested. It should be noted that if the macOS operating system is lower than version 10.10, it is impossible to run the Bitcoin Core client higher than version 0.17.0. This is because 0.17.0 is built using Qt 5.9.x, which does not support macOS operating systems lower than version 10.10. This version of the precompiled distribution provides binaries for the RISC-V platform in addition to previously supported CPU platforms. If you use the systemd unit configuration file located at contrib/init/bitcoind.service , it has been changed to use /var/lib/bitcoind as the data directory instead of ~bitcoin/.bitcoin . When switching to the new configuration file, make sure that the filesystem where /var/lib/bitcoind is located has enough space (check with df-h/var/lib/bitcoind ), and optionally copy the existing data directory. See the System Initialization Files section for more information. Notable changes Mining If segwit rules are not specified, calls to getblocktemplate will fail. Calling getblocktemplate without segwit specified is almost certainly a misconfiguration, as doing so will reduce miner rewards. Failed calls will generate an error message explaining how to enable segwit rules. Configuration Option Changes If an unrecognized section name is used in the configuration file, a warning will be displayed. The recognized sections are [test] , [main] , and [regtest] . There are four new options for configuring the maximum number of messages that ZMQ will queue in memory before dropping attached messages. The default value is 1000, which is the same as previous versions. See the ZMQ documentation for details. The enablebip61 option (introduced in Bitcoin Core 0.17.0) toggles the sending of BIP61 reject messages. Reject messages have no application on the P2P network, and are only logged for debugging purposes by most network nodes. This option will now be off by default to improve privacy and security, and reduce upload usage. For local network debugging purposes, users can explicitly turn this option on. The rpcallowip option can no longer be used to automatically listen on all network interfaces. Instead, the rpcbind parameter must also be used to specify the IP address to listen on. Since listening for RPC commands over a public network connection is insecure and should be disabled, a warning will now be prompted if the user chooses such a configuration. If you need to expose RPC in order to use tools such as Docker, make sure to bind RPC only to the local host, for example Docker run[…]-p 127.0.0.1:8332:8332 . The rpcpassword option now causes a startup error if the password set in the configuration file contains a hash character (#) because it is ambiguous whether the hash character is used for a password or as a comment. The WhiteListforceRelay option is used to relay transactions from whitelisted peers even when not accepted by the mempool. This option is now off by default, so changes to policy and disconnect/ban behavior do not cause another node in the whitelist to be removed by peers. Users can still enable this behavior explicitly using a command line option (this feature may be deprecated in the future).
System initialization files The system initialization file ( contrib/init/bitcoind.service ) has been changed to use /var/lib/bitcoind as the data directory, rather than ~bitcoin/.bitcoin . This change makes Bitcoin Core more consistent with other services, and makes the system initialization file more consistent with existing Upstart and OpenRC configs. Configuration, PID and data directories are now fully managed by SystemD, which will take care of their creation, permissions, etc. See systemd.exec(5) for details; When using the provided init files under contrib/init , overriding the datadir option in /etc/bitcoin/bitcoin.conf will have no effect. This is because command line arguments specified in the init file take precedence over options specified in /etc/bitcoin/bitcoin.conf . document A new short document about the JSON-RPC interface describes some cases where the result of an RPC may contain inconsistencies between data from different subsystems, such as wallet state and mempool state. A note was added to the REST interface documentation stating that the same rules apply. More information on how to secure this interface will be added to the JSON-RPC documentation. A new document about the bitcoin.conf file, describing how to use it to configure Bitcoin Core. The new document introduces Bitcoin Core's BIP174 Partially Signed Bitcoin Transaction (PSBT) interface, which is used to allow multiple programs to collaborate to create, sign, and broadcast new transactions. This is very useful for offline (cold) wallets, multi-signature wallets, coinjoin implementations, and many other situations where two or more programs need to interact to generate a complete transaction. The output script descriptor documentation has been updated with information about new features of this still-in-development language. The language is currently used in the scantxstart RPC and is expected to be adapted to other RPCs and underlying wallet structures.
Build system changes A new --disable-bip70 option can be passed to ./configure， to prevent Bitcoin-Qt from building or linking against libssl with support for the BIP70 payment protocol. Since the payment protocol has exposed Bitcoin Core to libssl vulnerabilities in the past, builders who do not require bip70 support are encouraged to use this option to reduce the harm of future vulnerability exposure. The minimum required version of Qt (when building the GUI) has been increased from 5.2 to 5.5.1.
New RPC getnodeaddresses RPC returns the peer addresses known to this node. It can be used to find nodes to connect to without using a DNS seeder. listwalletdir RPC returns a list of wallets in the wallet directory (either the default wallet directory or the directory configured by -walletdir parameter). getrpcinfo returns uptime details for the RPC server. Currently, it returns an array of currently active commands, and how long they have been running. deriveaddresses returns one or more addresses corresponding to the output descriptors.
Updated RPC NOTE: The Low-level RPC changes section below describes some low-level RPC changes that are primarily useful for testing. getpeerinfo RPC now returns an additional minfeefilter field which is set to the peer's bip133 fee filter. You can use this to detect if your peer is willing to accept transactions with less than the default minimum relay fee. mempool RPCs, such as getrawmempool , verbose=true的情况下now return an additional “bip125-replaceable” value indicating whether the transaction has opted in to request that nodes and miners replace it with a higher fee transaction using the same inputs. SettXFee RPC previously silently ignored attempts to set the fee below the minimum allowed. It now issues a warning, and the special value "0" can still be used to request the minimum. getaddressinfo RPC now provides an ischange field indicating whether the wallet used an address in a change output. importmulti RPC has been updated to support P2WSH, P2WPKH, P2SH-P2WPKH, and P2SH-P2WSH. Requests to P2WSH and P2SH-P2WSH accept an additional witnessscript parameter. importmulti RPC now returns an additional warnings field for each request, containing a set of strings explaining when, if ever, fields were ignored or inconsistent. getaddressinfo RPC now returns an additional solvable boolean field when Bitcoin Core knows enough about an address’s scriptPubKey, optional redeemScript, and optional witnessScript so that a wallet can generate unsigned inputs to spend funds sent to that address. getaddressinfo , listunspent , and scantxoutset RPCs now return an additional desc field that contains an output descriptor containing all the keypath and signing information for the address (except the private key). getAddressInfo and listunPent return the desc field only if the address is solvable. importprivkey RPC will preserve previously set labels for the addresses or public keys corresponding to the private keys being imported. For example, if you imported a read-only address with the label "coldwallet" in an earlier version of Bitcoin Core, subsequently importing the private key would default to resetting the address label to the default empty string label (""). In this release, the previous "Cold Wallet" label is preserved. If you optionally specify any label other than the default when calling importprivkey , the new label will be applied to the address. See the Mining section for changes to GetBlockTemplate . getmininginfo RPC now omits currentblockweight and currentblocktx when the block has never been assembled via RPC on this node. getrawtransaction RPC and REST endpoints no longer check the transaction's unspent UTXO set. The remaining behavior is as follows: 1. If a block hash is provided, check the corresponding block. 2. If no block hash is provided, check the mempool. 3. If no block hash is provided, but txindex is enabled, also check txindex. unloadwallet RPC is now synchronous, meaning it will not return until the wallet is completely unloaded. importmulti RPC now supports importing addresses from descriptors. A "desc" parameter may be provided instead of "scriptpubkey" in the request, along with an optional range of range descriptors to specify the start and end of the range to import. More information on descriptors can be found here. listunspent RPC has now been modified so that it returns witnessScript, which is the witness script in the case of a P2WSH or P2SH-P2WSH output. createwallet RPC now has an optional blank parameter, which can be used to create a blank wallet. Blank wallets do not have any keys or HD seeds. They cannot be opened with bitcoin core clients older than 0.18. Once a blank wallet has an HD seed set (by using sethdseed ) or private keys, script addresses, and other read-only stuff have been imported, the wallet is no longer blank and can be opened in 0.17.x. Encrypting a blank wallet will also set an HD seed for it.
Deprecated or removed RPCs signrawtransaction RPC was deprecated in version 0.17.0 and was hidden behind a special configuration option, which has now been removed. The 'account' API has now been removed after being deprecated in v0.17. The 'label' API was introduced in v0.17 as a replacement for accounts. For a full description of the change from the 'account' API to the 'label' API, see the release notes for v0.17. addwitnessaddress RPC has now been removed after being deprecated in version 0.16.0. The wallet's generate RPC method has been deprecated and will be completely removed in a subsequent major release. This RPC is intended for testing only, but its implementation spans multiple subsystems (wallet and mining), so it is not recommended to simplify the wallet-node interface. Projects using generate for testing purposes should convert to using generatetoaddress RPC, which does not require or use the wallet component. generatetoaddress is called with the address returned by getnewaddress RPC, providing the same functionality as the old generate RPC. To continue using generate in this release, restart bitcoind with -deprecatedrpc=generate configuration option.
Remaining changes Added a new /rest/blockhashbyheight/ endpoint for getting the hash of a block in the current best blockchain, based on the block's height. Graphical User Interface (GUI) A new Window menu is added next to the existing File, Settings, and Help menus. Several items from other open new window menus have been moved to this new window menu. In the Send tab, the "Pay only required fees" checkbox has been removed. Instead, users can simply lower the value in the Custom Fee field to the minimum relay fee configured for their node. In the Overview tab, if the wallet was created using CreateWallet RPC and the disable_private_keys parameter was set to true, the read-only balance will be the only balance displayed. The launch-on-startup option will no longer be available on MacOS if compiled with a Macosx Min version greater than 10.11 (use CXXFLAGS="-mmacosx-version-min=10.11" CFLAGS="-mmacosx-version-min=10.11" to set the deployment SDK version)
tool A new bitcoin-wallet tool is now distributed with the other executables of Bitcoin Core. Without using any RPCs, this tool can currently create new wallet files or display some basic information about an existing wallet, such as whether the wallet is encrypted, whether it uses an HD seed, how many transactions it contains, and how many address book entries it has. Low level changes RPC (TODO pieter: I think this section can be merged with the earlier RPC changes section) submitblock RPC now always returns the base reason for rejecting an invalid block, and only returns "duplicates" of valid blocks it has already accepted. The new submitheader RPC allows submitting a block header independently of the block. This is probably only useful for testing. signrawtransactionwithkey and signrawtransactionwithwallet RPCs have been modified so that they can also optionally accept witnessScript , which is the witness script in the case of P2WSH or P2SH-P2WSH outputs. This is compatible with the changes to listunspent . Descriptors with key origin information imported by importmulti store their key origin information in the wallet for creating PSBTs If both walletprocesspsbt and walletcreatefundedpsbt have bip32derivs set to true, but the key metadata for a public key has not been updated, then that key will have a derivation path as if it were just a standalone key (i.e., there is no derivation path and its master fingerprint is itself).
Configuration The -usehd configuration option was removed in the 0.16 client release, and from that release onwards, all newly created wallets are Hierarchical Deterministic (HD) wallets. This release makes specifying -usehd an invalid configuration option. network This release allows peers that your node automatically disconnects due to misbehavior (such as sending invalid data) to reconnect to your node (if you have unused incoming connection slots). If your slots are full, misbehaving nodes will be disconnected to make room for nodes that have no history of problems (unless the misbehaving node is helping your node in other ways. Previously, Bitcoin Core banned the IP addresses of misbehaving peers for a period of time (1 day by default), which was easily circumvented by an attacker with multiple IP addresses. If a peer is manually banned, for example using the setban RPC, all connections from that peer will still be rejected. wallet The first time you use an HD seed, you will need to upgrade your key metadata. For unencrypted wallets, this will happen when the wallet is loaded. For encrypted wallets, this will happen when the wallet is first unlocked. Security This release changes the random number generator (RNG) used in OpenSSL to Bitcoin Core’s own implementation (although the entropy collected by Bitcoin Core is exported to OpenSSL and then read back in when a program needs strong randomness). This brings Bitcoin Core one step closer to no longer depending on OpenSSL, a dependency that has caused security issues in the past. Acknowledgements Thanks to everyone who was directly involved in this software release. |
