I think it would be good for Peercoin to implement motions and leave out the automatic voting for fees. Here is my reasoning:
Democratic?
The current system involves either decisions made by a few active in the forums (1) or by the core developers (2).
Not democratic at all. The risk I do see is that the spread of Peercoins is imbalanced, likely providing a relatively minor, but different and very rich group (3) with a strong voice.
All three of the above are not very satisfactorily in my opinion.
Peercoin DAC?
But lacking a better voting system at the moment I think the voting does incentivize groups to participate. This would increase the strength of the network and benefit all coinholders.
The other consideration is that Peercoin is not a DAC. So the results of voting won’t be executed automatically by the system. As we have seen in many countries people can still ignore any referenda as long as they are not constitutional. So as long as we don’t make the outcomes of motions constitutional in the Peercoin ecosystem I don’t see a problem with it.
As said by Pillow we could all still vote with our wallet if we think the network goes into a wrong direction as a result of motion followed up or not followed up on.
Fainting votes?
It still leaves the Peercoin community with a good tool to gauge opinions from a broader group than just those active in the forum or the developers.
My only concern is that with the increasing difficulty (higher participation) the voices of small stakeholders will faint away as they won’t be able to mint any block in a short time.
I suggest to enable a way for safe mint/motion vote pooling alongside the motion proposal of course with the necessary safety nets.
Vote bursts?
The other issue I see is that NuBits is different from Peercoin as Peercoin has the ability to build up coinage, although capped. This may incentivize strategic voting, releasing ‘votes’ when crucial motions are released and not voting on less important motions. I like to see this addressed in some way in order to make the process more fair.
Looking forward to this evolving discussion. It is good that this has been raised as we need to plot a way forward for Peercoin. Motions can assist us with that.
Doing nothing is not a great option!
[quote=“Cybnate, post:41, topic:3030”]Vote bursts?
The other issue I see is that NuBits is different from Peercoin as Peercoin has the ability to build up coinage, although capped. This may incentivize strategic voting, releasing ‘votes’ when crucial motions are released and not voting on less important motions. I like to see this addressed in some way in order to make the process more fair.[/quote]
This can be partially addressed by requiring a motion get not only the majority of share days, but also the majority of blocks. In Nu share days do not accumulate for the purpose of minting. Making a similar change to Peercoin would provide further remedy to this issue, but we can address that in a motion later.
@Sunny King – Now is not the time to keep stoic and silent as the community debates this.
I’m not asking for your approval to consider this, but I’m very interested in hearing your thoughts about how introducing consensus-based voting into the Peercoin protocol is in line or out of touch with your original design.
so
* 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…
Hey guys, there is one thing which occurred to me lately. Knowing that Sunnyking is busy with models to use sidechains for data storage, I can imagine a scenario to use motions in sidechains. In that case the motion as a whole can be captured into the blockchain staying there forever. It would be a sidechain, not bloating Peercoin’s blockchain and with appropiate fees to prevent/reduce spam or tagging in sidechain.
There are advantages and disadvantages with the sidechain/motion concept, but I think the blockchain becomes more and more a tool instead of just a store of value for tokens with some value. So going forward the question is, what would be the emphasis? One could even implement both, they are not mutually exclusive. Food for thought. Just my 0.02 PPC.
Would be good to hear from SK whether they see value in adding motions the way Nubits added it or envisage other strategies to add similar functionality to the Peercoin blockchain or sidechains.
I am agree with the proposal to add motions to peercoin.
I suggest the results of voting on motions just be used as a reference instead of mandatory command for a while.
Have we discussed a potential issue of voting: “tyranny of the majority”. If someone propose a motion to damage the interests of small ppc holders and benefit large ppc holders. Can that motion possibly pass?
I can provide an extreme example: Proposal like this: Every ppc holder vote for this proposal will be able to sell their ppcs in their voting address to a group of buyers at 1.5 times market price, every one hasn’t vote for this proposal will have to sell their ppc to that group of buyers at 0.1 times market price.
I guess a rational holder will vote for this. Because they can benefit from this motion immediately, and after that, they are not stake holder any more.
I’m for variable tx fees, but I think that voting is not the right way to adjust them.
Votes are slower than automatically adjusted tx fees. It’s unlikely to impossible to do anything against (costly) spam attacks on the block chain using a voting system.
Votes need active management, gathering information, quick reaction to stop attacks, etc.
If one of the core features of Peercoin’s block chain - the small size - shall be defended against attacks a faster reaction is more useful than waiting for the results of a vote.
It was some time since I last dealt with this topic, but my mind didn’t change much until then (the whole thread might be worth reading when discussing this topic):
[quote=“masterOfDisaster, post:20, topic:1103”][…]
It has taken some time, but now I find this approach of variable transaction fees more sophisticated than a fixed rate because it can adjust the fees to the demand for transactions.
A fixed rate might fail by being too high to attract people to Peercoin OR by being too low to prevent people from swamping the network with transactions. Variable fees can adjust!
I really like a variable fee, although it might be hard to create a sophisticated algorithm.
I see more advantages than disadvantages at the moment.[/quote]
I’m totally for an adjustment in the Peercoin code: develop and create a sophisticated automatic adjustment of the tx fees; prevent spam attacks on the block chain while keeping the tx fee in “normal times” low enough to make PPC usable as backbone asset.
For that automatic adjustment you have my vote.
I’m totally against continuous voting on the tx fees.
Hard forks are generally a bad defense to any attack, I think. Remember the BTER NXT hack? : That would be an argument for embedding variable-tx-fee-by-voting into the blockchain.
What is the advantage of a var-tx-fee-by-voting system over a var-tx-fee-by-automatic-adjustment system?
I only see disadvantages.
Have you read the partly quoted post or even larger parts of the quoted thread?
Btw. - switching to either of those systems would be a hard fork…
The hard fork should be in place to make an attack unlikely. I agree that a hard fork to defend an attack is not one of the best ideas.
…relying on a proper vote to defend an attack isn’t the best idea either…
If PPC is under attack, waiting for a motion to approve a hard fork is one of the slowest ways to react. :)) I think one of us might be misunderstanding the other (could be me).
It seems to me that var-tx-fee-by-automatic-adjustment is the best way to defend against this specific bloating attack scenario.
[list]sigh I was afraid that I miss something obvious
If I try to order several approaches (no complete list!) to adjust the tx fee by speed I come to this list (from slowest to fastest):
[ul][li]Voting on an adjustment of tx fee to be implemented in a new client version[/li]
[li]Ongoing voting on an adjustment of tx fee as a mechanism that is to be integrated in a new client version[/li]
[li]Ongoing automatic adjustment of tx fee based on a sophisticated mechnism that tries to keep the number of transactions low enough to keep the Peercoin block chain small[/li][/ul]
The automatic adjustment might be able to adjust the tx fees in a very small rolling window of blocks.
If the mechanism is working well, the above could be the order for the reliability as well…
Another quote from my quite old post:
[quote=“masterOfDisaster, post:20, topic:1103”][ul][li]
In PPC the transaction fee is mandatory. It is destroyed and not paid to miners. Fees don’t incentivize the miners directly. Fees incentivize the ones who want to execute transaction to do that deliberately. This prevents the network from being swamped.
If you were in a PPC world with a variable transaction fee you could save transaction fees by waiting for a period with smaller transaction fees if the current ones were to high for your taste.
One drawback might be: the variable transaction fees can stay high or even rise if lots of transactions need to be done and are postponed until they can’t be postponed any longer; eventually they might begin to swamp the network despite the high fees.
But thinking twice this is quite similar to paying high fees for BTC transactions if you are in a hurry:
the miners (I imply the majority being PoS miners) that work (energy efficiently) on the transaction do not only get a PoS reward, but by destroying the (relatively) high fees, their share of issued PPC rises. It’s quite similar to earning high fees for processing urgent BTC transactions.
[/li][/ul]
That would kind of resemble BTC’s dependency between the point of time you think about excuting a transaction and the point of time you want to have it done:
[ul][li]
BTC: individually eligible transaction fees incentivize miners to include the transaction to the next block. You pay extra if you are in a hurry.[/li]
[li]PPC: variable and determined by the network transaction fees incentivize people to execute a transaction in a time with low fees (caused by low transaction rates). Once again, you (might) pay extra if you are in a hurry.[/li][/ul]
0.5.0 will already be a “hard” fork. A required protocol-level upgrade needs to happen to integrate the new Peercoin updates as well as carry forward the underlying Bitcoin code base to 0.8.(2?3?) Planned network forks aren’t something to be afraid of; the migration from 0.3.x to 0.4.0 earlier this year was pretty seamless from what I saw.
“Hard fork” sounds more intimidating than “mandatory update”.
In the end it’s often the same.
If the protocol gets altered in a way that renders it incompatible with previous client versions, you can either switch to the new version or remain in the old world…
As most people decide to move forward (to the new client version) in case the introduced changes are welcome, this is no problem at all - whether or not to call it hard fork
Security improvements that do not effect the overall functionality of the coin are fine with me, though this motions idea is quite substantial and changes the high level functionality of the coin. I guess cold minting could be viewed as a security improvement which doesn’t ultimately effect the overall coin specifications, but changing the transaction fee? I’m not sure about that.
Jordan withdrew the part about changing the transaction fee. This is only about implementing motion voting now from what I understand.[/quote]
That’s correct. This thread is now basically on the topic of adding motions. If that happens, we can start a new thread (with motions?) for discussion about how to deal with 1) a bloating attack, and 2) the problem of the fee not scaling with the market value of PPC.
That would be an argument for embedding variable-tx-fee-by-voting into the blockchain.