When I traded securities on btct.co, I saw quite often the issuers will propose a motion on some issues for the shareholders to vote.
I think that’s very important for peershares too.
Issuer’s peershare client running on multiple servers.
As far as I can understand, the peershares issuer has the obligation to keep his peershare blockchain/network safe and running. Therefore he need keep the client running for pos minting.
Could the issuer keep several clients running on several servers at the same time?
Probably these two questions have been answered or included in the coding of peershares.
When I traded securities on btct.co, I saw quite often the issuers will propose a motion on some issues for the shareholders to vote.
I think that’s very important for peershares too.[/quote]
A voting system for motions has been scheduled for phase 8. However, a voting system will be included in our extension of Peershares, so it is possible that could be brought back into the Peershares template prior to the completion of phase 8.
[quote=“redlee, post:1, topic:2029”]2. Issuer’s peershare client running on multiple servers.
As far as I can understand, the peershares issuer has the obligation to keep his peershare blockchain/network safe and running. Therefore he need keep the client running for pos minting.
Could the issuer keep several clients running on several servers at the same time?[/quote]
Certainly! The redundancy of this arrangement would be preferable and Peershares is designed to function in a decentralized manner like what you have described.
It would be interesting to be able to use Peershares to handle voting in non-profit organizations, each Peershare “membership” giving its owner a right to vote.
May be we’ll need to create something specific like “Peervotes” that could handle cases where number of shares differs from actual number of votes.
And we would also need some kind of time-limited Peershare to handle membership expiration/renewal.
[quote=“mably, post:3, topic:2029”]A really simple digital voting system using BIP-11/BIP-16 (multisig) has been described for Bitcoin here (in french) :
It would be really great to have something equivalent implemented in Peershares, it would be a killer feature for lots of organizations.[/quote]
We have a flexible and sophisticated voting mechanism presently implemented in the team’s extension of Peershares. We plan to pull parts of it back into the template so that motions can be voted on using the Peershares template. It hasn’t quite bubbled up to the top of our priority list but it is pretty close. My guess is we will do it before sigmike starts his Peer4commit Peershares implementation so he gets the benefit of it.
The specification and source code for our implementation are private at this time. So, unfortunately, there is no documentation available.
I can tell you how motions will work in the Peershares template though. The system will permit users to enter the hash of a motion using the user interface. The full text of the motion can be proposed by anyone and published anywhere (along with its RIPEMD-160 hash, which functions as an ID code for the motion). When the user mints a block, the vote for the motion is stored in the blockchain. If the majority of coin days destroyed and the majority of blocks contain a vote for the motion within any consecutive 1000 blocks, the motion is passed. With 10 minute block spacing, votes during a rolling 7 day period will be counted.
voting no and abstention and unable to vote are treated the same way.
Statistically holding less than 1/1000th total shares will have no voting rights because little chance to find a block in the period. Actually the chance is smaller than proportional because when the voting starts the POS difficulty will increase, and only taper back to normal towards the end of the period. The small share holders have even less integrated chance.
Those who recently have just found a POS block could lose as much as 520/1000 of their chance to vote because their stakes are still locked. There are 520 outputs to be affected this way. If there are less than 520 stakes in existence (say owned by 30 share holders of a small project) most people could be affected.
The rolling part seems to add chaos for the organizer, the finish time is not fixed when voting starts. There might be no 1000 consecutive blocks with the majority of blocks even everyone voted (yes) but the blocks just trickled in showly.
How to decide the majority part of “the majority of coin days destroyed”?
Would be more intuitive and deterministic to vote by signing somehow…
