monero-project/monero-docs
monero-project/monero-docs
2
1
Fork 0
mirror of https://github.com/monero-project/monero-docs.git synced 2024-12-22 19:49:22 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Update to Monero 0.14.0.0

Browse source
This commit is contained in:
Piotr Włodarek 2019-02-22 13:23:14 +01:00
parent a4840656fc
commit 5400fd5e09
6 changed files with 22 additions and 89 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
docs/interacting/monero-wallet-cli-reference.md
View file

@ -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: <br />`Monero 'Beryllium Bullet' (v0.13.0.4-release)`
| `--version` | Show `monero-wallet-cli` version to stdout. Example: <br />`Monero 'Boron Butterfly' (v0.14.0.0-release)`
#### Pick network

14
docs/interacting/monerod-reference.md
View file

@ -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: <br />`Monero 'Beryllium Bullet' (v0.13.0.4-release)`
| `--version` | Show `monerod` version to stdout. Example: <br />`Monero 'Boron Butterfly' (v0.14.0.0-release)`
| `--os-version` | Show build timestamp and target operating system. Example output:<br />`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: <br />`./monerod --block-notify="/usr/bin/echo %s"`<br /><br />Couple of notes:<br />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.<br />2) Mind blockchain reorganizations. Block notifications can revert to same and past heights. This actually happens pretty often.<br />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 <arg>` | Run a program for each new block. The `<arg>` must be a **full path**. If the `<arg>` contains `%s` it will be replaced by the block hash. Example: <br />`./monerod --block-notify="/usr/bin/echo %s"`<br /><br />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. <br /><br />Mind blockchain reorganizations. Block notifications can revert to same and past heights. Small reorganizations are natural and happen every day.
| `--block-rate-notify <arg>` | Run a program when the number of blocks received in the recent past deviates significantly from the expectation. The `<arg>` must be a **full path**. The `<arg`> can contain any of `%t`, `%b`, `%e` symbols to interpolate: <br /><br >`%t`: the number of minutes in the observation window<br /><br >`%b`: the number of blocks observed in that window<br /><br >`%e`: the ideal number of blocks expected in that window<br /><br > 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.<br /><br />**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 <arg>` | Run a program when reorganization happens (ie, at least one block is removed from the top of the blockchain). The `<arg>` must be a **full path**. The `<arg`> can contain any of `%s`, `%h`, `%n` symbols to interpolate: <br /><br >`%s`: the height at which the split occurs <br /><br />`%h`: the height of the new blockchain<br /><br />`%d`: the number of blocks discarded from the old chain <br /><br />`%n`: the number of blocks being added <br /><br /> 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). <br /><br />**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 [<command>]` | Show help for `<command>`.
| `version` | Show version information. Example output:<br />`Monero 'Beryllium Bullet' (v0.13.0.2-release)`
| `version` | Show version information. Example output:<br />`Monero 'Boron Butterfly' (v0.14.0.0-release)`
| `status` | Show status. Example output:<br />`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

2
docs/interacting/overview.md
View file

@ -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 ----

13
docs/interacting/verify-monero-binaries.md
View file

@ -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 <ric@spagni.net>" [full]
`gpg: Good signature from "Riccardo Spagni <ric@spagni.net>" [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`

7
docs/proof-of-work/cryptonight.md
View file

@ -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.

73
docs/todo/notify-changes-2019-03-09
View file

@ -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.