We have discovered an error in how the getmotions RPC counts motion votes. This means the vote counts as displayed in the block explorer and your Nu client have been incorrect for the open source motion. The blockchain record of votes is not corrupted in any way. Using a fixed getmotions RPC, we see that the vote to open source code only cleared 44% so far. Previous motions were properly counted. As the issue came to the team’s attention in recent days, someone began exploiting the issue which caused vote counts as reported by the getmotions RPC to become skewed. Other types of voting that result in protocol actions such as custodial grants and parking rates are unaffected by the defect. Previously passed motions are also unaffected.
The open source code motion content gives us 45 days to open the source, and it has been our plan to release it during the later portion of that time window. I’m certain that the open source motion will pass very soon with the corrected counting method so that we will still release source code within 45 days.
However, to provide clarity and fairness to those who are opposed to opening the source code, we need to keep voting on the motion. If you support the motion and have removed it from your client, please put it back. Here is the hash:
6f361693a7b248730b41d4292f89dc6f6f166bc8
A new release will be posted very soon with a fix to this issue, probably within 24 hours.
How is this possible? Either the counting is correct or not … can you please elaborate on the error?
Furthermore I also get > 50% without using the getmotions command. Running this here
def getmotions(_votespan=10000, _start = 0):
nblocks = rpc.getblockcount()
motions = {}
totccd = 0
for i in xrange(_start - _votespan, _start):
block = rpc.getblock(rpc.getblockhash(i))
totccd += block['coinagedestroyed']
for m in block['vote']['motions']:
if not m in motions.keys(): motions[m] = []
motions[m].append(block['coinagedestroyed'])
return motions, totccd
Gives 50% count, 50.77% CDD for block 229319 and is completely independent of the getmotions RPC command. So either its not only this command that’s buggy or the motion has passed. Or is the counting above wrong?
I know you are very busy and probably never read any of my posts, but this time I really would appreciate to get an answer on this. Its probably the worst case motion where this could happen because that now the core developers say that there was an error in the voting gives a lot of food for the doubters who claim that it was never planned to go open source, although this is not the case.
I was wondering about the exact same thing and I share your expectation of how this motion not having passed because of a counting error might be perceived by doubters.
I just hope the motion will have passed before the doubters get aware of that.
I agree that this is the worst motion that this discovery could have happened with. We risk harm with announcing it as we would withholding it. At least this way everything is open.
The issue stems from shareholders entering motion hashes multiple times into their client. This results in duplicate (tirplicate even) votes for the same motion. The RPC command was counting each of these as distinct votes even though, in reality, they were just single votes. This double count is now fixed in 0.5.4 and in 0.6 you won’t be able to enter hashes into the client multiple times. @creon, your code isn’t using the RPC call but it is also counting these votes multiple times instead of just once.
Scans of the blockchain indicate that this double voting has only started happening recently and has only affected the open source motion so far.
It is a pain but, to stand up to blockchain scrutiny, the motion must be passed without counting these multiple votes.
The error is the protocol allows a shareholder to vote multiple times for the same motion, and that was counted as multiple votes.
@creon your script does the same as the old RPC. The new RPC only counts unique motion votes in each block.
The proper fix is to forbid duplicate motion votes but it requires a protocol update. It will be done in 0.6.0. In the meantime we just changed the way votes are counted by the RPC.
It doesn’t affect previous motions because nobody tried to vote for multiple motions until very recently. You can verify that on the blockchain. A shareholder started voting many times for the open source motion a few days ago.
It’s my fault. When we changed the motion vote to allow multiple motions I forgot to add this check. The custodians and park rates votes are not affected because multiple votes were allowed from the beginning and the appropriate checks were implemented.
You can’t be serious And this wasn’t exploited before this motion? I can imagine that many people have duplicate entries in their motions, simply because they added it twice by mistake (its hard to distinguish them).
This bug is a perfect example how a hundred eyes are always better than only a few. It was impossible to see for anyone since nobody knew how the coinbase string was parsed internally except you - and the evil staker who apparently reverse engineered the parsing method. I am pretty sure we would have detected this problem much earlier with more people having access to the code.
So you want reject blocks with coinbase strings that contain duplicate hashes? Why not just adjust the parser to count each hash only once? That wouldn’t require a hard fork.
EDIT: Yes, as @masterOfDisaster says, thanks a lot that you are so open and I agree that there is nobody to blame here!
I’d rather say:"Shit happens!"
It might as well be your “fault” as it is the “fault” of the peer review, QA, etc.
I’m just glad that the development team did what was right and expected from them: to be open about that issue.
While forgetting to add this check was not on purpose, being open about what happened was on purpose.
So I’d like to say: everything’s right!
If anything this whole thing shows how important it is to open the source code for it allows others to check it and possibly find issues like the one Nu ran into with this motion!
I favor that because it would work without a fork and wouldn’t punish those who entered a motion hash more than once by accident…
…or do we need to disincentivize putting multiple motion hashes into a block because it can be abused for a block chain bloating attack?
I can confirm that only the open-source motion was affected and that the duplicate motions only appeared recently and most certainly on purpose.
The first block that contained a duplicate version of the open-source motion was block 223951 with 4 duplicates. The “attacker” then increased the number of duplicates in a step-wise manner to up to 13 duplicates (with few outliers):
You can already see that this a quite a large block generation frequency, and the person who did this must own a lot of NSR. And in fact all those malicious blocks were generated by the same wallet, with the main address SUKmDo6jyZ1RzFDCFRUGV6ex86x1LgjLhG. In total these addresses were involved in the blocks, which all show a connection to the main address:
ScaPHSZSFgEZScAQ5vJX8xhaw96MLkBMLB
SeoX2j3L7jN3cLq39SxLT3NZmKBTuUpzrG
SRciMBmxkDaZEaaCaU49F6yTzjhXCga6Fh
SRLnqTf8CiTq8JAeQ7p2LcYUpTT72vJAn9
SVyyqpTjSLprUBhMX3FB1XtkgqBRvgozU3
SUKmDo6jyZ1RzFDCFRUGV6ex86x1LgjLhG
So it really appears that this was an attempt to manipulate the voting on purpose by a single person with a lot of funds. Its hard to say what happened to those NSR, since they were removed from that address recently.
Vote multiple count attack - how awesome.
I guess this will make Nu definitely reliable once passed.
Thanks for the team for detecting and analysing it.
Thanks for verifying. To give some benefit of doubt, it could because someone wrote a script to add motion items to a voting script that calls nud to set vote, and has ran the first script to add the motion many times. I have a voting script but I edit it by hand.
could be, thinking of it, if done deliberately, isn’t it funny the code was reverse engineered to vote extra for a motion that would make reverse engineering not needed anymore
To NuShareholders:
Please install the new mandatory upgrade: Nu client version 0.5.4 , that fixes the way motion votes are counted, before “revoting” for the motion.
There’s only one answer that leads to a reliable situation:
an NSR owner who doesn’t want others (e.g. exchanges) to mint with his/her NSR is well advised not to have NSR outside the own wallet
As exchanges don’t have a stake in Nu, they shouldn’t mint.
One could argue that more minting increases the network security, but that is not really true.
If no exchange would be allowed to mint (that can’t be forced, though…), the ratio of minting NSR (compared to the total amount of minting enabled NSR) would only be higher (assuming you cancel the NSR kept at exchanges form the “minting enabled” NSR) if the ratio of minting NSR is low.
So it’s no big security plus (given the current difficulty and hence the minting ratio¹), but it leads to awkward situations where exchanges can follow an own agenda, which might not be in the best interest of the NSR owner - even if feeds are used!
…and they don’t even have to pay for that; instead they get rewarded by 40 NSR per block…
I can only recommend not to keep NSR at exchanges for longer than necessary.
¹ it would be crazy to find out that the difficulty is only that high because exchanges are minting like hell…
And this wasn’t exploited before this motion? I can imagine that many people have duplicate entries in their motions, simply because they added it twice by mistake (its hard to distinguish them).
