Maybe this is a feature request?

camosoul

Grizzled Member
Sep 19, 2014
2,261
1,130
1,183
I know how to
Code:
~/.dashcore/dash-cli getnewaddress
It stands to reason that, since DASH supports HD Wallets, there would be a
Code:
~/.dashcore/dash-cli getfirstunusedhdaddress
Instead of doing it the hard way... Clearly the wallet must already be doing it the hard way... Why is there no easy way to grab this info, which the daemon clearly knows? Or am I just not seeing it? I RTFMed quite bit and never saw it...
 
  • Like
Reactions: AgnewPickens

AgnewPickens

Moderator
Moderator
Mar 11, 2017
372
127
113
57
I'm not certain the coding on HD wallets is standardized enough to make a general command to an hd firstunusedaddress
 

camosoul

Grizzled Member
Sep 19, 2014
2,261
1,130
1,183
I guess I'll do it the hard way...

Grab and check all addresses in the wallet for presence on blockchain and memory pool (pretty sure this is already done to calculate the balance(s)).

All which return null will be saved from the purge. (boolean opposite of what is done to calculate balance(s)).

This list will be run through Some Kind of [age] Test(tm)(c). Can't test block height because the whole point of finding unused addresses is that they aren't used and won't be in the blockchain, duh... So, I have yet to devise this test.

If none return null, and none survive the purge; fallback to getnewaddress...

Seems this logic could be baked-in, and wouldn't care about "standardization" of how the chain is chased...

Grab everything, purge used, sort by age, present oldest first by similar method of getnewaddress...

This doesn't account for other wallets going further out the HD chain on the same HD seed.

But, for my application, it doesn't have to.

Which is likely why nothing has been implemented; to allow flexibility.

But it creates a problem. Given the high-speed nature of IS and the memory pool, and the large amount of computational power this requires; the results could go stale almost immediately. An address could end up being used in the meantime. Which is why it'd be much better if it were baked-in. The dashd is already keeping a proper inventory and is much better suited to keeping track of this. Especially on low-clock embedded/IoT systems...

Something that stops after finding 10 consecutive unused addresses is, IIRC, how the standard is supposed to work. The ability to override that 10 with an integer of one's choosing via CLI option or an option in the already-exists config file, dash.conf, would solve all concerns. Same flexibility, but it's baked into the API, no worries about stale data being used to issue an address, and the same work doesn't have to be done twice on the same CPU. Or, repeatedly, to check for staleness... ...at least thats how it looks from where I'm standing. I'm not aware of any other considerations being needed to facilitate it.
 
Last edited:
  • Like
Reactions: AgnewPickens