Skip to content

Conversation

@aszepieniec
Copy link
Contributor

Adds two CLI commands, the second one with RPC and application support:

  1. neptune-cli index-of <address> Computes the derivation index from the given address.
  2. neptune-cli rescan --block 1337 --address <address> Re-scans block 1337 to look for output UTXOs that can be spent by the secret spending key associated with the given address, and if any are found, adds them to the wallet database and adds their randomness to incoming_randomness.dat.

Add a CLI command to neptune-cli for obtaining the derivation index from a given
address. Usage:

 > neptune-cli index-of <full-address>

Example output:

```
key type: Generation
index: 97
```
Add a CLI command, along with an RPC function and application support, for
re-scanning a particular block (identified by `BlockSelector`) for UTXOs bound
a given address. The wallet database will be appraised of any new UTXOs found,
and `incoming_randomness.dat` will get new entries for them.

Usage:

 > neptune-cli rescan --block 1337 --address <address>

Also!: deprecate `GenerationReceivingAddress::to_bech32m_abbreviated`. Reason:
we already have `ReceivingAddress::to_display_bech32m_abbreviated`, which works
for both `GenerationReceivingAddress` and `SymmetricKey` and it disagrees with
this method.
@dan-da
Copy link
Collaborator

dan-da commented Nov 24, 2025

2. neptune-cli rescan --block 1337 --address

Perhaps address should be optional, and if no address is specified then the block is scanned for all known wallet keys.

(Though that could be further constrained by an optional --key-types argument that defaults to all.)

Copy link
Member

@Sword-Smith Sword-Smith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks OK to me. Let's see if we can't add a test or two though. Maybe one where block_n has already been processed, and then scan_for_utxos_announced_to_given_key is called, and you verify that nothing is returned? Such that you ensure that this recovery does not create duplicates.

@aszepieniec
Copy link
Contributor Author

@Sword-Smith: which parts, if any,of this PR are obviated by the new branch for faster wallet updates? If all, then let's close the PR without merging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants