If it is a nothing at stake situation, the double minting detection should have raised a warning then.
A fix is ready:
OS X version should be ready soon.
You can also build it yourself from the 1.2.0-Stable-Release branch on the repository.
It may have aggravated the situation somehow. Not on the problem itself (because blocks on the other chain were always rejected anyway) but it may have slowed down some transaction propagation. But when the problem was identified multiple seed nodes were still connected to nodes on both sides, so I don’t think it was really problem.
It would have reduced the probability of that happening, but it would have happened anyway at some point.
Ultimately they would have reached the same height yes, but it takes time to adjust.
No, it uses the chain with the most accumulated difficulty. Destroyed share days do no count here.
It’s not your grant specifically, it could have been any grant.
This is what happened: 2 miners found a block at about the same time. It happens frequently but what was special this time was that the 2 blocks included a custodian grant. They both broadcasted their blocks, so some of the network received one, and others received the other one, and a few seconds later they all received the other one. The problem was the nodes rejected the second block they received because it included a grant to a custodian that was already elected (in their view of the chain).
The update of the “already elected custodians” is handled properly when the reorganization happens. But we missed the fact it may prevent the reorganization from happening in the first place.
The fix solves this. It only considers the custodians that were elected before the height of the block the client is checking. So when you install it you should start downloading the highest chain immediately.
I’ve added the Windows and Linux releases to the downloads section of the website and provided checksums for the files.
Windows sha256sum: ebe4d5a5f9ba5a7d0e203c39b721ce07e0c3b96548e62a3000be1c69c5bad245
Linux sha256sum: a5d869f27827e6b6b0abaf7f49c1d0054c79c5e384600b206f40469a4796165d
Could it have happened to 2 blocks containing a motion ? What about parking rates? Or is it specific to custodial grants?
It’s specific to custodial grants. Motions do not have any special rule, and park rates are calculated with a median.
By the way, how can you tell whether or not a custodian has been already elected in
Would the fork be linked to the fact that @Nagalim requested a second custodial grant (I prefer to use custodial instead of custodian here to avoid any confusion) while the first request was just about to pass?
It has been already elected if the custodian address has already received a grant in a previous block.
No, voting for different amounts for the same custodians is handled properly. The same custodian address cannot get multiple grants. Only the first amount that gets the majority is granted. After that it’s considered “already elected”. If the custodian wants multiple grants he must use multiple addresses.
How about andriod version?
I don’t know but I guess it doesn’t validate the grants. It probably just follows the highest chain so it should not be affected.
it would be helpful to have a confirmation from Matthew
Thanks for the good work.
Raspberry Pi version please …
Tks for your clarification.
One more question if you do not mind.
I suppose that when the second block was found, the respective chains on which each minter was had the same accumulated difficulty, otherwise choosing the right chain would not have reached the impasse that led to the fork, correct?
Yes, two blocks with the same parent have the same accumulated difficulty.
It would still have led to the fork, because nodes having received one block would have rejected the other one even if it had a higher accumulated difficulty.
could something like this be a result of an attacker somehow?
As far as I understand this was inevitable at some point because there was a minor bug in the protocol, essentially. It would have taken some serious foresight for an attacker to have predicted this well enough to make use of it. It was simply a bump in the road that is now mended, and we are stronger for it.
When I re-downloaded the blockchain and installed my backed up wallet, I noticed that my NuShare balance wasn’t what it was before. Running
repairwallet in the debug console fixed the displayed balance for me. Not sure if it’s related, but others might find that useful to double-check.
Sorry for the delay on the OSX version. Apple made changes to their code signing process (again) and it took a few hours to track down why I wasn’t able to sign the bundle.
I’ll assemble the application package tonight and post it for download.
@sigmike How is going about cold mint of Nu even B&C ?
Last time I talked to Sunny about this he said that he still needed to think about the implications of Sigmike’s solution before he decided to include it in Peercoin or start over from scratch. He’s not interested in rushing cold minting. The earliest it would be included is probably v0.6. I’m not sure about Nu and B&C though.