It’s the opposite, the bloomfilter contains at most the 10 motion hashes.
I used 10 as an example. If there were say 100 motions outside of the vote, then you have a 91% chance of more than 1 false positive, and a 77% chance of more than 2 false positives.
10 is the maximum number of motion votes you can have in a vote as you specified.
The bloomfilter contains the hashes of the motion being voted for only.
I know, but you will have other motion hashes that you must test against the bloom filter. The more of these you have the worse odds you get too many false positives.
Ok I see, I guess we will have up to 2000 motions running up at the same time, what numbers does that give?
About a 50% chance that you would have 80 or more false positives.
You are right, that’s quite a lot 
It would be far simpler to just store the 10 hashes in the scriptSig then.
So it seems the bloom filter false positive rate might actually be low enough at 160 bits (0.046%), assuming the number of voteable motions at any one time is low enough, and potentially something along those lines could work, though it would be complicated and less efficient in my opinion. I’m going to stick to the original solution but [member=30453]mably[/member] is free to champion an alternative.
[quote=“mhps, post:16, topic:3667”]This is great.
This should not be called motions in Peercoin, but voting in Peercoin, as the functiion is not to set anything in motion.
1000 blocks (~7 days) window is way too short to encourage people to vote. Most stakes find a block in 2-3 months. I bet many people read the forum once a week. I think a 30-day window is good. Since the voting is for information only, I don’t see any problem to provide 7-day, 1-month, and 3-month statistics.[/quote]
+1
I’ve changed the number of blocks to 12,970 (~90 days) such that any number of votes up-to that number of blocks can be counted. I’ll think about the OP_RETURN transactions for raising motions at some point.
Right. As Treebeard said - no need to discuss it unless it takes a long time to discuss. 
Coin game brings up a good point about tertiary voting systems. Basically, if actions are taken due to a block chain vote then a formal definition of consensus needs to be reached, which cannot effectively be done if an abstain vote is allowed. If actions are not taken in any way, then the block chain vote has no value or purpose.
Removing an abstention would require minters to vote for every single motion. I’m sure most would agree that this is undesirable.
A person that raises a motion may use the voting mechanism to implement provisos (ie, “I will do xyz, if there is x% or more yes votes for this motion”), however the mechanism is designed to be informational. That does not make it useless. It helps to inform decisions by gauging the level of support or controversy for a particular motion. Think of it a little like market research. Maybe more formal voting thresholds can be set for particular types of motions in the future, though requiring minters to vote is going too far in my opinion. A message advising users to vote would be better than mandatory voting.
[quote=“MatthewLM, post:1, topic:3667”]There are several reasons why the Nu motion voting code should not be used:
Vote information is stored in the NuBits blockchain. To prevent blockchain bloat this proposal suggests that the vote and motion information is stored outside of the blockchain. Only a 20 byte hash will be stored in each coinbase scriptSig. Only the most recent voting information needs to be kept, making this proposal space efficient.[/quote]
NuBits only stores a 20 byte hash on the blockchain, just like this proposal. I don’t see how there is a difference between the two approaches in terms of the amount of blockchain space used. The approach proposed here would require quite a bit more use of network bandwidth and opens the network to denial of service attacks using the new votes, getvotes and motion messages. In the NuBit protocol, every message must either contain a transaction fee or be signed by a custodian elected within the last 6 months. These new messages don’t have the kind of restrictions needed on them to prevent spamming the network.
While I can appreciate why an abstention is intuitively appealing, it incentivises apathetic voting. It also opens up a number of difficulties when determining whether a vote passed or not. If 70% abstain, 20% vote in favour and 10% vote against a motion, does it pass?
It is certainly optimal to present motions directly to the client. NuBits doesn’t do this right now, but it has long been the plan to have data feed providers send the content of motions to a client. This will be done outside the scope of the NuBit network, thereby avoiding use of NuBit network bandwidth and the associated risk of a denial of service attack.
I strongly favour the proposal to add motion voting to the Peercoin network, but I believe the implementation provided by Nu and B&C is more elegant, does not require as many bandwidth resources and does not open a vector for denial of service attacks.
I would change one thing about the motion system as implemented in Nu and B&C. I would use a shorter hash, perhaps only 10 bytes. The purpose of the hash is to allow verification of motion content and to distinguish motions from one another. A 10 byte hash is sufficient for these purposes, but has the advantage of using less blockchain space.
I support the idea of voting in the Peercoin blockchain, but do have similar questions and reservations as Jordan and others raised. Jordan’s example can be explained as that people don’t care and let the minority decide, or that a discussion is still going and most haven’t arrived at a decision or anything in between.
Given that it is a advisory vote, in Holland smart politicians call that a non-binding referendum so they can choose to do what they want depending on the outcome, it might be not that important anyway and therefore the question raises what the benefits would be to implement it. Current implementation sounds like a unscientific street poll. We just hear from some random passerby’s (minters) what they think. If that is the intention to start with, then it is fine.
Thanks [member=17446]Jordan Lee[/member] and [member=28779]Cybnate[/member]. I’m tending to agree with many points.
Nu uses 20 bytes per motion, and additional space for custodian votes, park rates, and fee votes. There has been some concerns over adding voting data to the blockchain before, though in reflection I do agree that it would be worthwhile adding the data to the blockchain, as it would be simpler. The votes would also be stored permanently inside the blocks. The Peercoin votes can be based on the Nu votes but only including the motion data as previously suggested. This would give 19 bytes per block plus 20 bytes per motion vote.
I would suggest adding an extra byte per motion to support the yes/no distinction. There is no way around abstentions. Nu simply counts them as “no” votes, but this still involves users who are apathetic and are not explicitly against a motion. Abstentions can be counted as “no” votes in Peercoin as well, but why not add an explicit “no” as well? It provides more information at little cost. It only requires a byte per vote and adds little complexity.
A benefit to using a single 20 byte hash in every block may become realised if significantly more data is attached to blocks in the future. But for motion votes I’d be happy with just adding the votes to a coinstake output, as Nu does it. Do people think leaving no more than a few KB on the blockchain would be reasonable for sharing motion details? It would only be done once per motion and each KB would come at a transaction fee cost. Motion details can be compressed to save on space. The proposal I came up with was largely biased on fears of adding blockchain bloat, but the motion votes will not add much data and new motions would be sparse.
Using 10 bytes for a motion hash may seem to open up collision attack possibilities, but if motions are advertised on the blockchain, then the first motion to be advertised can be considered the correct one. Any future collisions can be ignored. Only accidental collisions need to be avoided, and therefore using 10 bytes seems to be a good idea and would save on space.
I would suggest adding an extra byte per motion to support the yes/no distinction. There is no way around abstentions. Nu simply counts them as "no" votes, but this still involves users who are apathetic and are not explicitly against a motion. Abstentions can be counted as "no" votes in Peercoin as well, but why not add an explicit "no" as well? It provides more information at little cost. It only requires a byte per vote and adds little complexity.
I think this makes sense to do, if only to provide more information on how many people actively voted no, rather than how many abstained by minting without voting. Like in Nu, over 50% vote in favor would mean the motion has passed while no votes and abstentions would both count as votes against. For example, if 55% vote yes, 10% vote no and 35% abstain, then the motion will pass with 55% in favor and 45% against. For a second example, if 40% vote yes, 30% vote no and 30% abstain, then the motion will fail with 40% in favor and 60% against. No votes and abstentions continue to count as votes against the motion. Adding the extra data will simply allow us to know specifically how many people actively voted no.
[member=890]Sentinelrv[/member]: Indeed. Decisions can be made in various ways, including an over 50% yes vote. Having the no/abstain distinction does not remove any information but it does add additional information that may prove useful.
I agree. We’ve had some challenges in Nu because of the blurred lines between an explicit “no” vote and an “abstain” vote. I think PPC would benefit from this extra bit of information, even if it makes calculating a majority less clear.