This topic has been moved to Mining.

https://bitcointalk.org/index.php?topic=5479481.0

This topic has been moved to Bitcoin Technical Support.

https://bitcointalk.org/index.php?topic=5479083.0

This topic has been moved to Bitcoin Discussion.

https://bitcointalk.org/index.php?topic=5479570.0

This topic has been moved to Trashcan.

Duplicate of https://bitcointalk.org/index.php?topic=5477119.0

26.0 Release Notes

Bitcoin Core version 26.0 is now available from:

https://bitcoincore.org/bin/bitcoin-core-26.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, 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

P2P and network changes

• Experimental support for the v2 transport protocol defined in
  BIP324 was added.
  It is off by default, but when enabled using -v2transport it will be negotiated
  on a per-connection basis with other peers that support it too. The existing
  v1 transport protocol remains fully supported.
  
• Nodes with multiple reachable networks will actively try to have at least one
  outbound connection to each network. This improves individual resistance to
  eclipse attacks and network level resistance to partition attacks. Users no
  longer need to perform active measures to ensure being connected to multiple
  enabled networks. (#27213)
  

Pruning

• When using assumeutxo with -prune, the prune budget may be exceeded if it is set
  lower than 1100MB (i.e. MIN_DISK_SPACE_FOR_BLOCK_FILES * 2). Prune budget is normally
  split evenly across each chainstate, unless the resulting prune budget per chainstate
  is beneath MIN_DISK_SPACE_FOR_BLOCK_FILES in which case that value will be used. (#27596)

Updated RPCs

• Setting -rpcserialversion=0 is deprecated and will be removed in
  a future release. It can currently still be used by also adding
  the -deprecatedrpc=serialversion option. (#28448)
  
• The hash_serialized_2 value has been removed from gettxoutsetinfo since the value it
  calculated contained a bug and did not take all data into account. It is superseded by
  hash_serialized_3 which provides the same functionality but serves the correctly calculated hash. (#28685)
  
• New fields transport_protocol_type and session_id were added to the getpeerinfo RPC to indicate
  whether the v2 transport protocol is in use, and if so, what the session id is.
  
• A new argument v2transport was added to the addnode RPC to indicate whether a v2 transaction connection
  is to be attempted with the peer.
  
• Miniscript expressions can now be used in Taproot descriptors for all RPCs working with descriptors. (#27255)
  
• finalizepsbt is now able to finalize a PSBT with inputs spending Miniscript-compatible Taproot leaves. (#27255)
  

Changes to wallet related RPCs can be found in the Wallet section below.

New RPCs

• loadtxoutset has been added, which allows loading a UTXO snapshot of the format
  generated by dumptxoutset. Once this snapshot is loaded, its contents will be
  deserialized into a second chainstate data structure, which is then used to sync to
  the network's tip.
  
  Meanwhile, the original chainstate will complete the initial block download process in
  the background, eventually validating up to the block that the snapshot is based upon.
  
  The result is a usable bitcoind instance that is current with the network tip in a
  matter of minutes rather than hours. UTXO snapshot are typically obtained via
  third-party sources (HTTP, torrent, etc.) which is reasonable since their contents
  are always checked by hash.
  
  You can find more information on this process in the assumeutxo design
  document (https://github.com/bitcoin/bitcoin/blob/master/doc/design/assumeutxo.md).
  
  getchainstates has been added to aid in monitoring the assumeutxo sync process.
  
• A new getprioritisedtransactions RPC has been added. It returns a map of all fee deltas created by the
  user with prioritisetransaction, indexed by txid. The map also indicates whether each transaction is
  present in the mempool. (#27501)
  
• A new RPC, submitpackage, has been added. It can be used to submit a list of raw hex
  transactions to the mempool to be evaluated as a package using consensus and mempool policy rules.
  These policies include package CPFP, allowing a child with high fees to bump a parent below the
  mempool minimum feerate (but not minimum relay feerate). (#27609)
  
  • Warning: successful submission does not mean the transactions will propagate throughout the
    network, as package relay is not supported.
    
  • Not all features are available. The package is limited to a child with all of its
    unconfirmed parents, and no parent may spend the output of another parent.  Also, package
    RBF is not supported. Refer to doc/policy/packages.md for more details on package policies
    and limitations.
    
  • This RPC is experimental. Its interface may change.
    
• A new RPC getaddrmaninfo has been added to view the distribution of addresses in the new and tried table of the
  node's address manager across different networks(ipv4, ipv6, onion, i2p, cjdns). The RPC returns count of addresses
  in new and tried table as well as their sum for all networks. (#27511)
  
• A new importmempool RPC has been added. It loads a valid mempool.dat file and attempts to
  add its contents to the mempool. This can be useful to import mempool data from another node
  without having to modify the datadir contents and without having to restart the node. (#27460)
  
  • Warning: Importing untrusted files is dangerous, especially if metadata from the file is taken over.
  • If you want to apply fee deltas, it is recommended to use the getprioritisedtransactions and
    prioritisetransaction RPCs instead of the apply_fee_delta_priority option to avoid
    double-prioritising any already-prioritised transactions in the mempool.

Updated settings

• bitcoind and bitcoin-qt will now raise an error on startup
  if a datadir that is being used contains a bitcoin.conf file that
  will be ignored, which can happen when a datadir= line is used in
  a bitcoin.conf file. The error message is just a diagnostic intended
  to prevent accidental misconfiguration, and it can be disabled to
  restore the previous behavior of using the datadir while ignoring
  the bitcoin.conf contained in it. (#27302)
  
• Passing an invalid -debug, -debugexclude, or -loglevel logging configuration
  option now raises an error, rather than logging an easily missed warning. (#27632)
  

Changes to GUI or wallet related settings can be found in the GUI or Wallet section below.

New settings

Tools and Utilities

• A new bitcoinconsensus_verify_script_with_spent_outputs function is available in libconsensus which optionally accepts the spent outputs of the transaction being verified.
• A new bitcoinconsensus_SCRIPT_FLAGS_VERIFY_TAPROOT flag is available in libconsensus that will verify scripts with the Taproot spending rules.

Wallet

• Wallet loading has changed in this release. Wallets with some corrupted records that could be
  previously loaded (with warnings) may no longer load. For example, wallets with corrupted
  address book entries may no longer load. If this happens, it is recommended
  load the wallet in a previous version of Bitcoin Core and import the data into a new wallet.
  Please also report an issue to help improve the software and make wallet loading more robust
  in these cases. (#24914)
  
• The gettransaction, listtransactions, listsinceblock RPCs now return
  the abandoned field for all transactions. Previously, the "abandoned" field
  was only returned for sent transactions. (#25158)
  
• The listdescriptors, decodepsbt and similar RPC methods now show h rather than apostrophe (') to indicate
  hardened derivation. This does not apply when using the private parameter, which
  matches the marker used when descriptor was generated or imported. Newly created
  wallets use h. This change makes it easier to handle descriptor strings manually.
  E.g. the importdescriptors RPC call is easiest to use h as the marker: '["desc": ".../0h/..."]'.
  With this change listdescriptors will use h, so you can copy-paste the result,
  without having to add escape characters or switch ' to 'h' manually.
  Note that this changes the descriptor checksum.
  For legacy wallets the hdkeypath field in getaddressinfo is unchanged,
  nor is the serialization format of wallet dumps. (#26076)
  
• The getbalances RPC now returns a lastprocessedblock JSON object which contains the wallet's last processed block
  hash and height at the time the balances were calculated. This result shouldn't be cached because importing new keys could invalidate it. (#26094)
  
• The gettransaction RPC now returns a lastprocessedblock JSON object which contains the wallet's last processed block
  hash and height at the time the transaction information was generated. (#26094)
  
• The getwalletinfo RPC now returns a lastprocessedblock JSON object which contains the wallet's last processed block
  hash and height at the time the wallet information was generated. (#26094)
  
• Coin selection and transaction building now accounts for unconfirmed low-feerate ancestor transactions. When it is necessary to spend unconfirmed outputs, the wallet will add fees to ensure that the new transaction with its ancestors will achieve a mining score equal to the feerate requested by the user. (#26152)
  
• For RPC methods which accept options parameters ((importmulti, listunspent,
  fundrawtransaction, bumpfee, send, sendall, walletcreatefundedpsbt,
  simulaterawtransaction), it is now possible to pass the options as named
  parameters without the need for a nested object. (#26485)
  

This means it is possible make calls like:

Code:

src/bitcoin-cli -named bumpfee txid fee_rate=100

instead of

Code:

]src/bitcoin-cli -named bumpfee txid options='{"fee_rate": 100}'

• The deprecatedrpc=walletwarningfield configuration option has been removed.
  The createwallet, loadwallet, restorewallet and unloadwallet RPCs no
  longer return the "warning" string field. The same information is provided
  through the "warnings" field added in v25.0, which returns a JSON array of
  strings. The "warning" string field was deprecated also in v25.0. (#27757)
  
• The signrawtransactionwithkey, signrawtransactionwithwallet,
  walletprocesspsbt and descriptorprocesspsbt calls now return the more
  specific RPC_INVALID_PARAMETER error instead of RPC_MISC_ERROR if their
  sighashtype argument is malformed. (#28113)
  
• RPC walletprocesspsbt, and descriptorprocesspsbt return
  object now includes field hex (if the transaction
  is complete) containing the serialized transaction
  suitable for RPC sendrawtransaction. (#28414)
  
• It's now possible to use Miniscript inside Taproot leaves for descriptor wallets. (#27255)
  

GUI changes

• The transaction list in the GUI no longer provides a special category for "payment to yourself". Now transactions that have both inputs and outputs that affect the wallet are displayed on separate lines for spending and receiving. (gui#119)
  
• A new menu option allows migrating a legacy wallet based on keys and implied output script types stored in BerkeleyDB (BDB) to a modern wallet that uses descriptors stored in SQLite. (gui#738)
  
• The PSBT operations dialog marks outputs paying your own wallet with "own address". (gui#740)
  
• The ability to create legacy wallets is being removed. (gui#764)
  

Low-level changes

Tests

• Non-standard transactions are now disabled by default on testnet
  for relay and mempool acceptance. The previous behaviour can be
  re-enabled by setting -acceptnonstdtxn=1. (#28354)

Credits

Thanks to everyone who directly contributed to this release:

• 0xb10c
• Amiti Uttarwar
• Andrew Chow
• Andrew Toth
• Anthony Towns
• Antoine Poinsot
• Antoine Riard
• Ari
• Aurèle Oulès
• Ayush Singh
• Ben Woosley
• Brandon Odiwuor
• Brotcrunsher
• brunoerg
• Bufo
• Carl Dong
• Casey Carter
• Cory Fields
• David Álvarez Rosa
• dergoegge
• dhruv
• dimitaracev
• Erik Arvstedt
• Erik McKelvey
• Fabian Jahr
• furszy
• glozow
• Greg Sanders
• Harris
• Hennadii Stepanov
• Hernan Marino
• ishaanam
• ismaelsadeeq
• Jake Rawsthorne
• James O'Beirne
• John Moffett
• Jon Atack
• josibake
• kevkevin
• Kiminuo
• Larry Ruane
• Luke Dashjr
• MarcoFalke
• Marnix
• Martin Leitner-Ankerl
• Martin Zumsande
• Matthew Zipkin
• Michael Ford
• Michael Tidwell
• mruddy
• Murch
• ns-xvrn
• pablomartin4btc
• Pieter Wuille
• Reese Russell
• Rhythm Garg
• Ryan Ofsky
• Sebastian Falbesoner
• Sjors Provoost
• stickies-v
• stratospher
• Suhas Daftuar
• TheCharlatan
• Tim Neubauer
• Tim Ruffing
• Vasil Dimov
• virtu
• vuittont60
• willcl-ark
• Yusuf Sahin HAMZA

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

25.1 Release Notes

Bitcoin Core version 25.1 is now available from:

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

This release includes 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, 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.

Notable changes

P2P

• #27626 Parallel compact block downloads, take 3
• #27743 p2p: Unconditionally return when compact block status == READ_STATUS_FAILED

Fees

• #27622 Fee estimation: avoid serving stale fee estimate

RPC

• #27727 rpc: Fix invalid bech32 address handling

Rest

• #27853 rest: fix crash error when calling /deploymentinfo
• #28551 http: bugfix: allow server shutdown in case of remote client disconnection

Wallet

• #28038 wallet: address book migration bug fixes
• #28067 descriptors: do not return top-level only funcs as sub descriptors
• #28125 wallet: bugfix, disallow migration of invalid scripts
• #28542 wallet: Check for uninitialized last processed and conflicting heights in MarkConflicted

Build

• #27724 build: disable boost multi index safe mode in debug mode
• #28097 depends: xcb-proto 1.15.2
• #28543 build, macos: Fix qt package build with new Xcode 15 linker
• #28571 depends: fix unusable memory_resource in macos qt build

Gui

• gui#751 macOS, do not process actions during shutdown

Miscellaneous

• #28452 Do not use std::vector = {} to release memory

CI

• #27777 ci: Prune dangling images on RESTART_CI_DOCKER_BEFORE_RUN
• #27834 ci: Nuke Android APK task, Use credits for tsan
• #27844 ci: Use podman stop over podman kill
• #27886 ci: Switch to amd64 container in "ARM" task

Credits

Thanks to everyone who directly contributed to this release:

• Abubakar Sadiq Ismail
• Andrew Chow
• Bruno Garcia
• Gregory Sanders
• Hennadii Stepanov
• MacroFake
• Matias Furszyfer
• Michael Ford
• Pieter Wuille
• stickies-v
• Will Clark

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

25.0 Release Notes

Bitcoin Core version 25.0 is now available from:

https://bitcoincore.org/bin/bitcoin-core-25.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, 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.

Notable changes

P2P and network changes

• Transactions of non-witness size 65 bytes and above are now allowed by mempool
  and relay policy. This is to better reflect the actual afforded protections
  against CVE-2017-12842 and open up additional use-cases of smaller transaction sizes. (#26265)

New RPCs

• The scanblocks RPC returns the relevant blockhashes from a set of descriptors by
  scanning all blockfilters in the given range. It can be used in combination with
  the getblockheader and rescanblockchain RPCs to achieve fast wallet rescans. Note
  that this functionality can only be used if a compact block filter index
  (-blockfilterindex=1) has been constructed by the node. (#23549)

Updated RPCs

• All JSON-RPC methods accept a new named
  parameter called args that can
  contain positional parameter values. This is a convenience to allow some
  parameter values to be passed by name without having to name every value. The
  python test framework and bitcoin-cli tool both take advantage of this, so
  for example:
  bitcoin-cli -named createwallet wallet_name=mywallet load_on_startup=1
  Can now be shortened to:
  bitcoin-cli -named createwallet mywallet load_on_startup=1
  
• The verifychain RPC will now return false if the checks didn't fail,
  but couldn't be completed at the desired depth and level. This could be due
  to missing data while pruning, due to an insufficient dbcache or due to
  the node being shutdown before the call could finish. (#25574)
  
• sendrawtransaction has a new, optional argument, maxburnamount with a default value of 0.
  Any transaction containing an unspendable output with a value greater than maxburnamount will
  not be submitted. At present, the outputs deemed unspendable are those with scripts that begin
  with an OP_RETURN code (known as 'datacarriers'), scripts that exceed the maximum script size,
  and scripts that contain invalid opcodes.
  
• The testmempoolaccept RPC now returns 2 additional results within the "fees" result:
  "effective-feerate" is the feerate including fees and sizes of transactions validated together if
  package validation was used, and also includes any modified fees from prioritisetransaction. The
  "effective-includes" result lists the wtxids of transactions whose modified fees and sizes were used
  in the effective-feerate (#26646).
  
• decodescript may now infer a Miniscript descriptor under P2WSH context if it is not lacking
  information. (#27037)
  
• finalizepsbt is now able to finalize a transaction with inputs spending Miniscript-compatible
  P2WSH scripts. (#24149)
  

Changes to wallet related RPCs can be found in the Wallet section below.

Build System

• The --enable-upnp-default and --enable-natpmp-default options
  have been removed. If you want to use port mapping, you can
  configure it using a .conf file, or by passing the relevant
  options at runtime. (#26896)

Updated settings

• If the -checkblocks or -checklevel options are explicitly provided by the
  user, but the verification checks cannot be completed due to an insufficient
  dbcache, Bitcoin Core will now return an error at startup. (#25574)
  
• Ports specified in -port and -rpcport options are now validated at startup.
  Values that previously worked and were considered valid can now result in errors. (#22087)
  
• Setting -blocksonly will now reduce the maximum mempool memory
  to 5MB (users may still use -maxmempool to override). Previously,
  the default 300MB would be used, leading to unexpected memory usage
  for users running with -blocksonly expecting it to eliminate
  mempool memory usage.
  
  As unused mempool memory is shared with dbcache, this also reduces
  the dbcache size for users running with -blocksonly, potentially
  impacting performance.
  
• Setting -maxconnections=0 will now disable -dnsseed
  and -listen (users may still set them to override).
  

Changes to GUI or wallet related settings can be found in the GUI or Wallet section below.

New settings

• The shutdownnotify option is used to specify a command to execute synchronously
  before Bitcoin Core has begun its shutdown sequence. (#23395)

Wallet

• The minconf option, which allows a user to specify the minimum number
  of confirmations a UTXO being spent has, and the maxconf option,
  which allows specifying the maximum number of confirmations, have been
  added to the following RPCs in #25375:
  
  • fundrawtransaction
  • send
  • walletcreatefundedpsbt
  • sendall
• Added a new next_index field in the response in listdescriptors to
  have the same format as importdescriptors (#26194)
  
• RPC listunspent now has a new argument include_immature_coinbase
  to include coinbase UTXOs that don't meet the minimum spendability
  depth requirement (which before were silently skipped). (#25730)
  
• Rescans for descriptor wallets are now significantly faster if compact
  block filters (BIP158) are available. Since those are not constructed
  by default, the configuration option "-blockfilterindex=1" has to be
  provided to take advantage of the optimization. This improves the
  performance of the RPC calls rescanblockchain, importdescriptors
  and restorewallet. (#25957)
  
• RPC unloadwallet now fails if a rescan is in progress. (#26618)
  
• Wallet passphrases may now contain null characters.
  Prior to this change, only characters up to the first
  null character were recognized and accepted. (#27068)
  
• Address Purposes strings are now restricted to the currently known values of "send",
  "receive", and "refund". Wallets that have unrecognized purpose strings will have
  loading warnings, and the listlabels RPC will raise an error if an unrecognized purpose
  is requested. (#27217)
  
• In the createwallet, loadwallet, unloadwallet, and restorewallet RPCs, the
  "warning" string field is deprecated in favor of a "warnings" field that
  returns a JSON array of strings to better handle multiple warning messages and
  for consistency with other wallet RPCs. The "warning" field will be fully
  removed from these RPCs in v26. It can be temporarily re-enabled during the
  deprecation period by launching bitcoind with the configuration option
  -deprecatedrpc=walletwarningfield. (#27279)
  
• Descriptor wallets can now spend coins sent to P2WSH Miniscript descriptors. (#24149)
  

GUI changes

• The "Mask values" is a persistent option now. (gui#701)
• The "Mask values" option affects the "Transaction" view now, in addition to the
  "Overview" one. (gui#708)

REST

• A new /rest/deploymentinfo endpoint has been added for fetching various
  state info regarding deployments of consensus changes. (#25412)

Binary verification

• The binary verification script has been updated. In previous releases it
  would verify that the binaries had been signed with a single "release key".
  In this release and moving forward it will verify that the binaries are
  signed by a threshold of trusted keys. For more details and
  examples, see:
  https://github.com/bitcoin/bitcoin/blob/master/contrib/verify-binaries/README.md
  (#27358)

Low-level changes

RPC

• The JSON-RPC server now rejects requests where a parameter is specified multiple
  times with the same name, instead of silently overwriting earlier parameter values
  with later ones. (#26628)
• RPC listsinceblock now accepts an optional label argument
  to fetch incoming transactions having the specified label. (#25934)
• Previously setban, addpeeraddress, walletcreatefundedpsbt, methods
  allowed non-boolean and non-null values to be passed as boolean parameters.
  Any string, number, array, or object value that was passed would be treated
  as false. After this change, passing any value except true, false, or
  null now triggers a JSON value is not of expected type error. (#26213)

Credits

Thanks to everyone who directly contributed to this release:

• 0xb10c
• 721217.xyz
• @RandyMcMillan
• amadeuszpawlik
• Amiti Uttarwar
• Andrew Chow
• Andrew Toth
• Anthony Towns
• Antoine Poinsot
• Aurèle Oulès
• Ben Woosley
• Bitcoin Hodler
• brunoerg
• Bushstar
• Carl Dong
• Chris Geihsler
• Cory Fields
• David Gumberg
• dergoegge
• Dhruv Mehta
• Dimitris Tsapakidis
• dougEfish
• Douglas Chimento
• ekzyis
• Elichai Turkel
• Ethan Heilman
• Fabian Jahr
• FractalEncrypt
• furszy
• Gleb Naumenko
• glozow
• Greg Sanders
• Hennadii Stepanov
• hernanmarino
• ishaanam
• ismaelsadeeq
• James O'Beirne
• jdjkelly@gmail.com
• Jeff Ruane
• Jeffrey Czyz
• Jeremy Rubin
• Jesse Barton
• João Barbosa
• JoaoAJMatos
• John Moffett
• Jon Atack
• Jonas Schnelli
• jonatack
• Joshua Kelly
• josibake
• Juan Pablo Civile
• kdmukai
• klementtan
• Kolby ML
• kouloumos
• Kristaps Kaupe
• laanwj
• Larry Ruane
• Leonardo Araujo
• Leonardo Lazzaro
• Luke Dashjr
• MacroFake
• MarcoFalke
• Martin Leitner-Ankerl
• Martin Zumsande
• Matt Whitlock
• Matthew Zipkin
• Michael Ford
• Miles Liu
• mruddy
• Murray Nesbitt
• muxator
• omahs
• pablomartin4btc
• Pasta
• Pieter Wuille
• Pttn
• Randall Naar
• Riahiamirreza
• roconnor-blockstream
• Russell O'Connor
• Ryan Ofsky
• S3RK
• Sebastian Falbesoner
• Seibart Nedor
• sinetek
• Sjors Provoost
• Skuli Dulfari
• SomberNight
• Stacie Waleyko
• stickies-v
• stratospher
• Suhas Daftuar
• Suriyaa Sundararuban
• TheCharlatan
• Vasil Dimov
• Vasil Stoyanov
• virtu
• w0xlt
• willcl-ark
• yancy
• Yusuf Sahin HAMZA

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

24.1 Release Notes

Bitcoin Core version 24.1 is now available from:

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

This release includes 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, 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

• #26878 I2P network optimizations
• #26909 net: prevent peers.dat corruptions by only serializing once
• #27608 p2p: Avoid prematurely clearing download state for other peers
• #27610 Improve performance of p2p inv to send queues

RPC and other APIs

• #26515 rpc: Require NodeStateStats object in getpeerinfo
• #27279 doc: fix/improve warning helps in {create,load,unload,restore}wallet
• #27468 rest: avoid segfault for invalid URI

Build System

• #26944 depends: fix systemtap download URL
• #27462 depends: fix compiling bdb with clang-16 on aarch64

Wallet

• #26595 wallet: be able to specify a wallet name and passphrase to migratewallet
• #26675 wallet: For feebump, ignore abandoned descendant spends
• #26679 wallet: Skip rescanning if wallet is more recent than tip
• #26761 wallet: fully migrate address book entries for watchonly/solvable wallets
• #27053 wallet: reuse change dest when re-creating TX with avoidpartialspends
• #27080 wallet: Zero out wallet master key upon locking so it doesn't persist in memory
• #27473 wallet: Properly handle "unknown" Address Type

GUI changes

• gui#687 Load PSBTs using istreambuf_iterator rather than istream_iterator
• gui#704 Correctly limit overview transaction list

Miscellaneous

• #26880 ci: replace Intel macOS CI job
• #26924 refactor: Add missing includes to fix gcc-13 compile error

Credits

Thanks to everyone who directly contributed to this release:

• Andrew Chow
• Anthony Towns
• Hennadii Stepanov
• John Moffett
• Jon Atack
• Marco Falke
• Martin Zumsande
• Matthew Zipkin
• Michael Ford
• pablomartin4btc
• Sebastian Falbesoner
• Suhas Daftuar
• Thomas Nguyen
• Vasil Dimov

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

23.2 Release Notes

Bitcoin Core version 23.2 is now available from:

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

This release includes 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, 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

• #26909 net: prevent peers.dat corruptions by only serializing once
• #27608 p2p: Avoid prematurely clearing download state for other peers
• #27610 Improve performance of p2p inv to send queues

Build system

• #25436 build: suppress array-bounds errors in libxkbcommon
• #25763 bdb: disable Werror for format-security
• #26944 depends: fix systemtap download URL
• #27462 depends: fix compiling bdb with clang-16 on aarch64

Miscellaneous

• #25444 ci: macOS task imrovements
• #26388 ci: Use macos-ventura-xcode:14.1 image for "macOS native" task
• #26924 refactor: Add missing includes to fix gcc-13 compile error

Credits

Thanks to everyone who directly contributed to this release:

• Anthony Towns
• Hennadii Stepanov
• MacroFake
• Martin Zumsande
• Michael Ford
• Suhas Daftuar

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

This topic has been moved to Trashcan.

Duplicate of https://bitcointalk.org/index.php?topic=5430588.0

24.0.1 Release Notes

Due to last-minute issues (#26616), 24.0, although tagged, was never fully
announced or released.

Bitcoin Core version 24.0.1 is now available from:

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

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

Notice of new option for transaction replacement policies

This version of Bitcoin Core adds a new mempoolfullrbf configuration
option which allows users to change the policy their individual node
will use for relaying and mining unconfirmed transactions.  The option
defaults to the same policy that was used in previous releases and no
changes to node policy will occur if everyone uses the default.

Some Bitcoin services today expect that the first version of an
unconfirmed transaction that they see will be the version of the
transaction that ultimately gets confirmed---a transaction acceptance
policy sometimes called "first-seen".

The Bitcoin Protocol does not, and cannot, provide any assurance that
the first version of an unconfirmed transaction seen by a particular
node will be the version that gets confirmed.  If there are multiple
versions of the same unconfirmed transaction available, only the miner
who includes one of those transactions in a block gets to decide which
version of the transaction gets confirmed.

Despite this lack of assurance, multiple merchants and services today
still make this assumption.

There are several benefits to users from removing this first-seen
simplification.  One key benefit, the ability for the sender of a
transaction to replace it with an alternative version paying higher
fees, was realized in Bitcoin Core 0.12.0 (February 2016) with the
introduction of BIP125 opt-in Replace By Fee (RBF).

Since then, there has been discussion about completely removing the
first-seen simplification and allowing users to replace any of their
older unconfirmed transactions with newer transactions, a feature called
full-RBF.  This release includes a mempoolfullrbf configuration
option that allows enabling full-RBF, although it defaults to off
(allowing only opt-in RBF).

Several alternative node implementations have already enabled full-RBF by
default for years, and several contributors to Bitcoin Core are
advocating for enabling full-RBF by default in a future version of
Bitcoin Core.

As more nodes that participate in relay and mining begin enabling
full-RBF, replacement of unconfirmed transactions by ones offering higher
fees may rapidly become more reliable.

Contributors to this project strongly recommend that merchants and services
not accept unconfirmed transactions as final, and if they insist on doing so,
to take the appropriate steps to ensure they have some recourse or plan for
when their assumptions do not hold.

Notable changes

P2P and network changes

• To address a potential denial-of-service, the logic to download headers from peers
  has been reworked.  This is particularly relevant for nodes starting up for the
  first time (or for nodes which are starting up after being offline for a long time).
  
  Whenever headers are received from a peer that have a total chainwork that is either
  less than the node's -minimumchainwork value or is sufficiently below the work at
  the node's tip, a "presync" phase will begin, in which the node will download the
  peer's headers and verify the cumulative work on the peer's chain, prior to storing
  those headers permanently. Once that cumulative work is verified to be sufficiently high,
  the headers will be redownloaded from that peer and fully validated and stored.
  
  This may result in initial headers sync taking longer for new nodes starting up for
  the first time, both because the headers will be downloaded twice, and because the effect
  of a peer disconnecting during the presync phase (or while the node's best headers chain has less
  than -minimumchainwork), will result in the node needing to use the headers presync mechanism
  with the next peer as well (downloading the headers twice, again). (#25717)
  
• With I2P connections, a new, transient address is used for each outbound
  connection if -i2pacceptincoming=0. (#25355)
  

Updated RPCs

• The -deprecatedrpc=softforks configuration option has been removed.  The
  RPC getblockchaininfo no longer returns the softforks field, which was
  previously deprecated in 23.0. (#23508) Information on soft fork status is
  now only available via the getdeploymentinfo RPC.
  
• The deprecatedrpc=exclude_coinbase configuration option has been removed.
  The receivedby RPCs (listreceivedbyaddress, listreceivedbylabel,
  getreceivedbyaddress and getreceivedbylabel) now always return results
  accounting for received coins from coinbase outputs, without an option to
  change that behaviour. Excluding coinbases was previously deprecated in 23.0.
  (#25171)
  
• The deprecatedrpc=fees configuration option has been removed. The top-level
  fee fields fee, modifiedfee, ancestorfees and descendantfees are no
  longer returned by RPCs getmempoolentry, getrawmempool(verbose=true),
  getmempoolancestors(verbose=true) and getmempooldescendants(verbose=true).
  The same fee fields can be accessed through the fees object in the result.
  The top-level fee fields were previously deprecated in 23.0. (#25204)
  
• The getpeerinfo RPC has been updated with a new presynced_headers field,
  indicating the progress on the presync phase mentioned in the
  "P2P and network changes" section above.
  

Changes to wallet related RPCs can be found in the Wallet section below.

New RPCs

• The sendall RPC spends specific UTXOs to one or more recipients
  without creating change. By default, the sendall RPC will spend
  every UTXO in the wallet. sendall is useful to empty wallets or to
  create a changeless payment from select UTXOs. When creating a payment
  from a specific amount for which the recipient incurs the transaction
  fee, continue to use the subtractfeefromamount option via the
  send, sendtoaddress, or sendmany RPCs. (#24118)
  
• A new gettxspendingprevout RPC has been added, which scans the mempool to find
  transactions spending any of the given outpoints. (#24408)
  
• The simulaterawtransaction RPC iterates over the inputs and outputs of the given
  transactions, and tallies up the balance change for the given wallet. This can be
  useful e.g. when verifying that a coin join like transaction doesn't contain unexpected
  inputs that the wallet will then sign for unintentionally. (#22751)
  

Updated REST APIs

• The /headers/ and /blockfilterheaders/ endpoints have been updated to use
  a query parameter instead of path parameter to specify the result count. The
  count parameter is now optional, and defaults to 5 for both endpoints. The old
  endpoints are still functional, and have no documented behaviour change.
  
  For /headers, use
  GET /rest/headers/<BLOCK-HASH>.<bin|hex|json>?count=<COUNT=5>
  instead of
  GET /rest/headers/<COUNT>/<BLOCK-HASH>.<bin|hex|json> (deprecated)
  
  For /blockfilterheaders/, use
  GET /rest/blockfilterheaders/<FILTERTYPE>/<BLOCK-HASH>.<bin|hex|json>?count=<COUNT=5>
  instead of
  GET /rest/blockfilterheaders/<FILTERTYPE>/<COUNT>/<BLOCK-HASH>.<bin|hex|json> (deprecated)
  
  (#24098)
  

Build System

• Guix builds are now reproducible across architectures (x86_64 &amp; aarch64). (#21194)

New settings

• A new mempoolfullrbf option has been added, which enables the mempool to
  accept transaction replacement without enforcing BIP125 replaceability
  signaling. (#25353)

Wallet

• The -walletrbf startup option will now default to true. The
  wallet will now default to opt-in RBF on transactions that it creates. (#25610)
  
• The replaceable option for the createrawtransaction and
  createpsbt RPCs will now default to true. Transactions created
  with these RPCs will default to having opt-in RBF enabled. (#25610)
  
• The wsh() output descriptor was extended with Miniscript support. You can import Miniscript
  descriptors for P2WSH in a watchonly wallet to track coins, but you can't spend from them using
  the Bitcoin Core wallet yet.
  You can find more about Miniscript on the reference website. (#24148)
  
• The tr() output descriptor now supports multisig scripts through the multi_a() and
  sortedmulti_a() functions. (#24043)
  
• To help prevent fingerprinting transactions created by the Bitcoin Core wallet, change output
  amounts are now randomized. (#24494)
  
• The listtransactions, gettransaction, and listsinceblock
  RPC methods now include a wtxid field (hash of serialized transaction,
  including witness data) for each transaction. (#24198)
  
• The listsinceblock, listtransactions and gettransaction output now contain a new
  parent_descs field for every "receive" entry. (#25504)
  
• A new optional include_change parameter was added to the listsinceblock command.
  
• RPC getreceivedbylabel now returns an error, "Label not found
  in wallet" (-4), if the label is not in the address book. (#25122)
  

Migrating Legacy Wallets to Descriptor Wallets

An experimental RPC migratewallet has been added to migrate Legacy (non-descriptor) wallets to
Descriptor wallets. More information about the migration process is available in the
documentation.

GUI changes

• A new menu item to restore a wallet from a backup file has been added (gui#471).
  
• Configuration changes made in the bitcoin GUI (such as the pruning setting,
  proxy settings, UPNP preferences) are now saved to <datadir>/settings.json
  file rather than to the Qt settings backend (windows registry or unix desktop
  config files), so these settings will now apply to bitcoind, instead of being
  ignored. (#15936, gui#602)
  
• Also, the interaction between GUI settings and bitcoin.conf settings is
  simplified. Settings from bitcoin.conf are now displayed normally in the GUI
  settings dialog, instead of in a separate warning message ("Options set in this
  dialog are overridden by the configuration file: -setting=value"). And these
  settings can now be edited because settings.json values take precedence over
  bitcoin.conf values. (#15936)
  

Low-level changes

RPC

• The deriveaddresses, getdescriptorinfo, importdescriptors and scantxoutset commands now
  accept Miniscript expression within a wsh() descriptor. (#24148)
  
• The getaddressinfo, decodescript, listdescriptors and listunspent commands may now output
  a Miniscript descriptor inside a wsh() where a wsh(raw()) descriptor was previously returned. (#24148)
  

Credits

Thanks to everyone who directly contributed to this release:

• /dev/fd0
• 0xb10c
• Adam Jonas
• akankshakashyap
• Ali Sherief
• amadeuszpawlik
• Andreas Kouloumos
• Andrew Chow
• Anthony Towns
• Antoine Poinsot
• Antoine Riard
• Aurèle Oulès
• avirgovi
• Ayush Sharma
• Baas
• Ben Woosley
• BrokenProgrammer
• brunoerg
• brydinh
• Bushstar
• Calvin Kim
• CAnon
• Carl Dong
• chinggg
• Cory Fields
• Daniel Kraft
• Daniela Brozzoni
• darosior
• Dave Scotese
• David Bakin
• dergoegge
• dhruv
• Dimitri
• dontbyte
• Duncan Dean
• eugene
• Eunoia
• Fabian Jahr
• furszy
• Gleb Naumenko
• glozow
• Greg Weber
• Gregory Sanders
• gruve-p
• Hennadii Stepanov
• hiago
• Igor Bubelov
• ishaanam
• Jacob P.
• Jadi
• James O'Beirne
• Janna
• Jarol Rodriguez
• Jeremy Rand
• Jeremy Rubin
• jessebarton
• João Barbosa
• John Newbery
• Jon Atack
• Josiah Baker
• Karl-Johan Alm
• KevinMusgrave
• Kiminuo
• klementtan
• Kolby Moroz
• kouloumos
• Kristaps Kaupe
• Larry Ruane
• Luke Dashjr
• MarcoFalke
• Marnix
• Martin Leitner-Ankerl
• Martin Zumsande
• Michael Dietz
• Michael Folkson
• Michael Ford
• Murch
• mutatrum
• muxator
• Oskar Mendel
• Pablo Greco
• pasta
• Patrick Strateman
• Pavol Rusnak
• Peter Bushnell
• phyBrackets
• Pieter Wuille
• practicalswift
• randymcmillan
• Robert Spigler
• Russell Yanofsky
• S3RK
• Samer Afach
• Sebastian Falbesoner
• Seibart Nedor
• Shashwat
• Sjors Provoost
• Smlep
• sogoagain
• Stacie
• Stéphan Vuylsteke
• Suhail Saqan
• Suhas Daftuar
• t-bast
• TakeshiMusgrave
• Vasil Dimov
• W. J. van der Laan
• w0xlt
• whiteh0rse
• willcl-ark
• William Casarin
• Yancy Ribbens

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

Bitcoin Core version 23.0 is now available from:

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

Or through BitTorrent:

magnet:?xt=urn:btih:32bc317cce76b966a26bdb53d42f64d66d595954&amp;dn=bitcoin-core-23.0&amp;tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&amp;tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&amp;tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&amp;tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&amp;tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&amp;tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&amp;tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969

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 Mac)
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, 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.

Notable changes

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 -cjdnsreachable and doc/cjdns.md (#23077)
  

Fee estimation changes

• Fee estimation now takes the feerate of replacement (RBF) transactions into
  account. (#22539)

Rescan startup parameter removed

The -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/.

Updated RPCs

• The validateaddress RPC now returns an error_locations array 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 error field now also returns more specific
  errors when decoding fails. (#16807)
  
• The -deprecatedrpc=addresses configuration option has been removed.  RPCs
  gettxout, getrawtransaction, decoderawtransaction, decodescript,
  gettransaction verbose=true and REST endpoints /rest/tx, /rest/getutxos,
  /rest/block no longer return the addresses and reqSigs fields, which
  were previously deprecated in 22.0. (#22650)
  
• The 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.
  • height
  • value
  • scriptPubKey
• The top-level fee fields fee, modifiedfee, ancestorfees and descendantfees
  returned by RPCs getmempoolentry,getrawmempool(verbose=true),
  getmempoolancestors(verbose=true) and getmempooldescendants(verbose=true)
  are deprecated and will be removed in the next major version (use
  -deprecated=fees if needed in this version). The same fee fields can be accessed
  through the fees object in the result. WARNING: deprecated
  fields ancestorfees and descendantfees are denominated in sats, whereas all
  fields in the fees object are denominated in BTC. (#22689)
  
• Both createmultisig and addmultisigaddress now include a warnings
  field, 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.

New RPCs

• Information on soft fork status has been moved from getblockchaininfo
  to the new getdeploymentinfo RPC which allows querying soft fork status at any
  block, rather than just at the chain tip. Inclusion of soft fork
  status in getblockchaininfo can currently be restored using the
  configuration -deprecatedrpc=softforks, but this will be removed in
  a future release. Note that in either case, the status field
  now reflects the status of the current block rather than the next
  block. (#23508)

Files

• On startup, the list of banned hosts and networks (via setban RPC) in
  banlist.dat is ignored and only banlist.json is considered. Bitcoin Core
  version 22.x is the only version that can read banlist.dat and also write
  it to banlist.json. If banlist.json already exists, version 22.x will not
  try to translate the banlist.dat into json. After an upgrade, listbanned
  can be used to double check the parsed entries. (#22570)

Updated settings

• In previous releases, the meaning of the command line option
  -persistmempool (without a value provided) incorrectly disabled mempool
  persistence.  -persistmempool is now treated like other boolean options to
  mean -persistmempool=1. Passing -persistmempool=0, -persistmempool=1
  and -nopersistmempool is unaffected. (#23061)
  
• -maxuploadtarget now allows human readable byte units [k|K|m|M|g|G|t|T].
  E.g. -maxuploadtarget=500g. No whitespace, +- or fractions allowed.
  Default is M if no suffix provided. (#23249)
  
• If -proxy= is given together with -noonion then 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
  addnode RPC. To mimic the old behavior use -proxy= together with
  -onlynet= listing all relevant networks except onion. (#22834)
  

Tools and Utilities

• Update -getinfo to return data in a user-friendly format that also reduces vertical space. (#21832)
  
• CLI -addrinfo now returns a single field for the number of onion addresses
  known to the node instead of separate torv2 and torv3 fields, as support
  for Tor V2 addresses was removed from Bitcoin Core in 22.0. (#22544)
  

Wallet

• 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 importmulti and 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.
  
• upgradewallet will 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 newkeypool has been added, which will flush (entirely
  clear and refill) the keypool. (#23093)
  
• listunspent now includes ancestorcount, ancestorsize, and
  ancestorfees for each transaction output that is still in the mempool.
  (#12677)
  
• lockunspent now 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)
  
• receivedby RPCs now include coinbase transactions. Previously, the
  following wallet RPCs excluded coinbase transactions: getreceivedbyaddress,
  getreceivedbylabel, listreceivedbyaddress, 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 receivedby RPCs, include_immature_coinbase
  (default=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)
  

GUI changes

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

Low-level changes

RPC

• getblockchaininfo now returns a new time field, that provides the chain tip time. (#22407)

Tests

• For the regtest network the activation heights of several softforks were
  set to block height 1. They can be changed by the runtime setting
  -testactivationheight=name@height. (#22818)

Credits

Thanks to everyone who directly contributed to this release:

• 0xb10c
• 0xree
• Aaron Clauson
• Adrian-Stefan Mares
• agroce
• aitorjs
• Alex Groce
• amadeuszpawlik
• Amiti Uttarwar
• Andrew Chow
• Andrew Poelstra
• Andrew Toth
• anouar kappitou
• Anthony Towns
• Antoine Poinsot
• Arnab Sen
• Ben Woosley
• benthecarman
• Bitcoin Hodler
• BitcoinTsunami
• brianddk
• Bruno Garcia
• CallMeMisterOwl
• Calvin Kim
• Carl Dong
• Cory Fields
• Cuong V. Nguyen
• Darius Parvin
• Dhruv Mehta
• Dimitri Deijs
• Dimitris Apostolou
• Dmitry Goncharov
• Douglas Chimento
• eugene
• Fabian Jahr
• fanquake
• Florian Baumgartl
• fyquah
• Gleb Naumenko
• glozow
• Gregory Sanders
• Heebs
• Hennadii Stepanov
• hg333
• HiLivin
• Igor Cota
• Jadi
• James O'Beirne
• Jameson Lopp
• Jarol Rodriguez
• Jeremy Rand
• Jeremy Rubin
• Joan Karadimov
• John Newbery
• Jon Atack
• João Barbosa
• josibake
• junderw
• Karl-Johan Alm
• katesalazar
• Kennan Mell
• Kiminuo
• Kittywhiskers Van Gogh
• Klement Tan
• Kristaps Kaupe
• Kuro
• Larry Ruane
• lsilva01
• lucash-dev
• Luke Dashjr
• MarcoFalke
• Martin Leitner-Ankerl
• Martin Zumsande
• Matt Corallo
• Matt Whitlock
• MeshCollider
• Michael Dietz
• Murch
• naiza
• Nathan Garabedian
• Nelson Galdeman
• NikhilBartwal
• Niklas Gögge
• node01
• nthumann
• Pasta
• Patrick Kamin
• Pavel Safronov
• Pavol Rusnak
• Perlover
• Pieter Wuille
• practicalswift
• pradumnasaraf
• pranabp-bit
• Prateek Sancheti
• Prayank
• Rafael Sadowski
• rajarshimaitra
• randymcmillan
• ritickgoenka
• Rob Fielding
• Rojar Smith
• Russell Yanofsky
• S3RK
• Saibato
• Samuel Dobson
• sanket1729
• seaona
• Sebastian Falbesoner
• sh15h4nk
• Shashwat
• Shorya
• ShubhamPalriwala
• Shubhankar Gambhir
• Sjors Provoost
• sogoagain
• sstone
• stratospher
• Suriyaa Rocky Sundararuban
• Taeik Lim
• TheCharlatan
• Tim Ruffing
• Tobin Harding
• Troy Giorshev
• Tyler Chambers
• Vasil Dimov
• W. J. van der Laan
• w0xlt
• willcl-ark
• William Casarin
• zealsham
• Zero-1729

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

22.0 Release Notes

Bitcoin Core version 22.0 is now available from:

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

Or through bittorrent

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 Mac)
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, 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.

Notable changes

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 peers.dat.  (#22050)
  
• Added NAT-PMP port mapping support via
    libnatpmp. (#18077)
  

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)
  
• The getpeerinfo RPC returns two new boolean fields, bip152_hb_to and
    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 cmpctblock message rather than the usual inv/headers
    announcements. See BIP 152 for more details. (#19776)
  
• getpeerinfo no longer returns the following fields: addnode, banscore,
    and whitelisted, which were previously deprecated in 0.21. Instead of
    addnode, the connection_type field returns manual. Instead of
    whitelisted, the permissions field indicates if the peer has special
    privileges. The banscore field has simply been removed. (#20755)
  
• The following RPCs:  gettxout, getrawtransaction, decoderawtransaction,
    decodescript, gettransaction, and REST endpoints: /rest/tx,
    /rest/getutxos, /rest/block deprecated the following fields (which are no
    longer returned in the responses by default): addresses, reqSigs.
    The -deprecatedrpc=addresses flag 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 scriptPubKey object returned in the RPC response. However, in the response
    of decodescript these fields are top-level attributes, and included again as attributes
    of the scriptPubKey object. (#20286)
  
• When creating a hex-encoded bitcoin transaction using the bitcoin-tx utility
    with the -json option set, the following fields: addresses, reqSigs are no longer
    returned in the tx output of the response. (#20286)
  
• The listbanned RPC now returns two new numeric fields: ban_duration and 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_created field is repositioned to come before banned_until. (#21602)
  
• The setban RPC can ban onion addresses again. This fixes a regression introduced in version 0.21.0. (#20852)
  
• The getnodeaddresses RPC now returns a "network" field indicating the
    network type (ipv4, ipv6, onion, or i2p) for each address.  (#21594)
  
• getnodeaddresses now also accepts a "network" argument (ipv4, ipv6, onion,
    or i2p) to return only addresses of the specified network.  (#21843)
  
• The testmempoolaccept RPC 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 testmempoolaccept to return "allowed"=True for a
    group of transactions, but "too-long-mempool-chain" if they are actually submitted. (#20833)
  
• addmultisigaddress and createmultisig now 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.

Build System

• Release binaries are now produced using the new guix-based build system.
    The document has been updated accordingly.

Files

• The list of banned hosts and networks (via setban RPC) is now saved on disk
    in JSON format in banlist.json instead of banlist.dat. banlist.dat is
    only read on startup if banlist.json is not present. Changes are only written to the new
    banlist.json. A future version of Bitcoin Core may completely ignore
    banlist.dat. (#20966)

New settings

• The -natpmp option 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)

Updated settings

Changes to Wallet or GUI related settings can be found in the GUI or Wallet section below.

• Passing an invalid -rpcauth argument now cause bitcoind to fail to start.  (#20461)

Tools and Utilities

• A new CLI -addrinfo command 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 -rpcwaittimeout argument to bitcoin-cli sets the timeout
    in seconds to use with -rpcwait. If the timeout expires,
    bitcoin-cli will report a failure. (#21056)
  

Wallet

• External signers such as hardware wallets can now be used through the new RPC methods enumeratesigners and displayaddress. Support is also added to the send RPC call. This feature is experimental. See external-signer.md for details. (#16546)
  
• A new listdescriptors RPC 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)
  
• The bumpfee RPC is not available with wallets that have private keys
    disabled. psbtbumpfee can be used instead. (#20891)
  
• The fundrawtransaction, send and walletcreatefundedpsbt RPCs now support an include_unsafe option
    that when true allows 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 multi() and sortedmulti() descriptors
    under wsh(). (#20867)
  
• 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.
  

GUI changes

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

Low-level changes

RPC

• 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 (HTTP_SERVICE_UNAVAILABLE). (#18335)
  
• Error codes have been updated to be more accurate for the following error cases (#18466):
  
• signmessage now returns RPC_INVALID_ADDRESS_OR_KEY (-5) if the
      passed address is invalid. Previously returned RPC_TYPE_ERROR (-3).
• verifymessage now returns RPC_INVALID_ADDRESS_OR_KEY (-5) if the
      passed address is invalid. Previously returned RPC_TYPE_ERROR (-3).
• verifymessage now returns RPC_TYPE_ERROR (-3) if the passed signature
      is malformed. Previously returned RPC_INVALID_ADDRESS_OR_KEY (-5).

SHA256SUMS:

Code:

9547fa03574f8bde296f707c7d9f7d89827c75c5a28f84402578a4fa92a787ec  bitcoin-22.0-aarch64-linux-gnu-debug.tar.gz
ac718fed08570a81b3587587872ad85a25173afa5f9fbbd0c03ba4d1714cfa3e  bitcoin-22.0-aarch64-linux-gnu.tar.gz
80071e0ecd24edfec8a1972b495b9822c79a5d33c7123bff51688638aac97cab  bitcoin-22.0-arm-linux-gnueabihf-debug.tar.gz
b8713c6c5f03f5258b54e9f436e2ed6d85449aa24c2c9972f91963d413e86311  bitcoin-22.0-arm-linux-gnueabihf.tar.gz
8f70852feb39078e02182563517d17bdfc4a12904cf1bdabbae95594d9a1e473  bitcoin-22.0-codesignatures-22.0.tar.gz
d0e9d089b57048b1555efa7cd5a63a7ed042482045f6f33402b1df425bf9613b  bitcoin-22.0.tar.gz
bfc04a3c4e8b613bfd9359e54da6cc60f027860e9723f9a6bfd6f13873eb811f  bitcoin-22.0-powerpc64-linux-gnu-debug.tar.gz
2cca5f99007d060aca9d8c7cbd035dfe2f040dd8200b210ce32cdf858479f70d  bitcoin-22.0-powerpc64-linux-gnu.tar.gz
5f0bf1491bc8825ca1506f7cf586030f06bb17a563ccde92e8c75720022704e6  bitcoin-22.0-powerpc64le-linux-gnu-debug.tar.gz
91b1e012975c5a363b5b5fcc81b5b7495e86ff703ec8262d4b9afcfec633c30d  bitcoin-22.0-powerpc64le-linux-gnu.tar.gz
59b16e63aa935f50fd2813efe7f137187fcf0fff84e3205a9c6cb462a8bb160c  bitcoin-22.0-riscv64-linux-gnu-debug.tar.gz
9cc3a62c469fe57e11485fdd32c916f10ce7a2899299855a2e479256ff49ff3c  bitcoin-22.0-riscv64-linux-gnu.tar.gz
3b3e2680f7d9304c13bfebaf6445ada40d72324b4b3e0a07de9db807389a6c5b  bitcoin-22.0-osx-signed.dmg
52449aa894a6ce5653315e1260d0ce87c1d9f490afe3c92b44285710804b11ae  bitcoin-22.0-osx-unsigned.dmg
f51156774c24c0ac5cc30237fa08aa17ed04a180dfd72c3e7d20fdc3f45806dc  bitcoin-22.0-osx-unsigned.tar.gz
2744d199c3343b2d94faffdfb2c94d75a630ba27301a70e47b0ad30a7e0155e9  bitcoin-22.0-osx64.tar.gz
3a4f05657c048d3e9505bdb9c4fb3658e5e3d4233b0b93c1853e080620589765  bitcoin-22.0-x86_64-linux-gnu-debug.tar.gz
59ebd25dd82a51638b7a6bb914586201e67db67b919b2a1ff08925a7936d1b16  bitcoin-22.0-x86_64-linux-gnu.tar.gz
9169989d649937c0f9ebccd3ab088501328aa319fe9e91fc7ea8e8cf0fcccede  bitcoin-22.0-win64-setup.exe
f890473d6d910d478f8ff08f9356d0305d19b46cf06e4fc3b5a49b0b684fd2a7  bitcoin-22.0-win-unsigned.tar.gz
0a97ebc8ae44913e3ef9c5b1ddd2af3a4ffb0ba25b6ab1ee8173e40e60499402  bitcoin-22.0-win64-debug.zip
ecc579d006230d6ffc5a5b7b53ce8c76477d37c1c7bad69694e9c2d69f00331d  bitcoin-22.0-win64-setup-unsigned.exe
9485e4b52ed6cebfe474ab4d7d0c1be6d0bb879ba7246a8239326b2230a77eb1  bitcoin-22.0-win64.zip

SHA256SUM Signatures

Code:

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEDMuq/Xai7OLM0xQd4v/VsdiMqX0FAmE7QY0ACgkQ4v/VsdiM
qX3Gcg/9H1KC6eJAfwJCLQHyRiu7F2cvRt27dPGOuGllKwxDAl5gVwclgK0YpykL
2mkj0A/JAhSY4n3DWGDve7617rkgZjUh1OmlR4VGckC11mufh5+FR0sRNbbwcR4R
LjIKJ56U89pPjMxrJyGCINSO/DwNVDefx6wOK3UxIH2trQrQcuNCD62U58B/+A99
7E/vUsGj/dItiLLGQ3f1Fx4zBSGECtyhi/3iiHutQqT1s1gmDLa3efxT8Dety1Z/
vwvZtJUrXoc550a+a/I6K2SK8pDr9ZAZ3XGmft+daHaT9gFPRbh+mfd9ZdTZceDi
eS/d3leYLPU3pFHZL21li78/nb9/bV8GCgMXtz7tX4lHmwnWAolp03JJ3QmaUwnG
47pxR5WqeexGQ9RbTepcFY5gHE496dVctTA74uE99QSHZ8GOHA4wFPiaY7zxHwSO
nx9H5R7v1fljF688RAqT6WU7iHgpemZsxHPUcYhf2kO5dk4TWvcn4jQ8bGssOv6b
ZFZs/qs4cWsfqCusfOxcK9Qsb3FD2etd3BOU+m4zDX22Vd2whBbIn4MtUA/h0s8C
FNpECJgNQBEmqHBDWrJBD8DP7PxhU2UJZGJKaazu7kEv19y0Pyv/dlT5Xo3nq2NP
n+msw3Q5hoYG/c9VlV/Am4NM8lxEM9BWz/6XbPvOFBKICQ8D3A0=
=MC+w
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQJHBAABCAAxFiEEFSgSMAeFyWRE0zNNF1ZXMuCOXkEFAmE6aeATHGFjaG93MTAx
QGdtYWlsLmNvbQAKCRAXVlcy4I5eQcnLD/9jWUd/B2OFQzfUoZQEyPQ11yMciTW7
zgJC0EbPSM7og48X05qQB8Y2s9r1K3rlwwTtZMsgXtAEmhYBVdHoWnFzNBMus+/I
ch04lOp05eoFqV52eKH6oMiRaLam7dhnq3og99LhqnESAvUZbB/8EH/5hi24VfDI
zro9sh9BK+EBFXKA4/UU66bbgbHUpQkxYjEv/GnoGki/jPghoj1vQAtYqenoHM1u
MvbhbeKC1QAl1IWwBI74jIa4COb1QhbcT5b7Ub77Bi4ppL8qHg6JJM8E6ZcS9KWk
wSYJ/QDzPtJvvva4bTGF8qLTTdV003Knr/OlCbVVmgsHq8/IgP0natrMjbgWri8T
4Zqk9W+6ZG1NSX8KJjDoAepGU1G+eOAzyORSxK5AMu4Yd9Eaycu3RN3b7FDJ7fuz
OLMIzYmGmWS7Bo1hFln+6Rp23d5W8ChpF4oZOPdQzVdQm0m4pwkTEVYa+SAd6YAs
MXBxYiKzKWPOlAB0DZ3UjCY1cmAb02asjAjNDfX5fY2MhJN60rA5NIIVRcD3OzLb
XE09NsQX88ApKn2t2rpnw4D1mzt9ovh0WN4zu7q9l+REzLam+hP5D36GlFH9B74v
SIGmDtHcNf9+tpbdG9T1tdTMpk4MK/3xMUvvN9iG1OKMBald0QQXecXuQHxKpP7s
CFFNEpv/IC8Rng==
=MNG8
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQHKBAABCAA0FiEECtg4d8HwzR7pvWYK18x3C4H9IqgFAmE6a5IWHGJlbnRoZWNh
cm1hbkBsaXZlLmNvbQAKCRDXzHcLgf0iqOigC/wNIZFjD7aCAqICsYzzDhl0Joth
En/3X0S1WOvAr9Io/sXJJmAeCCiihF/wv0WVXLJZnOiLD2z3rgiyOTtxrJbRPibx
bO3zvuVFKKza5G2OgpyoefrqMPmlzFNCDHBF0OP94WgHpkHDGM6OHWZADs3HZ9pi
oQJ3rozPmpTiyYxXt7D6zYlqt0kOTeP05KY/xlYfnhIODxB5JUJaomKBGNKfcdrB
1C0bfNZfrrBwdhwO5s1SJIv1CRlOWB1VW+lybsbNzfMuvVHXsR54WnrVBTGbANXJ
YIZ8qqyzjBZhC7X2orf9JprwPxIx1RJQ678l3Vm2kh8XOTeKXbseejVckpjuSk4r
UjOYdDzvacrwVTAnpYjhY0vxoLnjDH2z6PKiUX7onfQBirxwAQkGHk9YYH548ty2
IA+Qr6XqLBzTyC6KDQP0SaK2LuK2fAZEXnnrC/UIdc32AKaJhDztjBTaJZR8bczD
OMs2oR+dLXZdTDX0Wx0TZRFXxWDP3i2bzgd5jlQ=
=uK1f
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQHMBAABCAA2FiEEWQtykmla/6W2csuy4T/BRc0/QwQFAmE7VvMYHGRhcm9zaW9y
QHByb3Rvbm1haWwuY29tAAoJEOE/wUXNP0MEuF0L/0Jt6BeXFCI0Pe8cVGHNXPaF
Cd+HtxnPuAQuM3AqFWrW7OF8Cerf0uqah7ZhhyrhnaqcBY6c01n5479ba/M/ZvXn
1cdCeiC4jyzA8kq6hAm/Tc6derhYIoo3PCfLRlRae6L5c9j3va+4HBraA9VSZO8Z
lPHopifojOyNtsX2IqJ0mazEwl1MR4yQcFzopdXF/x0UimUxygxSCQljm4F28baV
Qm6uaH1jijSgnE61HWbzsX5e/+C2gtq+x6OAAu0nE7TOb4gHdvnUyhXLIp2iNhSG
rMaDM5wZ03MqhBJl05fp3zzDLcPC2rU45B5cn58snlUJKsHBR+s5AxCcQ2qQ888m
ynk3IODmknyYIM5s39bn1mCGH5ABcJOKGYotIJv2qjSvk+Kw40iQU0EzLS9W3O4A
QAgcrGTPbdeZ6UELmvHry8dmb5Nig24eHDt5IuAEqNfKW4EnGdCdeBMnhRIbdtu/
lghCVxjvhAYj1rBKCGqGFcdQlIuLVaCNtElTHxk0MQ==
=9yB3
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEKPWQCxu10aS2ttGp7TVwFShqMz0FAmE6dGkACgkQ7TVwFShq
Mz21aBAAmSM1k9FeKk4ZGG0ildHjb7q1J1ZVVhBI3iiBawT8HA6a9HZS4CORmMgu
or7aFxnxO9skzQNMGu57C+n1yb9vQ+mrfXWB5DK26z2iZmiuziU4xHHcgbDurLMw
uiVnpfRjHfBaiKYyZfmZypOYvbfgbSIU8oC8KRMpMDM9e9Bck2+RA4mjEddBl2oV
PHZcH5gkAnJYR8/vKXB1b+TuQo1Do3mP8EGDHCi8CgitcMfx4eV91b277s7KQj2T
ofZpmQ2Uoix5c3zRkbAf0zrjb/ZMJDMcZlZBTaIqFwSSO8+CE7QQyKypDePkUtrn
h8eapnVwiJE+aE/bzTm5nOsfDYlIKRsvPmKxI0dRmD7LUdTafsRbf5npTrikwa74
9RaM8/aoeA6MJfxK4ktM4QYFYGXBnEkCKWQoWosSj4+wKb00e+M2ITfq1tJb7dC1
XXacfExUAefCMXI69DGobteU3miJ3oWEnUmMfygE1rTotTlsYQl/pEjBvkNlaEt8
ce10dKmnYFnaL+PoouNGHdFt5PBaG1ziPFWM6BgMb8LHGXV065On2rkm7m9K/uIY
nzwbN2BElEOODKBQ+gxHyyVJZRczMGRSYzmGzfeLI13Dq4m+kj7ZofOWMjyqR7sU
F7yXYUSM9XL9/chLRbfeM8qJULkTyyH1h/yaMoqp76+25sVhZA0=
=rcFD
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEY32x4jNw+Er/iMzgMVI0fQfaYnwFAmE7avsACgkQMVI0fQfa
YnxvhQ/9HUgAqa9cPC5LSdQJzOD4W6b8MrI6OtML/XFyvjx0Bvsz4K+vqFVpshUs
HwQ+rqb2eE7k6zm+Uu+7o7oUvqDlroCc4rhPj3u89p1NFXNfhDpfxGWDD8sVvRot
UH5jtG3cHqMkKI4i7WuCYsOKW4/zH/T4Hf18IeXQmSzn4V8Hw+JluGJcs6Y8jwS8
UePnjor95CD6NngpeSb5TzN+jBVROYjs6HDJxdTKhaY8m7y7gg5u+dMtzqFDrnWC
uQnvLck3l1t0LbP9LsY4GvL2DtfsIsAbJIKLFbeZk9Tw+4pN8gY7lZZUmOyTYyyp
j7RzcaADGadvLJ7DhPY7Qu2DGm6K0Inel5+zNxFhKobBYNsOuyPMXkDQccIT9E+B
5bUSpUadhAM/h68TnJBXwilodPuj/SonnlyokW/rUpsNmJxm7lsyzRNa+ETbTA+J
JurWTpeH20XakU8wv5CXf5+qtkJyo16V4zn5WqD4rHI9jhePXt8ba/CESWcLk7nR
4f2hCw7hGUa2zjWzsUfFgGNpCwQww+rwFS1/gdGRhgLyCiO6zK+giIfTRWrs5nV4
KQhBhHc0/W6M/dH1EkiQWpvk0gVEFoIEWfSOLRQJQYlkq0WOutj4rBw8gDJLkMLH
ZaYSUZQNNqs9HEZ6h6V9Xf4vrsOvZi46cv3TqxLh+HcoHi95nNg=
=fZ8R
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQJHBAABCAAxFiEEz7FuIclQ9n+pXlWPLuufXMCVJsEFAmE6rw4THGZhbnF1YWtl
QGdtYWlsLmNvbQAKCRAu659cwJUmwQdCEACQrb/PPOKRK1ypkk28i1JfkKmtSZbP
/mwrtfnmhhGfC9eqc8dtLVURiSV+ZM7lOFBvhCPAxhYeUxcz/nppiYMOD2THl+gc
0WVhuwwbom/vsTJx1c7Dfeh/bTZIh9UecbNE8J5kinSxGsc/XJO+QfxvDqawny6W
naRxyjgW09zXo4RWZhIXxhlJ+/+y+irQph8CEREojRfcdI8PNwqg3aEG8feP3JKw
KlsLmqLlUallc4LPxcyiQodvvtXLBB19dxqKHtqqKWACJOv3qJlxIPVaw1IBt9ei
10PvWhGnBLxqJcl72wOFx6klAsHQsbjEEoUIF6yu9FlEuazSwHPH9NLJv79O3TKv
0+lAIE0kotZDN/GICWE9caAzyrLTeKWMqYjDEUGqbox8S96D7hPxUTXh2q23+qgQ
7hkgiDmhu2nZq2rAyGbXTdxFYb4m/NccaEhajoW60kmVua9aid2rMgH3F9RuQ8bY
nqrqCml0hOXBCk3qnPVcKhLs51UNc6gPVLN9m18AmEQ+BWlWXLrtURxldL06mYJ9
gfHmf8QthQDb0ceO7DwXAOHgbl4fU3e2D1qNxkEHH4nug8WOHTeBilHPM4vcCv4o
33mC2Ww81hNeNk/TjmOkfvLfHHVqUQDGzajGqBVJbGN35y0KupE7ohceGGFJHlN+
CoA3INIpnYJMbQ==
=/ZzS
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQFFBAABCAAvFiEEbgHuyWVpA7BUK48QA9tjIiZ8NzsFAmE7EUQRHGd1Z2dlckBn
bWFpbC5jb20ACgkQA9tjIiZ8NzsMogf/fGbs0Xo/2RRkxnnVr8yh4eyvivdKIMRP
Q9nAaSIxARZRNJMnwDp3nDDtsX8lmgNtZ13uVs9y4T+ANjR5ieJG63Ro879njsh5
LuEhCEHYoQgwQeus0pgN1HZKoE277KL0jmn+k9NNvXbQMxVJ9c5D72HdNsC1BT6E
lgIEr6QuE4pDJcytQjeAuMBYF+reN/D1MciD+WpGicMhb9JxsU7QyUlIsTdG/1ze
MSvRSf2HANjbZrvYN5uy58ZXv8rwxrYVmVUbjSXgZlQugfu8+ysY62JVVNxUy40F
1SIq3sHBChObGqZD5PFhLzZchAcerhc/MBFDSdxpbsvRnse90rwm8g==
=VWwE
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQJGBAABCAAwFiEE0dvyxLlvLev0wWZUQQEIES5+qB8FAmE6aZkSHGhlYmFzdG9A
Z21haWwuY29tAAoJEEEBCBEufqgfpyUP/R26rRVnFPUlFluosEpYIomm9E9dMl35
Gavp4hQDHcK5tHYi+t+xoZ0w+yBBSR6SPJzopwZjGQr+PfHzCn97T8V8ueI5BXdD
Kip4MfwSgZjY3aGVWFK+4C9STRqEIQbL4pzdft4QnYnZpC4nEtuJSODv3lojzle9
VUg69FnyzfneeuUuzX8xjRLQ3tBunoh4n3BhN15H5SIVA7Jkd525koxEjAuP87Gv
q0sQHCH5e7n7wgxmFPep7m22mL5lfZZGZiy4mTVx/GuOy+vnWCsdrhhORXCPCTKm
Z9hBWXcJCKEuI3lvfKbnQaLrn6lWxoul4k+CSwFKNuYt9mGOQRSrHv/rKPHyViD6
NgyYOuNQ2RYGVMIrBSdCclkA9XYe1Qq4xJbJfGI/aDRJlZbyeLgRH2g4dxoefzUH
kVHVDZMTp0Ej+hC7vLY4BskejyhimBeLflIQelrivrErxhRA0MJaiT1E6wIxMt6n
4sYt7sSftxZdjlPGz5K6NC98pyQ++6e3pqhLUfpF1vAkql6jESoaDrnG3A3PQWwT
niI2DWp4qbqcx2GesnSASOnXAfzYrAnlZnAc/+yqRnHSBilvMQ5EVU9M9V7T8j2N
9VrHvDv++YJEAVybg58gNjPlJ6CmCYMxj+QaYhp6ThKo8Jm6iZdEFkdL5m5IbO4l
pUb6ocJqlOpa
=lxm4
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQHCBAABCAAsFiEEgpIaS4j9RUt+uM48eWxBCQY9Tq8FAmE7BcYOHGpvbkBhdGFj
ay5jb20ACgkQeWxBCQY9Tq/htAwAxEUWk+zkqGMSc7EOB8t8hd5F16LwnllZiWW3
+SKXfeWtKNP3h1J8GLgeMheojXlvKjV/xW1Dgt7T/i8dWjkg7qAcrTVYN1BCPMR/
+Ygh0pT/nbJm73F8fPg7AQmCqojGVyF4zJzQTl+RSEQii7jmof5la9nek6lArOV6
18KWbhGDWDikPL93RbvfFivSXbr+ZJSV89Icg4xTkGcU1HZoP/m7F4V72dJopA2O
R9eJbonzqypS35gDMp/YVAAElwi7mw9xBQtDPPpO9gFMx6i/dsQ/QRRfVQzYlA1O
n/Nkcz+G2SpqfUk3KyZlsIQzoz3Z48MdhKz6VDsD05S/qVRHBLt4hbDUtNrqz7oD
LBPKmGWdhXV0Vzh+HCL48JHNbgmPGpddya869+8bqxOdvni8UMtdwsNdVNzEqsnH
DJSlIpcMzOoPBtE6j2w//OzPtMLD8vPSkVjF3GPOV0WH8x2UyJIj/eIupg0EY26G
LrhrRt3ZZdnpFHlEPk2vBTiuiPKA
=Xipi
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEnerg3HBjJJ+wVHRoHkrtYphs0l0FAmE7luoACgkQHkrtYphs
0l2mnAgAg86T5PE69NxlVgAp7901Vj02mn3TeUEsyhfLbohFkur+3sI2+gVwNjSB
CYnkf6QCFiOM5Pt6hXcTzY0fls2bJEpQaKbZpqZcXB74wi+Am40TdS4S3s8AghfN
FLV8zWItoJ5grJcDoJeV9aN609qglJMFP9NDWp/nj3wLwQPVOtnYiPHGAkjCcBiU
/+Tm43wXedoTcr2NykJKfX6ueMjfeYXy0CoUXjnflBUaJzb+kyvWggZ0rJMXg0Pu
wsm2WeYqV5Ck47aq2d0xhNuv0G9K0qYMxCuwDdIsjrdD2EUds4UloBNQJ0a9ppXc
FlNHhtTgHqI88sS/e/wsdGepnqz8+Q==
=R0SQ
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQJJBAABCAAzFiEEnTzIanL4SUNC6l/RCkG9w/T6/xwFAmE6bQwVHGFhcm9uQHNp
cHNvcmNlcnkuY29tAAoJEApBvcP0+v8clGcP/3H6uQFZPQOI/Bp2NH3+2jv/o/7l
p/zRIJiICHeBRkkNmxK8x2fEIUzxWCa4LHcN9h8Lws8YCTqC5UNCH7LQVENwYFG2
Z2AQUsvnREGAYJfTtmo5T+waMbJEeS2EWa2Za+9WmBUWxVz9QVspQCzZlWgLv807
/4qTh7+8otdJ7KTSEbjWkXw/rQcUpjw1R7mfYM6RpapjzQwXY0jrpSHFYCabfc/S
sacnc6KIQDOGgTQRvBbP+s9GmZORFptoKMAjDLSTNe91qfc8zDOw5RBJmQEc+m9O
DChyTtO+5N+qL+YneiulMeOu2TfBHrvzh/akDpE9tZOrn1Uv4gvTinCfelgt5n31
aqpZ9Bjg5Pcpz+/FOPUsfK0w8z49LM5Y8XYdgIH+WrVhGz9B0oRYyK86zGgEO6Q0
Vo6kfsc05DdWVFpLn19jbsC9r8sZGMquiBiv/AZAjxQTpOMO4j5Ux7ZancuowfeV
/wCj8PSyHna5zGN2HCnNB127Uf9HKy0oFUmQrt1fr+eXaJws/8n/TaaloR3dEEf/
CA7jgol2llsNfK34jR0wdFZViqmcMvb159uhoEACpsqT9xV3m5e+ov4jMuc9qSWC
a8BBZJfqmFgUlAEzptCD0+gsgHBDaDyLNsH1RpZx8dBp+VkPYXLVpT2q8PCRdl7Z
Me9/RAuortWg53T7
=tcZj
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQJJBAABCAAzFiEEdOLe9ddyYLmLwZQ4CZutFjxw+/oFAmE7LIUVHHdpbGw4Y2xh
cmtAZ21haWwuY29tAAoJEAmbrRY8cPv6PvMP/i0Cf10irrcJ7GoRwT8RRUvBVcaT
MVrrefiF2efkFqaGyJuLme7l93hqQqVfKPdCrbSD8Dh/JEGaBb1AMn6VqSAIu88U
vCCOAglT/TpP+yGOjensU6KuodZgH7RVRF0I55c/2Nqiif/Udg1WcygFo1ZkFXrq
jzrjKaZi08hF7i9zlMTH6WMCnndsdjRdJAhw3qxdDgIEIkw+qAiSjuORSmhFkDpo
14tDQpPnHqoOFvjBQzKoNM6bgwHL1oklVNLPRQr4Kvauq8oHICNDFvHv/+el+lS2
TCqzFELFROPK8G3bbz5q17CobUDbWg+mryTznxWaIjxYgBxQt7lekaTFJk/Vh2WP
gZxeUaBbxJ7Qx9aWH0TNCP7/Fe6c4TlddBvPDadLTg+8fJX9bkJ41lu3qCYAaChM
BjVCPl45J3Sfylzmj4Wk/WuTjLWpCLhLzAIqGVqPhhOztdWF7vNduFtpKbFvTtdQ
e0euhTCY+ib28kOUXXg2ySmduOy2IrmLwB+o4+6eDvLErUtMvrLkDghuSoEwlNtj
wdEejAfxRY78sNP1nPmVq5lguiUu2VY30j/LW86c4dmBSsWquHf/E9p0lITXkpDb
loV5hz8n71uqDSgT8k+T/3x8oZDcU+HQGI92JYyl5FQSuvNhEepEmhnXx/M7NwgX
FjEO3YRTI5Ltj58H
=c8Wb
-----END PGP SIGNATURE-----

0.21.1 Release Notes

Bitcoin Core version 0.21.1 is now available from:

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

This minor release includes 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 Mac)
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, macOS 10.12+, 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 0.20.0 onwards, macOS versions earlier than 10.12 are no
longer supported. Additionally, Bitcoin Core does not yet change appearance
when macOS "dark mode" is activated.

Notable changes

Taproot Soft Fork

Included in this release are the mainnet and testnet activation
parameters for the taproot soft fork (BIP341) which also adds support
for schnorr signatures (BIP340) and tapscript (BIP342).

If activated, these improvements will allow users of single-signature
scripts, multisignature scripts, and complex contracts to all use
identical-appearing commitments that enhance their privacy and the
fungibility of all bitcoins. Spenders will enjoy lower fees and the
ability to resolve many multisig scripts and complex contracts with the
same efficiency, low fees, and large anonymity set as single-sig users.
Taproot and schnorr also include efficiency improvements for full nodes
such as the ability to batch signature verification.  Together, the
improvements lay the groundwork for future potential
upgrades that may improve efficiency, privacy, and fungibility further.

Activation for taproot is being managed using a variation of BIP9
versionbits called Speedy Trial (described in BIP341). Taproot's
versionbit is bit 2, and nodes will begin tracking which blocks signal
support for taproot at the beginning of the first retarget period after
taproot’s start date of 24 April 2021.  If 90% of blocks within a
2,016-block retarget period (about two weeks) signal support for taproot
prior to the first retarget period beginning after the time of 11 August
2021, the soft fork will be locked in, and taproot will then be active
as of block 709632 (expected in early or mid November).

Should taproot not be locked in via Speedy Trial activation, it is
expected that a follow-up activation mechanism will be deployed, with
changes to address the reasons the Speedy Trial method failed.

This release includes the ability to pay taproot addresses, although
payments to such addresses are not secure until taproot activates.
It also includes the ability to relay and mine taproot transactions
after activation.  Beyond those two basic capabilities, this release
does not include any code that allows anyone to directly use taproot.
The addition of taproot-related features to Bitcoin Core's wallet is
expected in later releases once taproot activation is assured.

All users, businesses, and miners are encouraged to upgrade to this
release (or a subsequent compatible release) unless they object to
activation of taproot.  If taproot is locked in, then upgrading before
block 709632 is highly recommended to help enforce taproot's new rules
and to avoid the unlikely case of seeing falsely confirmed transactions.

Miners who want to activate Taproot should preferably use this release
to control their signaling.  The getblocktemplate RPC results will
automatically be updated to signal once the appropriate start has been
reached and continue signaling until the timeout occurs or taproot
activates.  Alternatively, miners may manually start signaling on bit 2
at any time; if taproot activates, they will need to ensure they update
their nodes before block 709632 or non-upgraded nodes could cause them to mine on
an invalid chain.  See the versionbits
FAQ for
details.

For more information about taproot, please see the following resources:

• Technical specifications
  
  • BIP340 Schnorr signatures for secp256k1
  • BIP341 Taproot: SegWit version 1 spending rules
  • BIP342 Validation of Taproot scripts
• Popular articles
  
  • Taproot Is Coming: What It Is, and How It Will Benefit Bitcoin
  • What do Schnorr Signatures Mean for Bitcoin?
  • The Schnorr Signature &amp; Taproot Softfork Proposal
• Development history overview
  
  • Taproot
  • Schnorr signatures
  • Tapscript
  • Soft fork activation
• Other
  
  • Questions and answers related to taproot
  • Taproot review

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
    (e.g. 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).

0.21.1 change log

Consensus

• #21377 Speedy trial support for versionbits (ajtowns)
• #21686 Speedy trial activation parameters for Taproot (achow101)

P2P protocol and network code

• #20852 allow CSubNet of non-IP networks (vasild)
• #21043 Avoid UBSan warning in ProcessMessage(…) (practicalswift)

Wallet

• #21166 Introduce DeferredSignatureChecker and have SignatureExtractorClass subclass it (achow101)
• #21083 Avoid requesting fee rates multiple times during coin selection (achow101)

RPC and other APIs

• #21201 Disallow sendtoaddress and sendmany when private keys disabled (achow101)

Build system

• #21486 link against -lsocket if required for *ifaddrs (fanquake)
• #20983 Fix MSVC build after gui#176 (hebasto)

Tests and QA

• #21380 Add fuzzing harness for versionbits (ajtowns)
• #20812 fuzz: Bump FuzzedDataProvider.h (MarcoFalke)
• #20740 fuzz: Update FuzzedDataProvider.h from upstream (LLVM) (practicalswift)
• #21446 Update vcpkg checkout commit (sipsorcery)
• #21397 fuzz: Bump FuzzedDataProvider.h (MarcoFalke)
• #21081 Fix the unreachable code at feature_taproot (brunoerg)
• #20562 Test that a fully signed tx given to signrawtx is unchanged (achow101)
• #21571 Make sure non-IP peers get discouraged and disconnected (vasild, MarcoFalke)
• #21489 fuzz: cleanups for versionbits fuzzer (ajtowns)

Miscellaneous

• #20861 BIP 350: Implement Bech32m and use it for v1+ segwit addresses (sipa)

Documentation

• #21384 add signet to bitcoin.conf documentation (jonatack)
• #21342 Remove outdated comment (hebasto)

Credits

Thanks to everyone who directly contributed to this release:

• Aaron Clauson
• Andrew Chow
• Anthony Towns
• Bruno Garcia
• Fabian Jahr
• fanquake
• Hennadii Stepanov
• Jon Atack
• Luke Dashjr
• MarcoFalke
• Pieter Wuille
• practicalswift
• randymcmillan
• Sjors Provoost
• Vasil Dimov
• W. J. van der Laan

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

Code:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

28264751c982d30b9330e6c1475ddb9ed28be6a2601e8a5f33b6ba49a3d9f5f2  bitcoin-0.21.1-aarch64-linux-gnu.tar.gz
3a92e312ffd3ca92579d46ec52e3dcb1b09bbdd11fe7c6a735e8546c7d9975e0  bitcoin-0.21.1-arm-linux-gnueabihf.tar.gz
1ea5cedb64318e9868a66d3ab65de14516f9ada53143e460d50af428b5aec3c7  bitcoin-0.21.1-osx64.tar.gz
2df15131cd18fd1941adc26f014012b437ccaadab39f1f5dc10282a68e8f9923  bitcoin-0.21.1-osx.dmg
259d74f13271dc51eb4db4b733fb1589038ff7819e849d2351e899f67de218c5  bitcoin-0.21.1-riscv64-linux-gnu.tar.gz
caff23449220cf45753f312cefede53a9eac64000bb300797916526236b6a1e0  bitcoin-0.21.1.tar.gz
afdd0f1717a74af01b88631d17a2f29f89d21ca2e3be0fec0678e7a1e20712d5  bitcoin-0.21.1-win64-setup-unsigned.exe
94c80f90184cdc7e7e75988a55b38384de262336abd80b1b30121c6e965dc74e  bitcoin-0.21.1-win64.zip
366eb44a7a0aa5bd342deea215ec19a184a11f2ca22220304ebb20b9c8917e2b  bitcoin-0.21.1-x86_64-linux-gnu.tar.gz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJgja0mAAoJEJDIAZ42wulkV+IQAI84JuMhIs5muAqTX6G/sxPV
sJ2RJ5aansLEcnFQrrmUNqXpGRB+yiCwlUg9cXLV6zKQkdmDnSuqhTGbivFDLoO3
WeEcQdvkUEodHOk9NK8AVB8NGRK2lkevij4OK0jUUdSVg31dJsygs09TKQGmfXKJ
QnGR7Oz4h/BExrzYfC6PY3AYVJXOkVR86hb2w4r33xNy9DMkvxqbX+B9v1fvqO/V
arcPriVKd0YiEi5nIV5/4ghkHGPAakXzd49DgxW8BVXXqPILBS/MatjgQ5BWJWpK
p4B6V0FYJ2ZpvaTWNBOllUTNRq7YACcKSAEyW3cD9aNPz4o8mb3O7LMr+qb2z0+4
KZuubmOT3sJD37nsZ7DfmERQ7hFYHdlqvthCEQQyglasEZrsLnuCJQNGOSAT+ixM
8jPf3XFDNWm3QFS5icAmykzOWSV4Z0WcQfDjIRbcoXR09N5PgYavhSiwPqpfQ94/
q2igiMmIPH8rlRySc9fKfpYomkWP4W1vfm/wIeSrNm2oNeedL4/4zcv4v6mmnQhO
+i1Npk1TY9+pMAh5xrjUxw3W1QgpVxttIlRmKw6StpVB2Lxl+bGAXp5N7hA8znWX
3AHSDYcdIVEpjvAWGpNPspsyrDv42zElgR8PqS462d/Go6HHhIqd+wHoRIEJTfXM
m6bC44Ak09Ayxu4IxxBw
=5612
-----END PGP SIGNATURE-----

Note that for this release, due to issues with acquiring a Windows code signing certificate, the Windows installer is not code signed. This means that there will be additional warnings when attempting to run the Windows installer.

Today I'm launching the Bitcoin Core usage survey. This survey is aimed at gathering information about how people use Bitcoin Core so that we can improve it in the future. If you have any feedback about Bitcoin Core that you want to share, this survey is a great place to do that.

Click here to take the survey

As I know that many people are concerned about their privacy, this survey is designed to protect your privacy as much as possible. The survey is configured so that there are no trackers and no IP information is stored. Even so, if you want to use Tor, feel free to do so. I've tested that Tor doesn't break the survey (no annoying CAPTCHAs and no broken JS). Questions that ask for any information that could be identifying or privacy revealing are either optional or have an "opt out" type of answer.

For more information about the survey which breaks down why each question is being asked, see this blog post: https://achow101.com/2021/01/bitcoin-core-survey

0.21.0 Release Notes

Bitcoin Core version 0.21.0 is now available from:

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

Or through BitTorrent:

magnet:?xt=urn:btih:665c5bdc6f49948e47c1098d91ace98bd216150e&dn=bitcoin-core-0.21.0&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969

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 Mac)
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, macOS 10.12+, 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 0.20.0 onwards, macOS versions earlier than 10.12 are no
longer supported. Additionally, Bitcoin Core does not yet change appearance
when macOS "dark mode" is activated.

The node's known peers are persisted to disk in a file called peers.dat. The
format of this file has been changed in a backwards-incompatible way in order to
accommodate the storage of Tor v3 and other BIP155 addresses. This means that if
the file is modified by 0.21.0 or newer then older versions will not be able to
read it. Those old versions, in the event of a downgrade, will log an error
message "Incorrect keysize in addrman deserialization" and will continue normal
operation as if the file was missing, creating a new empty one. (#19954, #20284)

Notable changes

P2P and network changes

• The mempool now tracks whether transactions submitted via the wallet or RPCs
    have been successfully broadcast. Every 10-15 minutes, the node will try to
    announce unbroadcast transactions until a peer requests it via a getdata
    message or the transaction is removed from the mempool for other reasons.
    The node will not track the broadcast status of transactions submitted to the
    node using P2P relay. This version reduces the initial broadcast guarantees
    for wallet transactions submitted via P2P to a node running the wallet. (#18038)
  
• The size of the set of transactions that peers have announced and we consider
    for requests has been reduced from 100000 to 5000 (per peer), and further
    announcements will be ignored when that limit is reached. If you need to dump
    (very) large batches of transactions, exceptions can be made for trusted
    peers using the "relay" network permission. For localhost for example it can
    be enabled using the command line option -whitelist=relay@127.0.0.1.
    (#19988)
  
• This release adds support for Tor version 3 hidden services, and rumoring them
    over the network to other peers using
    BIP155.
    Version 2 hidden services are still fully supported by Bitcoin Core, but the
    Tor network will start
    deprecating them in the
    coming months. (#19954)
  
• The Tor onion service that is automatically created by setting the
    -listenonion configuration parameter will now be created as a Tor v3 service
    instead of Tor v2. The private key that was used for Tor v2 (if any) will be
    left untouched in the onion_private_key file in the data directory (see
    -datadir) and can be removed if not needed. Bitcoin Core will no longer
    attempt to read it. The private key for the Tor v3 service will be saved in a
    file named onion_v3_private_key. To use the deprecated Tor v2 service (not
    recommended), the onion_private_key can be copied over
    onion_v3_private_key, e.g.
    cp -f onion_private_key onion_v3_private_key. (#19954)
  
• The client writes a file (anchors.dat) at shutdown with the network addresses
    of the node’s two outbound block-relay-only peers (so called "anchors"). The
    next time the node starts, it reads this file and attempts to reconnect to those
    same two peers. This prevents an attacker from using node restarts to trigger a
    complete change in peers, which would be something they could use as part of an
    eclipse attack. (#17428)
  
• This release adds support for serving
    BIP157 compact
    filters to peers on the network when enabled using
    -blockfilterindex=1 -peercfilters=1. (#16442)
  
• This release adds support for signets
    (BIP325) in
    addition to the existing mainnet, testnet, and regtest networks. Signets are
    centrally-controlled test networks, allowing them to be more predictable
    test environments than the older testnet. One public signet is maintained, and
    selectable using -signet. It is also possible to create personal signets.
    (#18267).
  
• This release implements
    BIP339
    wtxid relay. When negotiated, transactions are announced using their wtxid
    instead of their txid. (#18044).
  
• This release implements the proposed Taproot consensus rules
    (BIP341 and
    BIP342),
    without activation on mainnet. Experimentation with Taproot can be done on
    signet, where its rules are already active. (#19553)
  

Updated RPCs

• The getpeerinfo RPC has a new network field that provides the type of
    network ("ipv4", "ipv6", or "onion") that the peer connected through. (#20002)
  
• The getpeerinfo RPC now has additional last_block and last_transaction
    fields that return the UNIX epoch time of the last block and the last <em>valid</em>
    transaction received from each peer. (#19731)
  
• getnetworkinfo now returns two new fields, connections_in and
    connections_out, that provide the number of inbound and outbound peer
    connections. These new fields are in addition to the existing connections
    field, which returns the total number of peer connections. (#19405)
  
• Exposed transaction version numbers are now treated as unsigned 32-bit
    integers instead of signed 32-bit integers. This matches their treatment in
    consensus logic. Versions greater than 2 continue to be non-standard
    (matching previous behavior of smaller than 1 or greater than 2 being
    non-standard). Note that this includes the joinpsbt command, which combines
    partially-signed transactions by selecting the highest version number.
    (#16525)
  
• getmempoolinfo now returns an additional unbroadcastcount field. The
    mempool tracks locally submitted transactions until their initial broadcast
    is acknowledged by a peer. This field returns the count of transactions
    waiting for acknowledgement.
  
• Mempool RPCs such as getmempoolentry and getrawmempool with
    verbose=true now return an additional unbroadcast field. This indicates
    whether initial broadcast of the transaction has been acknowledged by a
    peer. getmempoolancestors and getmempooldescendants are also updated.
  
• The getpeerinfo RPC no longer returns the banscore field unless the configuration
    option -deprecatedrpc=banscore is used. The banscore field will be fully
    removed in the next major release. (#19469)
  
• The testmempoolaccept RPC returns vsize and a fees object with the base fee
    if the transaction would pass validation. (#19940)
  
• The getpeerinfo RPC now returns a connection_type field. This indicates
    the type of connection established with the peer. It will return one of six
    options. For more information, see the getpeerinfo help documentation.
    (#19725)
  
• The getpeerinfo RPC no longer returns the addnode field by default. This
    field will be fully removed in the next major release.  It can be accessed
    with the configuration option -deprecatedrpc=getpeerinfo_addnode. However,
    it is recommended to instead use the connection_type field (it will return
    manual when addnode is true). (#19725)
  
• The getpeerinfo RPC no longer returns the whitelisted field by default.
    This field will be fully removed in the next major release. It can be accessed
    with the configuration option -deprecatedrpc=getpeerinfo_whitelisted. However,
    it is recommended to instead use the permissions field to understand if specific
    privileges have been granted to the peer. (#19770)
  
• The walletcreatefundedpsbt RPC call will now fail with
    Insufficient funds when inputs are manually selected but are not enough to cover
    the outputs and fee. Additional inputs can automatically be added through the
    new add_inputs option. (#16377)
  
• The fundrawtransaction RPC now supports add_inputs option that when false
    prevents adding more inputs if necessary and consequently the RPC fails.
  

Changes to Wallet or GUI related RPCs can be found in the GUI or Wallet section below.

New RPCs

• The getindexinfo RPC returns the actively running indices of the node,
    including their current sync status and height. It also accepts an index_name
    to specify returning the status of that index only. (#19550)

Build System

Updated settings

• The same ZeroMQ notification (e.g. -zmqpubhashtx=address) can now be
    specified multiple times to publish the same notification to different ZeroMQ
    sockets. (#18309)
  
• The -banscore configuration option, which modified the default threshold for
    disconnecting and discouraging misbehaving peers, has been removed as part of
    changes in 0.20.1 and in this release to the handling of misbehaving peers.
    Refer to "Changes regarding misbehaving peers" in the 0.20.1 release notes for
    details. (#19464)
  
• The -debug=db logging category, which was deprecated in 0.20 and replaced by
    -debug=walletdb to distinguish it from coindb, has been removed. (#19202)
  
• A download permission has been extracted from the noban permission. For
    compatibility, noban implies the download permission, but this may change
    in future releases. Refer to the help of the affected settings -whitebind
    and -whitelist for more details. (#19191)
  
• Netmasks that contain 1-bits after 0-bits (the 1-bits are not contiguous on
    the left side, e.g. 255.0.255.255) are no longer accepted. They are invalid
    according to RFC 4632. Netmasks are used in the -rpcallowip and -whitelist
    configuration options and in the setban RPC. (#19628)
  
• The -blocksonly setting now completely disables fee estimation. (#18766)
  

Changes to Wallet or GUI related settings can be found in the GUI or Wallet section below.

Tools and Utilities

• A new bitcoin-cli -netinfo command provides a network peer connections
    dashboard that displays data from the getpeerinfo and getnetworkinfo RPCs
    in a human-readable format. An optional integer argument from 0 to 4 may
    be passed to see increasing levels of detail. (#19643)
  
• A new bitcoin-cli -generate command, equivalent to RPC generatenewaddress
    followed by generatetoaddress, can generate blocks for command line testing
    purposes. This is a client-side version of the former generate RPC. See the
    help for details. (#19133)
  
• The bitcoin-cli -getinfo command now displays the wallet name and balance for
    each of the loaded wallets when more than one is loaded (e.g. in multiwallet
    mode) and a wallet is not specified with -rpcwallet. (#18594)
  
• The connections field of bitcoin-cli -getinfo is now expanded to return a JSON
    object with in, out and total numbers of peer connections. It previously
    returned a single integer value for the total number of peer connections. (#19405)
  

New settings

• The startupnotify option is used to specify a command to
    execute when Bitcoin Core has finished with its startup
    sequence. (#15367)

Wallet

• Backwards compatibility has been dropped for two getaddressinfo RPC
    deprecations, as notified in the 0.20 release notes. The deprecated label
    field has been removed as well as the deprecated labels behavior of
    returning a JSON object containing name and purpose key-value pairs. Since
    0.20, the labels field returns a JSON array of label names. (#19200)
  
• To improve wallet privacy, the frequency of wallet rebroadcast attempts is
    reduced from approximately once every 15 minutes to once every 12-36 hours.
    To maintain a similar level of guarantee for initial broadcast of wallet
    transactions, the mempool tracks these transactions as a part of the newly
    introduced unbroadcast set. See the "P2P and network changes" section for
    more information on the unbroadcast set. (#18038)
  
• The sendtoaddress and sendmany RPCs accept an optional verbose=True
    argument to also return the fee reason about the sent tx. (#19501)
  
• The wallet can create a transaction without change even when the keypool is
    empty. Previously it failed. (#17219)
  
• The -salvagewallet startup option has been removed. A new salvage command
    has been added to the bitcoin-wallet tool which performs the salvage
    operations that -salvagewallet did. (#18918)
  
• A new configuration flag -maxapsfee has been added, which sets the max
    allowed avoid partial spends (APS) fee. It defaults to 0 (i.e. fee is the
    same with and without APS). Setting it to -1 will disable APS, unless
    -avoidpartialspends is set. (#14582)
  
• The wallet will now avoid partial spends (APS) by default, if this does not
    result in a difference in fees compared to the non-APS variant. The allowed
    fee threshold can be adjusted using the new -maxapsfee configuration
    option. (#14582)
  
• The createwallet, loadwallet, and unloadwallet RPCs now accept
    load_on_startup options to modify the settings list. Unless these options
    are explicitly set to true or false, the list is not modified, so the RPC
    methods remain backwards compatible. (#15937)
  
• A new send RPC with similar syntax to walletcreatefundedpsbt, including
    support for coin selection and a custom fee rate, is added. The send RPC is
    experimental and may change in subsequent releases. (#16378)
  
• The estimate_mode parameter is now case-insensitive in the bumpfee,
    fundrawtransaction, sendmany, sendtoaddress, send and
    walletcreatefundedpsbt RPCs. (#11413)
  
• The bumpfee RPC now uses conf_target rather than confTarget in the
    options. (#11413)
  
• fundrawtransaction and walletcreatefundedpsbt when used with the
    lockUnspents argument now lock manually selected coins, in addition to
    automatically selected coins. Note that locked coins are never used in
    automatic coin selection, but can still be manually selected. (#18244)
  
• The -zapwallettxes startup option has been removed and its functionality
    removed from the wallet.  This option was originally intended to allow for
    rescuing wallets which were affected by a malleability attack. More recently,
    it has been used in the fee bumping of transactions that did not signal RBF.
    This functionality has been superseded with the abandon transaction feature. (#19671)
  
• The error code when no wallet is loaded, but a wallet RPC is called, has been
    changed from -32601 (method not found) to -18 (wallet not found).
    (#20101)
  

Automatic wallet creation removed

Bitcoin Core will no longer automatically create new wallets on startup. It will
load existing wallets specified by -wallet options on the command line or in
bitcoin.conf or settings.json files. And by default it will also load a
top-level unnamed ("") wallet. However, if specified wallets don't exist,
Bitcoin Core will now just log warnings instead of creating new wallets with
new keys and addresses like previous releases did.

New wallets can be created through the GUI (which has a more prominent create
wallet option), through the bitcoin-cli createwallet or bitcoin-wallet
create commands, or the createwallet RPC. (#15454, #20186)

Experimental Descriptor Wallets

Please note that Descriptor Wallets are still experimental and not all expected functionality
is available. Additionally there may be some bugs and current functions may change in the future.
Bugs and missing functionality can be reported to the issue tracker.

0.21 introduces a new type of wallet - Descriptor Wallets. Descriptor Wallets store
scriptPubKey information using output descriptors. This is in contrast to the Legacy Wallet
structure where keys are used to implicitly generate scriptPubKeys and addresses. Because of this
shift to being script based instead of key based, many of the confusing things that Legacy
Wallets do are not possible with Descriptor Wallets. Descriptor Wallets use a definition
of "mine" for scripts which is simpler and more intuitive than that used by Legacy Wallets.
Descriptor Wallets also uses different semantics for watch-only things and imports.

As Descriptor Wallets are a new type of wallet, their introduction does not affect existing wallets.
Users who already have a Bitcoin Core wallet can continue to use it as they did before without
any change in behavior. Newly created Legacy Wallets (which remains the default type of wallet) will
behave as they did in previous versions of Bitcoin Core.

The differences between Descriptor Wallets and Legacy Wallets are largely limited to non user facing
things. They are intended to behave similarly except for the import/export and watchonly functionality
as described below.

Creating Descriptor Wallets

Descriptor wallets are not the default type of wallet.

In the GUI, a checkbox has been added to the Create Wallet Dialog to indicate that a
Descriptor Wallet should be created. And a descriptors option has been added to createwallet RPC.
Setting descriptors to true will create a Descriptor Wallet instead of a Legacy Wallet.

Without those options being set, a Legacy Wallet will be created instead.

IsMine Semantics

IsMine refers to the function used to determine whether a script belongs to the wallet.
This is used to determine whether an output belongs to the wallet. IsMine in Legacy Wallets
returns true if the wallet would be able to sign an input that spends an output with that script.
Since keys can be involved in a variety of different scripts, this definition for IsMine can
lead to many unexpected scripts being considered part of the wallet.

With Descriptor Wallets, descriptors explicitly specify the set of scripts that are owned by
the wallet. Since descriptors are deterministic and easily enumerable, users will know exactly
what scripts the wallet will consider to belong to it. Additionally the implementation of IsMine
in Descriptor Wallets is far simpler than for Legacy Wallets. Notably, in Legacy Wallets, IsMine
allowed for users to take one type of address (e.g. P2PKH), mutate it into another address type
(e.g. P2WPKH), and the wallet would still detect outputs sending to the new address type
even without that address being requested from the wallet. Descriptor Wallets do not
allow for this and will only watch for the addresses that were explicitly requested from the wallet.

These changes to IsMine will make it easier to reason about what scripts the wallet will
actually be watching for in outputs. However for the vast majority of users, this change is
largely transparent and will not have noticeable effect.

Imports and Exports

In Legacy Wallets, raw scripts and keys could be imported to the wallet. Those imported scripts
and keys are treated separately from the keys generated by the wallet. This complicates the IsMine
logic as it has to distinguish between spendable and watchonly.

Descriptor Wallets handle importing scripts and keys differently. Only complete descriptors can be
imported. These descriptors are then added to the wallet as if it were a descriptor generated by
the wallet itself. This simplifies the IsMine logic so that it no longer has to distinguish
between spendable and watchonly. As such, the watchonly model for Descriptor Wallets is also
different and described in more detail in the next section.

To import into a Descriptor Wallet, a new importdescriptors RPC has been added that uses a syntax
similar to that of importmulti.

As Legacy Wallets and Descriptor Wallets use different mechanisms for storing and importing scripts and keys
the existing import RPCs have been disabled for descriptor wallets.
New export RPCs for Descriptor Wallets have not yet been added.

The following RPCs are disabled for Descriptor Wallets:

• importprivkey
• importpubkey
• importaddress
• importwallet
• dumpprivkey
• dumpwallet
• importmulti
• addmultisigaddress
• sethdseed

Watchonly Wallets

A Legacy Wallet contains both private keys and scripts that were being watched.
Those watched scripts would not contribute to your normal balance. In order to see the watchonly
balance and to use watchonly things in transactions, an include_watchonly option was added
to many RPCs that would allow users to do that. However it is easy to forget to include this option.

Descriptor Wallets move to a per-wallet watchonly model. Instead an entire wallet is considered to be
watchonly depending on whether it was created with private keys disabled. This eliminates the need
to distinguish between things that are watchonly and things that are not within a wallet itself.

This change does have a caveat. If a Descriptor Wallet with private keys <em>enabled</em> has
a multiple key descriptor without all of the private keys (e.g. multi(...) with only one private key),
then the wallet will fail to sign and broadcast transactions. Such wallets would need to use the PSBT
workflow but the typical GUI Send, sendtoaddress, etc. workflows would still be available, just
non-functional.

This issue is worsened if the wallet contains both single key (e.g. wpkh(...)) descriptors and such
multiple key descriptors as some transactions could be signed and broadcast and others not. This is
due to some transactions containing only single key inputs, while others would contain both single
key and multiple key inputs, depending on which are available and how the coin selection algorithm
selects inputs. However this is not considered to be a supported use case; multisigs
should be in their own wallets which do not already have descriptors. Although users cannot export
descriptors with private keys for now as explained earlier.

BIP 44/49/84 Support

The change to using descriptors changes the default derivation paths used by Bitcoin Core
to adhere to BIP 44/49/84. Descriptors with different derivation paths can be imported without
issue.

SQLite Database Backend

Descriptor wallets use SQLite for the wallet file instead of the Berkeley DB used in legacy wallets.
This will break compatibility with any existing tooling that operates on wallets, however compatibility
was already being broken by the move to descriptors.

Wallet RPC changes

• The upgradewallet RPC replaces the -upgradewallet command line option.
    (#15761)
  
• The settxfee RPC will fail if the fee was set higher than the -maxtxfee
    command line setting. The wallet will already fail to create transactions
    with fees higher than -maxtxfee. (#18467)
  
• A new fee_rate parameter/option denominated in satoshis per vbyte (sat/vB)
    is introduced to the sendtoaddress, sendmany, fundrawtransaction and
    walletcreatefundedpsbt RPCs as well as to the experimental new send
    RPC. The legacy feeRate option in fundrawtransaction and
    walletcreatefundedpsbt still exists for setting a fee rate in BTC per 1,000
    vbytes (BTC/kvB), but it is expected to be deprecated soon to avoid
    confusion. For these RPCs, the fee rate error message is updated from BTC/kB
    to sat/vB and the help documentation in BTC/kB is updated to BTC/kvB. The
    send and sendtoaddress RPC examples are updated to aid users in creating
    transactions with explicit fee rates. (#20305, #11413)
  
• The bumpfee RPC fee_rate option is changed from BTC/kvB to sat/vB and the
    help documentation is updated. Users are warned that this is a breaking API
    change, but it should be relatively benign: the large (100,000 times)
    difference between BTC/kvB and sat/vB units means that a transaction with a
    fee rate mistakenly calculated in BTC/kvB rather than sat/vB should raise an
    error due to the fee rate being set too low. In the worst case, the
    transaction may send at 1 sat/vB, but as Replace-by-Fee (BIP125 RBF) is active
    by default when an explicit fee rate is used, the transaction fee can be
    bumped. (#20305)
  

GUI changes

• Wallets created or loaded in the GUI will now be automatically loaded on
    startup, so they don't need to be manually reloaded next time Bitcoin Core is
    started. The list of wallets to load on startup is stored in
    \<datadir\>/settings.json and augments any command line or bitcoin.conf
    -wallet= settings that specify more wallets to load. Wallets that are
    unloaded in the GUI get removed from the settings list so they won't load
    again automatically next startup. (#19754)
  
• The GUI Peers window no longer displays a "Ban Score" field. This is part of
    changes in 0.20.1 and in this release to the handling of misbehaving
    peers. Refer to "Changes regarding misbehaving peers" in the 0.20.1 release
    notes for details. (#19512)
  

Low-level changes

RPC

• To make RPC sendtoaddress more consistent with sendmany the following error
      sendtoaddress codes were changed from -4 to -6:
• Insufficient funds
• Fee estimation failed
• Transaction has too long of a mempool chain
  
• The sendrawtransaction error code for exceeding maxfeerate has been changed from
    -26 to -25. The error string has been changed from "absurdly-high-fee" to
    "Fee exceeds maximum configured by user (e.g. -maxtxfee, maxfeerate)." The
    testmempoolaccept RPC returns max-fee-exceeded rather than absurdly-high-fee
    as the reject-reason. (#19339)
  
• To make wallet and rawtransaction RPCs more consistent, the error message for
    exceeding maximum feerate has been changed to "Fee exceeds maximum configured by user
    (e.g. -maxtxfee, maxfeerate)." (#19339)
  

Tests

• The BIP 325 default signet can be enabled by the -chain=signet or -signet
    setting. The settings -signetchallenge and -signetseednode allow
    enabling a custom signet.
  
• The generateblock RPC allows testers using regtest mode to
    generate blocks that consist of a custom set of transactions. (#17693)
  

Code:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

43416854330914992bbba2d0e9adf2a6fff4130be9af8ae2ef1186e743d9a3fe  bitcoin-0.21.0-aarch64-linux-gnu.tar.gz
f028af308eda45a3c4c90f9332f96b075bf21e3495c945ebce48597151808176  bitcoin-0.21.0-arm-linux-gnueabihf.tar.gz
695fb624fa6423f5da4f443b60763dd1d77488bfe5ef63760904a7b54e91298d  bitcoin-0.21.0-osx64.tar.gz
6223fd23d07133a6bfa2aa3d2554a09dc1d790d28ce67b0085d3fdcc1c126e05  bitcoin-0.21.0-osx.dmg
f8b2adfeae021a672effbc7bd40d5c48d6b94e53b2dd660f787340bf1a52e4e9  bitcoin-0.21.0-riscv64-linux-gnu.tar.gz
1a91202c62ee49fb64d57a52b8d6d01cd392fffcbef257b573800f9289655f37  bitcoin-0.21.0.tar.gz
54050748ef4d4f000ea1ece472491b3e5fd546efc74ed52119354b2893f6624b  bitcoin-0.21.0-win64-setup.exe
1d0052c4ce80227fb6d0bc1c4e673ba21033e219c1f935d25f130ef7f43360d4  bitcoin-0.21.0-win64.zip
da7766775e3f9c98d7a9145429f2be8297c2672fe5b118fd3dc2411fb48e0032  bitcoin-0.21.0-x86_64-linux-gnu.tar.gz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJgADqTAAoJEJDIAZ42wulkjtkQAJwlSTDinKsxZIMky3MeVhwB
CmxxYiMLPQA8bwgxyc4RaTxUrqL2oExPOtfcDzcR1WbQe12niG40N/2yrtf66lG9
KbSsQD6nKat9B3mCk9/jNkJHWmq5JJbOyfRs2mex75Lj7UHaPPrqh2rMfEewljed
kHkDuaqeqYlTAh981WqLD+l5jnpQZqBSrcz3YTTvXWd7xKfFSVzqF/tD4CQFrPX2
9b2BLzA/u+29Z3s+zio1l5c7fikNDd404T5U/y+NMOyCmgT4eiDGLQPlEpoGNq3w
GYU7FNZUO9xXeatx4PI8qiq5mIK46UwfPUTeruTzNrHsME7YioUa87uSYKM8jqwP
FSnbhYoUqCB/wPaKZwEF+2WzG88yj2+PzalVt8cnjRnTQ77COtHJqs8AjLWnVACF
LluplM16xyiLn0FWkrEHyi5HlI+X+cqIiTtehojMBXIkHugIYMnT5XB9llh5OWXg
Bp1UGupojLXYuMNF5R6cU5Iq+xJjbUiQ/PDm38MBlFlQ9RzRCYyZpMYZE3K9p789
jpjdYdMPtzkYlIKD87S89JtE1s6i/SkTPhebyu/328rqkqnNKSCHnuB7Fy2iEKJj
5kLs/LjY8yxSMuGeNl6LhWGKVZKy0AS/BztSHr2jgThfhN1BemFRcViSvcXhMeNw
ka8Z9KLt/N0ziabBexAw
=bi4p
-----END PGP SIGNATURE-----

New paper from Jonas Nick, Tim Ruffing, and Yannick Seurin for a 2 round Schnorr Multisignature scheme based upon the original 3 round MuSig scheme.

Abstract: Multi-signatures enable a group of signers to produce a single signature on a given message. Recently, Drijvers et al. (S&P'19) showed that all thus far proposed two-round multi-signature schemes in the DL setting (without pairings) are insecure under concurrent sessions, i.e., if a single signer participates in multiple signing sessions concurrently. While Drijvers et al. improve the situation by constructing a secure two-round scheme, saving a round comes with the price of having less compact signatures. In particular, the signatures produced by their scheme are more than twice as large as Schnorr signatures, which arguably are the most natural and compact among all practical DL signatures and are therefore becoming popular in cryptographic applications (e.g., support for Schnorr signature verification has been proposed to be included in Bitcoin). If one needs a multi-signature scheme that can be used as a drop-in replacement for Schnorr signatures, then one is either forced to resort to a three-round scheme such as MuSig (Maxwell et al., DCC 2019) or MSDL-pop (Boneh, Drijvers, and Neven, ASIACRYPT 2018), or to accept that signing sessions are only secure when run sequentially, which may be hard to enforce in practice, e.g., when the same signing key is used by multiple devices.

In this work, we propose MuSig2, a novel and simple two-round multi-signature scheme variant of the MuSig scheme. Our scheme is the first multi-signature scheme that simultaneously i) is secure under concurrent signing sessions, ii) supports key aggregation, iii) outputs ordinary Schnorr signatures, iv) needs only two communication rounds, and v) has similar signer complexity as regular Schnorr signatures. Furthermore, our scheme is the first multi-signature scheme in the DL setting that supports preprocessing of all but one rounds, effectively enabling a non-interactive signing process, without forgoing security under concurrent sessions. The combination of all these features makes MuSig2 highly practical. We prove the security of MuSig2 under the one-more discrete logarithm (OMDL) assumption in the random oracle model, and the security of a more efficient variant in the combination of the random oracle and algebraic group models.

https://eprint.iacr.org/2020/1261

0.20.1 Release Notes

Bitcoin Core version 0.20.1 is now available from:

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

This minor release includes 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 Mac)
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, macOS 10.12+, 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 0.20.0 onwards, macOS versions earlier than 10.12 are no
longer supported. Additionally, Bitcoin Core does not yet change appearance
when macOS "dark mode" is activated.

Known Bugs

The process for generating the source code release ("tarball") has changed in an
effort to make it more complete, however, there are a few regressions in
this release:

• The generated configure script is currently missing, and you will need to
    install autotools and run ./autogen.sh before you can run
    ./configure. This is the same as when checking out from git.
  
• Instead of running make simply, you should instead run
    BITCOIN_GENBUILD_NO_GIT=1 make.
  

Notable changes

Changes regarding misbehaving peers

Peers that misbehave (e.g. send us invalid blocks) are now referred to as
discouraged nodes in log output, as they're not (and weren't) strictly banned:
incoming connections are still allowed from them, but they're preferred for
eviction.

Furthermore, a few additional changes are introduced to how discouraged
addresses are treated:

• Discouraging an address does not time out automatically after 24 hours
    (or the -bantime setting). Depending on traffic from other peers,
    discouragement may time out at an indeterminate time.
  
• Discouragement is not persisted over restarts.
  
• There is no method to list discouraged addresses. They are not returned by
    the listbanned RPC. That RPC also no longer reports the ban_reason
    field, as "manually added" is the only remaining option.
  
• Discouragement cannot be removed with the setban remove RPC command.
    If you need to remove a discouragement, you can remove all discouragements by
    stop-starting your node.
  

Notification changes

-walletnotify notifications are now sent for wallet transactions that are
removed from the mempool because they conflict with a new block. These
notifications were sent previously before the v0.19 release, but had been
broken since that release (bug
[#18325](https://github.com/bitcoin/bitcoin/pull/18325)).

PSBT changes

PSBTs will contain both the non-witness utxo and the witness utxo for segwit
inputs in order to restore compatibility with wallet software that are now
requiring the full previous transaction for segwit inputs. The witness utxo
is still provided to maintain compatibility with software which relied on its
existence to determine whether an input was segwit.

0.20.1 change log

Mining

• #19019 Fix GBT: Restore "!segwit" and "csv" to "rules" key (luke-jr)

P2P protocol and network code

• #19219 Replace automatic bans with discouragement filter (sipa)

Wallet

• #19300 Handle concurrent wallet loading (promag)
• #18982 Minimal fix to restore conflicted transaction notifications (ryanofsky)

RPC and other APIs

• #19524 Increment input value sum only once per UTXO in decodepsbt (fanquake)
• #19517 psbt: Increment input value sum only once per UTXO in decodepsbt (achow101)
• #19215 psbt: Include and allow both non_witness_utxo and witness_utxo for segwit inputs (achow101)

GUI

• #19097 Add missing QPainterPath include (achow101)
• #19059 update Qt base translations for macOS release (fanquake)

Build system

• #19152 improve build OS configure output (skmcontrib)
• #19536 qt, build: Fix QFileDialog for static builds (hebasto)

Tests and QA

• #19444 Remove cached directories and associated script blocks from appveyor config (sipsorcery)
• #18640 appveyor: Remove clcache (MarcoFalke)

Miscellaneous

• #19194 util: Don't reference errno when pthread fails (miztake)
• #18700 Fix locking on WSL using flock instead of fcntl (meshcollider)

Credits

Thanks to everyone who directly contributed to this release:

• Aaron Clauson
• Andrew Chow
• fanquake
• Hennadii Stepanov
• João Barbosa
• Luke Dashjr
• MarcoFalke
• MIZUTA Takeshi
• Pieter Wuille
• Russell Yanofsky
• sachinkm77
• Samuel Dobson
• Wladimir J. van der Laan

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

0.20.0 Release Notes

Bitcoin Core version 0.20.0 is now available from:

https://bitcoincore.org/bin/bitcoin-core-0.20.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 Mac)
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, macOS 10.12+, 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 0.20.0 onwards, macOS versions earlier than 10.12 are no
longer supported. Additionally, Bitcoin Core does not yet change appearance
when macOS "dark mode" is activated.

Known Bugs

The process for generating the source code release ("tarball") has changed in an
effort to make it more complete, however, there are a few regressions in
this release:

• The generated configure script is currently missing, and you will need to
    install autotools and run ./autogen.sh before you can run
    ./configure. This is the same as when checking out from git.
  
• Instead of running make simply, you should instead run
    BITCOIN_GENBUILD_NO_GIT=1 make.
  

Notable changes

P2P and network changes
Removal of BIP61 reject network messages from Bitcoin Core

The -enablebip61 command line option to enable BIP61 has been removed.
(#17004)

This feature has been disabled by default since Bitcoin Core version 0.18.0.
Nodes on the network can not generally be trusted to send valid messages
(including reject messages), so this should only ever be used when
connected to a trusted node.  Please use the alternatives recommended
below if you rely on this removed feature:

• Testing or debugging of implementations of the Bitcoin P2P network protocol
    should be done by inspecting the log messages that are produced by a recent
    version of Bitcoin Core. Bitcoin Core logs debug messages
    (-debug=<category>) to a stream (-printtoconsole) or to a file
    (-debuglogfile=<debug.log>).
  
• Testing the validity of a block can be achieved by specific RPCs:
  
• submitblock
  
• getblocktemplate with 'mode' set to 'proposal' for blocks with
      potentially invalid POW
  
• Testing the validity of a transaction can be achieved by specific RPCs:
  
• sendrawtransaction
  
• testmempoolaccept
  
• Wallets should not assume a transaction has propagated to the network
    just because there are no reject messages.  Instead, listen for the
    transaction to be announced by other peers on the network.  Wallets
    should not assume a lack of reject messages means a transaction pays
    an appropriate fee.  Instead, set fees using fee estimation and use
    replace-by-fee to increase a transaction's fee if it hasn't confirmed
    within the desired amount of time.
  

The removal of BIP61 reject message support also has the following minor RPC
and logging implications:

• testmempoolaccept and sendrawtransaction no longer return the P2P reject
    code when a transaction is not accepted to the mempool. They still return the
    verbal reject reason.
  
• Log messages that previously reported the reject code when a transaction was
    not accepted to the mempool now no longer report the reject code. The reason
    for rejection is still reported.
  

Updated RPCs

• The RPCs which accept descriptors now accept the new sortedmulti(...) descriptor
    type which supports multisig scripts where the public keys are sorted
    lexicographically in the resulting script.  (#17056)
  
• The walletprocesspsbt and walletcreatefundedpsbt RPCs now include
    BIP32 derivation paths by default for public keys if we know them.
    This can be disabled by setting the bip32derivs parameter to
    false.  (#17264)
  
• The bumpfee RPC's parameter totalFee, which was deprecated in
    0.19, has been removed.  (#18312)
  
• The bumpfee RPC will return a PSBT when used with wallets that have
    private keys disabled.  (#16373)
  
• The getpeerinfo RPC now includes a mapped_as field to indicate the
    mapped Autonomous System used for diversifying peer selection. See the
    -asmap configuration option described below in <em>New Settings</em>.  (#16702)
  
• The createmultisig and addmultisigaddress RPCs now return an
    output script descriptor for the newly created address.  (#18032)
  

Build System

• OpenSSL is no longer used by Bitcoin Core.  (#17265)
  
• BIP70 support has been fully removed from Bitcoin Core. The
    --enable-bip70 option remains, but it will throw an error during configure.
    (#17165)
  
• glibc 2.17 or greater is now required to run the release binaries. This
    retains compatibility with RHEL 7, CentOS 7, Debian 8 and Ubuntu 14.04 LTS. (#17538)
  
• The source code archives that are provided with gitian builds no longer contain
    any autotools artifacts. Therefore, to build from such source, a user
    should run the ./autogen.sh script from the root of the unpacked archive.
    This implies that autotools and other required packages are installed on the
    user's system. (#18331)
  

New settings

• New rpcwhitelist and rpcwhitelistdefault configuration parameters
    allow giving certain RPC users permissions to only some RPC calls.
    (#12763)
  
• A new -asmap configuration option has been added to diversify the
    node's network connections by mapping IP addresses Autonomous System
    Numbers (ASNs) and then limiting the number of connections made to any
    single ASN.  See issue  #16599,
    PR #16702, and the
    bitcoind help for more information.  This option is experimental and
    subject to removal or breaking changes in future releases, so the
    legacy /16 prefix mapping of IP addresses remains the default.  (#16702)
  

Updated settings

• All custom settings configured when Bitcoin Core starts are now
    written to the debug.log file to assist troubleshooting.  (#16115)
  
• Importing blocks upon startup via the bootstrap.dat file no longer
    occurs by default. The file must now be specified with
    -loadblock=<file>.  (#17044)
  
• The -debug=db logging category has been renamed to
    -debug=walletdb to distinguish it from coindb.  The -debug=db
    option has been deprecated and will be removed in the next major
    release.  (#17410)
  
• The -walletnotify configuration parameter will now replace any %w
    in its argument with the name of the wallet generating the
    notification.  This is not supported on Windows. (#13339)
  

Removed settings

• The -whitelistforcerelay configuration parameter has been removed after
    it was discovered that it was rendered ineffective in version 0.13 and
    hasn't actually been supported for almost four years.  (#17985)

GUI changes

• The "Start Bitcoin Core on system login" option has been removed on macOS.
    (#17567)
  
• In the Peers window, the details for a peer now displays a Mapped AS
    field to indicate the mapped Autonomous System used for diversifying
    peer selection. See the -asmap configuration option in <em>New
    Settings</em>, above.  (#18402)
  
• A "known bug" announced
    in the release notes of version 0.18 has been fixed.  The issue
    affected anyone who simultaneously used multiple Bitcoin Core wallets
    and the GUI coin control feature. (#18894)
  
• For watch-only wallets, creating a new transaction in the Send screen
    or fee bumping an existing transaction in the Transactions screen will
    automatically copy a Partially-Signed Bitcoin Transaction (PSBT) to
    the system clipboard.  This can then be pasted into an external
    program such as HWI for
    signing.  Future versions of Bitcoin Core should support a GUI option
    for finalizing and broadcasting PSBTs, but for now the debug console
    may be used with the finalizepsbt and sendrawtransaction RPCs.
    (#16944, #17492)
  

Wallet

• The wallet now by default uses bech32 addresses when using RPC, and
    creates native segwit change outputs.  (#16884)
  
• The way that output trust was computed has been fixed, which affects
    confirmed/unconfirmed balance status and coin selection.  (#16766)
  
• The gettransaction, listtransactions and listsinceblock RPC
    responses now also include the height of the block that contains the
    wallet transaction, if any.  (#17437)
  
• The getaddressinfo RPC has had its label field deprecated
    (re-enable for this release using the configuration parameter
    -deprecatedrpc=label).  The labels field is altered from returning
    JSON objects to returning a JSON array of label names (re-enable
    previous behavior for this release using the configuration parameter
    -deprecatedrpc=labelspurpose).  Backwards compatibility using the
    deprecated configuration parameters is expected to be dropped in the
    0.21 release.  (#17585, #17578)
  

Documentation changes

• Bitcoin Core's automatically-generated source code documentation is
    now available at https://doxygen.bitcoincore.org.  (#17596)

Low-level changes

Utilities

• The bitcoin-cli utility used with the -getinfo parameter now
    returns a headers field with the number of downloaded block headers
    on the best headers chain (similar to the blocks field that is also
    returned) and a verificationprogress field that estimates how much
    of the best block chain has been synced by the local node.  The
    information returned no longer includes the protocolversion,
    walletversion, and keypoololdest fields.  (#17302, #17650)
  
• The bitcoin-cli utility now accepts a -stdinwalletpassphrase
    parameter that can be used when calling the walletpassphrase and
    walletpassphrasechange RPCs to read the passphrase from standard
    input without echoing it to the terminal, improving security against
    anyone who can look at your screen.  The existing -stdinrpcpass
    parameter is also updated to not echo the passphrase. (#13716)
  

Command line

• Command line options prefixed with main/test/regtest network names like
    -main.port=8333 -test.server=1 previously were allowed but ignored. Now
    they trigger "Invalid parameter" errors on startup. (#17482)

New RPCs

• The dumptxoutset RPC outputs a serialized snapshot of the current
    UTXO set.  A script is provided in the contrib/devtools directory
    for generating a snapshot of the UTXO set at a particular block
    height.  (#16899)
  
• The generatetodescriptor RPC allows testers using regtest mode to
    generate blocks that pay an arbitrary output script descriptor.
    (#16943)
  

Updated RPCs

• The verifychain RPC default values are now static instead of
    depending on the command line options or configuration file
    (-checklevel, and -checkblocks). Users can pass in the RPC
    arguments explicitly when they don't want to rely on the default
    values. (#18541)
  
• The getblockchaininfo RPC's verificationprogress field will no
    longer report values higher than 1.  Previously it would occasionally
    report the chain was more than 100% verified.  (#17328)
  

Tests

• It is now an error to use an unqualified walletdir=path setting in
    the config file if running on testnet or regtest networks. The setting
    now needs to be qualified as chain.walletdir=path or placed in the
    appropriate [chain] section. (#17447)
  
• -fallbackfee was 0 (disabled) by default for the main chain, but
    0.0002 by default for the test chains. Now it is 0 by default for all
    chains. Testnet and regtest users will have to add
    fallbackfee=0.0002 to their configuration if they weren't setting it
    and they want it to keep working like before. (#16524)
  

Build system

• Support is provided for building with the Android Native Development
    Kit (NDK).  (#16110)

Code:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

081b30b0f1af95656242c83eef30bbf7216b1a30fa8e8f29b3b160fe520d28f6  bitcoin-0.20.0-aarch64-linux-gnu.tar.gz
05014c7ff00f4496b1f389f0961d807e04505d8721d5c6f69567f2a0ec1985cc  bitcoin-0.20.0-arm-linux-gnueabihf.tar.gz
34f377fee2c7adf59981dde7e41215765d47b466f773cf2673137d30495b2675  bitcoin-0.20.0-osx64.tar.gz
a6e44b928d9ac04f11d43e920f4971fbdf1e77a8c28f7c14fafdd741ca7bc99f  bitcoin-0.20.0-osx.dmg
5b9cae3aa4197d1e557ff236754f489bce877ebba2267ce33af79b2ca4a13af6  bitcoin-0.20.0-riscv64-linux-gnu.tar.gz
ec5a2358ee868d845115dc4fc3ed631ff063c57d5e0a713562d083c5c45efb28  bitcoin-0.20.0.tar.gz
0f1ea61a9aa9aba383a43bcdb5755b072cfff016b9c6bb0afa772a8685bcf7b0  bitcoin-0.20.0-win64-setup.exe
3e9ddfa05b7967e43fb502b735b6c4d716ec06f63ab7183df2e006ed4a6a431f  bitcoin-0.20.0-win64.zip
35ec10f87b6bc1e44fd9cd1157e5dfa483eaf14d7d9a9c274774539e7824c427  bitcoin-0.20.0-x86_64-linux-gnu.tar.gz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJe13SYAAoJEJDIAZ42wulkYrwQAIcbo6TAtb0AZkyC4ewM7+80
nQZTx7d0w9ljdr/0Wt9B/2F6BNhiW2TR1n+tYZ//Juk+kH79qQSVwsBSSdMpQJOR
7hlivCHUx5fwJEhtP7mEtuMnu/9o1YOX5lahPV3Yjfv8l3zdec6Dwlf6OAsPX8Dc
PAiWfhu/UplQnnI1U47LctwqTD6F5ywYunQ4U7S6Qfd8jqvQUTT7JQ68au1P1oHM
29/FCc9Qx7KbSVDgRWe9cjok7R6XRal1rQUz/4HW9OClRDUAsQym0Kxf3OzJVgJi
5hUq666Ld/rh7jQVjlMkSK8vrQn6VaNKk15q8TM238kRwj932zeZn9swkPaNf6ml
+pKFu7HxZhYpACa97vlHwEais4e/mVanTI5MBtt2POTT5ffkSD3isTfkiPHgYV3D
rTo4pmhAcFiOkXWcuNe5yWV2zZFkwy0gRgL/aNwHc3jnuv3foMkgS4SApL1/RnUs
hFf/Ce299c7WQa73tupHUJI0PrTggvvQHniGEZdomlFxaEzcTbOIW3Ao5IizZ5Yw
Aaum8n5/lRQgUMOQgF6EeWxEMKoqCA3wZITZ6mqoJBega52o3anZam5Lu+UKqhLV
a7May7n6L4acZkeJLKeJ4cMSsQYQ45Cc3dQJTmEmNicL9ix/crig38mKGLi7Sj6T
s3iI+NZb2h7g7gYg93MF
=e/wL
-----END PGP SIGNATURE-----

0.19.1 Release Notes

Bitcoin Core version 0.19.1 is now available from:

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

This minor release includes 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 for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac)
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 datadir 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, macOS 10.10+, and Windows 7 and newer. It is not recommended
to use Bitcoin Core on unsupported systems.

Bitcoin Core should also work on most other Unix-like systems but is not
as frequently tested on them.

From Bitcoin Core 0.17.0 onwards, macOS versions earlier than 10.10 are no
longer supported, as Bitcoin Core is now built using Qt 5.9.x which requires
macOS 10.10+. Additionally, Bitcoin Core does not yet change appearance when
macOS "dark mode" is activated.

In addition to previously supported CPU platforms, this release's pre-compiled
distribution provides binaries for the RISC-V platform.

0.19.1 change log

Wallet

• #17643 Fix origfee return for bumpfee with feerate arg (instagibbs)
• #16963 Fix unique_ptr usage in boost::signals2 (promag)
• #17258 Fix issue with conflicted mempool tx in listsinceblock (adamjonas, mchrostowski)
• #17924 Bug: IsUsedDestination shouldn't use key id as script id for ScriptHash (instagibbs)
• #17621 IsUsedDestination should count any known single-key address (instagibbs)
• #17843 Reset reused transactions cache (fjahr)

RPC and other APIs

• #17687 cli: Fix fatal leveldb error when specifying -blockfilterindex=basic twice (brakmic)
• #17728 require second argument only for scantxoutset start action (achow101)
• #17445 zmq: Fix due to invalid argument and multiple notifiers (promag)
• #17524 psbt: handle unspendable psbts (achow101)
• #17156 psbt: check that various indexes and amounts are within bounds (achow101)

GUI

• #17427 Fix missing qRegisterMetaType for size_t (hebasto)
• #17695 disable File->CreateWallet during startup (fanquake)
• #17634 Fix comparison function signature (hebasto)
• #18062 Fix unintialized WalletView::progressDialog (promag)

Tests and QA

• #17416 Appveyor improvement - text file for vcpkg package list (sipsorcery)
• #17488 fix "bitcoind already running" warnings on macOS (fanquake)
• #17980 add missing #include to fix compiler errors (kallewoof)

Platform support

• #17736 Update msvc build for Visual Studio 2019 v16.4 (sipsorcery)
• #17364 Updates to appveyor config for VS2019 and Qt5.9.8 + msvc project fixes (sipsorcery)
• #17887 bug-fix macos: give free bytes to F_PREALLOCATE (kallewoof)

Miscellaneous

• #17897 init: Stop indexes on shutdown after ChainStateFlushed callback (jimpo)
• #17450 util: Add missing headers to util/fees.cpp (hebasto)
• #17654 Unbreak build with Boost 1.72.0 (jbeich)
• #17857 scripts: Fix symbol-check &amp; security-check argument passing (fanquake)
• #17762 Log to net category for exceptions in ProcessMessages (laanwj)
• #18100 Update univalue subtree (MarcoFalke)

Credits

Thanks to everyone who directly contributed to this release:

• Aaron Clauson
• Adam Jonas
• Andrew Chow
• Fabian Jahr
• fanquake
• Gregory Sanders
• Harris
• Hennadii Stepanov
• Jan Beich
• Jim Posen
• João Barbosa
• Karl-Johan Alm
• Luke Dashjr
• MarcoFalke
• Michael Chrostowski
• Russell Yanofsky
• Wladimir J. van der Laan

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

Code:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

3a80431717842672df682bdb619e66523b59541483297772a7969413be3502ff  bitcoin-0.19.1-aarch64-linux-gnu.tar.gz
657f28213823d240dd3324d14829702f9ad6f0710f8bdd1c379cb3c447197f48  bitcoin-0.19.1-arm-linux-gnueabihf.tar.gz
10d1e53208aa7603022f4acc084a046299ab4ccf25fe01e81b3fb6f856772589  bitcoin-0.19.1-i686-pc-linux-gnu.tar.gz
1ae1b87de26487075cd2fd22e0d4ead87d969bd55c44f2f1d873ecdc6147ebb3  bitcoin-0.19.1-osx64.tar.gz
206d8d92189d22e735393abebeb7a2e7237a119dd448b4a40df8c357da1287b2  bitcoin-0.19.1-osx.dmg
aa7a9563b48aa79252c8e7b6a41c07a5441bd9f14c5e4562cc72720ea6cb0ee5  bitcoin-0.19.1-riscv64-linux-gnu.tar.gz
f2591d555b8e8c2e1bd780e40d53a91e165d8b3c7e0391ae2d24a0c0f23a7cc0  bitcoin-0.19.1.tar.gz
69e4d7f710a29be6ead2ef5da2905736b7cea107213ae6ddde3bcca8affbb8fd  bitcoin-0.19.1-win64-setup.exe
56323ec91afecd8e321a2925c0ca5f1da8b2ae1c99f4e08a3652e1dc68908717  bitcoin-0.19.1-win64.zip
5fcac9416e486d4960e1a946145566350ca670f9aaba99de6542080851122e4c  bitcoin-0.19.1-x86_64-linux-gnu.tar.gz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJeZiE8AAoJEJDIAZ42wulkkQsQAIlvZ9Em4wm2jpn4L7QUJgCE
4Mr6Q/tCPMs4U15q4wkjoBbdP06Bts1DzV0m/qoirTKoTKCCyRwdaeRn+Oj5Kkoh
MuyPt9EEsrnNk80xaPXSpYnhYjqSGrKux+IuHrlZtCy0QEoeIiOVaWWEtEe6I/eU
lvooE8ywxcUvsOwU3Kga0WnCA0WsfwduMAU+LvmtiXgjudsWvoERwHav+eiQva60
kgfwK5W+XI0lt7clFw6zPXBTZeWWhc97fp1uKv7KBPpACHWgKUaXP3WPMHZhsnSF
1L5fi5EcafjNzbbUusmgo807xThM5eMFZQpzHFZhiFNngW6mjxyEo1m2vrvVE8mN
1LZ7h1QahdSUVsgr+w/JkN1Wx9WcJyzGvFuH7dIbe1J6kb5IMyUKESEtTkWgJeo4
5MCk9pwvstAXcXPnWbNolrBo2IB9mrFC9o/9n2ZCyncCofre8BmbIsvxVqBu4hfE
9E4rCTHDGwWvCDYY68iWdlnyUl9FAvYB8UEOYs4o4f1fDMLdbOEqDojIa7ZnOJwV
oPth/MJxHcaCHNTAk7981LbOyn/oJMMzly4br5WFqWbdgzdXUSBTZDoeT26gdX8P
rnCo7JMvaxcvE8AASD9OpegKZP/E5TnHEzcgkVncABj9gVrsuOm7DlTFsE9YuRv+
jerPsU4Izg+hoVdUiuPT
=Iefa
-----END PGP SIGNATURE-----