URGENT! Not enough minters on 2.0 for protocol switch to occur

We are now about 12 hours away from our protocol switch date of 14:00 UTC. Two conditions must be met for the protocol switch to occur:

  1. The date must be greater than 14:00 August 25 UTC
  2. 90% of the last 2000 blocks must have been minted by client running Nu version 2.0

Right now only is 86.1% of the last 2000 blocks were minted by 2.0 clients. This means the protocol change is not set to occur at 14:00 UTC. It still can happen then, but we will need shareholders running versions less than 2.0 to upgrade and shareholders to bring any dormant minting power onto the network to push the percentage up over the next 12 hours. If this doesn’t occur, then the protocol change will occur whenever we pass the 90% threshold. That is somewhat disorderly and subjects the network to some additional risk.

So I am asking all shareholders to make sure they are upgraded right now and to bring as much minting power to the network as possible right now. You can download Nu 2.0 here.

4 Likes

I posted it on Nu’s subreddit, Peercoin’s Twitter and forum.

1 Like

this is a vacation period, thus i would expect the delay switching to 2.0 :wink:

Any chance nud 2.0 and bcexchanged could not get along on a Raspberry Pi2? My nud is minting blocks rather rarely now that I upgraded to nud 2.0 and also installed bcexchanged on the same system to be ran in parallel. I cannot debug it since I’m far away from the Pi but there have been some hiccups with the daemons. With the previous version of nud (lesser than 2.0) I once found it unresponsive and had to kill -KILL it. Right now I can see bcexchanged minting blocks successfully but nud hasn’t found a single block today. There’s a chance it has stopped working but the process didn’t terminate so it won’t be restarted by my script.

I have nud 2.0.0 and bcexchanged running on the same RPI2.
They run fine in parallel:

bcexchanged getinfo
{
    "version" : "v3.0.0-unk-beta",
[...]
    "blocks" : 71775,
    "moneysupply" : 186284.0082,
[...]


nud getinfo
{
    "version" : "v2.0.0-dirty-beta",
[...]
    "blocks" : 498580,
    "moneysupply" : 875857144.99880004,
[...]

But I can’t tell you about minting…

nud is memory intensive… something like twice as much as bcexchanged. Unless you have the R-pi 2, Nud itself could use up all physical memory and need swap space (it will still find blocks). If you run nud and bcexchanged on the same R-pi B or B+ (both are versions of R-pi 1) I can imagin nud getting bogged down.

Yes I suspected the same thing. At some point nud was unable to boot up, so it froze. I suspected it ran out of memory so after adding a swapfile it booted up normally. However, I removed the swapfile because later both instances were able to run together. I have Pi2 though, so it has 1 GiB of RAM.

Way more memory required for nud than for bcexchanged:

 PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
25561 pi        20   0  650m 524m  41m S  12,2 53,9 856:57.84 nud
20943 pi        20   0  226m 111m  37m S   2,3 11,4 439:44.42 bcexchanged

the output is from a RPI2 which has 1 GB.
The 512 MB on a RPI1 wouldn’t be enough to run nud without using swap.

I suspect there should be done some memory optimizations and configurations to respect some memory limit at the cost of speed. I also wonder how big is the threat of memory fragmentation with bitcoin based cryptocurrency implementations. The OS might not be able to free the unused memory after heavy fragmentation. As a counter measure I would propose spawning a child process from nud that would do the memory intensive stuff and clone its state once in a while into another child process so that fragmentation would be taken care of automatically.

The percentage of blocks found by 2.0 minters is now 88.25%.

It is certainly true that the Nu client takes a lot of memory. It is something sigmike and I discussed and decided some time ago to fix in the 2.1 release. Block metadata for the entire blockchain gets held in memory. This hasn’t been a problem for Bitcoin or Peercoin because their blocks have very little metadata. Nu blocks have quite a bit of extra metadata, such as shareholder votes. Our blockchain is currently mostly metadata, which means most of the blockchain is held in memory. So we will only retain most types of metadata in memory for a period of 10,000 blocks. I expect Nu 2.1 will be released in a matter of weeks.

3 Likes

Came across some YAC discussion on and off in the last month that might be relevant.

what about “cold wallet” minting? are you waiting PPC first?

Based on the recent rate of change, we can expect the 90% threshold will be passed at around 20:00 UTC, in about six hours. So that is when the protocol change will occur, approximately.

2 Likes

A flexible protocol change time should be seen as a feature that allows the protocol to migrate when the network is ready.

Maybe for some situations the protocol change happens at a predictable future moment is desireable (for example so servers can restart at a certain moment after giving users sufficient warning time). To accomodate this need the protocol change can set to happen e.g. 700 blocks (~12 hours) after the current criteria are met.

1 Like

I agree there is value in knowing the exact time of the protocol change. I’m inclined to think the optimal delay is more than 12 hours, however. What does everyone think about a week?

1 Like

Fine. There would be a bigger chance for node percentage to drop below 90% (for example key big shareholders get off line). The change decision has to be “final” once the criteria are met.

Indeed. The code already works that way. If the percent minting with the new protocol drops below 90% after exceeding it, the protocol version will not revert back.

1 Like

Then there’s only advantages of postponing the protocol switch for some days after criteria have been met, but no disadvantages, right?