Nu 3.0.1 release with new currencies

[sigmike]

Should I add it to the nubits.com download page?

https://rbfi.io/dl.php?key=/WH1y/Nu-Qt.dmg

sha256: d721889cc1988c8058e150ab9730333a54687db27ba4a9d69c388d8234799205

Since shareholders funded these builds I guess they should be put on nubits.com. I did it.

[Phoenix]

The network is now at 68% adoption of the new protocol. That is good enough for the fork, although it would be better to have everyone switch before the fork on the 28th.

[Sabreiib]

Has this version solved the problem of high CPU occupation?

[Nagalim]

That is most likely a consequence of the way your stake is broken up into many outputs and will most likely never be fixed. I noticed my testnode for peercoin uses up more cpu than my real node because i am minting with so many test ppc outputs, so Nu is probably the same way. Basically, the cpu usage problem cannot be fixed in peershares without overhauling the entire voting system.

[mhps]

can be fixed by reqiring 10k to miint. splitshareoutput can be used to set chunks to 10k already.

[Sabreiib]

Good point, 10 addresses mean 10 times of computation demand?

[Nagalim]

My observations have been that higher output number (outputs, not addresses) leads to higher cpu usage. I doubt it is linear, but i wont hazard a guess.

[sigmike]

Has this version solved the problem of high CPU occupation?

I didn’t change anything about that.

That is most likely a consequence of the way your stake is broken up into many outputs and will most likely never be fixed. […] Basically, the cpu usage problem cannot be fixed in peershares without overhauling the entire voting system.

Indeed, although this system does not only help the voting system, it also makes the block creation more distributed. But if there’s no associated vote it probably isn’t worth the CPU cost.

higher output number (outputs, not addresses) leads to higher cpu usage. I doubt it is linear, but i wont hazard a guess.

Indeed, and it should be linear. Each of the available outputs (minus the reserve) is used every second to generate a hash that is checked against the difficulty.

[Phoenix]

With less than a day to go until the protocol change at 14:00 UTC on the 28th, we are at 90% adoption of the new protocol. If you haven’t upgraded yet, you need to do so now, as 2.x clients will be forked out of the network in less than a day.

[Phoenix]

The protocol change is occurring at this moment. 92.7% of the network has upgraded.

While we expect a smooth transition, everyone should watch the network closely for unexpected behavior and report it here immediately.