About getnewaddress RPC API

[~DefaultTrust]

Hi

I am studying the work of the RPC API of the old bitcoin fork (dogecoin).

It seems that the getnewaddress function generates not one, but a whole pool of addresses there. So that the next call getnewaddress does not generating, but simply gets ready-made addresses from the pool.

That is, something like this:

the first call getnewaddress generates an array [addr1, addr2, ... addrN] and outputs "addr1"
second call to getnewaddress yields "addr2"

***

The N-th call gives "addrN"

The N + 1 - th call again generates [addrN1, addrN2, ... addrNN] and outputs "addrN1"

and so on...

I wonder if I understand correctly how getnewaddress works? Has anything changed in the newest versions of Bitcoin RPC?

[1715655176]

1715655176

[HCP]

It's to do with the "keypool"... the system used to maintain 100 keys in a "pool", modern versions of Bitcoin Core have a pool of 1000... so it does the generation all at once and fills the pool up. Once it runs out of available keys in the pool, it then regenerates another 1000 (or 100 for the older versions etc).

For older (non-hd) wallets... it's important to make regular backups, otherwise, you might be using addresses/keys that aren't actually backed up! (This is a non-issue for HD wallets).

[~DefaultTrust]

It's to do with the "keypool"... the system used to maintain 100 keys in a "pool", modern versions of Bitcoin Core have a pool of 1000... so it does the generation all at once and fills the pool up. Once it runs out of available keys in the pool, it then regenerates another 1000 (or 100 for the older versions etc).

For older (non-hd) wallets... it's important to make regular backups, otherwise, you might be using addresses/keys that aren't actually backed up! (This is a non-issue for HD wallets).

Clear. Thanks.

I noticed another interesting thing. It looks like addresses from the pool are being used for change. I'm not sure about this. But it seems to me that sometimes  getnewaddress does output with address that already have balance (comes from change)

Like this:

the first call getnewaddress generates an array [addr1, addr2, ... addrN] and outputs "addr1"

If I call sendmany then one of [addr2, ... addrN] is used for change ("addrK" then got a balance)!

One of the subsequent calls getnewaddress does output "addrK".

I'm pretty sure this is exactly how it works in Dogecoin. Does newest Bitcoin RPC work the same way?

[nc50lc]

It's to do with the "keypool"... the system used to maintain 100 keys in a "pool", modern versions of Bitcoin Core have a pool of 1000... -snip-

I'm pretty sure this is exactly how it works in Dogecoin. Does newest Bitcoin RPC work the same way?

In Bitcoin core whether it's RPC or the GUI, the change will be sent to a "change address" derived from a different hdkeypath m/0'/1'/.
And those wont be used as "receiving" addresses nor return in getnewaddress command.

In addition to HCP's reply, just like "receiving address", Bitcoin core has a reserve keypool for the change addresses that consist of 1000 key pairs.
So there's a total of 2000 reserved keys.

[~DefaultTrust]

Thank you, guys