Bitcoin-Qt

Bitcoin-Qt interface.

Bitcoin-Qt was the name used for the graphical Bitcoin client from version 0.5.0 until the software was rebranded as Bitcoin Core in version 0.9.0. It is not a separate current wallet: modern Bitcoin Core releases still use the executable name bitcoin-qt for their graphical interface.

Naming history

Satoshi Nakamoto released the original Bitcoin software in 2009. The Qt-based graphical interface arrived with version 0.5.0 in November 2011, replacing the earlier wxWidgets interface; releases in this period were called Bitcoin-Qt. Version 0.9.0 adopted the Bitcoin Core name to distinguish the software project from the Bitcoin network and currency. The program name bitcoin-qt remains in release documentation, while bitcoind is the command-line daemon.

The two naming milestones have specific release dates: Bitcoin-Qt 0.5.0 was announced on 21 November 2011, and Bitcoin Core 0.9.0 on 19 March 2014. The latter release also separated the RPC client into bitcoin-cli. These were software-project changes; the rename did not create a new currency or require a new Bitcoin balance.

What it is today

Bitcoin Core is open-source software that includes a fully validating Bitcoin node and an optional wallet. A full node checks blocks and transactions against its own rules and can relay valid data to peers; initial synchronization therefore uses substantial storage, bandwidth and time. Pruning can reduce stored block data, but it does not turn Bitcoin Core into a lightweight client.

The node and wallet have different jobs. A node can validate and relay Bitcoin data without holding private keys or spending coins. Since version 0.21, Bitcoin Core no longer creates a default wallet automatically; users can create or open wallets separately through the graphical interface.

Bitcoin Core is not an “official client” controlled by the Bitcoin Foundation. Anyone can propose, test or review changes. Repository maintainers merge patches after public review, and users independently choose which software and rules to run.

Programs and architecture

Bitcoin Core is distributed as a set of related programs rather than only a desktop wallet. bitcoin-qt combines the node and wallet with a graphical interface; bitcoind runs the node and wallet as a daemon; and bitcoin-cli sends remote procedure calls to a running instance. The distribution also includes bitcoin-tx for transaction manipulation, bitcoin-wallet for wallet maintenance and other utilities.

The graphical application does not replace the validation engine. It presents node status, peer and synchronization information, transaction history, sending and receiving functions, fee controls and wallet management while using the same underlying node and wallet interfaces. Operators who do not need a desktop interface commonly run bitcoind instead.

Version 30.0 added a bitcoin command that dispatches to existing programs: bitcoin gui invokes bitcoin-qt, bitcoin node invokes bitcoind, and bitcoin rpc invokes bitcoin-cli with named arguments. The release notes explicitly retain the direct commands. Running the graphical application starts its node functionality; a separate bitcoind process is not required merely to use the GUI.

The Qt toolkit has continued to evolve after the project rename. Bitcoin Core 30.0 moved its graphical interface from Qt 5 to Qt 6, and the 31.0 release notes document an update to Qt 6.8. The executable name bitcoin-qt therefore does not mean that the program is still the old 2011 client.

Validation, synchronization and pruning

A new node downloads block data and independently checks the proof of work, transaction structure and applicable consensus rules. Its chainstate database records the currently unspent transaction outputs needed to validate later transactions. This is why Bitcoin Core offers stronger independent verification than a wallet that relies on a third-party server, but also requires more time, bandwidth and disk space.

Block pruning, introduced in Bitcoin Core 0.11, allows a fully validating node to delete older raw block and undo files after using them to build the block index and UTXO set. Pruning reduces storage but does not skip validation. It can restrict operations that require old block data, such as some rescans or historical transaction queries; later releases added wallet support in pruned mode.

Wallets and transactions

The wallet tracks keys or signing policies and the transaction outputs it can spend. A displayed balance is therefore the sum of one or more unspent transaction outputs (UTXOs), not a single value stored at one address. When selected UTXOs exceed a payment plus its fee, the transaction normally creates a change output returning the remainder to a wallet-controlled script. Change is not a second fee or a payment lost to an unfamiliar address.

Old configuration examples can also outlive the interfaces they describe. Bitcoin Core 31.0 removed the paytxfee startup option and settxfee RPC after their deprecation in 30.0. Its release notes direct users toward fee estimation or transaction-specific fee rates, so an old Bitcoin-Qt fee-setting example should be checked against the version being used.

Address generation and change handling are reasons wallet backups and key management matter. Modern wallets can derive many receiving and change scripts from recorded descriptors. Copying an active wallet database as though it were an ordinary document can be unsafe; the project documentation recommends the wallet backup function, which coordinates the database while producing a backup.

The blockchain data and the wallet serve different purposes. Downloading blocks again does not replace lost private keys. The documented Backup Wallet function or backupwallet RPC produces a coordinated database backup. Wallet encryption protects private keys, but it does not conceal transaction history or public-key metadata, and it cannot recover a forgotten passphrase. The wallet-management documentation calls for a fresh backup after encryption and after migration; backups should be protected as sensitive wallet material.

Legacy wallets and migration

Bitcoin Core added multiwallet support in version 0.15. Descriptor wallets were introduced experimentally in 0.21, became the default for newly created wallets in 23.0, and replaced legacy Berkeley DB wallets in version 30.0. Descriptor wallets explicitly describe the scripts and keys a wallet watches and use SQLite storage. These changes make many old Bitcoin-Qt backup, import and recovery instructions version-specific rather than generally applicable.

From version 30.0, legacy Berkeley DB wallets can no longer be created or loaded for ordinary use, although migration to descriptor wallets remains available. Version 26.0 introduced a graphical migration option. Migration can produce separate watch-only or solvable-script wallets as well as the main descriptor wallet. The project describes this as a best-effort conversion: unusual script configurations may need further attention. It retains a legacy backup and requires new backups of the resulting wallets. An old wallet.dat filename alone does not identify its database format or the recovery procedure it needs.

Watch-only wallets and external signing

A wallet that watches public keys or scripts can track relevant payments without having the private keys needed to spend them. External signing separates transaction preparation from signing: Bitcoin Core 22.0 added experimental GUI support for external signers, including hardware wallets, using a separately installed tool such as HWI. Support depends on the tool, device and software version; it is not a promise of compatibility with every hardware wallet. The project also supports Partially Signed Bitcoin Transactions (PSBTs), a format that lets multiple programs exchange a transaction while collecting the information and signatures needed to complete it.

Download and security

Current software should be obtained from the Bitcoin Core project, not from pages or mirrors offering “Bitcoin-Qt.” The official download page publishes SHA-256 checksums and signatures and explains how to verify them. Users remain responsible for protecting and backing up wallet material and for securing the computer against malware. Old Bitcoin-Qt instructions may describe obsolete releases, file formats or recovery steps and should not be followed without checking current Bitcoin Core documentation.

A January 2026 project notice identified a specific migration bug in Bitcoin Core 30.0 and 30.1: under rare failure conditions involving a default, unnamed legacy wallet.dat, migration through the GUI or RPC could delete files in the wallet directory and cause loss of funds. The notice said users not attempting migration were unaffected. The affected binaries were withdrawn, and the 30.2 release notes list the fix. This makes old instructions to migrate using 30.0 or 30.1 unsafe; the warning concerns those migration paths, not every use of Bitcoin Core or every later migration.