wallet: one quiet batch is not far enough to stop a restore (#115)

Restoring from a phrase gave up after the first batch of a hundred addresses that turned up nothing, and the wallet digs a wider gap than that by itself: a restore leaves nHDNext at the depth it scanned, the key pool derives KEYPOOL_SIZE more, and change takes the index after those. Measured on a real wallet with real coin -- restore, spend once, and the outputs land at indices 201 and 302; restoring again found only the first transaction and reported the spend as gone. With -restoredepth=500 the same wallet found both, which is what said this was reach and not loss.

Three quiet batches instead of one: 2 transaction(s) across 601 derived addresses on the same wallet, chain and phrase.

Worse after #109, not before it: change used to return to an input's key, a low index the scan had already passed. Making change recoverable moved it out to where the scan stopped looking.

Does not fix the gap growing with every restore -- pulling nHDNext back to the last used index is the structural answer and needs its own testing.

0 files changed, 0 insertions, 0 deletions