Topic: Bitcoin Core 23.0 Released (Read 6674 times)

Bitcoin Core 24.0.1 has been released

@achow101

Might want to announce that version 24.0 was just released: https://github.com/bitcoin/bitcoin/releases/tag/v24.0

yes true... I was suggesting to open new thread for 23 release and every future releases but this time you are first even before release post go live on website    

Waiting for the release post to go up on the website first.

@achow101
its time to create a new thread for the Bitcoin Core 24.0 release
https://bitcoincore.org/bin/bitcoin-core-24.0/

I had the same experience when the bitcoin blockchain data moved to a NAS. I have changed the storage directory path to the new location and have tried to delete the .lock file (https://bitcoin.stackexchange.com/questions/38303/bitcoin-core-cannot-obtain-lock), but the error message when opening Bitcoin Core on macOS still appears.


https://bitcointalksearch.org/topic/m.55907834

I try to run Bitcoin Core (Windows version) using the same data on the NAS, and it works.


https://bitcointalksearch.org/topic/m.55916292

---

Other references:
https://github.com/jimhashhq/bitcoin/blob/3c0377db483c50c5a9aecfc4684d6329951a1c7c/doc/file-partition.md

If you move your data directory into a remote NAS location, your data(setting) location should be on "/Volumes/Bitcoin Core Data".

Make sure the Bitcoin-QT application does not run in the background and try to delete .lock file on the directory. After that, try to run the application again.

I got error while launch bitcoin core 23.0 on macos after I set data loction on my remote NAS,
Error: Cannot obtain a lock on data directory /Volumes/Bitcoin Core Data. Bitcoin Core is probably already running.

It's still error after I reinstall. And I can not find setting file at ~/Library/Application Support/Bitcoin/

Wow, last time I compiled the source code I was at version 18, the Bitcoin core team are working a lot!

Is there anything we should do about our Bitcoin balance?

Not directly. By seeding the torrent file you are going to help those who want to download the bitcoin core binaries using torrent network which has nothing to do with bitcoin network.

I have started seeding the torrent URI of bitcoin core 23.0 (the one from bitcoincore.org), in a raspberry pi at home.
Does seeding the release help bitcoin in any way?
Yesterday when I downloaded the torrent I found around 20 seeders (or maybe that was my client config). I suppose most of them are offline.
Thanks, and great post!

I think it is better to make a new thread for each release so that the old ones can still be viewed for archival purposes. Similar to how researchers cite the 0.3 version even though it is very old.

Hey achow101...!!!

                        I respect your great work for the bitcoin local area.

As to refreshes, might be change the stuck string subject from "Bitcoin Core 22.0 Released" to "Bitcoin Core wallet update Releases" and so on and you can continue to post the updates there just Roll Eyes

Continuously the new update strings like this 23.0 string untraceable except if one go in to the last post under the stuck string and nobody will go there by seeing the subject as 22.0 (old) discharges.

this sort of worked but now i get "ignoring duplicate -wallet"

json file looks like this

{
    "wallet": [
        "",
        ""
    ]
}


ok i fixed it

i removed this line (  ,""   )

Open up your bitcoin data directory. Find and open the settings.json file. And then remove the line that has the name of the deleted wallet folder.

the problem is the other wallet was not created with bitcoin core, i just put it there from old client, so it work without its appropriate folder, it's something like "Bitcoin\wallets\wallet.dat"

I seem to recall running into this issue with BitcoinQT on Windows some time ago.  I don't remember exactly how I fixed it, and I'm at work right now so I don't have a node to play with to show some examples, but here's what I would try first:

Open a terminal window (CMD or PowerShell,) and cd into the directory where you have Bitcoin installed, example:


Then try the loadwallet command to load a wallet that does exist, and set the optional load_on_startup flag to true.  Example:

i run a shortcut without any wallet parameter just prune parameter

How do you run Bitcoin Core? If you use shortcut, command or script which include -wallet= as Bitcoin Core parameter, you can just remove it.

how to remove the msg "skipping -wallet path that does not exist"? i created and removed the folder of the new wallet, i want to remove this message at the start of bitcoin core

You can use the removeprunedfunds RPC.

can anyone explain simplified with any way to delete conflicted transaction?

By stealth address, do you mean Change address? If so, you cannot change the change address after the transaction is created. However, you can specify a custom change address if you enable Coin Control features in the settings. If you want just want a specific change address type, you can add changetype= to your bitcoin.conf file where is one of legacy, p2sh-segwit, bech32, or bech32m.

Ok tnx, another question, can you choose the stealth address on which the bitcoin are sent after you do a tx? Because sometimes they are sent to non-native address and more often it seems, to native segwit one

I want to add that the previous txs were sent to the same address but as a result the stealth address was native segwit so bc1 etc... so why suddenly it changed

The removeprunedfunds RPC can remove transactions from the wallet.

any way to delete conflicted transaction, due to increase fee? i sent the same multiple time by increase the fee each time, now it show those clonflicted transaction in the all transaction tab on bitcoin core, i want to get rid of them

walletnotify only executes shell commands. You can just write a shell script that sends a notification to whatever else you want and have wallet notify call that shell script.

Does anybody know if this release supports the walletnotify command to send notifications to multiple servers at once?

That's irrelevant. You should never fully trust anything that is centralized whether it is bitcoin.org or bitcoincore.org or blahblah.org. We are in a decentralized and open source world, you should only trust the source code and verify the reproducibility of the binaries and/or verify their signatures.

^ This!  I used to direct people to both bitcoincore.org and bitcoin.org, since bitcoin.org has some good tutorials and easy to follow instructions on setting up core.  If I'm not mistaken Bitcoin.org is (still?) owned by Cøbra, but he's got some legal trouble with it since a scammer is trying to claim he owns the domain name.

Until things get ironed out, I'm not too trusting of the bitcoin.org site.

Yeah, I a bunch of stuff slipped through the cracks on this release's release notes.

Bitcoincore.org is Bitcoin Core's official website. As part of separating Bitcoin Core from Bitcoin.org (presumably as part of efforts to distinguish between Bitcoin Core the software and Bitcoin the cryptocurrency), the maintainers no longer post Bitcoin Core releases to Bitcoin.org. However the maintainers of Bitcoin.org can choose to mirror the binaries on their website and do so as they wish. You should direct people to bitcoincore.org as it is the project's actual website.

I've just noticed that while bitcoincore.org advertises version 23.0, the bitcoin.org only has the old 22.0
Is there any problem there I've been missing? I'm asking because I've been usually sending people to bitcoin.org and not bitcoincore.org

Did you forget to mention listdescriptor now has boolean parameter to show xprv rather than xpub?

when you click on that , it will take you to the core website but not to the announcement thread .

---

ok , I thought you will do the sticky thing also.

[moderator's note: consecutive posts merged]

It would get too messy and confusing with new versions.

I've asked an admin to sticky this thread and remove the 22.0 one, as I usually do for each new release.

We're trying to move away from having a load of startup parameters and default startup actions for all the wallet things. IIRC rescan on startup also locks out a bunch of functionality until the rescan is done, and if you have multiple wallets, it would rescan them serially, not in parallel. rescanblockchain is also more flexible.

You can achieve the same by having a script call rescanblockchain for all of the wallets and then set that script in the -startupnotify option. This will execute that script once startup is completed.

You greatly misunderstood me, so here you are:

It's not easy task to search for the update thread under news section as you mentioned.

now that we replied to this thread, it's showing on top results otherwise it's gone for a long distance.

Any reason for this?

Just due to me playing with nodes all the time I actually use it a far amount.
The issue at least for me is that on some older / slower devices there can be a LONG delay between when you start the daemon and it actually is ready to respond to a command.
-rescan was a 'fire and forget'

Either way thanks to you and all the others who work on it.

-Dave

The Bitcoin Core updates are also announced in the news area on (more or less) the top of the forum pages. You can always find there the latest version.
So all those interested indeed, cannot miss it.

Hi achow101 ,

I admire your good work for the bitcoin community.

Regarding wallet updates, may be change the pinned thread subject from "Bitcoin Core 22.0 Released" to "Bitcoin Core wallet update Releases" etc... and you can keep posting the updates there only  

Always the new update threads like this 23.0 thread untraceable unless one go in to the last post under the pinned thread and no one will go there by seeing the subject as 22.0 (old) releases.

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&dn=bitcoin-core-23.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.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.