Does wallet.dat ever expose private keys?

[ranochigo]

Every wallet is encrypted specially the wallet.dat, so no attacker can brute force or decrypt your wallet.dat unless if the attacker already planted some malware to your computer then you are really DOOMED. Some professional programmer can decrypt it if they were working with these application before but i guess they shouldn't do it unless they were told. They should change their OS into LINUX or MAC so that the attacker won't have an easy way to get their wallet then.

Wallet.dat does not need to be encrypted. It isn't unless you set a password to it. You cannot decrypt a wallet easily, the source code is out there and there isn't any backdoors etc.

Changing your OS to a more secure one won't eliminate the physical access to it nor a weak password.

[1714930373]

1714930373

[1714930373]

1714930373

[1714930373]

1714930373

[1714930373]

1714930373

[1714930373]

1714930373

[rexter]

Nope, unless you expose them the private keys of Bitcoin they can't do anything apart from watching your Bitcoin address on that wallet.Installed Bitcoin core and fully synchronized wallet and saved wallet.dat to a Usb key.

[bob123]

Every wallet is encrypted specially the wallet.dat..

Thats not true. The wallet is only encrypted if you set a password to protect it. Else its not encrypted at all (encryption with an empty string doesn't count..).

Some professional programmer can decrypt it if they were working with these application before but i guess they shouldn't do it unless they were told.

Thats not true either. 'Professional programmer' can't just break cryptographical functions/methods if implemented right.
The only way for a programmer to decrypt an encrypted file (or whatever) would be if he manipulated the source code and built in a backdoor (un-)intentionally.
Usually most software runs through security audits, fuzzing, etc.. to make sure the implementation is correct and no bugs are found.
You can trust maths and cryptography but should be cautios when trusting implementations.

[cellard]

Everyone should be using Linux, and everyone should be using a separate computer to store offline private keys... one's private keys should never touch the internet. If they ever touched the internet, create a brand new wallet in an airgapped Linux computer, sign transactions there, then pass them into an online node, that is what im trying to learn, but Bitcoin Core GUI sucks for this compared to Armory, the problem is I don't trust Armory, so im stuck with learning the raw transaction crafting thing which can be dangerous if you enter the wrong numbers...

Achow could you please let other Core devs know how adding a better support to sign offline transactions in the GUI should be a priority? I don't want to rely on other software to do that. Armory had an exploit recently with their implementation of SSS for example...

[Dabs]

There is one method, but that involves copying over the blockchain files from the hot wallet, to the cold wallet, so the cold Bitcoin Core wallet can see all the transactions. Been doing that for awhile, can get tedious.

Now that I think of it, perhaps the hot wallet can craft the transaction, but it can't sign it, you import the unsigned transaction to the cold wallet, the cold wallet signs it.

That should work too, you just turned your laptop into a hardware wallet.

The trezor or ledger or whatever hardware wallets are smaller and don't do anything else.

[achow101]

If you are not using a HD wallet, anytime you sign a transaction, your wallet.dat will be unencrypted in RAM, or more specifically, the decryption key to decrypt the wallet.dat file will be in RAM, along with the private key(s) of what you are using to sign. If an attacker has access to your RAM when you are signing a transaction, all of your money is effectively stolen.


If you are using an HD wallet, anytime you sign a transaction, the private key(s) used to sign the transaction will be stored in RAM.

The behaviors for HD and non-HD wallets are exactly the same regarding encryption and decryption of keys. Literally the only difference is how the keys are generated and that the seed is stored in the wallet. Everything else is the same.

An attacker could use the private key along with the xpubkey (which will always be in an unencrypted state), to be able to calculate the rest of your private keys in your wallet.

Bitcoin Core uses hardened derivation which is not vulnerable to this attack.

[bismillahi]

Yes, please be careful with wallet.dat and don't give it to anyone, people can extract private key from your wallet. dat in conditions he know your password of your wallet.dat.
If you make mistakes, just backup your wallet.dat again, your old backup wallet.dat will expire and can't to use again

[ranochigo]

If you make mistakes, just backup your wallet.dat again, your old backup wallet.dat will expire and can't to use again

Bitcoin doesn't work that way. Your backups NEVER expire, anyone telling you that is lying. When you change/encrypt your wallet, the keypool will refresh (or the seed will change) but your previous addresses will still be inside and anyone with it can access them. So, you might end up losing your coins. When you suspect that your wallet is compromised/you threw a HDD with an unencrypted backup, encrypt your wallet and send your funds to a newly generated address.

[Thirdspace]

If you make mistakes, just backup your wallet.dat again, your old backup wallet.dat will expire and can't to use again

Bitcoin doesn't work that way. Your backups NEVER expire, anyone telling you that is lying. When you change/encrypt your wallet, the keypool will refresh (or the seed will change) but your previous addresses will still be inside and anyone with it can access them. So, you might end up losing your coins. When you suspect that your wallet is compromised/you threw a HDD with an unencrypted backup, encrypt your wallet and send your funds to a newly generated address.

what he meant by "will expire" might have related to how non-HD wallet behaves.
expired in the meaning the first backup for the first 100 receiving addresses would be irrelevant.
after the user has received his transaction on 120th receiving address and forgot to create new backup,
he could risk losing his access to the next 100 generated address (address #101-200) in non-HD wallet
or... I, too, misunderstood what Quickseller said below

With a 'traditional' wallet.dat wallet, you will need to backup your wallet at least once every 100 transactions, or else you will risk losing access to some of your funds, and the process of backing up your wallet is not without risks.