Bitcoin Core舊版本下載（所有版本）

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 macOS) 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 tested on operating systems using the Linux Kernel 3.17+, macOS 13+, and Windows 10+. 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.
Notable changes
P2P and Network Changes
- Support for UPnP was dropped. If you want to open a port automatically, consider using the -natpmp option instead, which uses PCP or NAT-PMP depending on router support. (#31130)
- libnatpmp was replaced with a built-in implementation of PCP and NAT-PMP (still enabled using the -natpmp option). This supports automatic IPv4 port forwarding as well as IPv6 pinholing. (#30043)
- When the -port configuration option is used, the default onion listening port will now be derived to be that port + 1 instead of being set to a fixed value (8334 on mainnet). This re-allows setups with multiple local nodes using different -port and not using -bind, which would lead to a startup failure in v28.0 due to a port collision. Note that a HiddenServicePort manually configured in torrc may need adjustment if used in connection with the -port option. For example, if you are using -port=5555 with a non-standard value and not using -bind=...=onion, previously Bitcoin Core would listen for incoming Tor connections on 127.0.0.1:8334. Now it would listen on 127.0.0.1:5556 (-port plus one). If you configured the hidden service manually in torrc now you have to change it from HiddenServicePort 8333 127.0.0.1:8334 to HiddenServicePort 8333 127.0.0.1:5556, or configure bitcoind with -bind=127.0.0.1:8334=onion to get the previous behavior. (#31223)
- Upon receiving an orphan transaction (an unconfirmed transaction that spends unknown inputs), the node will attempt to download missing parents from all peers who announced the orphan. This change may increase bandwidth usage but make orphan-handling more reliable. (#31397)
Mempool Policy and Mining Changes
- Ephemeral dust is a new concept that allows a single dust output in a transaction, provided the transaction is zero fee. In order to spend any unconfirmed outputs from this transaction, the spender must also spend this dust in addition to any other desired outputs. In other words, this type of transaction should be created in a transaction package where the dust is both created and spent simultaneously. (#30239)
- Due to a bug, the default block reserved weight (4,000 WU) for fixed-size block header, transactions count, and coinbase transaction was reserved twice and could not be lowered. As a result the total reserved weight was always 8,000 WU, meaning that even when specifying a -blockmaxweight higher than the default (even to the max of 4,000,000 WU), the actual block size will never exceed 3,992,000 WU. The fix consolidates the reservation into a single place and introduces a new startup option, -blockreservedweight which specifies the reserved weight directly. The default value of -blockreservedweight is set to 8,000 WU to ensure backward compatibility for users who relied on the previous behavior of -blockmaxweight. The minimum value of -blockreservedweight is set to 2,000 WU. Users setting -blockreservedweight below the default should ensure that the total weight of their block header, transaction count, and coinbase transaction does not exceed the reduced value or they may risk mining an invalid block. (#31384)
Updated RPCs
- The RPC testmempoolaccept response now includes a

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 macOS) 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 3.17+, macOS 11.0+, 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.
Notable changes
Build
- #31407 guix: Notarize MacOS app bundle and codesign all MacOS and Windows binaries
- #31500 depends: Fix compiling libevent package on NetBSD
- #31627 depends: Fix spacing issue
- #32070 build: use make < 3.82 syntax for define directive
- #32439 guix: accomodate migration to codeberg
- #32568 depends: use "mkdir -p" when installing xproto
- #32693 depends: fix cmake compatibility error for freetype
Test
- #32286 test: Handle empty string returned by CLI as None in RPC tests
- #32336 test: Suppress upstream -Wduplicate-decl-specifier in bpfcc
Tracing
- #31623 tracing: Rename the MIN macro to TRACEPOINT_TEST_MIN in log_raw_p2p_msgs
Doc
- #32003 doc: remove note about macOS self-signing
Misc
- #31611 doc: upgrade license to 2025
- #32187 refactor: Remove spurious virtual from final ~CZMQNotificationInterface