-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[PROPOSAL] Add advanced command to monero-wallet-cli: scan_block #7291
Comments
I think it might be useful, and should be a fairly simple shell over the mid-level wallet2 functions. |
In fact, an ordered list of txids is probably best. A user will know these, but not necessarily the block heights they got mined, and this'll be even faster. |
Hi @moneromooo-monero , I couldn't find any wallet2.h exported API to use from simplewallet.c that would allow to retrieve any tx in the blockchain by hash, or any block by hash or height. wallet2 exposes the high-level functionality of a wallet, so implementing this would require to get into wallet2. Apparently wallet2::refresh(), called on init, would do a fast scan of the blockchain and starting with the restore height it would iterate over the outputs of transactions in the blocks to detect and update the balance of the wallet (process_parsed_blocks -> process_new_blockchain_entry -> process_new_transaction -> scan_output) I think this information is cached so subsequent refresh() will be very fast. These operations are not accesible by simplewallet, all simplewallet can do is call refresh(). My idea for implementing the feature is to export a new wallet2 API to simplewallet that internally implements the operation of |
The wallet does not deal with the blockchain. The daemon does. You ask the daemon for the data you need. |
And yes, your last paragraph is what you should do. |
In commit f23dbe24af0c504297939f35e478f4cf63412859 of my fork I implemented the command scan_tx. Please review my code when you can. I have a couple of issue I'd like to raise:
After resolving this command, I'd like to add a similar command for block heights instead of txids. My initial idea was to write on paper some information for fast recovery of a paper wallet, and tx hashes seem very long. Have a nice day. |
@hMihaiDavid please open a PR, it will result in more people seeing it |
this would be great. seems similar to my idea of a "fast forward". The user mostly knows when they receive transactions. This would be awesome. |
I propose to add a command to monero-wallet-cli that allows an advanced user to specify a list of block heights that the client will scan for outputs.
Motivation
If an advanced user doesn't want to wait for scanning the whole blockchain for outputs they own (when, for example, restoring the wallet from a mnemonic seed), currently they can specify the block height to start the scanning from (by using the '--restore-height' or the interactive prompt during initialization). However, this can still be a lengthy process since the user would have to specify, ideally, the block height of the first transaction directed to them. This can still take a long time if restoring a paper wallet first used several years ago (all blocks from that height to the latest one will be scanned).
If an advanced user can omit the initial scanning, they can specify the list of blocks with all the known outputs by hand using the proposed command. These could be stored along the seed in a paper wallet. I am not aware for a current mechanism that implements this feature (either for block heights or tx hashes).
The user could omit the initial scanning by just specifying as restore height the current block or current date, which would take very little time to initialize.
Discussion
I am aware that starting a full node for the first time will still need to linearly traverse the whole blockchain. However, this command would help the restore time for paper wallets using a remote node already synced, either a trusted or untrusted node. There may be privacy concerns by leaking block ids of user's outputs to untrusted nodes which may be interesting to discuss.
Please let me know if this is already implemented or if the devs consider this as a very unnecessary feature that would not be merged.
If it is deemed to be somewhat worthwhile I would like to start developing this feature to alleviate dev time.
Have a nice day.
The text was updated successfully, but these errors were encountered: