In this guide we will walk through the steps on how to upgrade your Bitcoin Core node to the latest version and the features available through version 22.0
Bitcoin core full-node setup
Bitcoin Core is the original Bitcoin client and it builds the backbone of the bitcoin network. Bitcoin core downloads and store full blockchain history of every Bitcoin transactions therefore depending on the speed of your network/hardware, the synchronisation process can take anywhere from a few hours to a day or more. Check out the Bitcoin core setup guide if you want to run own your bitcoin node.
Upgrade Bitcoin Core Step-by-Step guide:
First of all, Stop bitcoin core before upgrade process can start.
$ bitcoin-cli stop Bitcoin server stopping
Make sure bitcoin core node is stopped
$ bitcoin-cli status error: Could not connect to the server 127.0.0.1:8332
Install the latest version of Bitcoin Core
There are multiple ways you can upgrade a Bitcoin core node. We will be covering in this article how to upgrade using all these methods.
Upgrade Bitcoin Core node securely using prebuilt binaries
Download the Bitcoin Core full-node binaries for Ubuntu OS
Download the Bitcoin Core signature file
Verify that the hash of the downloaded version file matches the hash in the signature file, this is to make sure you have downloaded the correct file for which the Bitcoin core developers have signed.
$ sha256sum bitcoin-22.0-x86_64-linux-gnu.tar.gz 59ebd25dd82a51638b7a6bb914586201e67db67b919b2a1ff08925a7936d1b16 bitcoin-22.0-x86_64-linux-gnu.tar.gz
$ cat SHA256SUMS | grep bitcoin-22.0-x86_64-linux-gnu.tar.gz 59ebd25dd82a51638b7a6bb914586201e67db67b919b2a1ff08925a7936d1b16 bitcoin-22.0-x86_64-linux-gnu.tar.gz
$ sha256sum --ignore-missing --check SHA256SUMS bitcoin-22.0-x86_64-linux-gnu.tar.gz: OK
Bitcoin releases are signed by a number of individuals, each with a unique public key. In order to recognise the validity of signatures, you must use GPG to load these public keys locally. You can find many developer keys listed in the bitcoin/bitcoin repository, which you can then load into your GPG key database.
$ gpg --keyserver hkps://keys.openpgp.org --recv-keys E777299FC265DD04793070EB944D35F9AC3DB76A
gpg: key 944D35F9AC3DB76A: public key "Michael Ford (bitcoin-otc) <[email protected]>" imported gpg: Total number processed: 1 gpg: imported: 1
Verify that the checksums file is PGP signed by the release signing key:
$ gpg --verify SHA256SUMS.asc Good signature from "Michael Ford (bitcoin-otc) <[email protected]>" [unknown] gpg: WARNING: The key's User ID is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: E777 299F C265 DD04 7930 70EB 944D 35F9 AC3D B76A Subkey fingerprint: CFB1 6E21 C950 F67F A95E 558F 2EEB 9F5C C095 26C1 gpg: Signature made Fri 10 Sep 09:03:16 2021 BST gpg: using RSA key 6E01EEC9656903B0542B8F1003DB6322267C373B gpg: issuer "[email protected]"
Congrats! you can now be assured that the Bitcoin Core upgrade binary is signed by at least one of its developers and is secure for usage.
You can now extract the file and copy-paste the binaries to its location.
Mostly the binaries are in /usr/bin/ or usr/local/bin file. You can check it for Bitcoin by running the command:
$ which bitcoind
Upgrade Bitcoin Core node from source code
Clone the Bitcoin core git repository.
$ git clone https://github.com/bitcoin/bitcoin.git
Change the current working directory to the bitcoin repo you just cloned.
$ cd bitcoin
Checkout to the desired version tag, in this case 22.0
$ git checkout v22.0
Finally, compile the latest version of Bitcoin Core with these steps.
$ ./autogen.sh $ ./configure $ make $ sudo make install
NOTE: You can enable or disable bitcoin core features when running the ./configure command
Upgrade Bitcoin Core full-node third party PPA
This is one of the easiest way to upgrade Bitcoin core node. Simply run the below update command for Ubuntu if you have installed Bitcoin using third party PPA.
$ sudo apt-get update
Start the Bitcoin Core daemon
$ bitcoind --version Bitcoin Core Daemon version v0.18.0 $ bitcoind -daemon Bitcoin server starting
How to check Check Bitcoin Core logs
$ tail -f ~/.bitcoin/debug.log
Bitcoin Core 22.0 Release Notes
Bitcoin Core version 22.0 is now available from:
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:
To receive security and update notifications, please subscribe to:
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
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.
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.
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
- Added NAT-PMP port mapping support via
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)
getpeerinfoRPC returns two new boolean fields,
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
cmpctblockmessage rather than the usual inv/headers announcements. See BIP 152 for more details. (#19776)
getpeerinfono longer returns the following fields:
whitelisted, which were previously deprecated in 0.21. Instead of
connection_typefield returns manual. Instead of
permissionsfield indicates if the peer has special privileges. The
banscorefield has simply been removed. (#20755)
- The following RPCs:
gettransaction, and REST endpoints:
/rest/blockdeprecated the following fields (which are no longer returned in the responses by default):
-deprecatedrpc=addressesflag 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
scriptPubKeyobject returned in the RPC response. However, in the response of
decodescriptthese fields are top-level attributes, and included again as attributes of the
- When creating a hex-encoded bitcoin transaction using the
bitcoin-txutility with the
-jsonoption set, the following fields:
reqSigsare no longer returned in the tx output of the response. (#20286)
listbannedRPC now returns two new numeric fields:
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_createdfield is repositioned to come before
setbanRPC can ban onion addresses again. This fixes a regression introduced in version 0.21.0. (#20852)
getnodeaddressesRPC now returns a "network" field indicating the network type (ipv4, ipv6, onion, or i2p) for each address. (#21594)
getnodeaddressesnow also accepts a "network" argument (ipv4, ipv6, onion, or i2p) to return only addresses of the specified network. (#21843)
testmempoolacceptRPC 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
testmempoolacceptto return "allowed"=True for a group of transactions, but "too-long-mempool-chain" if they are actually submitted. (#20833)
createmultisignow 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.
- Release binaries are now produced using the new
guix-based build system. The /doc/release-process.md document has been updated accordingly.
- The list of banned hosts and networks (via
setbanRPC) is now saved on disk in JSON format in
banlist.datis only read on startup if
banlist.jsonis not present. Changes are only written to the new
banlist.json. A future version of Bitcoin Core may completely ignore
-natpmpoption 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)
Changes to Wallet or GUI related settings can be found in the GUI or Wallet section below.
- Passing an invalid
-rpcauthargument now cause bitcoind to fail to start. (#20461)
Tools and Utilities
- A new CLI
-addrinfocommand 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=<network>or to upgrade to this release of Bitcoin Core 22.0 that supports Tor v3 only. (#21595)
- A new
bitcoin-clisets the timeout in seconds to use with
-rpcwait. If the timeout expires,
bitcoin-cliwill report a failure. (#21056)
- External signers such as hardware wallets can now be used through the new RPC methods
displayaddress. Support is also added to the
sendRPC call. This feature is experimental. See external-signer.md for details. (#16546)
- A new
listdescriptorsRPC 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)
bumpfeeRPC is not available with wallets that have private keys disabled.
psbtbumpfeecan be used instead. (#20891)
walletcreatefundedpsbtRPCs now support an
include_unsafeoption that when
trueallows 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
- Taproot descriptors can be imported into the wallet only after activation has occurred on the network (e.g. mainnet, testnet, signet) in use. See descriptors.md for supported descriptors.
- External signers such as hardware wallets can now be used. These require an external tool such as HWI to be installed and configured under Options -> Wallet. When creating a new wallet a new option "External signer" will appear in the dialog. If the device is detected, its name is suggested as the wallet name. The watch-only keys are then automatically imported. Receive addresses can be verified on the device. The send dialog will automatically use the connected device. This feature is experimental and the UI may freeze for a few seconds when performing these actions.
- The RPC server can process a limited number of simultaneous RPC requests. Previously, if this limit was exceeded, the RPC server would respond with status code 500 (
HTTP_INTERNAL_SERVER_ERROR). Now it returns status code 503 (
Error codes have been updated to be more accurate for the following error cases (#18466):
signmessagenow returns RPC_INVALID_ADDRESS_OR_KEY (-5) if the passed address is invalid. Previously returned RPC_TYPE_ERROR (-3).
verifymessagenow returns RPC_INVALID_ADDRESS_OR_KEY (-5) if the passed address is invalid. Previously returned RPC_TYPE_ERROR (-3).
verifymessagenow returns RPC_TYPE_ERROR (-3) if the passed signature is malformed. Previously returned RPC_INVALID_ADDRESS_OR_KEY (-5).
Full Release note can be found on below link.