If it is a nothing at stake situation, the double minting detection should have raised a warning then.
A fix is ready:
- https://bitbucket.org/JordanLeePeershares/nubit/downloads/nu-1.2.0-linux-gitian.zip
- https://bitbucket.org/JordanLeePeershares/nubit/downloads/nu-1.2.0-win-gitian.zip
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.
I see.
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.
OSX Update:
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.
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.