Proposal to Implement Motions in Peercoin


#1

Hello,

I’ve written up a proposal for implementing motions in Peercoin. I would like to submit this for discussion. If people are generally happy with the proposal then I plan to create a peer4commit project for the implementation of this proposal which would most likely be for Peerunity. Criticisms and suggestions are most welcome.

Matthew

[hr]
[hr]

[size=16pt]Overview[/size]

This proposal is for a protocol extension that will allow Peercoin minters to make a single yes or no vote for up-to 10 motions per block. The yes and no votes for these motions will be kept for 12,970 blocks, and vote results can be calculated over any time period up to ~90 days. A motion might for instance have 450 yes votes, 215 no votes, and 335 abstentions over a 1,000 block period. This would give 45% in favour and 21.5% against over a period of roughly 7 days. Each motion will also have a title and details that are shared by the p2p network. This would allow clients to retrieve and display the contents for each motion.

The votes of the 10 most recent Proof-of-Stake blocks will not be counted to account for potential fork scenarios and missing motion information. Each motion will have a title of up-to 50 characters, and details of up-to 5,000 characters which shall be shared by the P2P network. The motion details will use the mime type “text/plain” but different types may be supported in the future. In particular a lightweight markup language such as markdown may be used to provide better document structure to motion details with plaintext readability, simplicity and style consistency.

Proof-of-Stake blocks will include a 20 byte hash in the coinbase. This will serve as a method for minters to set their voting intention, and shall be a hash of a new “vote” message which lists votes for individual motions. Votes for up-to 10 motions inside a block will be supported. The network protocol will be extended with new messages which share votes and motion details. Compliance with the extended protocol will be signified with a new services flag.

Yes and no counts of up to 12,960 blocks will be producible for each motion. These numbers will have no effect on the protocol. They are purely informative and there is no number by which a motion is “passed”. These numbers may be used to approximate user consensus for decision making.

The terms “MUST”, “MUST NOT”, “SHOULD”, “SHOULD NOT” and “MAY” are to be interpreted according to RFC2119: http://www.ietf.org/rfc/rfc2119.txt

Occurrences of MUST should absolutely be implemented to ensure interoperability with other implementations.

Occurrences of SHOULD are not necessary for interoperability but are necessary to conform to the intended functionality of this protocol.

[hr]

[size=16pt]Rationale[/size]

There are four benefits to this proposal:

[ol][li]By introducing motions into Peercoin, it would provide a mechanism to measure user-support for controversial changes or ideas. For instance, a motion could be raised to disable Proof-of-Work in Peercoin. This would be a controversial change that may disappoint certain users, but by using a motion it would be possible to ascertain an estimate for user support.[/li]
[li]Motions would also provide user accountability for any changes. Users would have to review every motion before deciding to vote yes, voting no or to abstain. Votes would act as a useful source of feedback and may highlight ideas that would need changing to obtain enough support.[/li]
[li]By requiring a block for a vote, it would encourage user’s to mint, thus providing a potential side benefit for the health of the network.[/li]
[li]By sharing motion details between peers, reducing blockchain bloat, and providing a distinction between “no” votes and abstentions, this proposal is arguably more powerful than the motions in NuBits. This would demonstrate an additional level of innovation into Peercoin and may spark new interest.[/li][/ol]

Bitcoin has had controversial changes and proposals, especially with P2SH and increasing the blocksize limit. The bitcoin developers measure miner support to decide protocol changes. By only taking into account miner votes, the day to day users of bitcoin are alienated from the decisions of big protocol changes. It has been demonstrated with the likes of NuBits and BitShares that it is possible to utilise a user’s stake to vote instead.

NuBits uses a Proof-of-Stake system derived from Peercoin and currently measures motion votes through the number of supporting blocks and number of Share Days Destroyed (SDD) used in minting blocks. A motion is said to be passed if both the number of supporting blocks and the number of SDD surpasses 50%. It is planned for SDD to be removed from NuBits voting however (link). This is because it is possible for a user to save up share days to give unfair weight to future motions. If coin-days were similarly used to measure support for Peercoin motions a similar problem may arise. As minting probability is proportional to coin ownership, one-vote-per-block would be sufficient, as it has been for NuBits. Therefore only block votes are used in this proposal.

Motions for Peercoin was initially suggested by [member=17446]Jordan Lee[/member] in this topic (link). It was suggested that both the motion and transaction fee voting mechanisms in Nu be ported into Peercoin. This proposal is only concerned with motions. There are several reasons why the Nu motion voting code should not be used:

[ol][li]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.[/li]
[li]NuBits does not distinguish between “no” votes and abstentions. For decision making it is helpful to know the extent to which users are explicitly against a motion. If a motion has 70% support and only 2% against, it may be considered low in controversy, but if a motion had 70% support but 20% against, that would imply a large amount of disapproval. The only way to measure this is to have an explicit “no” vote.[/li]
[li]NuBits provides only motion hashes over the p2p network. The details corresponding to these hashes are stored on the NuBits forums. Whilst there is no problem with this, providing the motion details over the p2p network would enable powerful uses of the protocol. Motion details can be verified and displayed within the client to a user, so that they can read and then decide to vote for a motion within the same application.[/li][/ol]

As a result, motions for Peercoin should be implemented from scratch. As this votes are designed to be informational, votes may be counted over any period of up-to 90-days.

[hr]

[size=16pt]Issues[/size]

When outputs are spent, the coins lose their age and prevent the ability to mint blocks and therefore vote. Potential solutions for this include:

[ul][li]Maintaining coin age for outputs that send to an input address.[/li]
[li]Reducing the minimum coin age, so that minting becomes possible earlier.[/li]
[li]Reducing the maximum coin age, so that the highest probability for minting comes earlier.[/li][/ul]

[hr]

[size=16pt]New and Changed Protocol Messages[/size]

The messages are described using the data types used by the C++ client. This section contains some protocol rules for messages.

version: Add a new services flag with 1 << 3, named NODE_MOTIONS. This flag MUST be set in “version” messages sent to peers that an implementation intends to communicate with according to this protocol. An implementation SHOULD prioritise NODE_MOTIONS peers for at least two connections.

block: When providing a vote inside a block, the block MUST be a Proof-of-Stake block, the version MUST be set to 2 or higher, and the coinbase transaction MUST have a uint160 added to the scriptSig after the block height. This MUST be the RIPEMD-160 hash of the SHA-256 hash of the “vote” message associated with this block, ie. RIPEMD160(SHA256(votemessage)). No additional block validation rules are defined in this protocol, but note that version 2 blocks will require block heights in coinbase transactions, and a vote is invalid if these rules are not followed.

votes:

[ul][li]vVote (vector): A vector of vote messages, for each requested block. This MUST NOT exceed 12,970 votes and MUST contain at least 1.[/li][/ul]

vote:

[ul][li]vMotionVotes (vector): A vector of “motionvote” messages. All motions MUST have unique hashContents. This MUST NOT exceed 10 “motionvotes” messages, and MUST contain at least 1.[/li][/ul]

motionvote:

[ul][li]hashMotion (uint160): Hash of the motion message. When creating a new “motionvote” message an implementation MUST be able to produce the “motion” message corresponding to this hash.[/li]
[li]fFavour (bool): true if voting yes, false if voting no.[/li][/ul]

getvotes:

[ul][li]setVoteHashes (set): A set of the hashes of required vote messages. This MUST NOT exceed 12,970 hashes and MUST contain at least 1.[/li][/ul]

motion:

[ul][li]strTitle (string): A short title for the motion. This MUST NOT exceed 50 characters and MUST be 5 characters or more.[/li]
[li]nContentType (unsigned short): 0 explicitly for text/plain. For all other numbers an implementation SHOULD assume text/plain. Other types may be added in the future.[/li]
[li]strContent (string): The motion details. This MUST NOT exceed 5,000 characters and MAY be empty[/li][/ul]

There is a new inventory type named MSG_MOTION with the value 4. This MUST be used to acquire motion details only. An implementation MUST respond with known motions in response to “getdata” for every MSG_MOTION inventory item.

[hr]

[size=16pt]Protocol Logic[/size]

When Counting Votes

An implementation SHOULD be able to count the votes over a window of 1-12,960 blocks starting from the block that is 10 blocks back from the blockchain head block. The most recent 10 blocks SHOULD not be counted.

Votes for each motion can be counted by using the “vote” message corresponding to the vote hash in the coinbase scriptSig of a block. The vote hash is the second push operation in the scriptSig. Votes SHOULD not be counted for vote hashes without a corresponding “vote” message, or for blocks without a vote hash. Votes SHOULD be counted over a number of Proof-of-Stake blocks, including Proof-of-Stake blocks without a vote. Proof-of-Work blocks SHOULD NOT be counted.

After Connecting a Proof-of-Stake Block

The inventory for blocks containing a vote MUST be broadcast to all NODE_MOTIONS peers.

After Disconnecting a Proof-of-Stake Block

An implementation MUST keep at least 10 of the most recent vote messages that are no longer found in the last 1,010 blocks due to a block disconnections. This is for the case that blocks are reconnected again.

“vote” messages that are not contained in the last 12,970 blocks and are not retained due to block disconnections, MAY be discarded. “motion” messages that no longer exist inside any retained “vote” messages MAY be discarded.

After Connecting the Best Block With Full Synchronisation

An implementation MUST send a “getvotes” message containing the vote hashes of ALL missing “vote” messages. If the peer that provided the best block has NODE_MOTIONS set, the message MUST be sent to that peer. Otherwise the message MUST be sent to another peer with NODE_MOTIONS, if such a peer exists.

“vote” messages MUST NOT be requested for blocks that do not conform to the protocol rules. For example a uint160 after a block height in a coinbase scriptSig does not constitute as a vote hash if the block has the version 1 or if the block is a Proof-of-Work block.

When Receiving a “votes” Message

An implementation MAY ignore the message if it does not conform to the protocol rules, and MAY penalise the peer for this. Otherwise an implementation MUST read each vote in the message. An implementation MUST retain “vote” messages which correspond to vote hashes in any of the last 12,970 Proof-of-Stake blocks.

If there are any new motions found in the necessarily retained “vote” messages, then an implementation MUST ask for these motions by sending as many “getdata” messages as required to the peer that provided the “votes” message.

When Receiving a “getvotes” Message

An implementation MAY ignore the message if it does not conform to the protocol rules, and MAY penalise the peer for this. Otherwise an implementation MUST respond with a “votes” message for every “vote” message that exists and corresponds to a hash inside the “getvotes” message. If there are no “vote” messages to provide, then a “votes” message MUST not be sent.

When Receiving a “motion” Message

An implementation MAY ignore the message if it does not conform to the protocol rules, and MAY penalise the peer for this. Otherwise an implementation MUST retain the message if it corresponds to a motion hash contained in a retained “vote” message.

When Minting a Block

The version for new blocks SHOULD be 2, and MUST be 2 when voting. A correctly formatted “vote” message MUST be created when voting and MUST follow the protocol rules. Every included motion hash MUST have a corresponding “motion” message and these “motion” messages MUST be kept for as long as they exist in one or more retained “vote” messages. The “vote” message for a block vote MUST be retained as if the message was given by another peer. When voting, the hash of the vote message MUST be placed after the block height in the coinbase scriptSig, and the push operation SHOULD be as compact as possible. This hash MUST be calculated by first calculating the SHA-256 hash of the entire “vote” message and then calculating the RIPEMD-160 hash of the first hash.

Votes will only be counted for Proof-of-Stake blocks.

Every 30 Seconds After Requesting Votes/Motions

If there is one or more missing “vote” messages, an implementation SHOULD send a “getvotes” message with the missing vote hashes to a peer that has NODE_MOTIONS. The peer SHOULD be different to the previous used peer if possible, and the best block height at the time that the message was last sent to this peer SHOULD be lower than the most recent block which contains a missing “vote” message.

If there is one or more missing “motion” messages, an implementation SHOULD send a “getdata” message with the missing motion hashes to a peer that has NODE_MOTIONS. The peer SHOULD be different to the previous used peer if possible, and each peer SHOULD only be asked once until new motions are discovered.

[hr]

[size=16pt]RPC Commands[/size]

setvote “motionHash” favour (“title” “contents” “contentType”)

Used to vote yes or no to a motion whilst minting. If this is a new motion, the motion details can be provided. If no details are provided then the motion must have been included in the last 12,970 blocks.

Arguments:

  1. motionHash (string, required): Hex of the motion hash.
  2. favour (boolean, required): If true, vote yes for this motion. If false, vote no for this motion.
  3. title (string, optional): Title of the motion, with 5-50 characters.
  4. contents (string, optional): Contents of the motion, up to 5,000 characters. Can be empty.
  5. contentType (string, optional, default=“text/plain”): The mime type. Only text/plain is currently supported. Any other input will be assumed text/plain.

Errors:
-31: Too many votes.
-5: The motion does not exist.
-25: Motion details do not match hash.

unsetvote “motionHash”

Removes a vote for a motion with a particular hash.

Arguments:

  1. motionHash (string, required): Hex of the motion hash.

Errors:
-5: motionHash was not set.

clearvotes

Removes all motions from voting.

getselfvote

Gives a list of motions that are being voted for.

Result:

[
{
“motionHash”: (string) Hex of the motion hash.
“favour”: (bool) true if voting yes, false is voting no.
}
,…
]

getvotes (numBlocks)

Gives a list of all motions and their vote counts.

Arguments:

  1. numBlocks (numerical, optional, default=4320): The number of blocks to count. The default gives roughly 30 days of data.

Result:

[
{
“motionHash”: (string) Hex of the motion hash
“yes”: (numeric) The number of yes votes out of numBlocks.
“no”: (numeric) The number of no votes out of numBlocks.
}
,…
]

getmotiondetails “motionHash”

Gives the details for a motion.

Arguments:

  1. motionHash (string, required): Hex of the motion hash.

Result:

{
“title”: (string) The title of the motion.
“content”: (string) The content of the motion.
“contentType”: (string) “text/plain”
}

Errors:
-5: The motion does not exist.


#2

Hi Matthew,

Nice work you did there.

But could it be possible to start by describing what we want to achieve and only after explaining how we could do it?

I’m a bit lost.

Thanx for all.


#3

Hi [member=30453]mably[/member].

I’ve added a rationale section which explains why I’ve chosen to do things in certain ways, and it also describes some of the benefits and uses.

Hopefully that helps. But if you have any specific questions please ask.

Matthew


#4

Will have to actually sit down and read this soon…but I really like the idea of having a voting mechanism! :smiley:


#5

if the data is to be stored off-chain: is it centralised somewhere then for hackers to tweat the data?

O Wait, the hash is stored on chain, thats the essential part

carry on then


#6

i like the idea, if only to see some peercoin-related development/activity. however i would defer to the opinion of more technical/expert members for more insightful analysis. i would also be interested in hearing sunny king’s thoughts. [member=31330]MatthewLM[/member], thank you for taking the time and giving this your attention…


#7

Created a related page on the Peercoin wiki: https://wiki.peercointalk.org/index.php?title=Proposal_to_Implement_Motions_in_Peercoin


#8

I like it. I have some questions which admittedly may already have been answered in op.
How can this protocol be broken to manipulate voting results? Could I feasibly generate a ton of wallets, drop some coins, and then vote however I see fit? How is this mitigated by the current design proposed?
Is it fair and balanced, or does it favor certain coin holders (people with more coin matter more)?
I realize that we may be unable to implement the perfect voting system, I just want to make sure it’s as close as possible.


#9

[quote=“fishb0ne, post:8, topic:3667”]I like it. I have some questions which admittedly may already have been answered in op.
How can this protocol be broken to manipulate voting results? Could I feasibly generate a ton of wallets, drop some coins, and then vote however I see fit?
Is it fair and balanced, or does it favor certain coin holders (people with more coin matter more)?[/quote]

Vote is directly related to minting. You can cast up to ten motion votes with each block you mint.

Obviously big coin holders have more chance to mint with their coins than smaller ones, so more chance to cast some votes for the motions they support.


#10

If I understand this right, the system tends to, in a sense, favor the rich? I have mixed feelings about that. I think the mechanism should guarantee in some way that as long as a wallet is not empty, the owner has a chance to cast at least one vote and get their voice heard. Otherwise, I just don’t think this system solves for the more elegant and straight forward approach of rallying the community to contribute on this site.


#11

The problem is not to rally the community to contribute on this site but rather to find a way to communicate with the people who are securing the Peercoin network by minting and get their point of view on the future developments of the coin. They are the ones in control in some way.

And it’s only some kind of advisory vote.


#12

Ah! Gotcha! Then if that’s the scope and aim, I think it fits.


#13

The problem is not to rally the community to contribute on this site but rather to find a way to communicate with the people who are securing the Peercoin network by minting and get their point of view on the future developments of the coin. They are the ones in control in some way.

And it’s only some kind of advisory vote.[/quote]

Yes, this is how I see it. Right now we have no way of knowing how minters feel about any Peercoin related topic. Implementing a voting mechanism gives us the ability to directly communicate with the main people who are currently securing the Peercoin blockchain. And we know it is these people because they are the ones who are producing blocks with yes or no votes in them.

I think voting in Peercoin would be different than voting in Nu. Nu is a business, so shareholders with a larger stake or ownership should get more of a say in how that business is run. The majority rules, as a motion is considered passed when 51% is hit. Peercoin is not a business though, so I don’t think earning 51% should consider a motion passed. At best, I think it’s an advisory vote as Mably called it. It wouldn’t be the final say about whether something gets implemented or not, rather it’s a way to take the temperature on how Peercoin minters feel about a certain change or improvement. Once you have the results, then you can go from there and either reject it or plan for implementation, including raising funds for development.

Matthew, my question is if you’re going to make a motion for this to implement in Nu as well. Finding a way to separate “No” votes from abstentions is important I think.


#14

[member=31330]MatthewLM[/member] I have been thinking about your proposal tonight and here is what came out of my reflexion:

Once vote messages are discarded by peers there is no way to interpret those coinbase scriptsig vote hashes anymore, they become definitely meaningless and all corresponding motion votes are definitely lost. I find it a bit annoying.

I am also a bit wary about the endless voting period, I guess we are supposed to calculate and keep around the max number of votes (and probably the corresponding best block height) for each motion until there is no more vote over the sliding 1000 blocks window.

Another point that probably needs a bit of improvement is the way we are supposed to notify minters of the availability of a new motion. Looks like they have to watch for new motion in every new PoS block they received via the vote message.

What if I am a small holder and still want to push a motion but won’t be able to mint before months? Shouldn’t there be a way to push for a motion without minting a coresponding vote message first?

It also looks like keeping all these NODE_MOTIONS nodes perfectly in sync might not be an easy task. These two vote message fetching on new PoS block connecting sound a bit like a point of failure to me and that vote counter handler might be a bit complex to implement.

I think it would be great to find a way to be able to count votes in an “offline” way. May be a motion hash could be published by anyone using some kind of OP_RETURN tx output with a rather high fee to avoid spam. The voting period for this motion would start X (to be determined) PoS blocks after the block containing the motion tx and would last 1000 PoS blocks. Voters would combine in a deterministic way all the motion hashes they vote for in a single hash they would add to their coinbase tx scriptSig. They would also append to the scriptSig the number of votes (<10) and a bloomfilter containing all the motion hashes they voted for. This would allow us to calculate later on the number of votes for a specific motion as long we are able to identify the tx containing the motion hash and so the corresponding voting period.

The bloomfilter would allow us to identify some matching motion hashes from all the valid motion hashes for that specific block (motion voting periods the block is included in) with a small percentage of false positives. As we also have the number of votes in the scriptSig and as we know that all the motion hashes have been hashed in a deterministic way, it will be easy to eliminate the false positives after testing a few combinations and identify the exact motion vote hashes.

I’m not even sure to understand what I’m writing here :wink:

EDIT: My proposal on the Peercoin wiki: https://wiki.peercointalk.org/index.php?title=Simple_motion_voting_mechanism_for_Peercoin


#15

Thanks for the replies everyone. I’ll try to respond to each thing not already addressed.

I made a reply on the Nubits forums that I can see you have seen. A motion could be raised for Nu, though I think some discussion is needed first. Perhaps another topic should be started for that.

A node may choose to keep vote messages around, though there is no need to keep them other than for archival purposes. So keeping them is no requirement of the protocol.

Only the first 1,000 blocks of the last 1,010 PoS blocks have the vote messages counted. I see no issue with a endless voting period. Motions themselves might contain a time-limit proviso in their details, but otherwise I see no reason why not to allow motions to be voted for at any time.

[quote=“mably, post:14, topic:3667”]Another point that probably needs a bit of improvement is the way we are supposed to notify minters of the availability of a new motion. Looks like they have to watch for new motion in every new PoS block they received via the vote message.

What if I am a small holder and still want to push a motion but won’t be able to mint before months? Shouldn’t there be a way to push for a motion without minting a coresponding vote message first?[/quote]

Good point, I shall think about this tomorrow. Though maybe it would be sufficient to post the details on-line for other minters to set into their clients.

Can you please explain? Do you mean about fetching the vote messages to increment and decrement vote counts? This should be no issue unless you have located a flaw?

[quote=“mably, post:14, topic:3667”]I think it would be great to find a way to be able to count votes in an “offline” way. May be a motion hash could be published by anyone using some kind of OP_RETURN tx output with a rather high fee to avoid spam. The voting period for this motion would start X (to be determined) PoS blocks after the block containing the motion tx and would last 1000 PoS blocks. Voters would combine in a deterministic way all the motion hashes they vote for in a single hash they would add to their coinbase tx scriptSig. They would also append to the scriptSig the number of votes (<10) and a bloomfilter containing all the motion hashes they voted for. This would allow us to calculate later on the number of votes for a specific motion as long we are able to identify the tx containing the motion hash and so the corresponding voting period.

The bloomfilter would allow us to identify some matching motion hashes from all the valid motion hashes for that specific block (motion voting periods the block is included in) with a small percentage of false positives. As we also have the number of votes in the scriptSig and as we know that all the motion hashes have been hashed in a deterministic way, it will be easy to eliminate the false positives after testing a few combinations and identify the exact motion vote hashes.[/quote]

I think this would add significant complexity, extra bloat and requiring fees to vote is not ideal. Keeping as many things off the blockchain in as efficient and simplest a way as possible was important when deciding upon my proposal.


#16

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.


#17

[quote=“MatthewLM, post:15, topic:3667”][quote=“mably, post:14, topic:3667”]I think it would be great to find a way to be able to count votes in an “offline” way. May be a motion hash could be published by anyone using some kind of OP_RETURN tx output with a rather high fee to avoid spam. The voting period for this motion would start X (to be determined) PoS blocks after the block containing the motion tx and would last 1000 PoS blocks. Voters would combine in a deterministic way all the motion hashes they vote for in a single hash they would add to their coinbase tx scriptSig. They would also append to the scriptSig the number of votes (<10) and a bloomfilter containing all the motion hashes they voted for. This would allow us to calculate later on the number of votes for a specific motion as long we are able to identify the tx containing the motion hash and so the corresponding voting period.

The bloomfilter would allow us to identify some matching motion hashes from all the valid motion hashes for that specific block (motion voting periods the block is included in) with a small percentage of false positives. As we also have the number of votes in the scriptSig and as we know that all the motion hashes have been hashed in a deterministic way, it will be easy to eliminate the false positives after testing a few combinations and identify the exact motion vote hashes.[/quote]

I think this would add significant complexity, extra bloat and requiring fees to vote is not ideal. Keeping as many things off the blockchain in as efficient and simplest a way as possible was important when deciding upon my proposal.[/quote]

In fact I think it’s quite the opposite, I’m keeping most of it off the blockchain and off the peers. To simplify, only minters could be allowed to add that OP_RETURN output to their coinbase tx for no extra fee in order to keep things under control. My solution would also totally remove the need for most of all theses voting messaging stuff, we coud eventually keep the motion part, but it is not required. Implementation would become extra simple, no need to handle special type of NODE_MOTIONS nodes etc. Each compatible nodes would just need to track all on-going motions if they want to be able to show some live voting stats to the user. And all data stored in the blockchain would still be useable even after the voting period end as long as you have kept the motion hash you are interested in, even if you are not running a compatible node.

In your proposal, all data stored on chain becomes pure junk once all peers have discarded the related data from local storage, that’s what annoys me the most.

And in my point of view, it is not really clear how you start the voting process and handle/measure the voting results.


#18

[member=5782]mhps[/member]: I agree. If the number of stored votes were done over a 12,970 block window that would provide the ability to determine votes over 90 days, and unless minters were spamming the network with loads of motions, there should still not be much of a storage requirement. Implementations can choose to display votes over different time periods, 7 days, 30 days, 90 days etc. The getvotes RPC command could take a block window as a parameter (defaulting at 30 days?). The getvotes message could be just over 250kb but that should be fine. I’d be happy to change the proposal for that.

[member=30453]mably[/member]: The problem with using a bloom filter is that even a small number of false positives would quickly increase the number of combinations of motions. And anyone could deliberately create motions and bloom filters with many false positives. The number of combinations can get very high very quickly especially with up-to 10 motions a vote.

If we accept that bloom filters are not the way to go, keeping all vote messages and all motion details would make synchronisation more tricky as nodes would have to synchronise the entire history, and nodes would have to deal with missing vote messages and motions. Sharing only the most recent votes makes things simpler and more efficient. If the entire history was shared instead, then nodes ought to request vote messages in reverse order, so the most recent are synchronised first. Do people think it is worthwhile synchronising and storing the entire history?

Perhaps broadcasting motions could be done by a transaction as you’ve suggested. By placing a OP-RETURN transaction of the motion hash (to reduce spam) it would allow a peer to share the motion details without it being ignored. As it stands motions would become public only after minting a block which can indeed take a long time for some people.


#19

[member=31330]MatthewLM[/member] are you talking about misbehaving minters here? I guess we could throw away suspicious bloomfilters with two much false positives. I found out that for 10 motion hashes (max) and a 20 bytes bloomfilter we should only get about 4% of false positives. So theorically we could stop processing the bloomfilter and discard the vote as soon as we get more than 11 matches.

In fact there is nothing to synchronise as everything is available in the blockchain, except motion details.


#20

4% false positives is a lot. If we say there is 10 motions that are not included in the bloom filter then you have a 5.8% chance of getting more than 1 false positive. You would end up probabilistically throwing away votes and the more motions there are the worse it gets.