Here is an important aspect of blockchain technology that shouldn’t be taken lightly. I’m talking far off into the future, but this is some thing that visionaries now should be prepared for…
Even if this becomes an issue after we’re all dead, and future generations need to deal with it.
Blockchain pruning and reorg will eventually happen. If you plan for storage space, speed, and computers of the future to handle blockchain size (Moores Law) it is irresponsible in the early stages of designing Peercoin to hope that works out.
None of us know how many transactions will happen in the future if this becomes adopted worldwide. None of us know how large blockchains will grow.
An example:
Some one mined Peercoin early on, generated 500,000 peercoin, and even shows up in the forum and admits, yes, I was a whale, I had 500,000 peercoin, but my hard drive died, I had no backup, and those 500,000 peercoin never minted a block as a result. That 1/2 million peercoin are now lost. I will not use them, they will never be recovered, they are dead.
Now fast forward 100 years (yes, all of us reading this are dead too), our grandchildren’s children are dealing with the blockchain in some new ways that would blow our minds.
Why couldn’t the protocol burn those 500,000 peercoin and re-distribute them into the system?
Now at this point, we were talking about OP_RETURN. I chose this example to lead with, so you could see how there will be future reasons to burn wallets, OP_RETURNS, etc, to slim the blockchain at a future date.
The novelty in all of this, is being awake and aware of the future even though none of us see a need for it now. What it does do, is build longevity into the system.
All of these forked PoS coins are so worried about what will sell today, or be useful today. Since Peercoin is the mother of these PoS implementations, I think it is only prudent that we take a different approach and build into our blockchain responsibility, especially when we add new data to the chain on the next fork.
This is a subject that needs attention now, and needs to be an issue ongoing as Peercoin evolves and develops. If we’re the ones building a “green” version of low energy, low space utilization, then my thoughts on this are not strange.
mhps wants old records kept. That’s fine, old records can be kept, perhaps on a side chain, or on an official “archive” chain.
But I will tell you, in 100 years from now, some PeerMessages sent, where the PeerMessage developer tells you himself, that his OP_RETURNS will probably be no longer necessary on the official chain in 1-2 years needs to be heard loudly.
In 99 years from now, we don’t need that PeerMessage OP_RETURN. All I asked for is one a 1 byte flag.
How is it that we an happily introduce 80 bytes for OP_RETURN, but not a 1 byte flag?
By the way, on my first example, about the 500,000 whale address that could be burned. I believe that if a wallet holds coin, generates 0 stake after 5 years, does 0 transactions after 5 years, we should be able to burn that wallet balance and redistribute it to minters or miners.
A wallet balance without minting or mining, or moving, doesn’t need to live on the blockchain for 10,000 years. It’s obviously a rogue balance that needs to be pruned or burned.
All of what I’m proposing seems like a non-issue since what we have is working and suits our needs today.
To be a sincere pioneer in the industry though, these are issues that need to be addressed in the early stages. We should not leave problems for future generations if we can avoid it.
[size=14pt]My last example is spam and email. [/size] Early internet RFC’s didn’t think about abuse of email and spam. No realization of abuse of email was properly written into early RFC’s, and now you know why spam is as bad as it is… It’s a plague. Their attitude was “we don’t see it, and if it does happen, then future can deal with spam and email”.
Well we still haven’t solved this spam problem properly either (filtering minimizes but doesn’t solve it). Email authentication should have happened from the start. It didn’t.
Peercoin is still very new, and its technology has been adopted numerous times via multiple forked coins. Let’s put some real thought into this, so if Peercoin outlasts my life time or yours, we knew we did the best we could to prepare for future generations.
Here’s the immediate benefits:
-
We’ll be unique to Bitcoin, because we’re planning for the future even more than they are
-
We’ll prove ourselves as a real backbone, since we’ll continue to minimize our chain. Any one can add more bytes to their chain for this feature, or that option. But to be able to be self-pruning, or self-burning later, because we took precautions now means we’ll thank ourselves later.
-
PPCMAN is asking for a 1 byte flag. Heck, it can even be an “optional” flag, that no one must abide by. But at least give sidechain developers who use OP_RETURN a chance to set a 1 byte flag if they want.
Here’s the long-term benefits
-
You’re building into the system flags, that can be quite useful later for future use, or to better understand the new data flowing into OP_RETURN once we fork.
-
MOST IMPORTANT If you don’t flag from the introduction of OP_RETURN, you can’t go back to yesterday and start flagging. This is why I’m begging for the 1 byte flag to exist. If new developers don’t bother to set a flag, or go with the default flag, then it’s totally on them for being irresponsible. At least that functionality was available to them at the time.
Finally, picture this:
Disk defragmentation tools for hard drives. Ever see a visual representation of a hard drive utility defragmenting a disk? Think of Peercoin what it might need 100 years from now. A 1 byte flag with multiple uses is needed.
If I know any thing about Sunny King, he doesn’t like to hard fork very often. So if you’re going to hard fork for OP_RETURN, then please add a flag. It doesn’t need to be called OP_RETURN_FLAG, call it even OP_FLAG.
[size=14pt]At the end of the day, it’s Sunny King’s decision. At least I had him consider it. I will sleep well tonight knowing we discussed this before the fork.[/size]