Using Bitcoin Core Offline

I run two copies of Bitcoin Core: 1) One on laptop A to sync the blockchain. This one has a watch-only wallet.dat with just public keys to keep an eye on my funds and send out transactions. 2) The other is on laptop B, which holds the private keys. This one never goes online, so it doesn’t sync. It’s purely for keeping the wallet.dat secure and making transactions in .psbt files that I then send over to laptop A for broadcasting. So here’s my question: since laptop B doesn’t need internet, is there a way to stop this Bitcoin Core instance from trying to connect online? Like, is there an offline mode I can use that disables all internet functions? It’s really annoying that it’s constantly trying to sync the blockchain. It feels off that it’s making unnecessary attempts to connect just to start downloading blocks. If there’s no such mode, they really should create an offline option for setups like this.

There is no --offline command line arg but you can start it with: --noconnect to prevent it from trying to connect to other nodes. Given that it only prevents connections, the questionably annoying "xx years behind" message will still be visible even with that command line arg. I doubt that it'll be implemented since the issue is too personal IMO. You can try to convince the developers of the Bitcoin reference client though, post it an a "Feature Request" issue.

I'd disable all networking on the system. I haven't tested how Bitcoin Core would react, but it's can't try to query anything if there is no network interface.

The thing is, Core devs are strongly in favour of the fact that wallet encryption is sufficient and, therefore, I doubt they will implement a "cold-storage" feature. Wrong thought The whole purpose of a node is to be online, so the only way for this to happen, would be to develop a secondary program and detach the wallet from the node. By the way the setup that OP has looks good to me, I don't think it will get any better soon. The only thing I 'd like to submit is this accident: https://bitcointalk.org/index.php?topic=5432665.0. It's very obscure, as in we have no clue what happened and how, but I tend to believe that online keys can be secure but the problem is that it's very difficult to do it properly (i.e strong password, machine safe from keyloggers, machine without physical access from other people etc). I believe it's stressing and that's why I don't suggest keeping any key-related material online.

Running your node with your wallet online is simply not safe so I don't understand how anyone reasonable would do that. I think encrypting your wallet file with a 128 char impossible to crack password inside an encrypted volume with luks, veracrypt or something like that and storing it somewhere in the cloud is actually safer than running you node with your wallet file in there, since every time you do a transaction you are typing your password. If you have it stored somewhere, the password of the actual wallet.dat file that allows for transactions is never seen, since you will only be typing this in the airgap setup. The wallet.dat would at all times be inside an encrypted volume, and this file would also never be seen online, since you decrypt the volume inside the airgap laptop if you ever needed to use this online backup. I think if Luke was using his online node as also his wallet he did a massive mistake. It's either that or a made up boating accident story for security purposes.

Yes, in fact that's why I said: My only issue with your setup is the inheritance, because it's not very easy to create an easy-to-follow guide for your inheritors. But, this can be irrelevant for you and it's definitely subjective.

Can you show me a source for this statement? I believe Bitcoin Core's wallet encryption is sufficiently strong (assuming you use a strong password), but that doesn't mean the host system is secure. A simple key logger is enough to compromise even the strongest password.

No and it's a mistake that I expressed myself this way. Allow me to fix my post above to avoid future misunderstandings (I will edit it right away). In fact, the reason why I said it was because Luke admitted he had his keys encrypted with GPG and I, mistakenly, thought that it was an approach that they thought was correct. But as you said, a software can be safe, but if the environment where it lives is unsafe, then it's essentially like putting a bar of gold in a safe-box with a 100-digits pin and then living the safe-box out on the street.

Your setup looks great, bitcoin core works both offline and online. The only difference is that it will try to pair with other nodes even when offline, but you can easily (if using the GUI) right-click on the network icon and disable it (this only makes sense if your machine has an internet connection, otherwise it won’t change anything). As others have mentioned, there’s currently no way to remove the pending sync progress bar in bitcoin core. You can report this as an issue on github, but there’s no guarantee the developers will accept the idea. How do you transfer the signed transaction’s .psbt from laptop B to laptop A? Using a USB drive? What if you infect the malware that carries the signed transactions through laptop A? Since Core doesn’t support QR code export, you’d have to copy the .psbt to Electrum and handle it there. The only detail that bothers me a little about bitcoin core encryption is that it leaves the addresses visible, even if the wallet is encrypted. If someone gets my wallet.dat backup, they will know my addresses, xpubs, etc. But they won’t be able to send funds. But this can be worked around by using .gpg to encrypt the wallet.dat, signing it with my own gpg public key or using symmetric encryption. In other words, if the user is concerned about the privacy of less sensitive data, such as receiving addresses and descriptors containing the xpubs, they can use additional encryption. However, the complexity increases, as there are now two passwords to remember.

I actually like that feature. I can check incoming transactions without having to type my password, which means I use my password much less frequently. Some wallets ask for the password just to start the wallet, and it gets even worse if they don't ask for it again to send funds. That's now how I want my wallet security to be handled.   True. But if you need to decrypt it to use it, any attacker with access to your system can get it anyway.

Yeah definitely, but if you plan to use the wallet, like LoyceV said, it's better to be able to monitor the transactions, to view the addresses, to view the balance etc. So, if you wanted to receive a transaction you wouldn't have to type the password each time, posing an extra risk for the wallet. I haven't been able to find a way (that I like) to fully encrypt a wallet. BIP38 - The QR code is safe and the private key is also safe, but the address isn't hidden so that you can send to this address. BIP39 - The seed phrases are stored unencrypted, so the private keys' security depends on the hiding location and not on the backup itself. CORE - You could encrypt the full wallet.dat with GPG and store it on flash drives but again, it would ask for the password every time you wanted to send the funds out of the wallet. It could be ideal for one-time loading wallets. MultiSig - It's a way to make sure that if one key is lost, the funds aren't lost as well. Essentially it eliminates single points of failure. But the keys remain (most of the time) unencrypted. PassPhrases (BIP39) - I don't really like them because everytime you want to send funds out of the wallet you need to bring the passphrase and the seedphrase together, which brings an extra risk.

If that's the only thing you don't like about BIP38, here's an easy fix: you don't need to keep the address

Yeah, sometimes the obvious things are the easiest to miss. By the way, you seem to imply that there is something else I should worry about with BIP38, am I wrong?

I'm not implying anything, I like BIP38. But I'm not a cryptographer, so all I can do is rely on what I've read about it so far.

Me too, I no longer mind this since I can use a second password such as .gpg encryption, to work around it if necessary.   In this case, assuming you are referring to my second .gpg password, the important that the Bitcoin Core encryption password is not compromised. The gpg password is only to prevent others from seeing my xpubs/addresses/amount/descriptors. Obs: third-party encryption (gpg, 7zip or even VeraCrypt) should not have the same password as the wallet. It acts as a second layer of protection preventing anyone with access to wallet.dat from viewing the xpubs and consequently the balances, reducing the risk of becoming an even bigger target. I think the BIP39 passphrase is one of the best additional security features for wallets today. It has its pros and cons: - even if the seed has weak entropy, but the passphrase is strong enough, the funds stored in a passphrase-protected wallet will be protected against brute force attacks. - It's ideal for plausible deniability since there is no "correct passphrase." Different passphrase combinations generate different wallets, making it difficult for someone to prove the existence of the real one. - Wallets that require entering the BIP39 passphrase every time the wallet is opened reinforce memorization, but in sotware wallets like Sparrow, Green Wallet, etc. The risk of malware capturing the passphrase increases if the device or network is compromised. - Wallets like Electrum, Bluewallet, etc, only require the passphrase once, during the wallet creation/restoration process.

Great response but I still prefer to use 2-of-2 multi signature wallets because essentially they require the same number of backups (4 backups) and they allow you to bring a PSBT from wallet A to wallet B without ever bringing the wallets together. Apart from that, they give you the plausible deniability you referred to because there is no indication that wallets A and B are linked .

Multisig is also a great strategy for those who have the necessary knowledge and know how to handle it without fucking things up along the way. But I've a question: why a 2-of-2 multisig setup? As far as I know, in a multisig setup that requires all keys n to be available to sign m, like 2-of-2 or 3-of-3, if one of the keys is lost or compromised, it can result in the permanent loss of funds. Now a 2-of-3 or 3-of-5 etc setup is different and seems more ideal in case one of the keys is lost or one of the owners of M is involved in a natural disaster or due to human interference (death, accidents, or intellectual incapacity, etc) or discussions that result in the refusal of one of the participants, since the remaining participants would still be able to move the funds in a setup with redundancy greater than n of m like 2-3 and others. In your case, from what I understand, assuming you have two computers A and B. You keep laptop A online and laptop B offline, but each laptop has one of the keys to sign the transaction, while in a singlesig wallet, only one of the laptops has the necessary key while the other simply transmits the psbt. The only advantage I can see is that in a 2-of-2 setup, the attacker needs to compromise both keys to steal the funds, you don't need to worry so much if you compromise one of the keys, since the second and last key is needed to authorize the transaction.

Well I think we may be out of subject despite I like this conversation. In short: A 2-of-3 multisig requires 3 backups whereas a 2-of-2 requires 4 backups. In a 2-of-3 you must back up the wallet as follows: Location 1: seed A, xpub B Location 2: seed B, xpub C Location 3: seed C, xpub A In a 2-of-2 you must back up the wallet as follows: Location 1: seed A (backup 1) Location 2: seed A (backup 2) Location 3: seed B (backup 1) Location 4: seed B (backup 2) I don’t like having to backup the xpubs because I don’t know how to do it properly. I prefer having seed only backups because they don’t reveal to the attacker the existence of any other wallets. Don’t get me wrong, the 2-of-3 is much more recommended by sophisticated bitcoiners, but I feel confident with my knowledge and my setups, so I would choose the 2-of-2. But I have used (or still use) many different setups. The 2-of-3 and any other larger quorum for me is most suitable for multi-person setups. For inheritance or boards of directors in companies etc. The 2-of-2 is good for single-person setups or for joint accounts.

You can encrypt the .psbt file with an encryption program such as VeraCrypt and move the file in there. You also write down the sha-256 checksum for both the encrypted volume and the actual .psbt file to double check file integrity. The online node is only used as an online node and never does anything dodgy, you also limit the USB pendrive for this task alone and never use it anywhere else. This should be a reasonable way to not screw up during this step. As far as how Bitcoin Core leaves the addresses visible, I have mentioned how this is a mistake before. I remember someone making an argument about this which was not convincing at all. If someone finds the wallet.dat file for some reason, and the see the funds, depending on how many funds are there, they may persist more on trying to bruteforce the password or they may even try to find you and $5 wrench you. So they should add a way to encrypt the entire wallet, and if anything have a different password to confirm transactions so you can use it locked for watch-only purposes. But ultimately you always want to store your wallets encrypted with an encryption software on top of it.

You could do what you already do. I mean you could encrypt the USB stick with VeraCrypt or LUKS depending on your OS needs and then whatever you put inside is fairly well hardened because of the medium's encryption. So the wallet.dat file is supposed to be fully encrypted this way. And the advantage you have is that you can store multiple files in the same storage medium with one strong password. I mean if each wallet has their private keys encrypted with different passwords and then you also need a different password for every wallet.dat file, you 'd need to remember 2*N where N = the number of wallets (1 for the private keys and 1 for the file itself, for each wallet). Now you can have N+1 passwords where N = the number of wallets and 1 is the USB stick's password.