Bitcoin Core 22.0 Released

Home Bitcoin Core 22.0 Released Bitcoin Core 22.0 Released CryptoworldSeptember 16, 2021 Bitcoin Core version 22.0 is now available from: https://bitcoincore.org/bin/bitcoin-core-22.0/ Or through bittorrent This release includes new features, various bug fixes and performance improvements, as well as updated translations. Please report bugs using the issue tracker at GitHub: https://github.com/bitcoin/bitcoin/issues To receive security and update notifications, please subscribe to: https://bitcoincore.org/en/list/announcements/join/ How to Upgrade If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes in some cases), then run the 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 it might take some time if the data directory needs to be migrated. Old wallet versions of Bitcoin Core are generally supported. Compatibility Bitcoin Core is supported and extensively tested on operating systems using the Linux kernel, macOS 10.14+, and Windows 7 and newer. Bitcoin Core should also work on most other Unix-like systems but is not as frequently tested on them. It is not recommended to use Bitcoin Core on unsupported systems. From Bitcoin Core 22.0 onwards, macOS versions earlier than 10.14 are no longer supported. Notable changes P2P and network changes Added support for running Bitcoin Core as an I2P (Invisible Internet Project) service and connect to such services. See i2p.md for details. (#20685) This release removes support for Tor version 2 hidden services in favor of Tor v3 only, as the Tor network dropped support for Tor v2 with the release of Tor version 0.4.6. Henceforth, Bitcoin Core ignores Tor v2 addresses; it neither rumors them over the network to other peers, nor stores them in memory or to peers.dat. (#22050) Added NAT-PMP port mapping support via libnatpmp. (#18077) New and Updated RPCs Due to BIP 350 being implemented, behavior for all RPCs that accept addresses is changed when a native witness version 1 (or higher) is passed. These now require a Bech32m encoding instead of a Bech32 one, and Bech32m encoding will be used for such addresses in RPC output as well. No version 1 addresses should be created for mainnet until consensus rules are adopted that give them meaning (as will happen through BIP 341). Once that happens, Bech32m is expected to be used for them, so this shouldn't affect any production systems, but may be observed on other networks where such addresses already have meaning (like signet). (#20861) The getpeerinfo RPC returns two new boolean fields, bip152_hb_to and bip152_hb_from, that respectively indicate whether we selected a peer to be in compact blocks high-bandwidth mode or whether a peer selected us as a compact blocks high-bandwidth peer. High-bandwidth peers send new block announcements via a cmpctblock message rather than the usual inv/headers announcements. See BIP 152 for more details. (#19776) getpeerinfo no longer returns the following fields: addnode, banscore, and whitelisted, which were previously deprecated in 0.21. Instead of addnode, the connection_type field returns manual. Instead of whitelisted, the permissions field indicates if the peer has special privileges. The banscore field has simply been removed. (#20755) The following RPCs: gettxout, getrawtransaction, decoderawtransaction, decodescript, gettransaction, and REST endpoints: /rest/tx, /rest/getutxos, /rest/block deprecated the following fields (which are no longer returned in the responses by default): addresses, reqSigs. The -deprecatedrpc=addresses flag must be passed for these fields to be included in the RPC response. This flag/option will be available only for this major release, after which the deprecation will be removed entirely. Note that these fields are attributes of the scriptPubKey object returned in the RPC response. However, in the response of decodescript these fields are top-level attributes, and included again as attributes of the scriptPubKey object. (#20286) When creating a hex-encoded bitcoin transaction using the bitcoin-tx utility with the -json option set, the following fields: addresses, reqSigs are no longer returned in the tx output of the response. (#20286) The listbanned RPC now returns two new numeric fields: ban_duration and time_remaining. Respectively, these new fields indicate the duration of a ban and the time remaining until a ban expires, both in seconds. Additionally, the ban_created field is repositioned to come before banned_until. (#21602) The setban RPC can ban onion addresses again. This fixes a regression introduced in version 0.21.0. (#20852) The getnodeaddresses RPC now returns a "network" field indicating the network type (ipv4, ipv6, onion, or i2p) for each address. (#21594) getnodeaddresses now also accepts a "network" argument (ipv4, ipv6, onion, or i2p) to return only addresses of the specified network. (#21843) The testmempoolaccept RPC now accepts multiple transactions (still experimental at the moment, API may be unstable). This is intended for testing transaction packages with dependency relationships; it is not recommended for batch-validating independent transactions. In addition to mempool policy, package policies apply: the list cannot contain more than 25 transactions or have a total size exceeding 101K virtual bytes, and cannot conflict with (spend the same inputs as) each other or the mempool, even if it would be a valid BIP125 replace-by-fee. There are some known limitations to the accuracy of the test accept: it's possible for testmempoolaccept to return "allowed"=True for a group of transactions, but "too-long-mempool-chain" if they are actually submitted. (#20833) addmultisigaddress and createmultisig now support up to 20 keys for Segwit addresses. (#20867) Changes to Wallet or GUI related RPCs can be found in the GUI or Wallet section below. Build System Release binaries are now produced using the new guix-based build system. The document has been updated accordingly. Files The list of banned hosts and networks (via setban RPC) is now saved on disk in JSON format in banlist.json instead of banlist.dat. banlist.dat is only read on startup if banlist.json is not present. Changes are only written to the new banlist.json. A future version of Bitcoin Core may completely ignore banlist.dat. (#20966) New settings The -natpmp option has been added to use NAT-PMP to map the listening port. If both UPnP and NAT-PMP are enabled, a successful allocation from UPnP prevails over one from NAT-PMP. (#18077) Updated settings Changes to Wallet or GUI related settings can be found in the GUI or Wallet section below. Passing an invalid -rpcauth argument now cause bitcoind to fail to start. (#20461) Tools and Utilities A new CLI -addrinfo command returns the number of addresses known to the node per network type (including Tor v2 versus v3) and total. This can be useful to see if the node knows enough addresses in a network to use options like -onlynet= or to upgrade to this release of Bitcoin Core 22.0 that supports Tor v3 only. (#21595) A new -rpcwaittimeout argument to bitcoin-cli sets the timeout in seconds to use with -rpcwait. If the timeout expires, bitcoin-cli will report a failure. (#21056) Wallet External signers such as hardware wallets can now be used through the new RPC methods enumeratesigners and displayaddress. Support is also added to the send RPC call. This feature is experimental. See external-signer.md for details. (#16546) A new listdescriptors RPC is available to inspect the contents of descriptor-enabled wallets. The RPC returns public versions of all imported descriptors, including their timestamp and flags. For ranged descriptors, it also returns the range boundaries and the next index to generate addresses from. (#20226) The bumpfee RPC is not available with wallets that have private keys disabled. psbtbumpfee can be used instead. (#20891) The fundrawtransaction, send and walletcreatefundedpsbt RPCs now support an include_unsafe option that when true allows using unsafe inputs to fund the transaction. Note that the resulting transaction may become invalid if one of the unsafe inputs disappears. If that happens, the transaction must be funded with different inputs and republished. (#21359) We now support up to 20 keys in multi() and sortedmulti() descriptors under wsh(). (#20867)

Welcome to the Bitcoin World

 

Bitcoin

Bitcoin is a peer to peer electronic cash system created by Dr. Craig Wright under the pseudonym Satoshi Nakamoto. It was first detailed in the Bitcoin Whitepaper in October 2008, and the source code was released in January 2009. The Bitcoin ledger and Block chain were established with the generation of the Genesis block on the 3rd of January 2009 and the mining of Block 1 six days later on the 9th of January 2009.

Bitcoin allows electronic payments to be sent directly from one party to another, without requiring a central institution or server to process transactions and/or store funds.

The leaderless structure of the network is viewed as a resolution to The Byzantine Generals Problem allowing disconnected entities to follow a common direction without centralised instruction. This solves several issues previously seen as unsolvable in distributed networks, including the problem of preventing Double-spending of coins.

Applications

Bitcoin is primarily a payment system which supports peer to peer connection and Instant Transactions. Early in the History of Bitcoin payments required users to understand complicated technical details of Bitcoin's technological underpinnings to make transactions. But developments such as Paymail and Simplified Payment Verification are changing the landscape and making it much easier for users to connect.

Bitcoin also supports the development of application layer protocols which make use of Bitcoin Transactions as a transport layer for information exchange. Several Application layer protocols already exist for BitcoinSV - for more detail see Building on Bitcoin. The Metanet fuses Bitcoin's highly secure and instant sub-cent transactions with onchain data storage and transferability enabling efficient and secure web usage. This will bring forth an Internet of Value where Micropayments become a means to both access and monetize data.

Applications which make use of the immutable nature of the Bitcoin Ledger to store and retrieve data are emerging at an increasing rate. False Return scripts and other scripts that use Pushdata Opcodes to push data into Bitcoin transactions are creating new ways of recording data for public consumption. Bitcoin acts as a timestamp server allowing data to be validated and referenced using transactions.

Network

The Bitcoin Network is the network that all peers use to access the ledger. The network forms spontaneously over time as more peers access and use the system. There is no central governance that determines how peers on the network must connect, but the incentive structure that Bitcoin employs to bring enterprise miners into the system results in a spontaneously formed system which is simple and resilient.

Once the final restrictions on the protocol are removed in the Chronicle Update (expected early-mid 2021) network users will be able to create partitioned zones which employ specific rulesets particular to their requirements. This will be enabled by creating transactions that use OP_VER to give particular subsets of nodes specialised instructions, and will create the effect of layered network partitions over the core system which are referred to as Bitcoin Layered Networks.

The Ledger

The Bitcoin ledger is a record of all valid transactions that have ever been transmitted to the network. The ledger is formed as a Directed Acyclic Graph (DAG) where each transaction is a node. The graph starts at the Coinbase transaction of the first block ever found and via chains of digital signatures maps out the entire history of valid exchange actions, allowing the tracing of all bitcoins back to their creation.