Bitcoin Core 27.0 Released

[achow101]

27.0 Release Notes

Bitcoin Core version 27.0 is now available from:

https://bitcoincore.org/bin/bitcoin-core-27.0/

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 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

libbitcoinconsensus

• libbitcoinconsensus is deprecated and will be removed for v28. This library has
  existed for nearly 10 years with very little known uptake or impact. It has
  become a maintenance burden.
  
  The underlying functionality does not change between versions, so any users of
  the library can continue to use the final release indefinitely, with the
  understanding that Taproot is its final consensus update.
  
  In the future, libbitcoinkernel will provide a much more useful API that is
  aware of the UTXO set, and therefore be able to fully validate transactions and
  blocks. (#29189)
  

mempool.dat compatibility

• The mempool.dat file created by -persistmempool or the savemempool RPC will
  be written in a new format. This new format includes the XOR'ing of transaction
  contents to mitigate issues where external programs (such as anti-virus) attempt
  to interpret and potentially modify the file.
  
  This new format can not be read by previous software releases. To allow for a
  downgrade, a temporary setting -persistmempoolv1 has been added to fall back
  to the legacy format. (#28207)
  

P2P and network changes

• BIP324 v2 transport is now enabled by default. It remains possible to disable v2
  by running with -v2transport=0. (#29347)
  
• Manual connection options (-connect, -addnode and -seednode) will
  now follow -v2transport to connect with v2 by default. They will retry with
  v1 on failure. (#29058)
  
• Network-adjusted time has been removed from consensus code. It is replaced
  with (unadjusted) system time. The warning for a large median time offset
  (70 minutes or more) is kept. This removes the implicit security assumption of
  requiring an honest majority of outbound peers, and increases the importance
  of the node operator ensuring their system time is (and stays) correct to not
  fall out of consensus with the network. (#28956)
  

Mempool Policy Changes

• Opt-in Topologically Restricted Until Confirmation (TRUC) Transactions policy
  (aka v3 transaction policy) is available for use on test networks when
  -acceptnonstdtxn=1 is set. By setting the transaction version number to 3, TRUC transactions
  request the application of limits on spending of their unconfirmed outputs. These
  restrictions simplify the assessment of incentive compatibility of accepting or
  replacing TRUC transactions, thus ensuring any replacements are more profitable for
  the node and making fee-bumping more reliable. TRUC transactions are currently
  nonstandard and can only be used on test networks where the standardness rules are
  relaxed or disabled (e.g. with -acceptnonstdtxn=1). (#28948)

External Signing

• Support for external signing on Windows has been disabled. It will be re-enabled
  once the underlying dependency (Boost Process), has been replaced with a different
  library. (#28967)

Updated RPCs

• The addnode RPC now follows the -v2transport option (now on by default, see above) for making connections.
  It remains possible to specify the transport type manually with the v2transport argument of addnode. (#29239)

Build System

• A C++20 capable compiler is now required to build Bitcoin Core. (#28349)
• MacOS releases are configured to use the hardened runtime libraries (#29127)

Wallet

• The CoinGrinder coin selection algorithm has been introduced to mitigate unnecessary
  large input sets and lower transaction costs at high feerates. CoinGrinder
  searches for the input set with minimal weight. Solutions found by
  CoinGrinder will produce a change output. CoinGrinder is only active at
  elevated feerates (default: 30+ sat/vB, based on -consolidatefeerate×3). (#27877)
• The Branch And Bound coin selection algorithm will be disabled when the subtract fee
  from outputs feature is used. (#28994)
• If the birth time of a descriptor is detected to be later than the first transaction
  involving that descriptor, the birth time will be reset to the earlier time. (#28920)

Low-level changes

Pruning

• When pruning during initial block download, more blocks will be pruned at each
  flush in order to speed up the syncing of such nodes. (#20827)

Init

• Various fixes to prevent issues where subsequent instances of Bitcoin Core would
  result in deletion of files in use by an existing instance. (#28784, #28946)
• Improved handling of empty settings.json files. (#29144)

Credits

Thanks to everyone who directly contributed to this release:

• 22388o⚡️
• Aaron Clauson
• Amiti Uttarwar
• Andrew Toth
• Anthony Towns
• Antoine Poinsot
• Ava Chow
• Brandon Odiwuor
• brunoerg
• Chris Stewart
• Cory Fields
• dergoegge
• djschnei21
• Fabian Jahr
• fanquake
• furszy
• Gloria Zhao
• Greg Sanders
• Hennadii Stepanov
• Hernan Marino
• iamcarlos94
• ismaelsadeeq
• Jameson Lopp
• Jesse Barton
• John Moffett
• Jon Atack
• josibake
• jrakibi
• Justin Dhillon
• Kashif Smith
• kevkevin
• Kristaps Kaupe
• L0la L33tz
• Luke Dashjr
• Lőrinc
• marco
• MarcoFalke
• Mark Friedenbach
• Marnix
• Martin Leitner-Ankerl
• Martin Zumsande
• Max Edwards
• Murch
• muxator
• naiyoma
• Nikodemas Tuckus
• ns-xvrn
• pablomartin4btc
• Peter Todd
• Pieter Wuille
• Richard Myers
• Roman Zeyde
• Russell Yanofsky
• Ryan Ofsky
• Sebastian Falbesoner
• Sergi Delgado Segura
• Sjors Provoost
• stickies-v
• stratospher
• Supachai Kheawjuy
• TheCharlatan
• UdjinM6
• Vasil Dimov
• w0xlt
• willcl-ark

As well as to everyone that helped with translations on
Transifex.

[okae]

Ty to everyone who contribute to this update!!!

Please, never forget to Verifying Bitcoin Core before you install/use it, is a good practice... also go to the source and check those SHA256SUMS by yourselft.

Code:

dcd49a8e3711d867c4ad5d7ffbc1ff20f66c82cc8bf660b5f6964eeaa289a739  bitcoin-27.0-aarch64-linux-gnu-debug.tar.gz
cb35e250ae9d0328aa90e7aad0b877ed692597420a1092e8ab1a5dd756209722  bitcoin-27.0-aarch64-linux-gnu.tar.gz
61e1225d9c00b50c2e1712e722b285b6e4de1f1dd9da969596511b8a8986c1f0  bitcoin-27.0-arm-linux-gnueabihf-debug.tar.gz
9d4c28e7620d03bf346ebea388f222e4d6d2b996d7eb32fab72707b8320d5249  bitcoin-27.0-arm-linux-gnueabihf.tar.gz
7f060f2cd07746ff9d09b000b4195fee88dfca8444ab7a73f0c76aff4225227c  bitcoin-27.0-arm64-apple-darwin.zip
d1ddb2855a6c76ab4d2cc31315303cba77ef44fdd877b01ffd5918e548b07cae  bitcoin-27.0-arm64-apple-darwin-unsigned.tar.gz
48d47cf0944034d7ef288f24ce73a6e2f85a9b6199dad5425464dd589ecf96e9  bitcoin-27.0-arm64-apple-darwin-unsigned.zip
1d9d9b837297a73fc7a3b1cfed376644e3fa25c4e1672fbc143d5946cb52431d  bitcoin-27.0-arm64-apple-darwin.tar.gz
d22f0f8b2d9eb8eac0819d5ebc4b3c4c5f5984cf6e0acefa81ebc6e914938293  bitcoin-27.0-codesignatures-27.0.tar.gz
9c1ee651d3b157baccc3388be28b8cf3bfcefcd2493b943725ad6040ca6b146b  bitcoin-27.0.tar.gz
837c72fea5ceca69b3d06870dd4926c011dec7924f3f8f3428b2153945bbbb4a  bitcoin-27.0-powerpc64-linux-gnu-debug.tar.gz
6ceaedb59ca33b751387b15f2c8da7f2f7cd2739c6464fc6cbef440852869b92  bitcoin-27.0-powerpc64-linux-gnu.tar.gz
81102572b0aee8627b162680699ce1d2828908cc4dd317e34697404ac04220fa  bitcoin-27.0-powerpc64le-linux-gnu-debug.tar.gz
3c00f81a7c67b4cf3e382fae7eaa2c7facea2dfdf39f4c281512237c06b71960  bitcoin-27.0-powerpc64le-linux-gnu.tar.gz
7274aedbfc363adc28d3b19340e4578b983cfbd617f328313fb5b95e24864799  bitcoin-27.0-riscv64-linux-gnu-debug.tar.gz
371e53b21c3ba29a90e69c30b7213d75c165d084bde50ae6d73ee0e1ef179e68  bitcoin-27.0-riscv64-linux-gnu.tar.gz
8c94d3a7e34b59effdcf283263d5e84f2b009e601076282e9697ab4244bef3e8  bitcoin-27.0-x86_64-apple-darwin.zip
8cdabb19c0b2464ec21306615e0429362b6de9b73d5e796dc4dbc82437e76ddd  bitcoin-27.0-x86_64-apple-darwin-unsigned.tar.gz
0b347bd2474eab483ee24e1751a2de3e37260826bf71340eaad233f6017af306  bitcoin-27.0-x86_64-apple-darwin-unsigned.zip
e1efd8c4605b2aabc876da93b6eee2bedd868ce7d1f02b0220c1001f903b3e2c  bitcoin-27.0-x86_64-apple-darwin.tar.gz
3d9ed703ceaeba9d234d05bf7ae20dde48fb52287eae236e8c2b2021a8db0fbc  bitcoin-27.0-x86_64-linux-gnu-debug.tar.gz
2a6974c5486f528793c79d42694b5987401e4a43c97f62b1383abf35bcee44a8  bitcoin-27.0-x86_64-linux-gnu.tar.gz
a2aa3db390a768383e8556878250a44f3eb3b7a6e91e94e47fa35c06b6e8d09f  bitcoin-27.0-win64-setup.exe
33fadef48835acf9b2dfda42b2d2015f30403608dc8af7a3f3dd2b9ec224e56e  bitcoin-27.0-win64-debug.zip
e8114ed85a976ff439bd78cbf026e3f9bfafdf40d0fe75121e73bd4b7af347a4  bitcoin-27.0-win64-setup-unsigned.exe
1578aa2b88427086336e6990e4ce9b752d3d83b34b38ecc29f6325abb6ad3694  bitcoin-27.0-win64-unsigned.tar.gz
ca75babeaa3fb75f5a166f544adaa93fd7c1f06cf20d4e2c8c2a8b010f4c7603  bitcoin-27.0-win64.zip

[satscraper]

I have tested v.27.0 on a few machines running either Linux or Windows 10/11 and got the feeling that updated nodes halt  (when needed) all operations a bit faster than when they were armored with previous v. 26.0

Anyone can confirm this observation or it is solely my impression?

[SAHASAN]

What about Apple iOS is it able to mine and others work smoothly with apply IOS system?
I want to try it with apple ios system.

[khalidkhan82118]

Wow, version 27.0 of Bitcoin Core seems packed with updates! I'm particularly intrigued by the introduction of CoinGrinder for coin selection. I wonder how much this will impact transaction costs and overall efficiency. Also, the move towards a C++20 compiler requirement is interesting. I'm curious about the implications for developers and the ecosystem as a whole. Any insights or thoughts on these changes?

[MysteryMiner]

Would not C++20 requirement cause C++ runtime files being required on Windows and in turn not working on Windows7 or 8?

Also it appears that Bitcoin have catched mild form of featuritis causing bloat without reason.

[ABCbits]

Would not C++20 requirement cause C++ runtime files being required on Windows and in turn not working on Windows7 or 8?

Looking at microsoft website, i don't think that would happen.

Current versions of the Visual C++ Redistributable for Visual Studio 2015-2022 only support Windows 7, 8.1, 10, and 11.

Although i also wonder whether Bitcoin Core actually support Windows 7 or 8.

Also it appears that Bitcoin have catched mild form of featuritis causing bloat without reason.

I'm curious, which feature you're talking about?

[MysteryMiner]

Although i also wonder whether Bitcoin Core actually support Windows 7 or 8.

Running Bitcoin Core 27.0 64-bit on Windows 7 SP1 64-bit right now without issuses. I confirm it works.

I'm curious, which feature you're talking about?

New transport protocol, new wallet formats and options. These are the very basic of Bitcoin that should not be touched without great necessity and majority consensus. Imagine I go to prison for 10 years. Or join army. Or enter coma after colliding with train. When I get back to my computer I should be able to turn on my computer and sync the Bitcoin client right away. Bitcoin now have become a value storage medium in addition to tool for transactions.

[achow101]

New transport protocol, new wallet formats and options. These are the very basic of Bitcoin that should not be touched without great necessity and majority consensus. Imagine I go to prison for 10 years. Or join army. Or enter coma after colliding with train. When I get back to my computer I should be able to turn on my computer and sync the Bitcoin client right away. Bitcoin now have become a value storage medium in addition to tool for transactions.

These features are not added "without reason".

The new transport protocol is specifically an encrypted protocol in order to make it harder to censor Bitcoin nodes. However, just because a new protocol is introduced doesn't mean that the original protocol is going away. The new protocol has considerations for backwards compatibility so it will be possible for nodes that don't understand it to still be able to connect to the network.

The new wallet format is specifically BDB is entirely unmaintained and unmaintainable. Keeping the software in general up to date is generally a hard task, and gets harder when there are dependencies that are difficult to maintain. Even so, the change to the new wallet format is still specifically being done in a way to allow users with old wallets to still be able to use them in the future. There will be a migration path that will live indefinitely, and this will allow those people to load their old wallets and migrate them to the new format. This will not result in any loss of funds, whether preexisting, or new funds sent to old addresses.

[ABCbits]

I'm curious, which feature you're talking about?

New transport protocol, new wallet formats and options. These are the very basic of Bitcoin that should not be touched without great necessity and majority consensus. Imagine I go to prison for 10 years. Or join army. Or enter coma after colliding with train. When I get back to my computer I should be able to turn on my computer and sync the Bitcoin client right away. Bitcoin now have become a value storage medium in addition to tool for transactions.

Aside from what @achow101 said, personally i expect older version of Bitcoin Core still can connect to network and sync in the future. In 2022, Jameson Lopp manage to run full node with Bitcoin Core version 0.8 which released on 2013[1]. Although you would miss any performance improvement and bug/security fix.

[1] https://blog.lopp.net/bitcoin-core-performance-evolution/

[Jascrypt]

Can someone simplify the whole thing about Bitcoin Core.27.0 and is it going help reduce cost of trxn and enhance speed?

[NotATether]

Can someone simplify the whole thing about Bitcoin Core.27.0 and is it going help reduce cost of trxn and enhance speed?

It doesn't really do any of that except for the BIP324 part which makes connections between nodes more private.

It has already been covered extensively by achow101 in the post above.

But Bitcoin Core in general has no influence on txn cost and speed.

[MarketNeutral]

New transport protocol, new wallet formats and options. These are the very basic of Bitcoin that should not be touched without great necessity and majority consensus. Imagine I go to prison for 10 years. Or join army. Or enter coma after colliding with train. When I get back to my computer I should be able to turn on my computer and sync the Bitcoin client right away. Bitcoin now have become a value storage medium in addition to tool for transactions.

These features are not added "without reason".

The new transport protocol is specifically an encrypted protocol in order to make it harder to censor Bitcoin nodes. However, just because a new protocol is introduced doesn't mean that the original protocol is going away. The new protocol has considerations for backwards compatibility so it will be possible for nodes that don't understand it to still be able to connect to the network.

The new wallet format is specifically BDB is entirely unmaintained and unmaintainable. Keeping the software in general up to date is generally a hard task, and gets harder when there are dependencies that are difficult to maintain. Even so, the change to the new wallet format is still specifically being done in a way to allow users with old wallets to still be able to use them in the future. There will be a migration path that will live indefinitely, and this will allow those people to load their old wallets and migrate them to the new format. This will not result in any loss of funds, whether preexisting, or new funds sent to old addresses.

Sorry if this has been answered elsewhere, but is there true consensus among the Bitcoin developers that a migration path from legacy wallets will indeed be supported indefinitely, even decades from now, and that all legacy formats will remain operational in all newer versions of Bitcoin? I know there may be nuance, and things may change, but I've read some opinions contrary to indefinite legacy wallet migration, and the mixed signals and uncertainty on this topic are concerning.

[achow101]

Sorry if this has been answered elsewhere, but is there true consensus among the Bitcoin developers that a migration path from legacy wallets will indeed be supported indefinitely, even decades from now,

Yes. That is why there has been a lot of work put into the implementing the minimum required for migration to work without relying on any external dependencies.

and that all legacy formats will remain operational in all newer versions of Bitcoin? I know there may be nuance, and things may change, but I've read some opinions contrary to indefinite legacy wallet migration, and the mixed signals and uncertainty on this topic are concerning.

This sounds like you are conflating legacy wallets with legacy address types. Legacy wallets refer to Bitcoin Core's wallet format only, and has no effect on anything else. Legacy address types (address types that existed prior to segwit), are not guaranteed to stick around and there has been a little bit of discussion about maybe soft forking them out eventually, but this is not a seriously considered idea yet.

[MarketNeutral]

Sorry if this has been answered elsewhere, but is there true consensus among the Bitcoin developers that a migration path from legacy wallets will indeed be supported indefinitely, even decades from now,

Yes. That is why there has been a lot of work put into the implementing the minimum required for migration to work without relying on any external dependencies.

and that all legacy formats will remain operational in all newer versions of Bitcoin? I know there may be nuance, and things may change, but I've read some opinions contrary to indefinite legacy wallet migration, and the mixed signals and uncertainty on this topic are concerning.

This sounds like you are conflating legacy wallets with legacy address types. Legacy wallets refer to Bitcoin Core's wallet format only, and has no effect on anything else. Legacy address types (address types that existed prior to segwit), are not guaranteed to stick around and there has been a little bit of discussion about maybe soft forking them out eventually, but this is not a seriously considered idea yet.

Wonderful. I was primarily concerned about legacy wallets. As long as legacy wallets are still supported, I see no problem. While I do prefer legacy address support, I understand the reasoning behind deprecating them. Thank you for the clarification!