GRIN/nym
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

* removed old wallet-address flag

Browse Source 
* 'mixnode' -> 'mix node' for consistency in non-code / non-binary references
This commit is contained in:
mfahampshire
2023-08-03 16:43:58 +02:00
parent 10696ae4dc
commit 0b6eb17793
5 changed files with 57 additions and 57 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documentation/operators/src/faq.md
+3 -3
View File
@@ -2,7 +2,7 @@
## Mixnet nodes
### What determines the rewards when running a mixnode?
### What determines the rewards when running a mix node?
The stake required for a mix node to achieve maximum rewards is called mix node saturation point. This is calculated from the staking supply (all circulating supply + part of unlocked tokens). The target level of staking is to have 50% of the staking supply locked in mix nodes.
@@ -16,7 +16,7 @@ For more detailed calculation, read our blog post [Nym Token Economics update](h
Consider in which jurisdiction you reside and where do you want to run a mix node. Do you want to pay by crypto or not and what are the other important particularities for your case? We always recommend operators to try to chose smaller and decentralized VPS providers over the most known ones controlling a majority of the internet. We recieve some good feedback on these: Hertzner, DigitalOcean, Linode, Ghandi and Exoscale. Do your own research and share with the community.
<!---### Why is a mixnode setup on a self-hosted machine so tricky?--->
<!---### Why is a mix node setup on a self-hosted machine so tricky?--->
### What's the Sphinx packet size?
@@ -32,7 +32,7 @@ Right now only mix nodes are rewarded. We're working on gateway and service paym
### Are mixnodes whitelisted?
Nope, anyone can run a mixnode. Purely reliant on the node's reputation (self stake + delegations) & routing score.
Nope, anyone can run a mix node. Purely reliant on the node's reputation (self stake + delegations) & routing score.
## Validators and tokens
documentation/operators/src/nodes/maintenance.md
+16 -16
View File
@@ -2,7 +2,7 @@
<!---
TODO
- [x] Compare mixnode, gateway, NR steps and validator of upgrading and automation and make a generic page - this one - for all of them with additional notes for particular nodes
- [x] Compare mix node, gateway, NR steps and validator of upgrading and automation and make a generic page - this one - for all of them with additional notes for particular nodes
- [x] Include how to move a mix node from one VPS to another while keeping the delegation etc (ie init a new mix node and move `/home/nym/.nym/mixnodes/data/*` there ?)
- copy that dir over to the new vps
- re-run init - remember that init doesn't overwrite existing keys - to generate a config with the new listening address etc
@@ -25,7 +25,7 @@ For example `./target/debug/nym-network-requester --no-banner build-info --outpu
## Upgrading your node
> The process is the similar for mixnode, gateway and network requester. In the following steps we use a placeholder `<NODE>` in the commands, please change it for the type of node you want to upgrade. Any particularities for the given type of node are included.
> The process is the similar for mix node, gateway and network requester. In the following steps we use a placeholder `<NODE>` in the commands, please change it for the type of node you want to upgrade. Any particularities for the given type of node are included.
Upgrading your node is a two-step process:
* Updating the binary and `~/.nym/<NODE>/<YOUR_ID>/config.toml` on your VPS
@@ -116,7 +116,7 @@ If the `/dev/sda` partition is almost full, try pruning some of the `.gz` syslog
In case of a need to move a node from one machine to another and avoiding to lose the delegation, here are few steps how to do it.
The following examples transfers a mixnode (in case of other nodes, change the `mixnodes` in the command for the `<NODE>` of your desire.
The following examples transfers a mix node (in case of other nodes, change the `mixnodes` in the command for the `<NODE>` of your desire.
* Pause your node process.
@@ -128,7 +128,7 @@ Assuming both machines are remote VPS.
# in case none of the nym configs was created previously
mkdir ~/.nym
#in case no nym mixnode was initialized previously
#in case no nym mix node was initialized previously
mkdir ~/.nym/mixnodes
```
* Move the node data (keys) and config file to the new machine by opening a local terminal (as that one's ssh key is authorized in both of the machines) and running:
@@ -160,7 +160,7 @@ sudo ufw status
Finally open your `<NODE>` p2p port, as well as ports for ssh and ports for verloc and measurement pings:
```
# for mixnode
# for mix node
sudo ufw allow 1789,1790,8000,22/tcp
# for gateway
@@ -212,7 +212,7 @@ In case it didn't work for your distribution, see how to build `tmux` from [vers
**Running tmux**
No when you installed tmux on your VPS, let's run a mixnode on tmux, which allows you to detach your terminal and let your `<NODE>` run on its own on the VPS.
No when you installed tmux on your VPS, let's run a mix node on tmux, which allows you to detach your terminal and let your `<NODE>` run on its own on the VPS.
* Pause your `<NODE>`
* Start tmux with the command
@@ -235,7 +235,7 @@ tmux attach-session
Here's a systemd service file to do that:
##### For Mixnode
##### For mix node
```ini
[Unit]
@@ -354,8 +354,8 @@ If you have built nym in the `$HOME` directory on your server, and your username
Then run:
```
# for mixnode
systemctl enable nym-mixnode.service
# for mix node
systemctl enable nym-mix node.service
# for gateway
systemctl enable nym-gateway.service
@@ -364,7 +364,7 @@ systemctl enable nym-gateway.service
Start your node:
```
# for mixnode
# for mix node
service nym-mixnode start
# for gateway
@@ -402,12 +402,12 @@ This means that the operating system is preventing network connections from bein
> Replace `<NODE>` variable with `nym-mixnode`, `nym-gateway` or `nym-network-requester` according the node you running on your machine.
The ulimit setup is relevant for maintenance of nym mixnode only.
The ulimit setup is relevant for maintenance of nym mix node only.
Query the `ulimit` of your `<NODE>` with:
```
# for nym-mixnode, nym-gateway and nym-network requester:
# for nym-, nym-gateway and nym-network requester:
grep -i "open files" /proc/$(ps -A -o pid,cmd|grep <NODE> | grep -v grep |head -n 1 | awk '{print $1}')/limits
# for nyx validator:
@@ -454,7 +454,7 @@ Make sure the limit has changed to 65535.
#### Set the ulimit on `non-systemd` based distributions
In case you chose tmux option for mixnode automatization, see your `ulimit` list by running:
In case you chose tmux option for mix node automatization, see your `ulimit` list by running:
```
ulimit -a
@@ -479,7 +479,7 @@ username hard nofile 4096
username soft nofile 4096
```
Then reboot your server and restart your mixnode.
Then reboot your server and restart your mix node.
## Virtual IPs and hosting via Google & AWS
For true internet decentralization we encourage operators to use diverse VPS providers instead of the largest companies offering such services. If for some reasons you have already running AWS or Google and want to setup a `<NODE>` there, please read the following.
@@ -514,11 +514,11 @@ Numerous API endpoints are documented on the Nym API (previously 'Validator API'
### Mix node Reward Estimation API endpoint
The Reward Estimation API endpoint allows mixnode operators to estimate the rewards they could earn for running a Nym mixnode with a specific `MIX_ID`.
The Reward Estimation API endpoint allows mix node operators to estimate the rewards they could earn for running a Nym mix node with a specific `MIX_ID`.
> The `<MIX_ID>` can be found in the "Mix ID" column of the [Network Explorer](https://explorer.nymtech.net/network-components/mixnodes/active).
The endpoint is a particularly common for mixnode operators as it can provide an estimate of potential earnings based on factors such as the amount of traffic routed through the mixnode, the quality of the mixnode's performance, and the overall demand for mixnodes in the network. This information can be useful for mixnode operators in deciding whether or not to run a mix node and in optimizing its operations for maximum profitability.
The endpoint is a particularly common for mix node operators as it can provide an estimate of potential earnings based on factors such as the amount of traffic routed through the mix node, the quality of the mix node's performance, and the overall demand for mixnodes in the network. This information can be useful for mix node operators in deciding whether or not to run a mix node and in optimizing its operations for maximum profitability.
Using this API endpoint returns information about the Reward Estimation:
documentation/operators/src/nodes/mix-node-setup.md
+9 -9
View File
@@ -9,17 +9,17 @@
<!-- cmdrun ../../../../target/release/nym-mixnode --version | grep "Build Version" | cut -b 21-26 -->
```
The `nym-mixnode` binary is currently one point version ahead of the rest of the platform binaries due to a patch applied between releases.
The `nym-mix node` binary is currently one point version ahead of the rest of the platform binaries due to a patch applied between releases.
## Preliminary steps
Make sure you do the preparation listed in the [preliminary steps page](../preliminary-steps.md) before setting up your mixnode.
Make sure you do the preparation listed in the [preliminary steps page](../preliminary-steps.md) before setting up your mix node.
## Mix node setup
Now that you have built the [codebase](../binaries/building-nym.md), set up your [wallet](https://nymtech.net/docs/wallet/desktop-wallet.html), and have a VPS with the `nym-mixnode` binary, you can set up your mix node with the instructions below.
Now that you have built the [codebase](../binaries/building-nym.md), set up your [wallet](https://nymtech.net/docs/wallet/desktop-wallet.html), and have a VPS with the `nym-mix node` binary, you can set up your mix node with the instructions below.
To begin, move to `/taget/release` directory from which you run the node commands:
To begin, move to `/target/release` directory from which you run the node commands:
```
cd target/release
@@ -63,10 +63,10 @@ To check available configuration options for initializing your node use:
```
~~~
Initalise your mixnode with the following command, replacing the value of `--id` with the moniker you wish to give your mixnode, and the `--wallet-address` with the Nym address you created earlier. Your `--host` must be publicly routable on the internet in order to mix packets, and can be either an Ipv4 or IPv6 address. The `$(curl ifconfig.me)` command returns your IP automatically using an external service. If you enter your IP address manually, enter it **without** any port information.
Initalise your mix node with the following command, replacing the value of `--id` with the moniker you wish to give your mix node. Your `--host` must be publicly routable on the internet in order to mix packets, and can be either an Ipv4 or IPv6 address. The `$(curl ifconfig.me)` command returns your IP automatically using an external service. If you enter your IP address manually, enter it **without** any port information.
```
./nym-mixnode init --id <NODE_NAME> --host $(curl ifconfig.me) --wallet-address <WALLET_ADDRESS>
./nym-mixnode init --id <NODE_NAME> --host $(curl ifconfig.me)
```
<!---serinko: The automatized command did not work, printing the output manually--->
@@ -105,7 +105,7 @@ During the `init` process you will have the option to change the `http_api`, `ve
### Bonding your mix node
```admonish caution
From `v1.1.3`, if you unbond your mixnode that means you are leaving the mixnet and you will lose all your delegations (permanently). You can join again with the same identity key, however, you will start with **no delegations**.
From `v1.1.3`, if you unbond your mix node that means you are leaving the mixnet and you will lose all your delegations (permanently). You can join again with the same identity key, however, you will start with **no delegations**.
```
#### Bond via the Desktop wallet (recommended)
@@ -183,7 +183,7 @@ Have a look at the saved configuration files in `$HOME/.nym/mixnodes/` to see mo
## Node Description (optional)
In order to easily identify your node via human-readable information later on in the development of the testnet when delegated staking is implemented, you can `describe` your mixnode with the following command:
In order to easily identify your node via human-readable information later on in the development of the testnet when delegated staking is implemented, you can `describe` your mix node with the following command:
```
./nym-mixnode describe --id <YOUR_ID>
@@ -311,5 +311,5 @@ For more details see [Troubleshooting FAQ](../nodes/troubleshooting.md)
## Maintenance
For mixnode upgrade, firewall setup, port configuration, API endpoints, VPS suggestions, automation and more, see the [maintenance page](./maintenance.md)
For mix node upgrade, firewall setup, port configuration, API endpoints, VPS suggestions, automation and more, see the [maintenance page](./maintenance.md)
documentation/operators/src/nodes/troubleshooting.md
+23 -23
View File
@@ -78,7 +78,7 @@ Additional details can be obtained via various methods after you connect to your
##### Socket statistics with `ss`
```
sudo ss -s -t | grep 1789 # if you have specified a different port in your mixnode config, change accordingly
sudo ss -s -t | grep 1789 # if you have specified a different port in your mix node config, change accordingly
```
This command should return a lot of data containing `ESTAB`. This command should work on every unix based system.
@@ -90,7 +90,7 @@ This command should return a lot of data containing `ESTAB`. This command should
lsof -v
# install if not installed
sudo apt install lsof
# run against mixnode port
# run against mix node port
sudo lsof -i TCP:1789 # if you have specified a different port in your mixnode config, change accordingly
```
@@ -110,7 +110,7 @@ nym-mixno 103349 root 57u IPv6 1333229976 0t0 TCP [2a03:b0c0:3:d0::ff3:
sudo journalctl -u nym-mixnode -o cat | grep "Since startup mixed"
```
If you have created `nym-mixnode.service` file (i.e. you are running your mixnode via `systemd`) then this command shows you how many packets have you mixed so far, and should return a list of messages like this:
If you have created `nym-mixnode.service` file (i.e. you are running your mix node via `systemd`) then this command shows you how many packets have you mixed so far, and should return a list of messages like this:
```
2021-05-18T12:35:24.057Z INFO nym_mixnode::node::metrics > Since startup mixed 233639 packets!
@@ -140,7 +140,7 @@ For example `./target/debug/nym-network-requester --no-banner build-info --outpu
nmap -p 1789 <IP ADDRESS> -Pn
```
If your mixnode is configured properly it should output something like this:
If your mix node is configured properly it should output something like this:
```
bob@desktop:~$ nmap -p 1789 95.296.134.220 -Pn
@@ -164,7 +164,7 @@ You can query gateways by replacing `mixnodes` with `gateways` in the above comm
#### Check with Network API
We currently have an API set up returning our metrics tests of the network. There are two endpoints to ping for information about your mixnode, `report` and `history`. Find more information about this in the [Mixnodes metrics documentation](./maintenance.md#metrics--api-endpoints).
We currently have an API set up returning our metrics tests of the network. There are two endpoints to ping for information about your mix node, `report` and `history`. Find more information about this in the [Mixnodes metrics documentation](./maintenance.md#metrics--api-endpoints).
### Why is my node not mixing any packets?
@@ -172,24 +172,24 @@ If you are still unable to see your node on the dashboard, or your node is decla
- The firewall on your host machine is not configured properly. Checkout the [instructions](./maintenance.md#configure-your-firewall).
- You provided incorrect information when bonding your node.
- You are running your mixnode from a VPS without IPv6 support.
- You did not use the `--announce-host` flag while running the mixnode from your local machine behind NAT.
- You did not configure your router firewall while running the mixnode from your local machine behind NAT, or you are lacking IPv6 support.
- Your mixnode is not running at all, it has either exited / panicked or you closed the session without making the node persistent. Check out the [instructions](./maintenance.md#automating-your-node-with-tmux-and-systemd).
- You are running your mix node from a VPS without IPv6 support.
- You did not use the `--announce-host` flag while running the mix node from your local machine behind NAT.
- You did not configure your router firewall while running the mix node from your local machine behind NAT, or you are lacking IPv6 support.
- Your mix node is not running at all, it has either exited / panicked or you closed the session without making the node persistent. Check out the [instructions](./maintenance.md#automating-your-node-with-tmux-and-systemd).
```admonish caution
Your mixnode **must speak both IPv4 and IPv6** in order to cooperate with other nodes and route traffic. This is a common reason behind many errors we are seeing among node operators, so check with your provider that your VPS is able to do this!
Your mix node **must speak both IPv4 and IPv6** in order to cooperate with other nodes and route traffic. This is a common reason behind many errors we are seeing among node operators, so check with your provider that your VPS is able to do this!
```
#### Incorrect bonding information
Check that you have provided the correct information when bonding your mixnode in the web wallet [interface](https://sandbox-wallet.nymtech.net/). When in doubt, un-bond and then re-bond your node!
Check that you have provided the correct information when bonding your mix node in the web wallet [interface](https://sandbox-wallet.nymtech.net/). When in doubt, un-bond and then re-bond your node!
> All delegated stake will be lost when un-bonding! However the mixnode must be operational in the first place for the delegation to have any effect.
> All delegated stake will be lost when un-bonding! However the mix node must be operational in the first place for the delegation to have any effect.
#### Missing `announce-host` flag
On certain cloud providers such as AWS and Google Cloud, you need to do some additional configuration of your firewall and use `--host` with your **local ip** and `--announce-host` with the **public ip** of your mixnode host.
On certain cloud providers such as AWS and Google Cloud, you need to do some additional configuration of your firewall and use `--host` with your **local ip** and `--announce-host` with the **public ip** of your mix node host.
If the difference between the two is unclear, contact the help desk of your VPS provider.
@@ -222,15 +222,15 @@ bob@nym:~$ hostname -I
### Running on a local machine behind NAT with no fixed IP address
Your ISP has to be IPv6 ready if you want to run a mixnode on your local machine. Sadly, in 2020, most of them are not and you won't get an IPv6 address by default from your ISP. Usually it is a extra paid service or they simply don't offer it.
Your ISP has to be IPv6 ready if you want to run a mix node on your local machine. Sadly, in 2020, most of them are not and you won't get an IPv6 address by default from your ISP. Usually it is a extra paid service or they simply don't offer it.
Before you begin, check if you have IPv6 [here](https://test-ipv6.cz/) or by running command explained in the [section above](./troubleshooting.md#no-ipv6-connectivity). If not, then don't waste your time to run a node which won't ever be able to mix any packet due to this limitation. Call your ISP and ask for IPv6, there is a plenty of it for everyone!
If all goes well and you have IPv6 available, then you will need to `init` the mixnode with an extra flag, `--announce-host`. You will also need to edit your `config.toml` file each time your IPv4 address changes, that could be a few days or a few weeks. Check the your IPv4 in the [section above](./troubleshooting.md#no-ipv6-connectivity).
If all goes well and you have IPv6 available, then you will need to `init` the mix node with an extra flag, `--announce-host`. You will also need to edit your `config.toml` file each time your IPv4 address changes, that could be a few days or a few weeks. Check the your IPv4 in the [section above](./troubleshooting.md#no-ipv6-connectivity).
Additional configuration on your router might also be needed to allow traffic in and out to port 1789 and IPv6 support.
Here is a sample of the `init` command example to create the mixnode config.
Here is a sample of the `init` command example to create the mix node config.
```
./nym-mixnode init --id <YOUR_ID> --host 0.0.0.0 --announce-host 85.160.12.13
@@ -244,7 +244,7 @@ Make sure you check if your node is really mixing. We are aiming to improve the
### Accidentally killing your node process on exiting session
When you close your current terminal session, you need to make sure you don't kill the mixnode process! There are multiple ways on how to make it persistent even after exiting your ssh session, the easiest solution is to use `tmux` or `nohup`, and the more elegant solution is to run the node with `systemd`. Read the automation manual [here](./maintenance.md#automating-your-node-with-tmux-and-systemd).
When you close your current terminal session, you need to make sure you don't kill the mix node process! There are multiple ways on how to make it persistent even after exiting your ssh session, the easiest solution is to use `tmux` or `nohup`, and the more elegant solution is to run the node with `systemd`. Read the automation manual [here](./maintenance.md#automating-your-node-with-tmux-and-systemd).
### Common errors and warnings
@@ -273,24 +273,24 @@ Rocket runs on port `8000` by default. Although at this stage we need Rocket to
#### `failed to receive reply to our echo packet within 1.5s. Stopping the test`
This relates to the VerLoc implementation that appeared in `0.10.1`, which has a particularly high log sensitivity. This warning means that the echo packet sent to the mixnode was received, but not sent back. _This will not affect the rate of rewards or performance metrics of your mixnode in the testnet at this point._
This relates to the VerLoc implementation that appeared in `0.10.1`, which has a particularly high log sensitivity. This warning means that the echo packet sent to the mix node was received, but not sent back. _This will not affect the rate of rewards or performance metrics of your mix node in the testnet at this point._
#### `Connection to <IP>:1789 seems to be dead`
This warning is normal at the moment, and is _nothing to do with your mixnode!_ It is simply a warning that your node is unable to connect to other peoples' mixnodes for some reason, most likely because they are offline or poorly configured.
This warning is normal at the moment, and is _nothing to do with your mix node!_ It is simply a warning that your node is unable to connect to other peoples' mixnodes for some reason, most likely because they are offline or poorly configured.
--->
### Can I use a port other than 1789 ?
Yes! Here is what you will need to do:
Assuming you would like to use port `1337` for your mixnode, you need to open the new port (and close the old one):
Assuming you would like to use port `1337` for your mix node, you need to open the new port (and close the old one):
```
sudo ufw allow 1337
sudo ufw deny 1789
```
And then edit the mixnode's config.
And then edit the mix node's config.
> If you want to change the port for an already running node, you need to stop the process before editing your config file.
@@ -304,9 +304,9 @@ nano ~/.nym/mixnodes/alice-node/config/config.toml
You will need to edit two parts of the file. `announce_address` and `listening_address` in the config.toml file. Simply replace `:1789` (the default port) with `:1337` (your new port) after your IP address.
Finally, restart your node. You should see if the mixnode is using the port you have changed in the config.toml file right after you run the node.
Finally, restart your node. You should see if the mix node is using the port you have changed in the config.toml file right after you run the node.
### What is `verloc` and do I have to configure my mixnode to implement it?
### What is `verloc` and do I have to configure my mix node to implement it?
`verloc` is short for _verifiable location_. Mixnodes and gateways now measure speed-of-light distances to each other, in an attempt to verify how far apart they are. In later releases, this will allow us to algorithmically verify node locations in a non-fakeable and trustworthy manner.
documentation/operators/src/preliminary-steps.md
+6 -6
View File
@@ -1,23 +1,23 @@
# Preliminary Steps
> The Nym `mixnode`, `gateway` and `network-requester` binaries were built in the [building nym](../binaries/building-nym.md) section. If you haven't yet built Nym and want to run the code, go there first.
> The Nym `mix node`, `gateway` and `network-requester` binaries were built in the [building nym](../binaries/building-nym.md) section. If you haven't yet built Nym and want to run the code, go there first.
## Preliminary steps
There are a couple of steps that need completing before starting to set up your mixnode, gateway or a network requester:
There are a couple of steps that need completing before starting to set up your mix node, gateway or a network requester:
- preparing your [desktop wallet](https://nymtech.net/docs/wallet/desktop-wallet.html) or [CLI wallet](https://nymtech.net/docs/wallet/cli-wallet.html).
- requisitioning a VPS (Virtual Private Server)
### Wallet preparation
#### Mainnet
Before you initialise and run your mixnode, head to our [website](https://nymtech.net/download/) and download the Nym wallet for your operating system. If pre-compiled binaries for your operating system aren't available, you can build the wallet yourself with instructions [here](https://nymtech.net/docs/wallet/desktop-wallet.html).
Before you initialise and run your mix node, head to our [website](https://nymtech.net/download/) and download the Nym wallet for your operating system. If pre-compiled binaries for your operating system aren't available, you can build the wallet yourself with instructions [here](https://nymtech.net/docs/wallet/desktop-wallet.html).
If you don't already have one, please create a Nym address using the wallet, and fund it with tokens. The minimum amount required to bond a mixnode is 100 `NYM`, but make sure you have a bit more to account for gas costs.
If you don't already have one, please create a Nym address using the wallet, and fund it with tokens. The minimum amount required to bond a mix node is 100 `NYM`, but make sure you have a bit more to account for gas costs.
`NYM` can be purchased via Bity from the wallet itself with BTC or fiat, and is currently present on several [exchanges](https://www.coingecko.com/en/coins/nym#markets).
> Remember that you can **only** use Cosmos `NYM` tokens to bond your mixnode. You **cannot** use ERC20 representations of `NYM` to run a node.
> Remember that you can **only** use Cosmos `NYM` tokens to bond your mix node. You **cannot** use ERC20 representations of `NYM` to run a node.
#### Sandbox testnet
@@ -32,7 +32,7 @@ For now, see the below rough specs:
- Processors: 2 cores are fine. Get the fastest CPUs you can afford.
#### For Mixnode
#### For mix node
- RAM: Memory requirements are very low - typically a mix node may use only a few hundred MB of RAM.
- Disks: The mixnodes require no disk space beyond a few bytes for the configuration files.