Bitcoin Forum

It was always a mystery to me why wallet.dat files let anyone know what are the funds sitting inside. Why not allow an option to just fully encrypt and hide the funds?

If you are saving a wallet.dat file in the cloud, and someone somehow managed to get the file, they would still need to crack the password, but if you are holding a lot of BTC, they would be able to see it, and the more BTC the higher the incentive to keep trying into bruteforcing it.

If there was no way to know how many funds a particular wallet has, they wouldn't bother as much. But if you have a guaranteed jackpot waiting because you can see the funds, they will.

You don't even need to sync it, just open the wallet.dat file in a text editor and look up the addresses, and then put them in an explorer and you get to see the funds.

Ideally we would have plausible deniability, one password decrypts a set of addresses with a bit of BTC to make it more realistic, but the real amounts remain hidden.

Yes you should encrypt the wallet.dat file using some encryption software, but ideally we should have these options available just in case someone managed to get the actually wallet.dat file.

There are a lot of ways to encrypt files at the OS level or if you want to (and you never should) store it someplace else you can always zip it and password protect that file.
However.....you then run the risk of what we see here again and again of people forgetting passwords and so on.

On the surface it's probably not a bad idea, but I don't think it's worth the programming time and potential pitfalls.

-Dave

I get your point and I would prefer it to be like with encrypted wallet files of e.g. Electrum which are completely undecipherable without the correct encryption passphrase and don't reveal details should the wallet file get stolen somehow.

On the other hand, why would you upload unscrambled wallet.dat file(s) into the cloud? That seems to be wrong to me from the beginning. I would always put password-protected wallet.dat files into an encrypted container with a sufficiently long and strong encryption passphrase for the container.

I would never upload anything that isn't encrypted with a strong password, like I said on my last paragraph. The thing is, im just talking about some extreme scenario, in which they get ahold of your wallet.dat somehow. I just don't like the idea that a file that contains all of your public keys unencrypted has touched your hard drive at any time. They should only be decrypted temporarily on the ram when needed. If you have ever had had wallet.dat file on your drive (and you need to in order to use it) then these bytes of data have been there and with enough forensics one could look that up. This shouldn't be even possible, that's why I would like that this all remains hidden.

When you say 'public key' what you mean is the public address (what you get when you RIPEMD160(public key) and encode it with Base58check).

As far as I know, encrypting the wallet balances requires some changes inside codebase, to encrypt the balances with the same mkey that encrypts the private keys inside the file. The problem is, I don't see a strong use case for this - on the contrary it will induce hackers to lie about the balances of wallet.dats that they are selling, and nobody can verify their claims without cracking it first.

The protection from this is not to store you wallet.dat somewhere (such as the cloud) that leaves it open to attack or compromise.

But this means decrypting your private keys every time you want to check your balance, which is a security risk. Core would also have to rescan every block since the last time you unlocked your wallet if it didn't know which addresses it was watching.

From few past discussion, IIRC few of the reason are,
1. Preventing user from entering password when they just need to sync.
2. Letting user view transaction, address or balance without entering password.
3. Bitcoin Core don't need to scan blockchain (which could take some time) when user unlock their wallet.


IMO if they managed to get wallet.dat when you perform good security practice, you have other things to worry about.

Then you wouldn't be protected against improbable but possible scenarios such as flood, fire, thieves, taxman and so on, any physical attack basically.

"Make backups and give them to someone you trust"

I don't trust anyone to keep it safe long term.

"Make backups and store them in other places you own"

Everything under your name is a single point of failure for a government to exploit.

After having thought about every possible scenario, I concluded that putting the file with a strong randomly generated 128char password in an encrypted volume somewhere online is the best way alternative for a last-resort scenario, or if you needed to cross a border you would always have a backup ready. If someone managed to bruteforce a SHA-256 64+ character password then wouldn't basically render BTC unsafe as a whole.

As far as the public addresses, if they cannot be hidden because of some technical limitation, then I guess one has to deal with that. Just never decrypt the file in a computer that isn't your offline airgap one.

I've seen several (mobile) wallets that have an option to hide the balance. The thing about Bitcoin Core is that it only offers the basics. Many other wallets have more features, which can be built on top of Bitcoin Core.

By the time someone got their hands on your wallet.dat, they've gotten too close already. I wouldn't upload it to the cloud for instance, but if you do: encrypt it yourself. Why tell an adversary that it's a wallet in the first place, while it could just as well be other data that has no value to an attacker? Knowing it's a wallet is already an incentive to brute-force it. Don't give them that information!

If you are trusting encryption to keep your cloud back up safe from attack, then why would you not trust encryption to keep a back up stored with a friend or family member safe from attack? Offline back ups have the advantage that they can't be potentially attacked by anyone in the world at any time without your knowledge.

And as you say, with everything under your name being a target for a government, that includes any online storage or online accounts.

That's one of the main reasons why online storage is not safe - the vast majority of people don't do this. I've lost count of the number of people I've seen who add a text file with their seed phrase to a .zip container with a password, all from their main computer which is not clean and with constant internet access, and then upload that to their email account.

Because if you want that you can just encrypt the file or the volume.  If you don't the other files in the wallet like the debug log will leak this data anyways.

Every feature of the software comes with cost and risk.  Encrypting just the keys is something that the OS cannot do, so it's justified. Encrypting the whole thing is something that it can, so it's not justified.

Also if you encrypt everything it means you will have to enter the key on every use-- even just to see if you've been paid.  It means a key will have to be in memory at all times the software is running, not just when you spend.  If the same passphrase is used for both view and spend then these will increase your risk to shoulder surfing, key logging, and other malware (which otherwise you might be saved from if you realize you are compromised before you spend).  If different passphrases are used for each the risk of key loss is increased.

Keep in mind that it's likely that far more funds are lost due to accident and forgetting than are lost to coin thieves already, so anything that makes it easier to lose access is probably increasing the total amount of coins lost rather than decreasing it.  Arguably developers of Bitcoin software already have a small conflict of interest to make choices that error in the direction of taking coins out of circulation, since every coin forever lost makes everyone elses coins more valuable.

ETFbitcoin's point on scan when unlock is great too-- it takes a long time to scan months worth of blocks, big usability annoyance.

Mobile wallets are on platforms where things like encrypted volumes are less available-- you usually just get a whole device or not.  They're often also written with much more of an eye towards marketing rather than security and have liberally provided pretexual "features" in the past that only undermined the user's security, or just features that weren't justified based on the effort required to actually do them right.   I don't think it's correct to say that the Bitcoin node software only has 'basic' features, it just don't waste effort on snake oil and there is a lot of bitcoin wallet snake oil out there.

Encrypting the whole file isn't snakeoil but it provides relatively narrow benefits vs the costs. And at least on desktops where it's not too hard to use an encrypted volume the marginal benefit would be pretty small indeed.

Full index of address usage adds >> 1TB of storage (as of a couple years ago, it's probably >2TB now) and an according amount of sync indexing time.  Not exactly ideal if you're already slow on a spinning disk. :P  You need both payments and spends indexed for a wallet, since you need to know if a coin you were paid has already been spent by another copy of the wallet.

The challenge there is that even if such an index is viable for you today, it likely won't be viable for you in the not too distant future because the resources grow faster than those required to run a node.

The history of people using indexes is that they set up their usage to require one, and then when it's too burdensome switch to using a trusted third party to provide it (e.g. when their node crashes and they're facing a week of indexing before their business is back online, or when they need more storage than their hosting provider offers without the high cost of a dedicated high storage server).  If TTP is where you're ultimately going to end up, perhaps its best to be honest with your security model and do so now and in the meantime not encourage people who could do without the index with a bit more development effort (instead loading watching keys, etc.)  from building  infra that will inevitably push them onto a third party service.

If you do really want indexes there are some open source block explorer programs that will provide them.

Why not just simply zip&encrypt the wallet.dat file and then rename it to something else.... this way you will need a more "skilled" attacker to detect it and also to decrypt it.  ::)  Just leaving the unencrypted and original file in cloud storage, just attract attention to it, if the hacker knows what it is looking for.  ::)

Also, just write a few batch/script files to automate the renaming and decryption, if you have a lot of files.... and it will not be a lot of hassles to do this on a frequent basis.  ::)

Also, pop some "decoy" files in there, if you have to store the files in the cloud, to keep them busy.... might as well waste their time, while you are at it... right.  ;D

Not just mobile wallets though, desktop wallets like Electrum offer this feature too. They basically treat the wallet file differently. When the client opens it asks for the password and decrypts the addresses only and don't touch the keys at all. Then it keeps the list of addresses and their history in memory so it doesn't have to keep asking the user to enter password each time they want "to see if they've been paid".
User only has to enter their password if they want to spend coins (access private keys).

You would trust that you don't get snitched on by someone you handle your coins to? and what if they lose the backup? and what happens if you travel a lot and you have no one you would trust to handle the keys to?

I don't see it as viable. Now an encrypted volume with a randomly generated 128 character password with Keepass, generated in a clean computer with a live Tails CD session offline... if they crack this... then nothing is safe isn't it.

Being able to have a backup hidden somewhere online, could save your ass in several situations. There's no easy way to get around this necessity of having a backup in the cloud in case all of your physical stuff gets compromised for any reason. And when crossing a border, you probably have higher risk of getting stopped in an airport and being forced to decrypt than someone finding there's a file somewhere hidden worth spending years bruteforcing on. And it would require that the service you use has a database leak and someone logs in into your account and downloads the attached file, cracks the encrypted volume and cracks the password to make a transaction which would be different.

I've seen much more cases of people losing their funds by leaking it online, than from getting strip searched on an airport. But if the latter is really your concern, it's not that hard to hide a file somewhere on a storage system without making it obvious it's an encrypted wallet.

Why do they need to know it's a bitcoin wallet? Hand them an encrypted USB and just say it's a back up of important documents like your passport or various financial records or contracts.

Redundancy. You should never only have a single back up.

Then use something like a safe deposit box.

If you do things perfectly, sure. But I am still reminded of this quote:

Just use a hidden volume. Decrypt it to show back ups of important documents as above, with no evidence that a separate encrypted volume even exists.

Delete your wallet and use file recovery tool for recover wallet file then using wallet every time. No one can steal you wallet in this way.

?

You mean recover your wallet file from a back up every time you want to use it? Ignoring the inconvenience involved with that, it doesn't solve the problem being discussed. Your back ups are still vulnerable to attack, and the wallet can still be attacked whenever you have recovered it to your computer.

That's the dumbest thing I've read today. You don't throw your wallet in the trash bin at home, do you? With the risk of someone emptying (or overwriting) it?

I hope it's trolling, because it did crack me up! :D
But I wouldn't recommend it to anyone, no.

Regarding the topic at hand, in my opinion a wallet.dat should be handled like a seed phrase or private key, i.e. with extreme caution, including no cloud uploads and no transfers without prior AES encryption.
It's easy to do anyway:


So whether it includes addresses in plaintext or not, doesn't really matter.

replying to @o_e_l_e_o

If they tell you to decrypt, you'll have to decrypt, or face consequences of not decrypting. This is the problem with full volume encryption. If you use a simple encrypted volume file to put the files in there, they would be able to find it eventually once they check around your stuff since they do dumps of your entire drives. I thought this wasn't happening until i've read people getting stopped randomly on airports and border controls and so on. You can check it out on reddit.

About a safe box. I live in an apartment. There's no space for a proper safe box setup, or at least something strong enough that would resist and couldn't be moved. I've been considering hiring a storage safe thing spot, so im physically diversified too. Of course you would need to trust that no one breaks in there, that the place is well secured, that no employees are able to get in and steal stuff.. I will look at the market for this type of service. Hiring a storage room thing (like the ones seen in the American TV program "Storage Wars") to store an USB pendrive is overkill, so it would need to be a safe. Does anyone here hire such a service?

About hidden volumes, I have read about them quite a bit back then and discarded it because it was not clear to me that it would save your ass in a situation where you would be forced to decrypt. It may trick the computer illiterate thief but vs an informed attacker they may find out you are hiding something. Now knowing that you are hiding something would make it worse. Or perhaps it was a hidden OS inside a hidden volume that has flaws and it's fine for a simple volume. I remember reading about limitations of hidden volumes on Truecrypt mailing list or some site years ago and some claimed it's best to not do it and just claim you forgot the password, but against a 5$ wrench attack by some goons the hidden volume would save you for sure. It's one of those things.