New RPC command for Bitcoin Core: next_index

[Forsyth Jones]

Currently in Bitcoin Core, we can import descriptors and define from which index the wallet will show us a new address with "getnewaddress" or in the receiving tab, ex:

Code:

importdescriptors '[{"desc":"wpkh(wif_xpriv/0/*)#00000000","timestamp":"now","next_index": 9,"active":true}]'

Currently next_index is used as an argument, wouldn't it be better to also offer a new RPC Command for this, as with keypoolrefill?

What is the motivation for this request?

Whenever we generate a new address, Bitcoin Core will show that address only once and then it's saved in the address list, this is done for privacy so that users don't need to repeat addresses

However, there is a problem with this, if the user clicked on get new address 100 or 1000x times, the next index of their wallet will be, ex: 1001, the wallet may not immediately see the funds financed at the address, causing panic. Then he would have to call the newkeypool or keypoolrefill command.

Or better yet, having Bitcoin Core only generate new addresses when it identifies that the previous address has been used, this would avoid this problem of skipping addresses as well. I think that in my opinion, this type of solution makes our financial control easier.

Does this bother anyone else?

Or add an RPC command to the options window so that Bitcoin Core generates new addresses whenever we request it or only generates new addresses as they are used, as happens with most wallets.

[1715275896]

1715275896

[1715275896]

1715275896

[1715275896]

1715275896

[1715275896]

1715275896

[achow101]

I don't understand at all what you are asking for.

Currently next_index is used as an argument, wouldn't it be better to also offer a new RPC Command for this, as with keypoolrefill?

You can still use keypoolrefill.

However, there is a problem with this, if the user clicked on get new address 100 or 1000x times, the next index of their wallet will be, ex: 1001, the wallet may not immediately see the funds financed at the address, causing panic. Then he would have to call the newkeypool or keypoolrefill command.

Why would they have to? The wallet updates next_index every time a new address is produced to the user, so they never need to use newkeypool or keypoolrefil. If the descriptor is being imported, the point of having next_index in importdescriptors is to set it from the start. There's also the range option to set the initial keypool size.

Or better yet, having Bitcoin Core only generate new addresses when it identifies that the previous address has been used, this would avoid this problem of skipping addresses as well. I think that in my opinion, this type of solution makes our financial control easier.

That doesn't work. There are a number of common cases where you may request and give out an address, but not expect payment to that address before the next address needs to be given out.

A simple example is a donation address. You may get an address to use for donations and put that up somewhere, That address may not get any payments for a very long time. In that time, someone may want to pay you, and you would want to get a new address for them.

Or add an RPC command to the options window so that Bitcoin Core generates new addresses whenever we request it or only generates new addresses as they are used, as happens with most wallets.

What wallet does that? I don't think any wallet actually generates addresses on the fly, rather they all do something like Core with a pregenerated lookahead. It's usually called the gap limit. Without such a lookahead, rescans are likely to fail unless you can be sure that no addresses went unused. Even in that case though, reorgs can cause an address to become "unused", so you'd still need some gap limit.