Nu 3.0.1 release with new currencies

[Cybnate]

I’ll check that.

Thanks

Indeed my client was not minting anymore. It is now, and it has already found some blocks. It’s still on 2.1 though. I’ll start a 3.0 client.

That works!

[sigmike]

Indeed there’s a problem with the park rate calculation. I will certainly have to make another release. Do not upgrade yet.

[sigmike]

I’ve made a fix: https://bitbucket.org/JordanLeePeershares/nubit/pull-requests/270/30-park-rates-fix/diff

I’m testing a full chain download and when it’s done I’ll release version 3.0.1.

[sigmike]

The full download test was successful. I found another problem that I fixed though. The changes between 3.0.0 and 3.0.1 are here: https://bitbucket.org/JordanLeePeershares/nubit/branches/compare/v3.0.1 v3.0.0

I updated the first post and nubits.com.

[backpacker]

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

sha256: d721889cc1988c8058e150ab9730333a54687db27ba4a9d69c388d8234799205

[cryptog]

What is the current rate of adoption of Nu 3.0.1?

[Cybnate]

When I look at the number of nodes I’m connected to, I see 4 out of 13 nodes on v3.01. Just over 30%. For the protocol change it is about the % of minters and their stake though. I don’t know how to obtain those figures.

[sigmike]

What is the current rate of adoption of Nu 3.0.1?

Right now: 41.55% of the last 2000 blocks.

Testnet will switch at 2016-11-25 14:00:00 UTC.

I don’t know how to obtain those figures.

When I imported the protocol switch code from B&C I also imported the getprotocolvotes RPC that will give you these numbers.

[sigmike]

The protocol vote passed. The new protocol will be activated at 2016-11-28 14:00:00 UTC.

I made a mistake though. The protocol switch was triggered when 55% of the blocks were generated by this version whereas I proposed 60%. I guess when I imported the B&C code I planned to change the percentage after my proposal has been discussed, but when the final release came and there was no discussion about it I probably assumed I already had put the proposed percentage so I didn’t update it.

Given this percentage did not raise any discussion, that the numbers are not very different and that the absolute requirement to switch is 50%, I think it’s better to keep it that way. All the other options would probably result in a fork between shareholders wanting to switch and the others anyway.

[Cybnate]

Well, I suppose it won’t hurt to advance the date a bit. We just have to make sure that more than 55% of the block continue to be on v3.01 to prevent a fork I believe. Is that correct?

[sigmike]

We just have to make sure that more than 55% of the block continue to be on v3.01 to prevent a fork I believe. Is that correct?

No, a fork would happen only if some minters decided to reject some block from the other side (by running a different client). Since only those who don’t want to switch may want to do that, and given they are a minority (although this is fluctuating) they would just fork themselves out. Now that the switch has been triggered it will happen at the planned time. The only way to prevent it would be that a new majority build a higher chain starting before the vote passed, or that the majority decides to run a client with different protocol rules (but if they happen to not be the majority they will just be forked out).

So that means more than 50% of the minters must be running on 3.0 for the network to stay healthy. So 55% is actually a good target.

[cryptog]

I suppose it is now secure the do the upgrade. I ll do tmr.

[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.