Old Core wallet to Knots

Bitcoin
21

I’m not sure on the question of how to get a true 1:1 test – it might not be possible to do without needing to run through the IBD again (even if you skip testnet testing) which can take a very long time when you don’t have a lot of RAM and a fast file IO for your datadir, such as NVMe). It does depend on your own risk analysis how much time/money it is worth. If running through the IBD again is not a good option, I suppose you could skip testing the conversion part, but still test the transfer process between the airgapped and online systems. There could be some value in at least that part.

Note that the conversion step is not destructive, as long as you keep a backup of the original wallet file and only modify a copy (you can always go back and start with a new copy of the original if something goes wrong)

22

Im just going to migrate the file and see what happens, I will be doing this in the offline laptop anyway, so no chance funds are moved. The only paranoid thing here is that the migration gets something wrong, and then something goes wrong when I try to move funds.

Something I don’t like about this is how when you have an offline laptop, it says 0.00 BTC. It would be cool to be able to see your funds in the offline laptop but that’s the point of it being offline I guess. You have to trust the watch-only wallet is keeping up with the offline laptop…

You said that generating a new address on the offline computer and then in the online computer (or vice versa) should match each other. Could you explain how this happens? is it because they use the same seed or something? But isn’t having this seed on the online wallet dangerous? it’s a piece of information that spawns addresses, the same as you get in the offline wallet. But only the public key part of this is generated, because you disabled private keys when you create the watch-only wallet… so this must be some of that crypto magic I don’t get. Just from intuition, it makes me think of stuff like, derivation attacks or something.

Isn’t the old format were each private key, had it’s own public key without any seed safer? Sure it was more annoying to maintain, since I assume you would need to manually export and import in whichever correct way the public part of the key that would allow you to broadcast the transaction (im saying this because back then there were no descriptor wallets, but I remember people using the 2 laptop setup). The problem is, this does not allow PSBT files, so it would reintroduce risk when crafting a transaction. I think it was called raw transaction, and it was rather convoluted, you may screw up when manually editing it. No Coin Control to assist you with selecting what UTXO’s you want to use, so you had to do it in the console by manually entering each address and fee, then get a QR code for this (since it was either saving a txt file, or get a QR code with a safe device to scan and read QR codes) and then get it done like this… so PSBT files sound much more convenient than this old fashioned method, but im just wondering what is going on with this HD magic thing, specially with quantum computers being a potential threat eventually you know, I just think that you may be at bigger risk than if they had to figure out each private key for each public key separately, im not sure if I like this idea of having all addresses belonging to this same seed phrase, but it’s supposedly to be safe… Hope this makes sense.

23

–EDIT-- I mentioned xpub, but on these older formats, it isn’t actually an xpub. See my next post below.

There is technically a trade-off here. If someone gains access to your xpub, they will be able to follow all of your bitcoin across all addresses generated by that wallet. They won’t be able to move your bitcoin, though (that would still require the private key). Most people feel this trade-off is worth it, for the other functionalities that it opens up.

24

I think I have been confusing different wallet types here, sorry. You probably can’t generate addresses deterministically here, so that isn’t a good sanity check.

I think the way to sanity check with this wallet type will be to take a known address from the offline wallet and verify on the online wallet:

getaddressinfo "bc1q....."

Ensure iswatchonly == true and solvable == true

25

But if I use the migration tool, doesn’t it convert it to an HD-wallet , meaning that generated addresses should match on both watch-only and cold wallet?

26

Perhaps. Anyway, I am not entirely clear on how this works. Give it a shot and report back on your findings.

27

I haven’t tried yet but I was looking at this video, and this person uses listdescriptors without the false tag, why is that?

And he also used listdestriptors true to show the xpub key. Looks like a different workflow going on here with Electrum or something.

Btw according to a Core developer, they are working in a PR to do this with the GUI and actually export a .json file ready to be imported. And he also said that you can copy paste the things inside [ … ] without modifying anything. Im just not sure about the listdescriptors false thing.

Another problem would be that apparently I would get no labels exported, so when I import this .json file it will no contain any labels. By labels I mean what appears on the “Labels” row in Coin Control. This is a problem since if I don’t see the the labels then I don’t know what im even selecting at in Coin Control, so it’s pretty useless. How would one solve this?

28

Apparently, listdescriptors is the same thing as “listdescriptors false”

Btw, how does importdescriptors work to actually import the .json file?

I have saved all the content from “listdescriptors false” (the contents inside the […] including the []) but I just realized… okay I’ve got this .json file, what do I do with it? Looks like it does not look for a .json file. So I have to copypaste the whole thing after “importdescriptors”?

I mean:
importdescriptors [… all this stuff in there]

I have tried this and it says “Error: invalid syntax”

29

I think it is safer to pipe the contents of the JSON file, since it will avoid any potential escaping issues. Something like:

cat /path/to/filename.json | bitcoin-cli -stdin -rpcwallet=watchwallet importdescriptors
1 Like
30

So im going to need to use bitcoin-cli which I have never used. Could you tell me which are the best settings to use in bitcoin.conf to not screw up and expose the node to the internet?

Im seeing some interesting settings like rpcbind, I guess you have to set this to localhost or 127.0.0.1:8332 (or 18332 for testnet3)

Anything else? for instance, it says that this is ignored if you don’t use -rpcallowip on the exec path

Then I guess rpcuser and rpcpassword

If you got any useful settings here please let me know

31

I think you would just need the following:

listen=0
server=1
rpcbind=127.0.0.1

This will prevent peers from connecting, and serve the RPC only on the local machine. For authentication, rely on the .cookie rather than putting in an rpcuser and rpcpassword (it is secure, since it requries shell access to the computer and read access to the datadir for rpc authentication to be successful)

Then you just need to add -datadir to the bitcoin-cli call if your datadir is not in the default location. You can test this by:

bitcoin-cli getblockchaininfo

And if that fails with a message about the cookie, then add the flag:

bitcoin-cli -datadir=/path/to/datadir getblockchaininfo

If you need the -datadir flag, then just modify my earlier command to add it in there.

1 Like
32

Thanks, I will try that. I asked about this to GPT (for details about how the cookie works) and said:

Using the Cookie for Authentication: When you use bitcoin-cli, you can authenticate using the cookie file instead of specifying rpcuser and rpcpassword. To do this, you can run bitcoin-cli with the -usecookie option, which tells it to read the credentials from the cookie file automatically. For example:

bash

bitcoin-cli -usecookie getblockchaininfo

This looks like it’s completely made up by the AI out of nowhere somehow. I asked if he was sure, and admitted it was wrong:

I apologize for the confusion. The -usecookie option is not actually a valid option for bitcoin-cli. Instead, the cookie-based authentication is handled automatically by bitcoin-cli if the cookie file exists and the necessary conditions are met. Here’s how it works:

How Cookie-Based Authentication Works

  1. Automatic Detection: When you run bitcoin-cli, it automatically checks for the presence of the cookie file in the Bitcoin data directory. If the cookie file exists, bitcoin-cli will use the credentials stored in that file for authentication.
  2. No Need for -usecookie: You do not need to specify any additional options like -usecookie. Simply running bitcoin-cli commands will utilize the cookie for authentication if it is available.
  3. Environment Variable: If you want to specify a custom path for the cookie file or if you are running bitcoin-cli in an environment where it cannot find the default cookie file, you can set the BITCOINCLI_COOKIE environment variable to point to the cookie file. However, this is not commonly needed.

Example Usage

With the configuration you mentioned earlier, you can simply run:

bash

bitcoin-cli getblockchaininfo

If the cookie file is present and accessible, bitcoin-cli will authenticate using the credentials stored in that file.

This is why I still believe in internet forums. You cannot trust these AI’s. They are useful, but you must double, triplecheck everything before typing any commands there.

1 Like
33

Absolutely. AI at its current level is mainly good for brainstorming, but double-check anything it says. Bitcoiners may be in a better position to take advantage of it though, since our motto is already to verify, don’t trust.

Cookie authentication is done by default when another authentication method isn’t specified, so you don’t need any flags for it.

34

I added that into bitcoin.conf and when trying

bitcoin-cli -datadir=/path/to/datadir getblockchaininfo

I get this:

error: timeout on transient error: Could not connect to the server 127.0.0.1:8332

Make sure the bitcoind server is running and that you are connecting to the correct RPC port.

I don’t see a .cookie file anywhere on datadir. The -datadir=path is the correct path.

The bitcoin.conf has nothing on it that could be conflicting, only these 3 lines are used plus par and dbcache.

On bitcoin-qt in options, “RPC Enabled” checkbox is checked.

The node is fully synced, I have the testnet one opened and it’s up to date. So not sure what is blocking the cookie to be created. Im not sure about the port thing. I have not tweaked any network settings. This is a new Debian 13 install and the laptop is connected to the router with an ethernet cable.

As far as bitcoind, if you use bitcoin-qt, then you don’t need to use bitcoind right? or maybe you need to open both bitcoin-qt and bitcoind? I have never used it since I haven’t needed RPC so far until now since I want to use importdescriptors plus I want to run with Tor.

35

I think it is because you are on testnet. I haven’t used it in a while (I’ll check later when I get home from work), but my recollection is that the .cookie file is in a subfolder when you are on testnet (to help prevent thinking you are on mainnet when you are actually on testnet and potentially losing some sats). I think the subfolder (under the datadir) was called testnet3 or something similar. The name doesn’t matter here, just explaining why you don’t see the .cookie file.

I believe you just need to add the flag “-chain=test” to your bitcoin-cli call. It is either that or use the flag “-testnet” (IIRC the “-testnet” flag has been deprecated in newer versions and replaced by the “-chain” flag).

BTW, bitcoin-qt does everything that bitcoind does, plus the UI. So you would not run both of them at the same time (it will probably stop you if you try, anyway).

36

I got it working on the mainnet but not on the testnet3 for some reason

I have added it’s own bitcoin.conf file on:
/home/epicpanda/bitcoin_knots/.bitcoin/testnet3/bitcoin.conf

I have 2 .desktop files. One launches with mainnet and other with testnet, which also has -prune set to a value for the testnet one so I dont waste space.

-testnet=1 launches testnet3. This is what the documentation says:

#Use the chain (default: main). Allowed values: main, test,
#testnet4, signet, regtest
#chain=

#Use the testnet3 chain. Equivalent to -chain=test. Support for testnet3
#is deprecated and will be removed in an upcoming release.
#Consider moving to testnet4 now by using -testnet4.
#testnet=1

#Use the testnet4 chain. Equivalent to -chain=testnet4.
#testnet4=1

I have tried chain=test just in case and same thing.

For the mainnet bitcoin-cli it works. Both ./bitcoin and ./bitcoin/testnet3 generate a .cookie file when bitcoin-qt is opened

Each bitcoin.conf file has it’s own datadir=path pointing at the respective folders so I don’t need to add the -datadir option eachtime i use bitcoin-cli. At least that was the idea, but

bitcoin-cli getblockchaininfo

Doesn’t work. I still need to use

bitcoin-cli -datadir=/path/to/datadir getblockchaininfo

This works.

But for testnet it does not work. I don’t get it. The .cookie is there. I assume each datadir has it’s own bitcoin.conf file

/.bitcoin/bitcoin.conf
/.bitcoin/testnet3/bitcoin.conf

Is this correct? Or there is only one .conf file that controls all chains? (the one in the root ./bitcoin folder)

When I open bitcoin-qt in testnet mode and run this:

./bitcoin-cli -testnet=1 -datadir=/home/epicpanda/bitcoin_knots/.bitcoin/testnet3 getblockchaininfo

It says:

error: Could not locate RPC credentials. No authentication cookie could be found, and RPC password is not set. See -rpcpassword and -stdinrpcpass. Configuration file: (/home/epicpanda/bitcoin_knots/.bitcoin/testnet3/bitcoin.conf)

There’s clearly a .cookie file there right now. So looks like it’s not reading the file or something.

Contents of “/.bitcoin/testnet3/bitcoin.conf”

listen=0
server=1
rcpbind=127.0.0.1
datadir=/home/epicpanda/bitcoin_knots/.bitcoin/testnet3

Edit: I just realized it’s not actually using the testnet/bitcoin.conf file but the one in .bitcoin, not sure if there is a way to have different .conf files for each folder, but anyway I have removed the bitcoin.conf from testnet3, deleted datadir= from the .conf file so it doesn’t point to the wrong datadir when using testnet3, same result.

error: Could not locate RPC credentials. No authentication cookie could be found, and RPC password is not set. See -rpcpassword and -stdinrpcpass. Configuration file: (/home/epicpanda/bitcoin_knots/.bitcoin/testnet3/bitcoin.conf)

37

I’ll do a little testing when I have some free time. It has been too long since I played around with testnet, so my memory is a bit foggy.

38

Found out the reason. I was told that apparently -datadir= should be the same path as mainnet, because when you run testnet, it by default goes into /testnet3/… geez

So basically,

bitcoin-cli -testnet=1 -datadir=/path/to/datadir getblockchaininfo

Using this works.

1 Like
39

Okay so im trying to finally use importdescriptors and get the watch only wallet going. Problem is, like I said, If I just copypaste it on the console on the GUI, I get the syntax error, but you said to use this:

But it’s not working. Here is the command im running in the linux terminal and the error (note that I need to add ./ before executables otherwise they don’t work at least in Debian 13)

cat /home/epicpanda/software/bitcoin-29.1.knots20250903/json/testnet3_watchOnlyTestWallet.json | ./bitcoin-cli -stdin -testnet=1 -datadir=/home/epicpanda/software/.bitcoin -rpcwallet=testnet3_watchOnlyTestWallet importdescriptors
error: Error parsing JSON: [

And here is the cointainer of the “testnet3_watchOnlyTestWallet.json” file:

[
    {
      "desc": "redacted",
      "timestamp": redacted,
      "active": true,
      "internal": false,
      "range": [
        0,
        1005
      ],
      "next": 6,
      "next_index": 6
    },
    {
      "desc": "redacted",
      "timestamp": redacted,
      "active": true,
      "internal": true,
      "range": [
        0,
        999
      ],
      "next": 0,
      "next_index": 0
    },
    {
      "desc": "redacted",
      "timestamp": redacted,
      "active": true,
      "internal": false,
      "range": [
        0,
        999
      ],
      "next": 0,
      "next_index": 0
    },
    {
      "desc": "redacted",
      "timestamp": redacted,
      "active": true,
      "internal": true,
      "range": [
        0,
        999
      ],
      "next": 0,
      "next_index": 0
    },
    {
      "desc": "redacted",
      "timestamp": redacted,
      "active": true,
      "internal": false,
      "range": [
        0,
        999
      ],
      "next": 0,
      "next_index": 0
    },
    {
      "desc": "redacted",
      "timestamp": redacted,
      "active": true,
      "internal": true,
      "range": [
        0,
        999
      ],
      "next": 0,
      "next_index": 0
    },
    {
      "desc": "redacted",
      "timestamp": redacted,
      "active": true,
      "internal": false,
      "range": [
        0,
        1000
      ],
      "next": 1,
      "next_index": 1
    },
    {
      "desc": "redacted",
      "timestamp": redacted,
      "active": true,
      "internal": true,
      "range": [
        0,
        999
      ],
      "next": 0,
      "next_index": 0
    }
  ]

So im not sure what is going on with that. I think I copypasted it correctly and it’s meeting the expected format as described here, however the part below that I don’t understand if it’s some extra step im missing to reformat it:

Im not even sure what that jq command above does so I didn’t run it.

40

Oh, I see – it looks like -stdin flag treats each newline as a separate argument, so it is failing because it just tried to parse the first line “[” which isn’t valid JSON.

I think we can probably use jq to solve this, since it will parse JSON with newlines and spit out single-line. BTW, jq is just a lightweight JSON parsing tool that comes with most Linux distros.

See if something like this works (using jq instead of cat):

jq -c . /home/epicpanda/software/bitcoin-29.1.knots20250903/json/testnet3_watchOnlyTestWallet.json | ./bitcoin-cli -stdin -testnet=1 -datadir=/home/epicpanda/software/.bitcoin -rpcwallet=testnet3_watchOnlyTestWallet importdescriptors

If that doesn’t work, you could try stripping out the newlines. Something like:

tr -d '\n' < /home/epicpanda/software/bitcoin-29.1.knots20250903/json/testnet3_watchOnlyTestWallet.json | ./bitcoin-cli -stdin -testnet=1 -datadir=/home/epicpanda/software/.bitcoin -rpcwallet=testnet3_watchOnlyTestWallet importdescriptors
1 Like