In this guide we will discuss how to upgrade your Bitcoin Core node to the newest stable version.
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. If you ever need to go back to older version, follow our bitcoin core 22.0 version install guide.
$ 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-23.0-x86_64-linux-gnu.tar.gz 2cca490c1f2842884a3c5b0606f179f9f937177da4eadd628e3f7fd7e25d26d0 bitcoin-23.0-x86_64-linux-gnu.tar.gz
cat SHA256SUMS | grep bitcoin-23.0-x86_64-linux-gnu.tar.gz 2cca490c1f2842884a3c5b0606f179f9f937177da4eadd628e3f7fd7e25d26d0 bitcoin-23.0-x86_64-linux-gnu.tar.gz
$ sha256sum --ignore-missing --check SHA256SUMS bitcoin-23.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]"
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 23.0 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 23.0
$ git checkout v23.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 23.0 Release Notes
Bitcoin Core version 23.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.15+, 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.
P2P and network changes
- A bitcoind node will no longer rumour addresses to inbound peers by default. They will become eligible for address gossip after sending an ADDR, ADDRV2, or GETADDR message. (#21528)
- Before this release, Bitcoin Core had a strong preference to try to connect only to peers that listen on port 8333. As a result of that, Bitcoin nodes listening on non-standard ports would likely not get any Bitcoin Core peers connecting to them. This preference has been removed. (#23542)
- Full support has been added for the CJDNS network. See the new option
-cjdnsreachableand doc/cjdns.md (#23077)
Fee estimation changes
- Fee estimation now takes the feerate of replacement (RBF) transactions into account. (#22539)
Rescan startup parameter removed
-rescan startup parameter has been removed. Wallets which require rescanning due to corruption will still be rescanned on startup. Otherwise, please use the
rescanblockchain RPC to trigger a rescan. (#23123)
Tracepoints and Userspace, Statically Defined Tracing support
Bitcoin Core release binaries for Linux now include experimental tracepoints which act as an interface for process-internal events. These can be used for review, debugging, monitoring, and more. The tracepoint API is semi-stable. While the API is tested, process internals might change between releases requiring changes to the tracepoints. Information about the existing tracepoints can be found under doc/tracing.md and usage examples are provided in contrib/tracing/.
validateaddressRPC now returns an
error_locationsarray for invalid addresses, with the indices of invalid character locations in the address (if known). For example, this will attempt to locate up to two Bech32 errors, and return their locations if successful. Success and correctness are only guaranteed if fewer than two substitution errors have been made. The error message returned in the
errorfield now also returns more specific errors when decoding fails. (#16807)
-deprecatedrpc=addressesconfiguration option has been removed. RPCs
gettransaction verbose=trueand REST endpoints
/rest/blockno longer return the
reqSigsfields, which were previously deprecated in 22.0. (#22650)
getblock RPC command now supports verbosity level 3 containing transaction inputs'
prevout information. The existing
/rest/block/ REST endpoint is modified to contain this information too. Every
vin field will contain an additional
prevout subfield describing the spent output.
prevout contains the following keys:
generated- true if the spent coins was a coinbase.
- The top-level fee fields
descendantfeesreturned by RPCs
getmempooldescendants(verbose=true)are deprecated and will be removed in the next major version (use
-deprecated=feesif needed in this version). The same fee fields can be accessed through the
feesobject in the result. WARNING: deprecated fields
descendantfeesare denominated in sats, whereas all fields in the
feesobject are denominated in BTC. (#22689)
addmultisigaddressnow include a
warningsfield, which will show a warning if a non-legacy address type is requested when using uncompressed public keys. (#23113)
Changes to wallet related RPCs can be found in the Wallet section below.
- Information on soft fork status has been moved from
getblockchaininfoto the new
getdeploymentinfoRPC which allows querying soft fork status at any block, rather than just at the chain tip. Inclusion of soft fork status in
getblockchaininfocan currently be restored using the configuration
-deprecatedrpc=softforks, but this will be removed in a future release. Note that in either case, the
statusfield now reflects the status of the current block rather than the next block. (#23508)
- On startup, the list of banned hosts and networks (via
banlist.datis ignored and only
banlist.jsonis considered. Bitcoin Core version 22.x is the only version that can read
banlist.datand also write it to
banlist.jsonalready exists, version 22.x will not try to translate the
banlist.datinto json. After an upgrade,
listbannedcan be used to double check the parsed entries. (#22570)
- In previous releases, the meaning of the command line option
-persistmempool(without a value provided) incorrectly disabled mempool persistence.
-persistmempoolis now treated like other boolean options to mean
-nopersistmempoolis unaffected. (#23061)
-maxuploadtargetnow allows human readable byte units [k|K|m|M|g|G|t|T]. E.g.
-maxuploadtarget=500g. No whitespace, +- or fractions allowed. Default is
Mif no suffix provided. (#23249)
-proxy=is given together with
-noonionthen the provided proxy will not be set as a proxy for reaching the Tor network. So it will not be possible to open manual connections to the Tor network for example with the
addnodeRPC. To mimic the old behavior use
-onlynet=listing all relevant networks except
Tools and Utilities
-getinfoto return data in a user-friendly format that also reduces vertical space. (#21832)
-addrinfonow returns a single field for the number of
onionaddresses known to the node instead of separate
torv3fields, as support for Tor V2 addresses was removed from Bitcoin Core in 22.0. (#22544)
Descriptor wallets are now the default wallet type. Newly created wallets will use descriptors unless
descriptors=false is set during
createwallet, or the
Descriptor wallet checkbox is unchecked in the GUI.
Note that wallet RPC commands like
dumpprivkey cannot be used with descriptor wallets, so if your client code relies on these commands without specifying
descriptors=false during wallet creation, you will need to update your code.
- Newly created descriptor wallets will contain an automatically generated
tr()descriptor which allows for creating single key Taproot receiving addresses.
upgradewalletwill now automatically flush the keypool if upgrading from a non-HD wallet to an HD wallet, to immediately start using the newly-generated HD keys. (#23093)
- a new RPC
newkeypoolhas been added, which will flush (entirely clear and refill) the keypool. (#23093)
ancestorfeesfor each transaction output that is still in the mempool. (#12677)
lockunspentnow optionally takes a third parameter,
persistent, which causes the lock to be written persistently to the wallet database. This allows UTXOs to remain locked even after node restarts or crashes. (#23065)
receivedbyRPCs now include coinbase transactions. Previously, the following wallet RPCs excluded coinbase transactions:
listreceivedbylabel. This release changes this behaviour and returns results accounting for received coins from coinbase outputs. The previous behaviour can be restored using the configuration
-deprecatedrpc=exclude_coinbase, but may be removed in a future release. (#14707)
- A new option in the same
false), determines whether to account for immature coinbase transactions. Immature coinbase transactions are coinbase transactions that have 100 or fewer confirmations, and are not spendable. (#14707)
- UTXOs which are locked via the GUI are now stored persistently in the wallet database, so are not lost on node shutdown or crash. (#23065)
- The Bech32 checkbox has been replaced with a dropdown for all address types, including the new Bech32m (BIP-350) standard for Taproot enabled wallets.
getblockchaininfonow returns a new
timefield, that provides the chain tip time. (#22407)
- For the
regtestnetwork the activation heights of several softforks were set to block height 1. They can be changed by the runtime setting
Full Release note for bitcoin core 23.0 can be found on below link.