How to get the labels for the addresses when using listdescriptors false?

[takuma sato]

Edit: Please move this thread to the Technical Support section

So let's say you have 100's off addresses from transactions you have received and you want to create a watch-only wallet and use PSBT to move funds.

From what I've read, you must use listdescriptors (or add "false" for extra peace of mind, even tho listdescriptors without "true" does not include private addresses)

Example: I have a testnet wallet and I copy the result in green (imagine the list is way longer, like 100's of addresses):

listdescriptors false

{
  "wallet_name": "testnet3wallettest",
  "descriptors": [
    {
      "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
    }
  ]
}

Then I go to my online watch-only wallet and paste this with "importdescriptors 'thetextingreen'"

The addresses show up, however you have 100's of addresses that have no labels, so your wallet is unusable because you don't even know what you are moving.

Is there a way to get the labels all imported at once into the online wallet so you know what you are doing? I have found a script, but you have to use RPC with the jq command on linux using listlabels and getaddressesbylabel. However this seems rather cumbersome. Is it really no way to do this within the Bitcoin software? Why not just include the labels by default anyway?

[achow101]

Labels are associated per-address, not per-descriptor, so they are not provided in listdescriptors (and generally cannot be). You will have to get the addresses with getaddressesbylabel and apply them one by one with setlabel as there is currently no bulk label adding RPC.

I have an open PR that easily creates a watchonly wallet with all of your labels, transactions, etc. but that is still under review.

[takuma sato]

Labels are associated per-address, not per-descriptor, so they are not provided in listdescriptors (and generally cannot be). You will have to get the addresses with getaddressesbylabel and apply them one by one with setlabel as there is currently no bulk label adding RPC.

I have an open PR that easily creates a watchonly wallet with all of your labels, transactions, etc. but that is still under review.

That would be great. Like I said there is really no way to use the wallet without labels, if you've got a bunch of transactions, and nobody wants to do this one by one.

I've tested this script, it does the job:

Code:

CLI="./bitcoin-cli -datadir=/home/.bitcoin -rpcwallet=yourWalletFile"

$CLI listlabels | jq -r '.[]' \
| while read -r L; do
  $CLI getaddressesbylabel "$L" \
  | jq -r --arg L "$L" 'keys[] | {addr: ., label: $L} | @json'
done > labels.json

This will generate a labels.json file. Copy the file, paste it on your online node. Then run this:

Code:

CLI="./bitcoin-cli -datadir=/home/.bitcoin -rpcwallet=yourWatchOnlyWalletFile"

while read -r line; do
  addr=$(jq -r '.addr' <<<"$line")
  label=$(jq -r '.label' <<<"$line")
  $CLI setlabel "$addr" "$label" 2>/dev/null || true
done < labels.json

This will apply the labels in your watch-only wallet. Something like this couldn't have been applied by default? It does not add any complexity and seems to work fine.

[takuma sato]

I just realized I see another problem:

When I used "importdescriptors" and I added the label names, there is still a problem, the fact that it all gets dumped as if you received all of these transactions at once makes the transactions not ordered by date. This is quite annoying. You would expect recent transactions to be on top and then as you scroll down you see the older transactions, this is all over the place. So im not sure what to do with this.

[nc50lc]

You would expect recent transactions to be on top and then as you scroll down you see the older transactions, this is all over the place. So im not sure what to do with this.

What does it look like?
AFAIK, your transactions should have their dates updated once it synced/rescanned based from the "blocktime" of the block where it belongs.
And using setlabel command shouldn't mess-up the timestamps.

Are the dates in the GUI correct but the arrangement isn't?
If so, simply clicking "Date" will arrange it by date in ascending/descending order.

Or the Dates are actually wrong, with the same timestamps?

[Cricktor]

What did you specify for the required timestamp parameter of importdescriptors? And, yes, did you do a rescan for your wallet from the earliest descriptor or from the Genesis block?

Occording to help description the timestamp parameter specifies the "time from which to start rescanning the blockchain for this descriptor, in UNIX epoch time". With 0 (number zero) the rescan will be done for the entire blockchain, specifying "now" bypasses rescanning and substitutes the current synced blockchain time. (Source: bitcoin-cli help importdescriptors)

But as nc50lc said, once you rescanned the blockchain, existing transactions for the descriptors will have their transaction timestamp set to the block's header timestamp in which the transaction got confirmed.

I have done this for my watch-only wallets of Patoshi blocks, importing about 21,954 combo() descriptors for the attributed public keys, setting labels as mined block number and using different timestamps for the descriptors in two different wallets. After a complete resync the transactions timestamps show no difference between the two wallets.

I have no issues to order the transaction history by confirmation time (sorted by Date column in Core's Transactions display).

Recent transactions actually have a timestamp when the transactions becomes known to the running node's mempool (see last transaction with my local timestamp 11.03.26 05:00 (UTC+1) which actually got confirmed about 20min later in block 9402020).


Here are some older transactions:

[nc50lc]

But as nc50lc said, once you rescanned the blockchain, existing transactions for the descriptors will have their transaction timestamp set to the block's header timestamp in which the transaction got confirmed.

Since he didn't reply yet, I'll just note that it's more accurate to reproduce this in Bitcoin Knots (which is what OP is using).
Although AFAIK, that should still follow the same timestamping behavior that you've tested in Bitcoin Core.

Recent transactions actually have a timestamp when the transactions becomes known to the running node's mempool

Now that you mentioned it; this can be a major factor if it's the case of his transactions actually having the same timestamps.
If most of his transactions are included in the same block and the watch-only descriptors are restored to a new setup, it'll have no idea of the mempool-based timestamp that the original wallet knows.
So, the dates (including time) will be the same for those same-block transactions.

E.g.:
Original Wallet's Timestamps:

Restored Wallet's Timestamps (on other machine):

[Cricktor]

Since he didn't reply yet, I'll just note that it's more accurate to reproduce this in Bitcoin Knots (which is what OP is using).
Although AFAIK, that should still follow the same timestamping behavior that you've tested in Bitcoin Core.

I deliberately refuse to run Bitcoin Knots from Lunatic Luke on any of my devices. And I'm not willing to spend any time to check and verify if Knots is safe to run or has some iffy code segments. Not going to support any of the Knots nonsense.

[Forsyth Jones]

Now that you mentioned it; this can be a major factor if it's the case of his transactions actually having the same timestamps.
If most of his transactions are included in the same block and the watch-only descriptors are restored to a new setup, it'll have no idea of the mempool-based timestamp that the original wallet knows.
So, the dates (including time) will be the same for those same-block transactions.

This is a issue on Bitcoin Core, it happened to me when I imported addresses with transactions from 2018. 5 or 6 transactions had the same dates and times, even though they were actually received at different times, even days apart. However, years later, doing the same thing didn't happen again.

OP @takuma sato how are you importing addresses and xpubs with "importdescriptors"? Can you paste an example here?

What are you inserting in the "timestamp:" parameter? To avoid confusion, include "timestamp:"now" in the importdescriptors command, wait for confirmation that the descriptors have been imported, and then use the command "rescanblockchain start_height stop_height". I always do it in this order and it has always worked as expected.

These same commands should probably work on Knots.

Relevant topics that may help:

https://bitcointalk.org/index.php?topic=5483885.0

https://bitcointalk.org/index.php?topic=5498210.0

https://developer.bitcoin.org/reference/rpc/rescanblockchain.html

[nc50lc]

Now that you mentioned it; this can be a major factor if it's the case of his transactions actually having the same timestamps.
If most of his transactions are included in the same block and the watch-only descriptors are restored to a new setup, it'll have no idea of the mempool-based timestamp that the original wallet knows.
So, the dates (including time) will be the same for those same-block transactions.

This is a issue on Bitcoin Core, it happened to me when I imported addresses with transactions from 2018. 5 or 6 transactions had the same dates and times, even though they were actually received at different times, even days apart. However, years later, doing the same thing didn't happen again.

Year 2018; and you mentioned "years later", so it's also around that time? Lets see,
So the possible versions are Bitcoin Core v0.15.1 (Nov 2017, or older if your haven't updated) to v0.17.1 (Dec 2018).

Unfortunately, it looks different from what I've demonstrated in my screenshots which is reproducible in the latest version of Core (and isn't an issue per se, but a limitation)
And possibly an old but already solved issue since you've mentioned that it never happened again.
Unless, it's not backported to Knots.

[takuma sato]

What did you specify for the required timestamp parameter of importdescriptors? And, yes, did you do a rescan for your wallet from the earliest descriptor or from the Genesis block?

Occording to help description the timestamp parameter specifies the "time from which to start rescanning the blockchain for this descriptor, in UNIX epoch time". With 0 (number zero) the rescan will be done for the entire blockchain, specifying "now" bypasses rescanning and substitutes the current synced blockchain time. (Source: bitcoin-cli help importdescriptors)

But as nc50lc said, once you rescanned the blockchain, existing transactions for the descriptors will have their transaction timestamp set to the block's header timestamp in which the transaction got confirmed.

I have done this for my watch-only wallets of Patoshi blocks, importing about 21,954 combo() descriptors for the attributed public keys, setting labels as mined block number and using different timestamps for the descriptors in two different wallets. After a complete resync the transactions timestamps show no difference between the two wallets.

I have no issues to order the transaction history by confirmation time (sorted by Date column in Core's Transactions display).

Recent transactions actually have a timestamp when the transactions becomes known to the running node's mempool (see last transaction with my local timestamp 11.03.26 05:00 (UTC+1) which actually got confirmed about 20min later in block 9402020).


Here are some older transactions:

listdescriptors false shows the same timestamp value for all addresses except the first one (first as in the order delivered by listdescriptors false output)

All I know is that I labeled the names of the transactions such as:

Testnet test 1
Testnet test 2
... etc

So basically, the wallet shows them in reverse order. If I have for instance 5 transactions:

Testnet test 5
Testnet test 4
... etc until 1

Now if I go to the watch-only wallet, I get this order:

Testnet test 5
" " 3
" " 4
" " 1
" " 2

So clearly it's not in the same order I sent them. Im not sure why it has chosen to show that order.

I am not sure about what you mentioned of rescanning, I will try later.

Now that you mentioned it; this can be a major factor if it's the case of his transactions actually having the same timestamps.
If most of his transactions are included in the same block and the watch-only descriptors are restored to a new setup, it'll have no idea of the mempool-based timestamp that the original wallet knows.
So, the dates (including time) will be the same for those same-block transactions.

This is a issue on Bitcoin Core, it happened to me when I imported addresses with transactions from 2018. 5 or 6 transactions had the same dates and times, even though they were actually received at different times, even days apart. However, years later, doing the same thing didn't happen again.

OP @takuma sato how are you importing addresses and xpubs with "importdescriptors"? Can you paste an example here?

What are you inserting in the "timestamp:" parameter? To avoid confusion, include "timestamp:"now" in the importdescriptors command, wait for confirmation that the descriptors have been imported, and then use the command "rescanblockchain start_height stop_height". I always do it in this order and it has always worked as expected.

These same commands should probably work on Knots.

Relevant topics that may help:

https://bitcointalk.org/index.php?topic=5483885.0

https://bitcointalk.org/index.php?topic=5498210.0

https://developer.bitcoin.org/reference/rpc/rescanblockchain.html

Im reading this again and I don't understand what you mean by ""timestamp:"now" in the importdescriptors command,"

All I know is, like I said above, the order that the transactions show up are different on the watchonly. I did not enter any timestamps manually, I entered the output of "listdescriptors false" with "importdescriptors" and that is the result.

If you mean that I manually put "now" on all "timestamp" fields, that will take forever if you have many transactions. However, I just did that manually with the testnet wallet to see what happens, these are the results:

1) replaced the timestamp: "blockvalue" with "now" on all the fields
2) imported it with "importdescriptors"

Result: this error:

"Error: Error parsing JSON:"

It works if I leave the default timestamp values.

I ran "rescanblockchain", I didn't know what to put as values there, so I rescanned the entire blockchain, on the watch-only wallet to see if maybe it reordered that way, but nothing, the order is the same.

I believe the watch-only wallet has no idea how to order transactions if they are included on the same blockheight (I think "timestamp" value is a blockheight) and then as it sees a bunch of timestamps that were done in a row and included within the same block, it just adds them randomly or I don't know in which order.

[nc50lc]

"Error: Error parsing JSON:"

There must be a missing/excess quotation mark somewhere that broken your command's json object containing the descriptor.
The error doesn't indicate any invalid value but a syntax error.

I doubt that it'll fix your issue though.
That timestamp is just the "birthday" of your descriptor and also used by the command to indicate where/when to start rescanning the blockchain.
It doesn't affect the timestamps of the transactions that will be scanned.

[Cricktor]

When I used "importdescriptors" and I added the label names, there is still a problem, the fact that it all gets dumped as if you received all of these transactions at once makes the transactions not ordered by date. This is quite annoying. You would expect recent transactions to be on top and then as you scroll down you see the older transactions, this is all over the place.

You haven't responded to what nc50lc mentioned in his post after yours.

AFAIK, your transactions should have their dates updated once it synced/rescanned based from the "blocktime" of the block where it belongs.
...
Are the dates in the GUI correct but the arrangement isn't?
If so, simply clicking "Date" will arrange it by date in ascending/descending order.

Or the Dates are actually wrong, with the same timestamps?

OP, have you synced/rescanned your wallet after importing the descriptors with labels?

OP, where do you look? At the transactions list in the GUI or (as you imply how you write it) by dumping the list of transactions via command-line? Can you show your exact command-line you executed to dump your transactions?

Im reading this again and I don't understand what you mean by ""timestamp:"now" in the importdescriptors command,"

You can either provide a correct timestamp for the "birthday" of the descriptor which should be before a first transaction was recorded and normally would trigger an automatic rescan of the blockchain from blocks after that "birthday".

If you provide "timestamp": "now" the birthdate of your descriptor is current blocktime and no automatic rescan will be triggered, because the wallet assumes there are no transactions yet. It's not really a problem as far as I see it.

If there is a transaction history for that imported descriptor, you can simply do a rescan (use bitcoin-cli rescanblockchain start_height stop_height, see help page for more details) from an appropriate starting point which ensures the rescan will find all descriptor's transaction history. After this rescan your transactions will have timestamps of the blocktime of the block where they were confirmed.

At the moment I've a fealing you may have skipped the rescan, haven't you?

If you mean that I manually put "now" on all "timestamp" fields, that will take forever if you have many transactions.

You don't have to do that manually, scripting is a thing...

I for sure have not assembled and imported 21,954 or so descriptors for my Patoshi blocks watch-only wallet manually. Some bash, jq and other tools' magic was used.

[nc50lc]

At the moment I've a fealing you may have skipped the rescan, haven't you?

Since the wallet in question is a watch-only wallet imported with (public) descriptors from his offline air-gap wallet;
The transactions wouldn't have showed up unless his online node already finished rescanning the blockchain.

Since it does, it's safe to assume that it's already done rescanning
but the timestamps definitely wont match with the original if most of the transactions were broadcasted then confirmed with a huge date/time gap.

[takuma sato]

When I used "importdescriptors" and I added the label names, there is still a problem, the fact that it all gets dumped as if you received all of these transactions at once makes the transactions not ordered by date. This is quite annoying. You would expect recent transactions to be on top and then as you scroll down you see the older transactions, this is all over the place.

You haven't responded to what nc50lc mentioned in his post after yours.

AFAIK, your transactions should have their dates updated once it synced/rescanned based from the "blocktime" of the block where it belongs.
...
Are the dates in the GUI correct but the arrangement isn't?
If so, simply clicking "Date" will arrange it by date in ascending/descending order.

Or the Dates are actually wrong, with the same timestamps?

OP, have you synced/rescanned your wallet after importing the descriptors with labels?

OP, where do you look? At the transactions list in the GUI or (as you imply how you write it) by dumping the list of transactions via command-line? Can you show your exact command-line you executed to dump your transactions?

Im reading this again and I don't understand what you mean by ""timestamp:"now" in the importdescriptors command,"

You can either provide a correct timestamp for the "birthday" of the descriptor which should be before a first transaction was recorded and normally would trigger an automatic rescan of the blockchain from blocks after that "birthday".

If you provide "timestamp": "now" the birthdate of your descriptor is current blocktime and no automatic rescan will be triggered, because the wallet assumes there are no transactions yet. It's not really a problem as far as I see it.

If there is a transaction history for that imported descriptor, you can simply do a rescan (use bitcoin-cli rescanblockchain start_height stop_height, see help page for more details) from an appropriate starting point which ensures the rescan will find all descriptor's transaction history. After this rescan your transactions will have timestamps of the blocktime of the block where they were confirmed.

At the moment I've a fealing you may have skipped the rescan, haven't you?

If you mean that I manually put "now" on all "timestamp" fields, that will take forever if you have many transactions.

You don't have to do that manually, scripting is a thing...

I for sure have not assembled and imported 21,954 or so descriptors for my Patoshi blocks watch-only wallet manually. Some bash, jq and other tools' magic was used.

Like I said, im just entering the result of "listdescriptors false" and importing them with "importdescriptors" with whatever given "timestamp" values. After rescanning, it's the same, the transactions are not in the correct order. I think this is a limitation of watch-only wallet, it doesn't know how to order transactions properly.

Just test it yourself. Get a testnet wallet, get some coins and order each transaction with a label ("tx 1, tx 2, tx 3, tx 4, tx 5").

Then do "listdescriptors false" and paste it into a new watch-only wallet with "importdescriptors" and see if you can make the transactions show up in order.

I believe it doesn't know how to order them if they are all done within the same "timestamp" value.