Author

Topic: Which version of the Core Client for a cold wallet should I use? (Read 357 times)

legendary
Activity: 2534
Merit: 6080
Self-proclaimed Genius
Sorry, I lost the source and can't credit the original creator of it (any hint is welcome so I can provide correct source for it).
Found the source: https://raw.githubusercontent.com/EAWF/BTC-Toolbox/3938785f186c76598989cc0aa017ad351483d3b1/Images/KeyDerivationTechnicalOverview.png

It was added to the repository with this commit: https://github.com/EAWF/BTC-Toolbox/commit/3938785f186c76598989cc0aa017ad351483d3b1
But is was removed by the uploader for a slightly insignificant reason, some surviving image copies in Reddit show that it's uploaded by the same user.
Link to the commit that deleted it: https://github.com/EAWF/BTC-Toolbox/commit/f75e2b352ec9facc8d2da52b5ec303fb280c3298
hero member
Activity: 714
Merit: 1010
Crypto Swap Exchange
Now my questions: Where exactly does the binary seed come into play?

If you mean by binary seed what is the entropy in iancoleman's script, then this is what is hidden by Bitcoin Core when descriptors are used as far as I know it. For HD wallets this initial random secret is represented by human readable mnemonic words by means of BIP39 and later mangled in a specific setup through 2048 rounds of PBKDF2 to derive the Seed Entropy and subsequently the Master Private Key.

See below chart that I found somehere on bitcointalk.org. Sorry, I lost the source and can't credit the original creator of it (any hint is welcome so I can provide correct source for it).

Source: https://github.com/EAWF/BTC-Toolbox/commit/3938785f186c76598989cc0aa017ad351483d3b1
legendary
Activity: 2534
Merit: 6080
Self-proclaimed Genius
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?
The comments in "random.h" code conveniently answers that question.
Link: github.com/bitcoin/bitcoin/blob/v26.0/src/random.h

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.
You can post that as a new issue as "Feature Request" with "Feature" label in Bitcoin's GitHub repository.
But make sure to search for possible duplicate issue first before posting it.
jr. member
Activity: 42
Merit: 48
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.
Thank you again. It's really a great help, even if I've run out of Merit. Smiley

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.
legendary
Activity: 2534
Merit: 6080
Self-proclaimed Genius
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?
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.
legendary
Activity: 2044
Merit: 1018
Not your keys, not your coins!
I know that version 26 of the Core Client was released at the beginning of this month. But Bitcoin.org is still prominently offering version 25. See:

https://bitcoin.org/en/download
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.
jr. member
Activity: 42
Merit: 48

Quote from: tiffy
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?
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"

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
Code:
bitcoin-cli listdescriptors true

gives me, among other things, the lines

Code:
"desc": "wpkh(xprv............../84'/0'/0'/0/*)#......"
"desc": "wpkh(xprv............../84'/0'/0'/1/*)#......"

If I choose BIP84 and enter
Code:
xpriv..............
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:
Code:
bitcoin-cli listdescriptors

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?
legendary
Activity: 2534
Merit: 6080
Self-proclaimed Genius
Is there a command for this?
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.

Quote from: tiffy
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?
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.
jr. member
Activity: 42
Merit: 48
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.
Yes, but you'll have to encode the "seed" into WIF before it can be accepted by the command.
Is there a command for this?

But I'd like to confirm that you're actually talking about the "seed" and not the "seed phrase" (words).
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.

If so, then you're correct, you can only use that in legacy wallets though.
Okay, then that's out of the question for me. I decided against legacy after your comments

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.

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?

legendary
Activity: 2534
Merit: 6080
Self-proclaimed Genius
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.
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.
jr. member
Activity: 42
Merit: 48
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.

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.
jr. member
Activity: 42
Merit: 48
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.
hero member
Activity: 714
Merit: 1010
Crypto Swap Exchange
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.
jr. member
Activity: 42
Merit: 48
Bitcoin.org is operated by Cobra, not by the Bitcoin Core developers; bitcoincore.org is. I'd advice you to visit that.
Yes, I have already switched to bitcoincore.org. Thanks for the tip.

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

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.  
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
Bitcoin.org is operated by Cobra, not by the Bitcoin Core developers; bitcoincore.org is. I'd advice you to visit that.

I want to set up a device as a cold wallet.
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).
legendary
Activity: 2870
Merit: 7490
Crypto Swap Exchange
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)?

In that case, Raspberry Pi 2 will run Bitcoin Core just fine.

The page also says:
Quote
A broadband Internet connection with upload speeds of at least 400 kilobits (50 kilobytes) per second
It's about a full node, isn't it?

Yes.

My main concern so far has been not so much the RAM but the RNG.

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.
jr. member
Activity: 42
Merit: 48
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:
Quote
A broadband Internet connection with upload speeds of at least 400 kilobits (50 kilobytes) per second
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.


legendary
Activity: 3374
Merit: 3095
Playbet.io - Crypto Casino and Sportsbook

It's a Raspberry 2 with Raspberry Pi OS (based on Debian bookworm).

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.
legendary
Activity: 2380
Merit: 5213
Even bitcoin.org itself recommends checking bitcoincore.org to make sure you are downloading the latest version.

Quote from: bitcoin.org
For the latest developments related to Bitcoin Core, be sure to visit the project’s official website.
jr. member
Activity: 42
Merit: 48
Thank you very much, so I will use 26.

BTW, what is your setup for a cold storage, running  Bitcoin Core on persisted volume of Tails  or something else?

It's a Raspberry 2 with Raspberry Pi OS (based on Debian bookworm).
hero member
Activity: 714
Merit: 1010
Crypto Swap Exchange
I know that version 26 of the Core Client was released at the beginning of this month. But Bitcoin.org is still prominently offering version 25. See:

https://bitcoin.org/en/download

Does this have anything to do with stability?

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.
legendary
Activity: 3038
Merit: 4418
Crypto Swap Exchange
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.
hero member
Activity: 714
Merit: 1298
I apologize if this has been asked before.

I know that version 26 of the Core Client was released at the beginning of this month. But Bitcoin.org is still prominently offering version 25. See:

https://bitcoin.org/en/download

Does this have anything to do with stability?

I want to set up a device as a cold wallet. This machine will be disconnected from the network at some point and then never updated again. That's why I'm thinking about it. Should I use the 26 version or should I stick with 25? I am planning a (nowadays) normal hd wallet, as the core client currently generates by default.

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?
jr. member
Activity: 42
Merit: 48
I apologize if this has been asked before.

I know that version 26 of the Core Client was released at the beginning of this month. But Bitcoin.org is still prominently offering version 25. See:

https://bitcoin.org/en/download

Does this have anything to do with stability?

I want to set up a device as a cold wallet. This machine will be disconnected from the network at some point and then never updated again. That's why I'm thinking about it. Should I use the 26 version or should I stick with 25? I am planning a (nowadays) normal hd wallet, as the core client currently generates by default.
Jump to: