wallet: expose next unused address

[jharveyb]

I had an issue funding a node due to the existing get_new_address behavior:

• Call get_new_address() on a timer / loop when reporting the status of the node.
• After some # of calls, send funds to the returned address.
• On-chain balance isn't detected by the node.

IIUC, this is due to the gap limit here:

ldk-node/src/chain/electrum.rs

Line 471 in 7ad0d63

BDK_CLIENT_STOP_GAP,

After manually recovering the funds with Sparrow and sending them to the first unused address, funds were picked up successfully.

The next_unused_address behavior seems much less surprising so I've added it here + used it successfully with my nodes. Even if it's not recommended in the doc examples for creating a channel, a doc note similar to what's on the bdk_wallet page may be useful.

[ldk-reviews-bot]

👋 Hi! Please choose at least one reviewer by assigning them on the right bar.
If no reviewers are assigned within 10 minutes, I'll automatically assign one.
Once the first reviewer has submitted a review, a second will be assigned if required.

[tnull]

Call get_new_address() on a timer / loop when reporting the status of the node.

Yes, you should really not do this as it will slow down syncing over time. I am however a bit dubious why you weren't seeing the funds, the BDK_CLIENT_STOP_GAP limit you cited is really only used for the initial full-scan sync. Every sync after that will look up transactions for the generated SPKs, which is exactly why spamming address generation will slow down syncing right now.

[tnull]

Exposing this API will be super confusing, IMO, as it will be entirely unclear which variant to use. And we intentionally only expose APIs that advance the descriptor index to avoid address reuse.

[jharveyb]

Call get_new_address() on a timer / loop when reporting the status of the node.

Yes, you should really not do this as it will slow down syncing over time. I am however a bit dubious why you weren't seeing the funds, the BDK_CLIENT_STOP_GAP limit you cited is really only used for the initial full-scan sync. Every sync after that will look up transactions for the generated SPKs, which is exactly why spamming address generation will slow down syncing right now.

Ok - this was using ldk-node v0.2.0, and initially the esplora backend but I switched to electrum before also adding this patch. Maybe sync was just not making progress overall, though my read was that the sync should eventually complete, even with many addresses generated on a slow electrs backend. I can try and validate this behavior though.