Potential migration issue for node IP changes

[jimtalksdata]

Summary: Migrating from node A (old) to node B (new) with same private key for a node A in the cycle leads to node being dropped from the cycle

Severity: Medium-high (existing verifiers are blocked from hardware/cloud provider updates at the risk of being dropped from cycle)

In the white paper:

Only one verifier is allowed to be run at each IPv4 address. As nodes take very little computational power, a single system could otherwise run many instances of the Nyzo software and take a disproportionate share of transaction fees. This will prevent some users from running Nyzo verifiers in situations with shared public IP addresses (dorms, offices), but that is an acceptable limitation to ensure fairness in transaction verification. Also, this limitation does not prevent multiple Nyzo clients at an address.

Two mechanisms are in place to enforce the IPv4 address restriction. First, in the list of verifiers waiting to join the verification cycle as a new verifier, any verifier changes at an address cause that address to be demoted to the end of the queue. Second, when an existing verifier produces a block, a penalty score is applied if that verifier is not currently listed as active in the mesh. To prevent shuffling of a large set of verifiers over a smaller set of IP addresses, the verifier at an IP address is only allowed to be reassigned at a time interval slightly larger than the time interval of the current verification cycle length. So, attempts to circumvent the IPv4 address restriction will result in difficulty joining the cycle as a new verifier and will risk being removed from the cycle as an existing verifier.

The problem:

As node resource and bandwidth requirements increase, it may be prudent for users currently in the cycle to migrate to nodes with larger capacity/processing power. Unfortunately, this also changes the IP address usually. It is unclear from above, but two interpretations are possible:

1. Nodes in the cycle that change IP address and same private key should be allowed to do so no more than ~once per cycle (my reading of the above)
2. Nodes in the cycle that change IP address and same private key are dropped, since the time that the new IP address is blocked from the network is approximately one cycle

If (1), then this is a bug. If (2), then this is a design feature.

Now, replicating the bug (assuming my reading of 1 is correct):

1. Have node A (old) with registered private key and nickname operating in the cycle
2. Set up node B (new) from scratch with instructions from github, without starting the node yet
3. Stop nyzo_verifier instance at node A - node becomes red at mesh page
4. Transfer private key (of node A) and nickname to node B, and start the nyzo_verifier
5. Wait a few minutes - node remains red at mesh page

The following output is generated in logs: (info hidden by +++)

---

nickname: +++ version: 476 ID: +++ mesh: 0 active, 536 inactive cycle length: 301 transactions: 0 retention edge: -1 trailing edge: -1 frozen edge: 892692 (ajmo2-1) open edge: 892692 blocks transmitted/created: 0/0 votes requested: 0 new timestamp: 2604 old timestamp: 1543045657578 blocks: 14: 0,[892673,892692] balance lists: 3(G=-,r=-,f=-)

---

6. Shut down node B and start nyzo_verifier instance at node A - node becomes operational at mesh page

Is there a resolution or is this "working as designed"?

[jimtalksdata]

Proposed resolutions:

• Fix bugs in the current IP address evaluation that determines what to do with a node that changed address with the same private key
• Add a mechanism for old node to "signal" that it will be retired, or that new node should be used

Further comment:

• It is unclear whether anything in the /var/lib/nyzo/production folder, besides the private key and the nickname, should be transferred to the new node. Further clarification on this is welcome.

ubuntu@ip-xxx:/var/lib/nyzo/production$ ls
blocks      nickname          seed_transactions     verifier_private_seed
blocks.tgz  queue_timestamps  trusted_entry_points

[jimtalksdata]

Closing the issue. See below with @nyzo's comment on migration.

what he said and, yes, it's a richlist it's calculated every block, and the hash of the list is stored in the block we'll put up a page with migration instructions, because it can be done effectively, but it can be tricky we migrated Nyzo 6 to a new instance a while back because of another AWS failure and AWS does seem to be having a lot of failures recently

the basics of migration are this: (1) start a new instance with a different key (let it generate a new one) (2) run the new instance until it starts creating blocks and the -1 values disappear from the status; it won't transmit any blocks, but it will start creating them (3) put your key from your current verifier into the verifier_private_seed file on the new verifier (4) shut down your old verifier (5) restart your new verifier

step 2 will take the longest -- a little over 4 cycles