This worked, didn’t need the other command, it rescanned the wallet or something with a loading bar, then I saw the notifications of the incoming transactions and I can see the funds, awesome, finally making progress.
Of course, now the nightmare will be having a bunch of transactions with no labels. They should really improve this and have the .json include the labels but it is what it is. So basically, I have to manually check one by one, and edit the label. It lets you edit the label easily on the GUI. How would the best way to go about it?
The problem is, you have the wallet.dat file on your safe airgap computer, cool, but you see 0.00 BTC, you just have the private keys. To see the funds, you do this whole process on a watch-only wallet, but you are only seeing the funds with no context (no labels). So I don’t see how I add the labels correctly, since the wallet.dat on the airgap computer lacks blockchain data, it cannot load the funds and show the labels… I mean, am I really going to need to copy the blocks folder into the airgap computer’s /.bitcoin and reindex the chain there? Because I cannot think of any other way. The other computer is only 1TB free space and the damn blocks folder is already 793GB, plus it’s HDD since to store files long term from what I have researched it’s better to use HDD since it has less degradation (as long as you are not using it a lot). Not a problem for this use case. However, im going to give an HDD a beating by verifying all the blocks and copying them there… so I need to think about how to proceed there.
We are talking years of transactions, each transaction properly labeled, and now im just going to get a bunch of transactions with no context, so I cannot use the funds like that.
Ok, we could run a loop to compile a custom JSON file containing addresses and labels on the airgapped computer (using listlabels and getaddressesbylabel). Something like:
# Add any other flags or paths you need for bitcoin-cli to work:
CLI="./bitcoin-cli -rpcwallet=your_airgap_wallet"
$CLI listlabels | jq -r '.[]' \
| while read -r L; do
$CLI getaddressesbylabel "$L" \
| jq -r --arg L "$L" 'keys[] | {addr: ., label: $L} | @json'
done > addr_labels.json
And then take that JSON file to the other computer and run another loop which reads from it and applies the labels to the watch-only wallet (using setlabel). Something like:
# Add any other flags or paths you need for bitcoin-cli to work:
CLI="./bitcoin-cli -testnet=1 -datadir=/home/epicpanda/software/.bitcoin -rpcwallet=testnet3_watchOnlyTestWallet"
# Apply labels line by line
while read -r line; do
addr=$(jq -r '.addr' <<<"$line")
label=$(jq -r '.label' <<<"$line")
$CLI setlabel "$addr" "$label" 2>/dev/null || true
done < addr_labels.json
Awesome, it worked, thanks. Now I can finally do some testing with PSBT on testnet before I try this process with the real deal. Hopefully the migration does not introduce any problems, since the migration step wasn’t replicated there. Im still considering downloading an old Bitcoin Core version and replicating a migration, but If I install like 0.8.x and I open it using existing blockchain files, is it going to take ages again to verify the existing block files? (and hopefully do not damage them in this process). What about the chainstate folder files? I just want to be able to log in Knots again without any surprises.
Something I’ve noticed is, in “Date” all transactions (except the first 2), the dates are like 20 minutes later on the watch-only compared to the other one with the private keys (which is online since I have both wallets on the same laptop to test this, later I will test with the airgap laptop now that I know the steps), I guess this just logs whenever the wallet gets the transactions notified, and you should watch on the mempool for the actual time.
Btw, do you know what “Enable PSBT controls” does on the GUI? I see “Coin Control” enables the “Coin Control” section easily, but since I never did a PSBT transaction, im not sure what this does.
I haven’t done this myself, but I think you will probably have to reindex when you go back to an older version (and then again if you upgrade it to the newer version). I know there is at least one update (maybe more) which changed the way the blockchain data is stored and indexed.
Not off hand. I would imagine that it adds interfaces to create unsigned transactions as PSBTs, load them to sign if keys are available, finalize, broadcast, etc. I really don’t use Knots as a wallet, though, so I can’t say what exact UI paths are are enabled.
Some interesting findings:
The jq -c step is not really needed since apparently you can paste the json contents but you need to use importdescriptors “pastejsoncontentshere” (including " 's). It also works on the linux shell but it glitches out if it’s too big, but if you press enter it works. The other 2 commands to read and apply labels remain very useful. And im not sure if there is a limit on how long the json you paste there can be so it may still be useful to read a json file with jq -c if that doesn’t work but I would try that first.
That PSBT option enables a “Create Unsigned” button that is not there if it’s not checked.
I did some PSBT testing on testnet, it works well. Definitely way easier than way back in the day when you had to manually craft the rawtransactions. What im not sure about is the new wallet format. Because I reckon reading something about derivation of xpub key being easier than the old non HD wallets, but devs claim it’s safe. However devs also say Core 30 is great so im not sure at this point. I would need to research this a bit further before I migrate the real deal.
It’s still not clear to me how this works. If the Migration tool on Bitcoin Core/Knots turns your old wallet.dat into an HD wallet, the existing keys are not part of the hdseed. This means that when you make a transaction on your watch-only wallet (which is an HD wallet) it will create a change address that the airgap wallet.dat is not aware of. Or because it has been ported as an HD wallet, even if the old keys remain as non-HD, it doesn’t matter because the new change address will match both wallets? Im assuming this is the case, so in no scenario you should lose funds by the change address not matching both wallets.
I have found links to old Bitcoin versions, I will just generate a wallet.dat there, get some coins and then do the migration process to really get a 1:1 simulation with testnet coins, before I do anything with real funds. The old Bitcoin versions can be found on sourceforce through the internet archive and have the SHA256 checksums but no pgp keys that I can find for those files.
I think one of those should do. I will try to find signatures for these files and try this thing.
Im also still not sure why we are trusting HD wallet at all. Like why do we have to have every single private key sitting in a single point of failure (the seed) instead of having them separated from each other? I mean it makes things easier to manage, but im not sure about how reasonable that is in terms of encryption/security.
Well at least even if I migrate the old wallet, all those funds do not depend on a single seed, but any further new funds would.