Bitcoin Core 25.0 Released

[achow101]

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.

[1714834216]

1714834216

[1714834216]

1714834216

[1714834216]

1714834216

[darkv0rt3x]

Shouldn't it also have a "How to upgrade" for Linux OS?? I don't know why only Windows users are worth of the "How to"....
Anyway, thanks for the great job of the dev community in keep things running!

[achow101]

Shouldn't it also have a "How to upgrade" for Linux OS?? I don't know why only Windows users are worth of the "How to"....

Miss this part?

or just copy over /Applications/Bitcoin-Qt (on macOS)
or bitcoind/bitcoin-qt (on Linux).

I think many linux users also use package managers which will handle this automatically.

[NotATether]

Does the mempoolrbf config switch share the same default value as in 24.0?

Shouldn't it also have a "How to upgrade" for Linux OS?? I don't know why only Windows users are worth of the "How to"....

Miss this part?

or just copy over /Applications/Bitcoin-Qt (on macOS)
or bitcoind/bitcoin-qt (on Linux).

I think many linux users also use package managers which will handle this automatically.

Personally I just upgrade by coping the tarball extraction over /usr/local. It's always been a hassle-free experience. Although, I don't see Bitcoin Core in the Ubuntu repositories. (I am not sure about Debian or Arch though.)

[darkv0rt3x]

Shouldn't it also have a "How to upgrade" for Linux OS?? I don't know why only Windows users are worth of the "How to"....

Miss this part?

or just copy over /Applications/Bitcoin-Qt (on macOS)
or bitcoind/bitcoin-qt (on Linux).

I think many linux users also use package managers which will handle this automatically.

Is that enough to hanle all binaries? Only by copying bitcoind? What about bicoin-cli and all other binaires?
I was expecting to see some instructions for installing from scratch. Like cloning repository, or at least downloading source code, installing dependencies, and minimal commands to compile, make and install binaries!
What I see in the docs (./docs/INSTALL.md) is mostly for Ubuntu specific distro.

I cannot find either any reference to any package related to bitcoin in my Debian package manager

Code:

psysc0rpi0n@rockpro64:~$ apt-cache search bitcoind
psysc0rpi0n@rockpro64:~$ apt-cache search bitcoin
bruteforce-wallet - try to find the password of an encrypted wallet file
python3-btchip - Python library to communicate with BTChip dongle (Python 3)
electrum - Easy to use Bitcoin client
python3-electrum - Easy to use Bitcoin client - Python module
golang-github-btcsuite-btcd-btcec-dev - Go library for Elliptic curve cryptography
libbase58-0 - library for Bitcoin's base58 encoding
libbase58-dev - library for Bitcoin's base58 encoding -- development files
libencode-base58-perl - module to shorten numbers using a base58 conversion
libsecp256k1-0 - library for EC operations on curve secp256k1
libsecp256k1-dev - library for EC operations on curve secp256k1 - development headers
litecoin-qt - peer-to-peer network based digital currency - Qt GUI
litecoind - peer-to-peer network based digital currency - daemon
base58 - base58 encode/decode: command-line interface
python3-base58 - base58 encode/decode for Python
python3-bip32utils - Python implementation of Bitcoin hierarchical deterministic wallet
python3-bitcoinlib - Python module with an easy interface to the Bitcoin protocol
python3-mnemonic - Implementation of Bitcoin BIP-0039 (Python 3)
python3-stdnum - Python module to handle standardized numbers and codes (Python3 version)
python3-trezor - library for communicating with TREZOR Bitcoin HW wallet (Python 3)
trezor - utilities for communicating with TREZOR Bitcoin HW wallet
psysc0rpi0n@rockpro64:~$

[roksana.hee]

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.

Thank you for your helpful post. I hope it helps our local people to get the benefit of it. I want to convert your post to my local language. Also, I'll publish your remarkable helpful post on our local community board named Bengali. You can see the post by clicking the above link.

[Cricktor]

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

...
Wallet
...

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

...

I have assembled a watch-only wallet of more than 21000 combo(PubKey) descriptors and before v25.0 it took literally ages to rescan over the whole blockchain. Now with v25.0 I saw a significant speed-up. I wish I had this version quite some months ago. I ran a part of this wallet's rescan on a low energy consuming Raspberry Pi which isn't known for its computing power, so I was aware that it can take a while. But I didn't anticipate that with prior versions of Core it would take months for the rescan!

[Good_Doctor]

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


From the above the unsupported system can also be some Unix-like systems right? Or shouldn't a list of unsupported systems be given for clarity?


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


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)
  

A row stating whether or not it's wallet is a custodial or non-custodial wallet would have been more expository.

[achow101]

A row stating whether or not it's wallet is a custodial or non-custodial wallet would have been more expository.

The wallet is a non-custodial, as it has always been. It's not as if this is going to change between releases - there's no reason to restate the existing features for every single release. This isn't a new product announcement - it's a new version announcement.

[oppiet30]

I was always checking on bitcoin.org for the current release. Now I know to come here for current releases.

[pooya87]

I was always checking on bitcoin.org for the current release. Now I know to come here for current releases.

bitcoin.org is a simple mirror of the bitcoin core releases that sometimes updates with a delay. Topics like this on this forum are also announcements that can also be delayed.
The direct link to check for updates on bitcoin core project are bitcoincore.org website (the first link in OP) or the https://github.com/bitcoin/bitcoin repository that contains the source code.

[kirilldead]

is there support for the latest version of kali linux now?

[achow101]

is there support for the latest version of kali linux now?

Bitcoin Core does not publish official releases for any particular linux distros. The published linux binaries should work on any linux distro so long as the CPU architecture is supported.

[NotATether]

is there support for the latest version of kali linux now?

Bitcoin Core does not publish official releases for any particular linux distros. The published linux binaries should work on any linux distro so long as the CPU architecture is supported.

I'm curious though, what is the minimum supported glibc for these binaries (i.e. which one is it built against) and do you have any plans to change that?

[decryptit]

Hey guys. I switched Bitcoin Core to running on testnet. I have a couple of questions on that. I want to start solo mining tBTC. Can I prune the data when running on testnet? Or do I need the full blockchain db? Also, how do I configure the rpc server? In the Setting Options on the wallet UI, I clicked on Open Configuration FIle, but nothing happens. Do I need to create another configuration file for it via CLI? Or do I add the rpc server info to the bitcoin.conf? Thank you in advance.

[pooya87]

Hey guys. I switched Bitcoin Core to running on testnet. I have a couple of questions on that. I want to start solo mining tBTC. Can I prune the data when running on testnet? Or do I need the full blockchain db?

Yes, it is like mainnet. You don't need to store the whole blockchain, all you need is the chainstate (ie. the UTXO database) so you can prune the chain. But you still need to download and verify all blocks to build the chainstate before you can discard the old ones in the process called pruning.

[Cricktor]

In the Setting Options on the wallet UI, I clicked on Open Configuration FIle, but nothing happens. Do I need to create another configuration file for it via CLI? Or do I add the rpc server info to the bitcoin.conf?

Why nothing opened after you clicked in the GUI is not obvious to me, but it depends on too many not provided details.

In the bitcoin.conf file you can have sections specific to Mainnet and Testnet, e.g.

Code:

# Options only for mainnet
[main]
...

# Options only for testnet
[test]
#dbcache=2000
#blocksonly=1
maxuploadtarget=0

# Indexes
txindex=1
blockfilterindex=1
coinstatsindex=1

# Network
#listen=1
listenonion=1
proxy=127.0.0.1:9050
bind=127.0.0.1
onlynet=onion

# Connections
#rpcuser=...
#rpcpassword=...
port=18333
rpcport=18332
rpcbind=127.0.0.1
rpcallowip=127.0.0.1

# Options only for Regtest
[regtest]

# Options only for Signet
[signet]

This way you can keep the configuration all in one file and location and the appropriate options are read with whatever net you fire up your bitcoind or GUI.

I would recommend to use the Bitcoin Core Config Generator by Jameson Lopp: https://jlopp.github.io/bitcoin-core-config-generator/
Github sources: https://github.com/jlopp/bitcoin-core-config-generator

[decryptit]

Thanks guys. I was able to configure the bitcoin.conf to testnet and now the Bitcoin Core is running on testnet with the green logo. I did insert some rpc info like user/pw ports etc. I opened those ports. Does anyone have any info on how to set up a testnet pool to connect your miner to it? Thanks for your response. I also found another option to run a bitcoin full node via bitnodes. They have a one line command that you can run on your VPS or something. I just haven't figured out how to configure that one to testnet. I kept getting errors on it.

[Cricktor]

...

Your questions are turning more and more offtopic to this thread. I suggest you hop over to nullama's guide to solo mine Testnet bitcoins and see what you can get from his guide for your own purpose.

There might also be more guides on the mining Testnet coins topic in this forum. You probably should invest some time to use the forum's search or use https://ninjastic.space/ to search the forum. It's not rocket science to figure out some search keywords that give you helpful hits.

[decryptit]

...

Your questions are turning more and more offtopic to this thread. I suggest you hop over to nullama's guide to solo mine Testnet bitcoins and see what you can get from his guide for your own purpose.

There might also be more guides on the mining Testnet coins topic in this forum. You probably should invest some time to use the forum's search or use https://ninjastic.space/ to search the forum. It's not rocket science to figure out some search keywords that give you helpful hits.

Thank you for your response. And of course, it's not rocket science. But if it was easy to find, I would've found it. There's a difference between finding some out of date information that put you in the kinda right direction vs. actually finding the answer to your problem. In reality, there are not that many people in the world who mine mainnet bitcoin. So finding people who mine testnet bitcoin is even smaller than a needle in a haystack. I understand the the discussion is getting off topic. Ending it here. Thanks again for your reponse.