Best Core Client version for a cold wallet?

Sorry if this question has been asked before. So, I saw that version 26 of the Core Client dropped earlier this month, but Bitcoin.org is still pushing version 25. Check it out here: https://bitcoin.org/en/download Is this about stability or something? I'm looking to set up a device as a cold wallet. This thing will be offline at some point and won't get updates after that. So I'm kind of torn. Should I go for version 26 or stick with 25? I'm aiming for a standard hd wallet, which is what the core client generates by default now.

I would advocate  26th  which is the latest flavor of Bitcoin Core with some improvement listed here. You can download it from the official site run by developers.  Bitcoin.org, being  run by reputable community's member, likely,  was not updated yet. BTW, what is your setup for a cold storage, running  Bitcoin Core on persisted volume of Tails  or something else?

As said, there is no reason why you shouldn't use 26.0 over 25.0, or any other version for that matter. These are stable releases which are good for regular users, as opposed to release candidates which are found on GitHub as well. If you're thinking of whether you should update, then you should look at the release notes, for 26.0, it's here: https://bitcoincore.org/en/releases/26.0/. If there isn't anything particularly enticing for you, specifically any new features, then you can consider holding it off. Updates which are mandatory will be made known.

You should learn and understand that the site https://bitcoin.org is not the official site for Bitcoin Core. Bitcoin Core's official site is https://bitcoincore.org. Bitcoin Core devs have basically no access to https://bitcoin.org as far as I remember or know.

Thank you very much, so I will use 26. It's a Raspberry 2 with Raspberry Pi OS (based on Debian bookworm).

Even bitcoin.org itself recommends checking bitcoincore.org to make sure you are downloading the latest version.

I don't think Bitcoin Core would work normally on Raspberry 2 it didn't meet the minimum requirements. Read the minimum requirements here https://bitcoin.org/en/full-node#secure-your-wallet It requires 2 GB so this unit where you plan to install the Bitcoin core would not work normally due to low memory unless you configure it to use less memory.

Thanks for the tip.  But what would be the limitations for my use case (cold wallet)? The page also says: It's about a full node, isn't it? However, the Raspberry 2 will run without a network connection. I start the daemon with the "-noconnect" option. My main concern so far has been not so much the RAM but the RNG. I don't see that there are any problems with memory consumption. But I will allocate another 1GB of swap space.

In that case, Raspberry Pi 2 will run Bitcoin Core just fine. Yes. FYI Linux use various input for it's RNG, including mouse and keyboard you use. Using your Raspberry Pi for few minutes should guarantee strong entropy/randomness.

Bitcoin.org is operated by Cobra, not by the Bitcoin Core developers; bitcoincore.org is. I'd advice you to visit that. Then, why do you care about the version of Bitcoin Core? You're probably not going to use it in the first place. Cold storage software is better to be a lightweight client like Electrum or Sparrow. Nevertheless, you can still use Bitcoin Core to sign transactions (and of course, nothing crucial of that matter changes from 25.0 to 26.0).

Yes, I have already switched to bitcoincore.org. Thanks for the tip. Just uncertainty. But I have received my answer. Thanks for the reference to other clients. I'll keep that in mind. "Manually but using the wallet still" is what I intend to do. See: https://bitcoin.stackexchange.com/a/106204 This is certainly also possible with other clients. But I have been running a full node based on Bitcoin Core for weeks. And I run the daemon with "noconnect" on the cold wallet. With this option it didn't use many resources during my tests.

It's no cold wallet when the daemon runs on a device that is still connected to the internet, even when the daemon runs with "noconnect". By definition a cold wallet is never ever directly connected to the internet at all.

Yes, I know that. I just want to prevent the daemon from running into unnecessary timeouts and issuing error messages. I continued reading the documentary and discovered sethdseed. As I understand it, I can use it to set the seed from which the xpriv key is generated. Do I understand that correctly? I don't know if I want to do that, but would be a nice option. [moderator's note: consecutive posts merged]

Yes, but you'll have to encode the "seed" into WIF before it can be accepted by the command. But I'd like to confirm that you're actually talking about the "seed" and not the "seed phrase" (words). If so, then you're correct, you can only use that in legacy wallets though. In descriptor wallets, importing descriptors built from the master private key derived from a seed is basically the same So I can't see any advantage of using a legacy wallet to use that command.

Is there a command for this? Yes, I learned from your posts, among other things, that the Core Client does not support these BIP 39 word lists. I actually mean a binary seed. Okay, then that's out of the question for me. I decided against legacy after your comments Master key is the xpriv key I have in the descriptor list? And I can create this myself with a binary seed that I choose myself? What tools can I use to generate an xpriv key from a seed? Maybe I'll let the Bitcoin Core Client take care of everything. With my level of knowledge, this is perhaps more secure. But what does the Core Client actually do? Doesn't it also have to create a seed internally?  So something like: Binary random seed (or is it the master key?) -> xpriv key -> everything else derived from it?

In Bitcoin Core? There's none. Normally, you'd get this WIF encoded hdseed from the output of dumpwallet command in legacy wallets. For other sources, you'll have to encode it to WIF using any "Base58Check" tool. Yes, basically like that, binary seed->m->.... For the "master private key" (xprv), it's the "m" that you see in derivation paths, it's not the binary seed but is derived from it. The xprv from the lower depths should be called "extended private key" Creating the descriptors yourself is only an option if you want to use your own seed; For example, it's from a BIP39 seed that you want to backup or from another wallet. If I would use Bitcoin Core and have no troubles with backups, I would just use the wallet that it created.

Sorry, I still haven't quite got it. I use https://github.com/iancoleman/bip39 for computation (ironically, not to convert Mnemonic) and terminology. The command gives me, among other things, the lines If I choose BIP84 and enter as BIP32 Root Key, then the tool computes an Account Extended Private Key and an Account Extended Public Key. I also receive the Account Extended Public Key via the command: The BIP32 Extended Private Key  and the BIP32 Extended Public Key (which the tool shows me below) are then derived from the above Account Extended Keys plus the BIP32 derivation paths. The child keys are then derived from the BIP32 keys. Is that correct? Now my questions: Where exactly does the binary seed come into play? And what do you call the master private key? My guess: The master private key ist der BIP32 Root Key and the binary seed is used to create it? Correct?

Bitcoin is a open source project and you can download the software from many websites because basically there is no official website. For example, you can download it from https://bitcoincore.org/en/download/ I would prefer to use that site than bitcoin.org and you will see some guides from the site on how to verify your wallet. Verify your wallet, before using it to store and move your bitcoin is very important. If you don't verify the PGP signature, it means you trust that the website from which you download Bitcoin Core, is not a phishing site or nothing is wrong with that site. Don't trust, verify.

Yes. In IanColeman's BIP39 Tool; your binary seed is equivalent to that tool's "BIP39 Seed" that is derived from the BIP39 mnemonic. Your Master Private key is equivalent to that tool's "BIP32 Root Key" that's derived from the above. Additionally, your watching-only descriptor's xpub (extended public key) are equivalent to the "Account Extended Public Key" of each address type's specific derivation path.

Yes I always verify. I use: https://github.com/bitcoin-core/guix.sigs/tree/main/builder-keys Thank you again. It's really a great help, even if I've run out of Merit. Would the Core Client fail to create the wallet or issue a warning or block if it does not have enough entropy available when generating the binary seed? Does it read the entropy from /dev/random or also from /dev/urandom? I'm on some kind of embedded system, without a fine-grained clock, with no network, with little inputs, reading from flash which much more deterministic timing for operations. I therefore depend on the hwrng of the Raspi. Hence my concern. Unfortunately dieharder is currently broken on the 32-bit Raspis under Bookworm. I can probably fix this and have other testing options. In case there is a developer reading here: For the future it would be nice to have the option to pass a binary seed to the Core Client when creating a new wallet. Or to have something analogous to sethdseed for the new wallets. Creating a Master Private key and descriptor yourself is not necessarily what a beginner wants to do. But rolling the dice and handing over a binary seed (in a denfied format) is a minor intervention which requires only general computer and mathematical skills, no specific knowledge about Biicoin. [moderator's note: consecutive posts merged]