diff --git a/docs/interacting/monero-wallet-cli-reference.md b/docs/interacting/monero-wallet-cli-reference.md index d4aa26a..b57e80a 100644 --- a/docs/interacting/monero-wallet-cli-reference.md +++ b/docs/interacting/monero-wallet-cli-reference.md @@ -63,7 +63,7 @@ In a separate terminal window, run the wallet: | Option | Description |---------------------|-------------------------------------------------------------------------------------------------------------------------------------- | `--help` | Enlist available options. -| `--version` | Show `monero-wallet-cli` version to stdout. Example:
`Monero 'Beryllium Bullet' (v0.13.0.4-release)` +| `--version` | Show `monero-wallet-cli` version to stdout. Example:
`Monero 'Boron Butterfly' (v0.14.0.0-release)` #### Pick network diff --git a/docs/interacting/monerod-reference.md b/docs/interacting/monerod-reference.md index 9836fd1..9b71fec 100644 --- a/docs/interacting/monerod-reference.md +++ b/docs/interacting/monerod-reference.md @@ -63,7 +63,7 @@ The following groups are only to make reference easier to follow. The daemon its | Option | Description |---------------------|-------------------------------------------------------------------------------------------------------------------------------------- | `--help` | Enlist available options. -| `--version` | Show `monerod` version to stdout. Example:
`Monero 'Beryllium Bullet' (v0.13.0.4-release)` +| `--version` | Show `monerod` version to stdout. Example:
`Monero 'Boron Butterfly' (v0.14.0.0-release)` | `--os-version` | Show build timestamp and target operating system. Example output:
`OS: Linux #1 SMP PREEMPT Fri Aug 24 12:48:58 UTC 2018 4.18.5-arch1-1-ARCH`. #### Pick network @@ -150,9 +150,13 @@ The following options define how the API behaves. #### Accepting Monero -| Option | Description -|------------------|------------------------------------------------------------------------------------------------ -| `--block-notify` | Run a program for each new block. The argument must be a **full path**. If the argument contains `%s` it will be replaced by the block hash. Example:
`./monerod --block-notify="/usr/bin/echo %s"`

Couple of notes:
1) Block notifications are good for immediate reaction. However, you should always assume you will miss some block notifications and you should independently poll the API to cover this up.
2) Mind blockchain reorganizations. Block notifications can revert to same and past heights. This actually happens pretty often.
3) See also `--tx-notify` option of `monero-wallet-rpc` daemon [here](https://github.com/monero-project/monero/pull/4333). +These are network notifications offered by `monerod`. There are also wallet notifications like `--tx-notify` offered by `monero-wallet-rpc` [here](https://github.com/monero-project/monero/pull/4333). + +| Option | Description +|------------------------------|------------------------------------------------------------------------------------------------ +| `--block-notify ` | Run a program for each new block. The `` must be a **full path**. If the `` contains `%s` it will be replaced by the block hash. Example:
`./monerod --block-notify="/usr/bin/echo %s"`

Block notifications are good for immediate reaction. However, you should always assume you will miss some block notifications and you should independently poll the API to cover this up.

Mind blockchain reorganizations. Block notifications can revert to same and past heights. Small reorganizations are natural and happen every day. +| `--block-rate-notify ` | Run a program when the number of blocks received in the recent past deviates significantly from the expectation. The `` must be a **full path**. The ` can contain any of `%t`, `%b`, `%e` symbols to interpolate:

`%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

The option 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 more indicative it is of a possible chain reorg double-spend attack being prepared.

**Recommendation:** unless you run economically significant Monero exchange or operation, do **not** act on this data. It is hard to calibrate and easy to misinterpret. If this is a real attack, it will target high-liquidity entities and not small merchants. +| `--reorg-notify ` | Run a program when reorganization happens (ie, at least one block is removed from the top of the blockchain). The `` must be a **full path**. The ` can contain any of `%s`, `%h`, `%n` symbols to interpolate:

`%s`: the height at which the split occurs

`%h`: the height of the new blockchain

`%d`: the number of blocks discarded from the old chain

`%n`: the number of blocks being added

The option 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).

**Recommendation**: unless you run economically significant Monero exchange or operation, you do **not** need to bother with this option. Simply account for reorganizations by requiring at least 10 confirmations before shipping valuable goods. #### Performance @@ -232,7 +236,7 @@ You can also type commands directly in the console of the running `monerod` (if | Option | Description |------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------- | `help []` | Show help for ``. -| `version` | Show version information. Example output:
`Monero 'Beryllium Bullet' (v0.13.0.2-release)` +| `version` | Show version information. Example output:
`Monero 'Boron Butterfly' (v0.14.0.0-release)` | `status` | Show status. Example output:
`Height: 186754/186754 (100.0%) on stagenet, not mining, net hash 317 H/s, v9, up to date, 8(out)+0(in) connections, uptime 0d 3h 48m 47s` #### P2P network diff --git a/docs/interacting/overview.md b/docs/interacting/overview.md index fb05752..a948d62 100644 --- a/docs/interacting/overview.md +++ b/docs/interacting/overview.md @@ -15,7 +15,7 @@ Monero project nicely decouples network node logic from wallet logic. Wallet logic is offered through three independent user interfaces - the GUI, the CLI, and the HTTP API. ``` -# cd monero-gui-v0.13.0.3 +# cd monero-gui-v0.14.0.0 # ---- guide to Monero GUI ---- diff --git a/docs/interacting/verify-monero-binaries.md b/docs/interacting/verify-monero-binaries.md index c24820d..129fe23 100644 --- a/docs/interacting/verify-monero-binaries.md +++ b/docs/interacting/verify-monero-binaries.md @@ -7,7 +7,7 @@ Verification must be carried on **before extracting the archive and before using Instructions were tested on Linux. They should also work on macOS with slight modifications. -## 0. Import core dev PGP key +## 1. Import core dev PGP key This is a one time action. Skip this step for subsequent Monero releases. @@ -29,7 +29,7 @@ Trust Riccardo's public key (fingerprint must be exactly this): If key with this fingerprint was not found then remove imported key immediately (gpg --delete-keys ...). That would mean the key changed (likely was compromised). -## 1. Verify signature of hash list +## 2. Verify signature of hash list The list of binaries and their hashes is published on [getmonero.org](https://www.getmonero.org/downloads/hashes.txt) and a few other places like release notes on [r/monero](https://reddit.com/r/monero). Please note the publication channel does not matter as long as you properly verify the signature! u @@ -38,12 +38,11 @@ To verify these are real hashes (not tampered with) run: `curl https://www.getmonero.org/downloads/hashes.txt | gpg --verify` -The expected output is: +The expected output should contain the line: - ... - gpg: Good signature from "Riccardo Spagni " [full] +`gpg: Good signature from "Riccardo Spagni " [full]` -## 2. Verify the hash +## 3. Verify the hash By this step we checked that published hashes were not tampered with. @@ -53,7 +52,7 @@ The last step is to compare published hash with downloaded archive SHA-256 hash. Replace the example file name with actual one: - file_name=monero-linux-x64-v0.13.0.4.tar.bz2 + file_name=monero-linux-x64-v0.14.0.0.tar.bz2 file_hash=`sha256sum $file_name | cut -c 1-64` diff --git a/docs/proof-of-work/cryptonight.md b/docs/proof-of-work/cryptonight.md index 56e4d26..239597c 100644 --- a/docs/proof-of-work/cryptonight.md +++ b/docs/proof-of-work/cryptonight.md @@ -131,13 +131,16 @@ This is how Monero community refers to original implementation of CryptoNight. ### CryptoNight v1 -See the [source code diff](https://github.com/monero-project/monero/pull/3253/files) for CryptoNight v1 modifications. +See the [source code diff](https://github.com/monero-project/monero/pull/3253/files). ### CryptoNight v2 -The v2 changes were more involved. See the [rationale](https://github.com/SChernykh/xmr-stak-cpu/blob/master/README.md) and the [source code diff](https://github.com/monero-project/monero/commit/5fd83c13fbf8dc304909345e60a853c15b0de1e5#diff-7000dc02c792439471da62856f839d62). +### CryptoNight v3 aka CryptoNightR + +See the [rationale](https://github.com/monero-project/monero/pull/5126) and the [source code diff](https://github.com/monero-project/monero/pull/5126/files). + ## Critique * CryptoNight hash is relatively expensive to verify. This poses a risk of DoS-ing nodes with incorrect proofs to process. See [strong asymmetry](/proof-of-work/what-is-pow/#strong-asymmetry) requirement. diff --git a/docs/todo/notify-changes-2019-03-09 b/docs/todo/notify-changes-2019-03-09 deleted file mode 100644 index 74fd91b..0000000 --- a/docs/todo/notify-changes-2019-03-09 +++ /dev/null @@ -1,73 +0,0 @@ -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.