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.

There may be a temporary bitcoin recovery, but it is doomed long run b/c it is not quantum secure. IBM wll have a QC of 4,000+ qubits by 2025 (in two years). It takes only 1556  qubits to break the ECDSA encryption used to correllate private to public keys. What this means is if you have an exposed (unhashed) public key - which if you ever used your wallet it leaves an unhashed copy of your public key out there on the network for anyone to have - a quantum computer of 1556 or more qubits can take that public key and reverse engineer out your private key. Game over. Bitcoin has no value other than as a way to Secure information - security is literally its only selling point - when that security breaks, as it will, it has no more usefulness and the value will crash to probably just a few dollars, propped up by die-hard dead-ender BTC maxis. If you want to get rich on bitcoin, short it by buying a short bitcoin etf (example is ticker BITI - not financial advice). Doing anything else will result in losing investment.

Google this / do your own research - this is not "FUD", this is just sober fact. Bitcoin public keys can fall with QC's of just 1556 qubits. (Source: https://security.stackexchange.com/questions/33069/why-is-ecc-more-vulnerable-than-rsa-in-a-post-quantum-world ). Misinformation you hear is that it takes many qubits to crack RSA hence bitcoin is safe - this only relates to the bitcoin mining algorithm not the ECDSA algorithm used to relate public/private keys which is more vulnerable. Again - in 2 years or so IBM will have QC strong enough to reverse engineer private key from unhashed public key. When this happens panic will spread and bitcoin will crash. This is as predictable as the housing bubble collapse of 2008 and just like then, there are people who will shout "FUD" at anyone showing the plain and simple facts. Don't be on the wrong side of this.

As I am from Brazil, I have been following this for quite some time.

There is a fundamental problem here with this law, which can be checked in the portuguese version:

https://cointelegraph.com.br/news/on-a-historic-day-deputies-approve-cryptocurrency-bill-in-brazil
Abccripto, a group of old and low quality Brazilian exchanges is behind this law.

This group have tried many times before to as government to ban binance from Brazil, as binance offers a high quality service for very low fees.

You can see here abccripto asking central bank to ban binance
https://www.abcripto.com.br/post/abcripto-aciona-bacen-mpf-e-cvm-contra-corretora-binancehttps://exame.com/future-of-money/dinheiro-tendencias/abcripto-pede-que-bc-mpf-e-cvm-suspendam-operacoes-da-binance-no-brasil/

This group wouls never support this law if it didnt help them in their goal

In the end, national exchanges cannot compete with binance. They offer a bad service (low volume, few coins, high fees, instability and website goes down when price drops etc.. ). So they are trying to ban binance.

Biannce has now about 60% of Brazilian daily volume.

You can use bitcoin cash as much as you want, why don't you and why doesn't everyone else? Why isn't it worth more than bitcoin if so many people agree with you.

If 95% agree on something, why wait for the other 5 it's a stable shift regardless?

You can't upload a jpeg to most blockchains (eth included) you can upload a pointer but that's not a jpeg or parts of the file across multiple transactions but I doubt anyone's done that recently or found a way to do it that's useful. Anyone can already do that too.

+1

EDIT:  Wait, does +1 count as a zero-value post?