Address list

[darosior]

It's useful to be able to verify a deposit address generated by your cosigner when using a multisig.

[darosior]

While the OP was assuming we'd derive it directly from the descriptor, it could also be implemented as an RPC. Adding the daemon label.

[pythcoiner]

I'm interested in working on this, what about an rpc method getaddresses that returns something like:

{
  "result": {
    "addresses": [
      {"index": 0, "receive": "bc1....", "change": "bc1..."},
      {"index": 1, "receive": "bc1....", "change": "bc1..."},
      {"index": 2, "receive": "bc1....", "change": "bc1..."},
      {"index": 3, "receive": "bc1....", "change": "bc1..."}
    ]
  }
}

[darosior]

I guess the complexity stems from deciding what addresses to return. Should we give a range? A number of addresses past the last one used? A number of addresses preceding the last one used?
I think a safe bet that could both be used from the command line or by the GUI would be to take two (mandatory) parameters:

• The start_index, the index at which to start the listing
• The count, how many addresses to include in the list

The JSON you suggest to be returned makes sense to me. Let's call the command listaddresses though. That would be:

listaddresses start_index count
{
  "result": {
    "addresses": [
      {"index": start_index + 0, "receive": "bc1....", "change": "bc1..."},
      {"index": start_index + 1, "receive": "bc1....", "change": "bc1..."},
      {"index": start_index + 2, "receive": "bc1....", "change": "bc1..."},
      {"index": start_index + 3, "receive": "bc1....", "change": "bc1..."}
    ]
  }
}

What do you think?

---

Besides i think it could be useful to return the derivation index in the result of getnewaddress.

[pythcoiner]

looks good to me

what about if user just want to get all generated addresses, he just passes startindex=0 and count=0, then we replace count=<actual_db_index> ?

[darosior]

Hmm it's more complicated to accomodate a usecase related to the addresses which have already been generated. Hence my suggestion above to add the derivation index to getnewaddress.

Also i'm not sure it makes a lot of sense. What usecase do you have in mind? This is just an ever-growing list which could be pretty bulky to return at once.

One possibility would be to make the two arguments, with default value 0 for start_index and default value max(last_change_index, last_receive_index) - start_index for count. Seems a bit intricate to sanitize but hey could be done if that's of any use.

[pythcoiner]

Usecase i have in mind is to display all addresses generated in the same way it's done in Sparrow wallet.

what i don't like with the mandatory value of count is we need to know that value but we don't have method to only get it, we can call getnewaddress but it will also increment index...

One possibility would be to make the two arguments, with default value 0 for start_index and default value max(last_change_index, last_receive_index) - start_index for count. Seems a bit intricate to sanitize but hey could be done if that's of any use.

agree with these default values

if we want to avoid huge amount of addresses to be returned by a rpc call, we can maybe define a max for count (100?), then the user can loop requesting until the returned length < 100?

[darosior]

That's where i don't want to get. :) We've got indexes already this should be all the pagination we need. EDIT:

Usecase i have in mind is to display all addresses generated in the same way it's done in Sparrow wallet.

I have no idea what Sparrow does, would be interested to learn more about the usecase for listing *all* addresses that have *ever* been generated is.

…

------- Original Message -------

On Saturday, September 9th, 2023 at 5:11 PM, pythcoiner ***@***.***> wrote: Usecase i have in mind is to display all addresses generated in the same way it's done in Sparrow wallet. what i don't like with the mandatory value of count is we need to know that value but we don't have method to only get it, we can call getnewaddress but it will also increment index... > One possibility would be to make the two arguments, with default value 0 for start_index and default value max(last_change_index, last_receive_index) - start_index for count. Seems a bit intricate to sanitize but hey could be done if that's of any use. agree with these default values if we want to avoid huge amount of addresses to be returned by a rpc call, we can maybe define a max for count (100?), then the user can loop requesting until the returned length < 100? — Reply to this email directly, [view it on GitHub](#681 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AFLK3FZQVP54SOVGONTSP7TXZSBLFANCNFSM6AAAAAA4HMDTRU). You are receiving this because you authored the thread.Message ID: ***@***.***>

[pythcoiner]

The daemon have a track of indexes, but something external running only a lianad service and connecting it through rpc cannot retrieve these indexes, should we also implement a getaddressesindexes method?

[darosior]

What's wrong with my suggested command and default values from above? ------- Original Message -------

…

On Saturday, September 9th, 2023 at 5:23 PM, pythcoiner ***@***.***> wrote: The daemon have a track of indexes, but something external running only a lianad service and connecting it through rpc cannot retrieve these indexes, should we also implement a getaddressesindexes method? — Reply to this email directly, [view it on GitHub](#681 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AFLK3F76VYMJJIRCZY4B34DXZSCX5ANCNFSM6AAAAAA4HMDTRU). You are receiving this because you authored the thread.Message ID: ***@***.***>

[pythcoiner]

What's wrong with my suggested command and default values from above? ------- Original Message -------
…
On Saturday, September 9th, 2023 at 5:23 PM, pythcoiner @.> wrote: The daemon have a track of indexes, but something external running only a lianad service and connecting it through rpc cannot retrieve these indexes, should we also implement a getaddressesindexes method? — Reply to this email directly, [view it on GitHub](#681 (comment)), or unsubscribe. You are receiving this because you authored the thread.Message ID: @.>

nothing wrong, just in case you prefer to stick to initial idea of mandatory count without default ;)

[pythcoiner]

I have no idea what Sparrow does, would be interested to learn more about the usecase for listing all addresses that have ever been generated is.

it just display a table of all adresses from index 0 to (max_index_received +20), allowing you to check:

• if still a coin to this adress
• if never received a coin
• if have been reused (display history)
• let you add/edit label

[pythcoiner]

Besides i think it could be useful to return the derivation index in the result of getnewaddress.

should I implement this in #709 or in a separated PR?

[darosior]

Now it was implemented on the daemon side, i'm going to close this in favour of #809 for the GUI integration.