Questions about encrypting Bitcoin Core wallets

For me, encrypting a wallet is super important. A lot of folks don’t realize how crucial it is, but encryption can really protect us, especially when dealing with digital files like wallet.dat and similar. I’ve got some specific questions about encryption in Bitcoin Core. Just so you know, I already have some answers, but I’m looking for a bit more clarity on a few points. 1. So, Bitcoin Core does use AES-256 to encrypt the wallet.dat file, right? 2. If I decide to use GPG (also AES-256) to encrypt wallet.dat, without using Bitcoin Core’s own encryption, that means I’d basically be encrypting the whole file, making it completely unusable unless I decrypt it first. But with the built-in encryption in Bitcoin Core, it only encrypts the private keys, so I’d only need to decrypt for certain tasks like signing. Am I on the right track? 3. If my understanding from (2) is correct and I’m pretty sure it is would it be wise to keep the wallet.dat file encrypted in both ways? 4. Is the BIP-38 feature totally gone from Bitcoin Core now? 5. Does Bitcoin Core generally support or allow physical paper backups of private wallet descriptors? Is there a method to export my private descriptors from Bitcoin Core and print them in a secure way? I was thinking of doing the following: (a) export the descriptors to a json file (b) encrypt that file with GPG (c) turn the encrypted data into a QR code (d) print the QR code But honestly, I’m not a fan of all that manual work. Is there a chance Bitcoin Core might implement something like this in the future?

I always appreciate it when others take encryption seriously and want to learn more. 1) "Core encrypts wallet.dat with AES-256, right?" Core encrypts the key material, not the whole file. Each private key/seed is encrypted with a random master key using AES-256-CBC. The master key is encrypted with your passphrase via EVP_BytesToKey(SHA-512 + salt + iterations). Metadata (labels, txs, watch-only, etc.) stays readable so the wallet can load while locked. 2) If I GPG-encrypt wallet.dat externally… Correct: you'll encrypt the entire file and Core can't open it until you decrypt it first. Native encryption lets Core load/receive/watch while keeping spends locked. 3) Should I "double-encrypt"? For backups, yes--keeping a copy of the Core-encrypted wallet.dat additionally wrapped in GPG/VeraCrypt/LUKS is fine. Just keep at least one copy you know you can restore (test a restore!), and don't overwrite the only good backup with a failed re-encryption. 4) BIP-38? Core does not support BIP-38 (and never did). If you export WIF keys you'd need an external tool to BIP-38 them. Recommended path today is descriptor/seed backups, not BIP-38. 5) Paper/descriptors backup Core already lets you export the descriptor set (including privkeys) via RPC: listdescriptors true --> JSON of descriptors with xprv. dumpwallet <file> --> legacy: all keys + metadata in text. You can take that JSON/text offline and GPG-encrypt it. Printing a QR is your choice (be mindful of QR size; you'll likely split across multiple QRs). Core doesn't do the QR/encryption for you in the GUI; you'd script this yourself on an air-gapped machine. Use a long, unique wallet passphrase; Core's KDF has an iteration count but passphrase quality dominates. Make multiple offline backups (wallet.dat and/or listdescriptors true) in separate locations. If you want extra protection at rest, put the backup inside an encrypted container or GPG it--in addition to Core's native encryption. Test your restore procedure once, then seal the backups. The above setup gives you: usable day-to-day wallet (locked), plus verifiable offline backups with defense-in-depth.

I think we both described the same process for step (5). What I am actually asking is whether there is a good, recommended by Core's developers, in order to back up the wallet.dat in a physical medium, rather than a digital one. But, writing an XPRV isn't the optimal way, because it lacks encryption. So, I am wondering if they do it, if they recommend it and if they endorse it in general as a concept.

There isn't an "official paper-backup format" for Bitcoin Core and the project doesn't endorse one. Core only guarantees an encrypted wallet.dat file (your day-to-day wallet), and the ability to export the key material in plaintext if you ask for it (listdescriptors true, or legacy dumpwallet). Once you export keys/descriptors they are not encrypted by design. Core intentionally doesn't invent a special "paper-encryption" scheme or mnemonic. If you want a physical backup you have to add the protection yourself. Core devs generally recommend encrypting the wallet (encryptwallet), then keep multiple offline copies of the encrypted wallet.dat in different places (USB/offline disk, etc.). On top of that, keep a verifiable text backup of descriptors (listdescriptors true) offline and protect it yourself (e.g., GPG-encrypt and print the ASCII-armored text; or split with Shamir/SSKR if you like). Test a restore once, then seal the backups. So the practical, supported path is: keep the encrypted wallet.dat (digital) + store the passphrase and an offline, operator-protected descriptor dump (physical if you wish). There is no Core-endorsed "paper wallet.dat" because any exported key material is necessarily plaintext and must be protected by you. Hope this solves your issue.

I am not sure about the "intentional" part. Perhaps they've found some ways to do it manually that aren't standardized and that's why they're not featured in Bitcoin Core. I am not a fan of digital backups. If you have 3 media in which you store your wallet.dat, chances are you'll be ok, but I prefer trusting paper. The problem is, that the easiest way I 've found so far for doing a proper backup is the following: 1. Export the private descriptors in a JSON file. 2. GPG-encrypt the json file. 3. Print the encrypted cipher. The cipher though looks like this: Easy to print, but very difficult to write down in order to decrypt it. So, getting a QR code out of this is, perhaps, easier. Anyway, I guess I am asking primarily because I want to see if anyone has a good way to backup a Bitcoin Core wallet on a physical medium (paper ideally).

If you prefer paper backups (encrypted with a QR Code), the easiest and most secure way for you is to import a wallet with an existing recovery seed (created outside of Bitcoin Core, obviously) via descriptors, extracting the BIP32 root key (which is what I did in my case). But even so, you might prefer to encrypt the descriptors extracted from Core using gpg/aes, and then convert them into a Qr Code format. It would be an interesting experiment to follow. I'll tell you what I would do in my case: *Let's assume I created a native wallet in Core. I'll encrypt it with my password/passphrase before transferring funds, obviously. For me, just backing up the wallet.dat file is enough, but to prevent snoopers from accessing my wallet.dat and seeing the balance and transactions but not being able to spend, I'll add additional encryption, perhaps using gpg or aes, or perhaps something simpler like moving the file to a Veracrypt container or (even easier) to a KeePass database file. This would make a great topic (about additional encryption in the core). *Of course, I would do the entire procedure in an offline air-gapped environment, the same for any of the encryption methods mentioned. I wouldn't make any physical backups, at least for now.

So what I am trying to achieve is to have a physican backup of a core wallet, but being encrypted I am putting this emoji because it looks like nobody has done it, or hasn't seen this thread yet. Your approach looks like what I currently do, more or less and it's a common method. To be honest, encrypting the wallet.dat and the disc where it lies with another password is more than enough. It doesn't need extra gpg encryption on the file itself.

You want to do the same encryption method as Krux, right? It exports encrypted backups as a QR Code with your password. But only in mnemonic format. Anyway, if you want to do this with a native Bitcoin Core wallet, you'll have to do it manually through third-party applications.

Or, since it's cold storage for 10+ years, that I won't spend unless there is a good reason to do so, I could just stick with BIP38 which does that already. The problem is that I will need to have single addresses that aren't anyhow connected and that they'll be legacy addresses which means higher fees when I spend. Now to my original question, does everyone who uses Core, still keep their wallet.dat in digital media?

Reminder that stored minimum: SSD life is a few years but can be a low as 1-2 years, and HDD life I'd suggest not to expect more than 10 years.

Great reminder, because it strengthens my original necessity to store the wallet.dat backup on paper. But I've come across the M-Discs. They are supposed to be archival discs with relatively low capacity (25GB exist!). But I also remind people this quote by LoyceV: That way, you can do health checks and also adapt to the new technological inventions.

Don't make the mistake of buying a more expensive enterprise SSD thinking they're more durable for cold storage. Data retention can be as low as 3 months or even down to just 7 days at high storage temperature.

yes any time i use it i make sure to back up wallet.dat in case any new change addys or whatnot are generated. its habit at this point. same wallet.dat since 2011, and still in Non-HD format.

Wow that's tricky! When I asked I was expecting to see people storing bitcoin in this way, but I thought most people have migrated to descriptor wallets so far. So, how do you do it? Btw, is it cold-storage or are you also spending from this wallet? Because if you don't spend, then isn't it more rare that you actually use it and that you also get the chance to back it up? Lastly, you had no issues since 2011? That's remarkable to say the least. So self-custody of wallet.dat is doable, no matter what many other people say!

Not really: I have a non-HD wallet (my very first Bitcoin Core wallet created days after I joined Bitcointalk), and it has a keypool that stores 1000 unused keys. Each time it's unlocked, it refills the pool to 1000 again. So any backup is good for a very long time. I don't like how complicated those descriptor wallets are for a simple import/export. But I never really bothered upgrading to HD either: I like simple random pools. And I don't hold much in that wallet anyway.

They offer a significant advantage though, which is that you could store xprv9s21ZrQH143K24Mfq5zL5MhWK9hUhhGbd45hLXo2Pq2oqzMMo63o*, and with it you can restore your wallet not only in Bitcoin Core but everywhere. And you don't necessarily need to do backups every time you create an address. The question is, where do you store the wallet.dat regardless of how it works internally. Because this issue still exists. * example from https://en.bitcoin.it/wiki/List_of_address_prefixes

Backups I have more data I don't want to lose. I use rsync to copy it to one of many different backup media.

Especially for larger data, rsync seems to be the only reliable (and fast) way to do it. Drag & Drop, or cp and mv don't work as expected. In terms of storage type, what do you prefer?

I have no problem with cp and mv, both work fine. But the best thing about rsync is this: I have different backups from different dates, and it barely takes any additional disk space. It's very rare to need to find back an old file, but when I do, it's convenient to still have it. Like I said: different ones from different brands. I expect some brands to be more reliable than others, and as I can't know which one is best up front, I get a new one once in a while.

Until 2017, I used a non-HD wallet in Bitcoin Core, even though I had the option to upgrade to HD. However, I needed to create a new wallet, and since Bitcoin Core was already generating HD wallets by default, that’s how it happened. Bitcoin Core doesn't create wallets with mnemonic backups, making physical backups (on paper, steel, etc.) more difficult, since writing down the 111 characters of the BIP32 private root key greatly increases the margin of error. My suggestion for this is: If you want to have physical backups in addition to digital ones, create a BIP39 wallet, back it up as you would any BIP39 wallet, and import the BIP32 descriptor into Bitcoin Core. This is what I did. I think storing an xpriv physically is very risky (both in terms of errors and theft). An encrypted digital backup (wallet.dat) can be replicated much more easily, avoiding the risk of storage failure. (But why not combine physical and digital backups?) Descriptors were one of the best innovations I've seen in Bitcoin Core, after BIP32. It's a shame it's not very widespread.