nanocurrency / nano-docs Goto Github PK

Following nanocurrency/nano-node#2349

Related to nanocurrency/nano-node#2535

• Mention long upgrade time for V21: nanocurrency/nano-node#2545
• Callout subtype as recommendation when using RPC process call
• Include callouts for what epoch upgrade will be

Add documentation for nanocurrency/nano-node#2221

Do not include a full example anymore, but explain how to generate documented TOML files.

WebSockets: From https://docs.nano.org/running-a-node/configuration/#nodewebsocket to https://docs.nano.org/integration-guides/websockets/

Voting: From https://docs.nano.org/running-a-node/configuration/#nodeenable_voting and https://docs.nano.org/running-a-node/configuration/#nodevote_minimum to representative setup guide

After nanocurrency/nano-node#2204 RC/DB tags are not automatic, to have them in --version must do:

TRAVIS_TAG="TAG you want for version string e.g. v20RC1" cmake --build . -DCI_BUILD=TRUE <other CMAKE variables>

Docs needed for nanocurrency/nano-node#2588

nanocurrency/nano-node#2471

By default it will return blocks not in active but unconfirmed (e.g., block was received but node restarted, election was dropped, new ledger with reset conf height)

nanocurrency/nano-node#2289

From nanocurrency/nano-node#2534

https://docs.nano.org/running-a-node/troubleshooting/#statistics-from-rpc

...and update the configuration since it's no longer json

For nanocurrency/nano-node#2168

Documentation for nanocurrency/nano-node#2361

The current setup for RPC commands needs some cleanup including:

• Adjusting command titles to be the action used
• Better formatting of request/response details
• More consistent formatting across the board, including version callouts

Suggestions for how best to do the formatting of request/response details are welcome. A possible approach was included for the account_balance, account_block_count and account_info calls using tables for keys, version, format, etc.

Once we get the suggested formatting down additional cleanup efforts on the remaining calls can be done more consistently and this ticket will be used to help track that work.

nanocurrency/nano-node#2540

nanocurrency/nano-node#2619

Relate to #248 - look into updates to the Pre-caching section of the Work Generation page to potentially add better guidance or specific examples to better help external integration manage pre-caching optimally.

nanocurrency/nano-node#2283 is modifying all accounts to use the representative account instead of the representative block. This has been found to take a few minutes on some systems.

The account_info RPC should mark rep_block as deprecated and the representative shown by default when it eventually gets removed, RPC 2.0?

Related to:
nanocurrency/nano-node#2156
nanocurrency/nano-node#2233

Based on nanocurrency/nano-node#2455 new CLI command to automate most things.

For:

• nanocurrency/nano-node#2671
• nanocurrency/nano-node#2689
• nanocurrency/nano-node#2705
• nanocurrency/nano-node#2707

Also the new beta threshold, 2x higher for sends, 2x lower for receives.

Related to #248 - update the benchmarks to include new CPU/GPU targets with epoch v1 and new epoch v2 difficulties

https://docs.nano.org/integration-guides/advanced/#websocket-support

Needs a small callout when used in a docker node. The default websocket address in that situation is "::ffff:0.0.0.0". In the docker run command, -p 127.0.0.1:7078:7078 must be added (57000 for a beta node).

Move IPC Integration section of the Advanced Integration Guides page to it's own page and update with IPC 2.0 content from:

https://github.com/cryptocode/notes/wiki/IPC-Flatbuffers-API
https://github.com/cryptocode/notes/wiki/IPC-2.0---RPC-gateway
https://github.com/cryptocode/notes/wiki/IPC-Authorization

Related PRs
nanocurrency/nano-node#2487

For nanocurrency/nano-node#2203

Related to #248

• RPC process call
• Integration guides usage of process call

nanocurrency/nano-node#2555

nanocurrency/nano-node#2566

nanocurrency/nano-node#2481

RPC - account_info RPC now includes confirmation_height_frontier block hash of the most cemented block.

RPC command additions and other details to help make telemetry useful (response definitions?)

Related to: nanocurrency/nano-node#2446 and nanocurrency/nano-node#2521

To cover changes in nanocurrency/nano-node#2175

Auto mode (default): If not Principal Representative, start frontier confirmation process every 15 minutes; if Principal Representative, start frontier confirmation process every 3 minutes

Always: Start frontier confirmation process every 3 minutes

Disabled: Do not start frontier confirmation process

The node prints this message when "::ffff:0.0.0.0" is set as address an control is enabled: WARNING: control-level RPCs are enabled on non-local address ::ffff:0.0.0.0, potentially allowing wallet access outside local computer

We should add more information on this in the documentation and include the link in the printed message.

If not using docker:

• A non-local address exposes the RPC
• A firewall is necessary to properly manage exposure
• Recommended to use a proxy, V22 will bring management using API-keys but should be used with SSL or a proxy

If using docker:

• A non-local address is the default and required for other applications to use the RPC
• The setting by itself does not expose the RPC to outside the local machine, this depends on how the run command is created
• We have a warning against redirecting other addresses than localhost to the RPC port
• Docker overrides ufw - even if rules are defined in ufw to only allow certain IPs through the RPC port, docker overrides this unless a special configuration is used.

The section Validating blocks and voting weights mentions --compare_rep_weights CLI command option, which can not be recognized in recent nano_node. It should be denoted as V21+ specific command option.

In the tables on https://docs.nano.org/releases/node-releases/ to call out legacy vs. state v1, etc.

@zhyatt
This is available since v19, can we start recommending it now by using it in the documentation examples? The formatted output is much easier to read.

nanocurrency/nano-node#2557

https://docs.nano.org/integration-guides/key-management/#external-management

There are details on send and receive blocks, but not the first receive (also known as open).

Hello,

I asked quite a while ago about the eventuality of translating the documentation. I was answered to wait for the release of the new version of the official website, which is now online.

Any plans on the way to let people translate the doc, now ? I'm quite eager to.

Some stats were added with nanocurrency/nano-node#2485

To accommodate integrations preparing for epoch upgrade transition post-V21 release.

Add documentation for nanocurrency/nano-node#2298

Page here: https://docs.nano.org/running-a-node/beta-network/

At least add in details from this: nanocurrency/nano-node#1847 (reverted) nanocurrency/nano-node#2186

Relate to #248 - look into updates to the Difficulty thresholds section of the Work Generation page to potentially add better guidance or specific examples to better help external integration manage work levels properly.

The documentation should be updated at some point regarding the key derivation. I think it's correct info, just missing a few points.
I think it should be written by someone who really knows this, I just found out by trial and error.

For example from here: https://docs.nano.org/integration-guides/the-basics/#seed
PrivK[i] = blake2b(outLen = 32, input = seed || i)

That's true but should be noted that seed is not the same as the BIP39 seed which is 128 in length.

From here: https://docs.nano.org/integration-guides/key-management/
Derived Private Key for 44'/165'/0'

Yes, that's also true but should be noted that type of derivation is not the same as the one mentioned above using blake2b. It results in different private keys!
Should also be mentioned that the 24-word mnemonic can be derived from a Nano 64 length seed using either

BIP39:
mnemonic = bip39.entropyToMnemonic('seed')

or using nanocurrency-web-js like so:
mnemonic = wallet.generate('seed').mnemonic

Furthermore, the 64 nano seed can also be derived from a 24-word mnemonic by:
seed = bip39.mnemonicToEntropy(mnemonic)

Maybe also mention how to get the private key using both derivation methods (from either nanocurrency-web-js or nanocurrency-js

Default Nano (nanocurrency-js, index 0):
privKey = nano.deriveSecretKey(seed, 0)
Should be the same as blake2b(outLen = 32, input = seed || 0) but haven't tested

Ledger key (nanocurrency-web-js, index 0, seed is 64 char (also called entropy), nanowallet.seed is the 128 char BIP39 seed):
nanowallet = wallet.generate(seed)
accounts = nanowallet.accounts(nanowallet.seed, 0, 0)
privKey = accounts[0].privateKey
This should be the same as BIP39 derivation from 44'/165'/0'