@dantheman, I'm not sure every one quite understands the quandry posed when trying to enable a "forever payout" model when using Graphene as a framework for Steemit. I'll do my best to explain, but I'm sure I'll have missed some major key points as to why such a model is a much bigger problem than most people realize. Anyone who can point out things I missed please feel free to do so.
Why the forever payout model may not be as easy to implement as some might think :
The issue at hand is a very complex one because Graphene is a very different style of framework on which to build a social media platform. It's a very resilient framework that utilizes a Peer-to-Peer system to help distribute all content and transactions via a blockchain in a highly ordered and very expeditious manner, rather than constantly querying a centralized database over and over to access content.
With that upside comes the downside of it not being meant for long term random reads and writes like most other social media frameworks. Because Steemit uses a linear blockchain to get everything accomplished (unlike wikipedia) its blocks are unchangeable once they're validated and merged with the existing blockchain.
That's pretty much the root cause of the whole long term payout issue and where the long term payout problem stems from. You can always add to the existing blockchain but you can not go backwards and simply rewrite it. Once blocks have become part of the blockchain they remain immutable and may only be referenced, but must remain unchanged to preserve the integrity of the blockchain. Adding to or taking away from an existing post's payout has to end at sometime (based on how Steemit is currently written) or it would cause a whole mess of other issues that come with running a massive decentralized database. Such an overhaul would completely negate the merits of a Graphene based Peer-to-Peer network with an immutable blockchain. (Unless someone pulls a crazy thing like Ethereum, in which case all bets are off and we all saw how well that's working out.)
The choice to use Graphene poses a bit of a quandary when utilized as a social media framework because its biggest trade off is the speed and resilience that comes from using a decentralized Peer-to-Peer network with an immutable blockchain, in favor of a much slower centralized database that can be rewritten indefinitely. Graphene was never meant to be an indexing style of framework like the ones used for platforms like Facebook, Reddit, and Wikipedia. Graphene favors lots of small transactions happening in an incredibly short period of time and by its very nature was likely (originally) best suited for a Twitter style platform and not a Reddit or Facebook style one. Steemit took a massive quantum leap in trying to bridge that gap by utilizing the methodology of a Graphene style blockchain to accomplish the best of both worlds on a decentralized Peer-to-Peer network.
That sort of thing is something that simply could not be accomplished by Facebook, Reddit, or Wikipedia because they all rely on very centralized servers to get the same job done. They do so however by sacrificing the benefits you gain from decentralization in terms of speed, resilience, and the Peer-to-Peer viability that Graphene has to offer.
Is there a perfect solution to the forever payouts model that's been proposed? I honestly don't know at this time. I'm still very much at a loss as to how this sort of thing would be accomplished given the very nature and limitations that come with using Graphene as the framework with which the Steemit platform was built.
Actually the bigger issue with the long term payout model seems to be less the technical side (which could be fixed with some changes to the platform so that no comment or vote objects need to be kept in RAM) and more the issue of limited voter attention to fight potential "payout farming" abuse.
ok, so lets focus on the non technical aspect:
the main problem @arhag mentions is the ¨payout farming:¨ abuse.
Often a discussion is based on some kind of not really tangible fear, so lets first look at the worst case scenario, that everybody is self-voting, so that we know what exactly we have to fear..
All the steem that is newly created for post rewards in the end is payed through inflation by steem / steem power holders. The more you hold the more you pay. If all would only self vote in away in the end you only get what was already yours. But that is not truly the worst case. Even worser would be if only some part of the steem holders take part in the voting process. In this case you could get some part of their cake if you selfvote. That said this worst case scenario does no sound that worse. At worst it would be some kind of micro payment platform where you can distribute your money to posts, even if they are your own posts. In the end its mainly your money you distribute. In this scenario only passive accounts would loose money, but that sounds also ok, as long as the time period they have to distribute ¨their¨ money is long enough, lets say 30 days.
Now after seeing that this worst case scenario isn't that bad, lets further look how we could even improve that:
Simple self voting itself is easy detectable through the transparency of the block-chain, so we only have to look at sybil-voting where you use more then one account. Simply creating some accounts that vote circular is also easily detectable, so they would have go through some kind of hiding strategy like using an exchange. All the time they would risk, that their self-voting strategy becomes known. In this case they could get flagged. Currently without having the ability to flag users, we could simple flag the posts of the sybil accounts and or shadow vote the sybil account. In this case they would need 2 years before they could transfer their steem power to a new unknown sybil account.
Summary:
If nearly all would just selfvote, In worst case we have a micro payment platform where you can simply distribute your ¨own¨ money. Creating Sybil accounts and hiding them is not that easy. Every-time one Sybil account becomes known you risk to loose the ability to vote for two years through being flagged / or shadow voted. In this case you would loose more then 10% for your steem holings through inflation. Under the promise that most of the main steem holders would take part in the voting at best self voters would get what was already theirs , at worse their money get trapped for two years and on top of that they would loose 10 plus percent of their steem value through inflation. That does not sound that promising for Self Voters...
That raises a great point. Permanent payouts are a huge potential pitfall in that respect. They could become a very real issue that would present their own problems when abused. I think sometimes it's completely forgotten that the money has to come from somewhere because many users are are only posting, voting and flagging in the hopes of getting paid.
There's no actual exchanging of currency between two parties (voters and posters) so no one really cares what happens as long as the platform pays them out. The money is being paid out directly by the platform itself for user participation and even the short term model has already seen it's fare share of abuse. Extending the payout period would absolutely serve to further widen the potential window for such abuse.
After all Steemit isn't bringing in any money from ad revenues (like Facebook), or donations (like Reddit) right now, so all money that goes out has to be replenished in some fashion or the platform would die a slow and very expensive death. With a market cap of $180 million USD give or take, that's a whole lot of incentive to game the system to death by abuse, bots, or any means necessary to grab as much money as possible before the whole system collapsed.
Is there a way to renew that block at specific intervals, so that the old block goes into archive, while a clone is put up for another 30 days?
That's not really how a blockchain works. A blockchain is more of a historical record, sort of like a banking ledger. It purely records the activities that took place in the past while acting as a shared ledger that everyone has a copy of and can validate the accuracy of through the use of a cryptographic algorithm. This in turn creates security through consensus of the math proofs involved. It's sort of like a recording tape without the ability to rewind and overwrite things because it would ruin the integrity of the original recording.
Cloning parts of old blocks and replaying them doesn't really work because you can't just cherry pick what's in them when you replay them. You wouldn't want to just replay the whole block because most of the data would be useless, stale data that was just being replayed and reproofed for nothing while wasting valuable computational resources. You either have to create a whole new block that consists of purely good data , or start a whole separate fork off the original chain which historically has been disastrous for some currencies. (And very thoughtfully was covered in the open source licence agreement of STEEM.)
I'm not sure if you're familiar with the Ethereum Project and the whole Ethereum, vs. Ethereum Classic ordeal but I'd give it a quick read through to see what I mean as to why "replay attacks" are a very real threat in those kind of situations. In summary the Ethereum Foundation decided to roll back their blockchain to reclaim a multi million dollar loss because of an exploited bug in their code. While some supported the rollback as a form of bailout, others did not and that's when the situation grew even more dicey.
Total chaos ensued because some people continued along the new Ethereum fork and some marched on producing work on the old Classic fork. Blocks with duplicate ID numbers were being generated and both proven to be correct which further helped rain down the chaos when you're talking about a blockchain that stores people's accounting records and wallet addresses.
It's actually a really great story and will be remembered forever in history as one of the greatest crypto blunders of all time. I was going to try and summarize everything but it's simply too complicated of a topic to cover in a one page reply.
the blockchain itself does not necessarily need to store all the content. The static content / even the updates could be stored in the Interplanetary File System. What is needed to be stored in the blockchain in the end is just a hash of the content, that doesnt sound that expensive to me.
So yes, we could create a p2p wiki, and yes we could store the hash of it in the blockchain, and yes we could allow to make micro transactions (upvotes) for all content. The main problem we could run into is, that the upvotes becomes too much to handle. But this problem we have also now...