A new protocol version 3 was added. It will become active at 14:00 UTC 14 days after 60% of the last 2000 blocks have been generated by this new version.
After this protocol activates shareholders will be able to issue custodian grants on the 3 new currencies: CN-NBT, EU-NBT and X-NBT (the NuBit currency being renamed to US-NBT). The new protocol will also accept unknown currencies, so that adding other currencies will not require a new protocol change.
The changes are:
imported the signature fix from peercoin
imported miniupnpc fix and disabled UPNP by default
imported the protocol switch system from B&C Exchange
imported the -debugmint option
added the 3 new currencies
added a -initialunit option to make the GUI open a specific unit at startup
in the GUI, removed the button after the tabs to switch between units, and replaced it by a click on the current unit logo
added the ability to display the park rates and liquidity info of the new currencies in the vote tab
updated the parking rate calculation to supported other currencies
added tests of various parts to make sure they work with the new currencies
allowed unknown currencies in the protocol and made sure the client works fine when it encounters one
I’m very pleased to see this. @woolly_sammoth what remains to be done to adapt NuBot to 3.0?
The next step will be finding exchanges that will list CN-NBT. After the protocol change occurs, I will request the first grant of CN-NBT. Once we have this grant and the NuBot changes, we will be prepared to support trading pairs on exchanges.
Who wants to step up to lead this important marketing task?
I think we should really push exchanges to place CN-NBT as the denominator, not the numerator as is the case with US-NBT on Poloniex. This improves the readability of our price.
Finally, with the OP @sigmike has met the requirements for receiving a rapid deployment bonus. Having met the requirement on the the 30th, that qualifies as a 14 million NSR bonus as I recall. Is that what you were expecting @sigmike?
I’m having intermittent issues with the Linux 3.0.0 client. The first time it appeared to be stuck at:
“blocks” : 1120769,
Had to restart the client and it now appears to work.
Might be a coincidence but blockexplorers are also not working. Is it just me?
V2.01 client still works, although I noticed that there are unusual large gaps between the blocks at times (e.g. 7 minutes) or large reorgs, meshing issue, not sure. Haven’t seen that before with this blockexplorer. You can see it here: https://svr1.nubitsexplorer.nu/chain/Nubits. Maybe it is not v3 related, it seems to be going on longer than that.
Anyway, will start minting with the new v3.0.0 client.
Something is not right. V3.0.0 reports up to date while it is multiple blocks behind. It doesn’t seem to catch-up. It is now 25 minutes behind. When I start V2, it catches up. Restarting v3.0.0 recognises the updates but won’t progress by itself.
Curious to hear whether others have better results.
Edit BTW, the test env also seems to have stalled at block 612665 even though I still have a v2.1.1 client running with 2 peers. Can you confirm that? @sigmike
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.
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.
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?
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.