mirror of
https://github.com/monero-project/monero-docs.git
synced 2024-12-22 19:49:22 +00:00
WiP on monero-wallet-cli commands
This commit is contained in:
parent
e95e8ece4a
commit
a4840656fc
2 changed files with 210 additions and 3 deletions
|
@ -171,9 +171,143 @@ Log files are created in the same directory as `monero-wallet-cli` binary. Use `
|
|||
|
||||
## Commands
|
||||
|
||||
Usually you will use commands interactively in the `monero-wallet-cli` prompt.
|
||||
Commands are used interactively in the `monero-wallet-cli` prompt.
|
||||
|
||||
You can also run a one-off command by providing it as a commandline parameter.
|
||||
This is probably rarely useful though. For any automation use `monero-wallet-rpc` instead.
|
||||
This is rarely useful though. For automation prefer `monero-wallet-rpc`.
|
||||
|
||||
TODO: document commands.
|
||||
The CLI wallet has **built-in help for individual commands** - we will not attempt to reproduce that.
|
||||
Instead we focus on grouping commands so you can quickly find what you are looking for.
|
||||
Use `help command_name` to learn more.
|
||||
|
||||
### Help and version
|
||||
|
||||
`help` - list all commands
|
||||
|
||||
`help command_name` - show help for individual command
|
||||
|
||||
`version` - show version of the monero-wallet-cli binary
|
||||
|
||||
### Balance
|
||||
|
||||
`account` - total balance; list accounts with respective balances
|
||||
|
||||
`balance detail` - within the current account, list addresses with respective balances
|
||||
|
||||
### Manage accounts
|
||||
|
||||
`account`
|
||||
|
||||
`account new`
|
||||
|
||||
`account switch`
|
||||
|
||||
`account label`
|
||||
|
||||
### Manage addresses
|
||||
|
||||
`address all`
|
||||
|
||||
`address new`
|
||||
|
||||
`address label`
|
||||
|
||||
### Network status
|
||||
|
||||
`status` - show if synced up to the blockchain height
|
||||
|
||||
`fee` - show current fee-per-byte and full node's mempool (the backlog of transactions depending on the priority)
|
||||
|
||||
`wallet_info` - show wallet file path, standard address, type and network
|
||||
|
||||
### Secret mnemonic seed
|
||||
|
||||
`seed` - show raw mnemonic seed
|
||||
|
||||
`encrypted_seed` - create mnemonic seed encrypted with the passphrase; you will need to remember or store the passphrase separately; restoring will not be possible without the passphrase
|
||||
|
||||
### Secret keys
|
||||
|
||||
`spendkey` - show secret spend key and public spend key
|
||||
|
||||
`viewkey` - show secret view key and public view key
|
||||
|
||||
### Proofs
|
||||
|
||||
`get_reserve_proof` -> `check_reserve_proof` - prove the balance
|
||||
|
||||
`get_spend_proof` -> `check_spend_proof` - prove you made the payment
|
||||
|
||||
`sign <file>` -> `verify <filename> <address> <signature>` - prove ownership of the address; allows to verify the file was signed by the owner of specific Monero address
|
||||
|
||||
`get_tx_proof` -> `check_tx_proof`
|
||||
|
||||
### Multisig
|
||||
|
||||
#### Setup
|
||||
|
||||
`prepare_multisig`
|
||||
|
||||
`make_multisig`
|
||||
|
||||
`finalize_multisig`
|
||||
|
||||
#### Update
|
||||
|
||||
`export_multisig_info`
|
||||
|
||||
`import_multisig_info`
|
||||
|
||||
#### Other
|
||||
|
||||
`submit_multisig`
|
||||
|
||||
`exchange_multisig_keys`
|
||||
|
||||
`export_raw_multisig_tx`
|
||||
|
||||
### Tx private key
|
||||
|
||||
These allow to learn and verify transaction's private key `r`.
|
||||
This was useful to create a [proof of payment](https://www.getmonero.org/resources/user-guides/prove-payment.html)
|
||||
but got superseded by `get_spend_proof`.
|
||||
|
||||
`get_tx_key <txid>`
|
||||
|
||||
`check_tx_key <txid> <txkey> <address>`
|
||||
|
||||
`set_tx_key <txid> <tx_key>`
|
||||
|
||||
### Advanced
|
||||
|
||||
`unspent_outputs` - show a list of, and a histogram of unspent outputs (indivisible pieces of your total balance)
|
||||
|
||||
`export_key_images <file>` -> `import_key_images <file>` - used to inform the view-only wallet about outgoing transactions so it can calculate the real balance; normally view-only wallets only learn about incoming transactions, not outgoing
|
||||
|
||||
`export_outputs <file>` - export a set of outputs owned by this wallet to a `<file>`
|
||||
|
||||
### Mining
|
||||
|
||||
`start_mining`
|
||||
|
||||
`stop_mining`
|
||||
|
||||
### Donate
|
||||
|
||||
`donate <amount>` - donate `<amount> to development team.
|
||||
|
||||
### Non essential or legacy
|
||||
|
||||
`address_book [(add ((<address> [pid <id>])|<integrated address>) [<description possibly with whitespaces>])|(delete <index>)]`
|
||||
|
||||
`set_description [free text note]` -> `get_description` - manage convenience description of the wallet (the information is local)
|
||||
|
||||
`save` - this now happens automatically
|
||||
|
||||
`save_bc` - this now happens automatically
|
||||
|
||||
`bc_height` - show blockchain height (superseded with `status`)
|
||||
|
||||
`sweep_unmixable` - only relevant for very old wallets (<= 2016); send all unmixable outputs to yourself with ring_size 10
|
||||
|
||||
TODO: document remaining commands
|
||||
|
|
73
docs/todo/notify-changes-2019-03-09
Normal file
73
docs/todo/notify-changes-2019-03-09
Normal file
|
@ -0,0 +1,73 @@
|
|||
https://paste.debian.net/hidden/0d0d3694
|
||||
|
||||
How to use notifiers
|
||||
|
||||
monerod can call external programs upon certain events. These can be set with the following options:
|
||||
|
||||
--block-notify SPEC
|
||||
call a program when a new block is added to the chain
|
||||
|
||||
--block-rate-notify SPEC
|
||||
call a program when the number of blocks received in the recent past deviates significantly from the expectation
|
||||
|
||||
--reorg-notify SPEC
|
||||
call a program when a reorganization happens (ie, at least one block is removed from the top of the blockchain)
|
||||
|
||||
The wallets have another:
|
||||
|
||||
--tx-notify SPEC
|
||||
call a program whenever the wallet receives or spends monero
|
||||
|
||||
|
||||
For all these, the SPEC argument is a string representing a command line. It includes the fully qualified path
|
||||
to the program that should be run, along with any arguments. Each of the events above will have predefined tags
|
||||
which will be replaced by relevant information in the SPEC string. The SPEC string does not have to contain
|
||||
all of those, and some of those may be used more than once.
|
||||
|
||||
--block-notify
|
||||
%s: the block hash
|
||||
|
||||
--reorg-notify
|
||||
%s: the height at which the split occurs
|
||||
%h: the height of the new blockchain
|
||||
%n: the number of blocks being added
|
||||
|
||||
--block-rate-notify
|
||||
%t: the number of minutes in the observation window
|
||||
%b: the number of blocks observed in that window
|
||||
%e: the ideal number of blocks expected in that window
|
||||
|
||||
--tx-notify:
|
||||
%s: the transaction hash
|
||||
|
||||
|
||||
For example, if using "--reorg-notify /usr/local/bin/monero-event reorg %n", then a reorg of 2 blocks will
|
||||
call: /usr/local/bin/monero-event reorg 2
|
||||
|
||||
Note that the SPEC string is not interpreted by the shell, so you should include the full path to the binary,
|
||||
and may not use shell escapes (including quoting). Everything is passed as is.
|
||||
|
||||
Some of these may be used to partially protect against some 51% attacks, should they happen, by using
|
||||
both --reorg-notify and --block-rate-notify:
|
||||
|
||||
--block-rate-notify will let you know if the network hash rate drops by a lot. This may be indicative of
|
||||
a large section of the network miners moving off to mine a private chain, to be later released to the
|
||||
network. Note that if this event triggers, it is not incontrovertible proof that this is happening. It
|
||||
might just be chance. The longer the window (the %t parameter), and the larger the distance between
|
||||
actual and expected number of blocks, the likelier it is that the hash rate is fluctuating, and the
|
||||
higher the fluctuations.
|
||||
|
||||
--reorg-notify will let you know when a block is removed from the chain to be replaced by other blocks.
|
||||
This happens when a 51% attack occurs, but small reorgs also happen in the normal course of things. The
|
||||
%d parameter will be set to the number of blocks discarded from the old chain (so if this is higher than
|
||||
the number of confirmations you wait to act upon an incoming payment, that payment might have been
|
||||
cancelled). The %n parameter wil be set to the number of blocks in the new chain (so if this is higher
|
||||
than the number of confirmations you wait to act upon an incoming payment, any incoming payment in the
|
||||
first block will be automatically acted upon by your platform).
|
||||
|
||||
Using both of these, you can use --block-rate-notify to automatically increase the number of
|
||||
confirmations to accept payments when the actual number of blocks is much lower than the expected number
|
||||
of blocks, working on the temporary assumption that a reorg might happen later, and reset the number
|
||||
of confirmations after some time if no reorg has happened. If the --block-rate-notify happens repeatedly,
|
||||
it is recommended that the timer to reset confirmations to their default value be reset to its original
|
||||
value.
|
Loading…
Reference in a new issue