Debating PoW vs PoS (yet again) on Bitcointalk today made me think of something that I think would be neat. It was an idea proposed by Mike Caldwell (Casascius) for Litecoin in 2013, and I think it could work for Bitshares chains. It requires cooperation from both (or in our case multiple) chains, which is why it never really took off for Bitcoin/Litecoin. However, considering the close relationship that already exists in between Bitshares chains the politics of it may work out, and I think it is a great idea if we can make it work.
It seems like this idea (or something similar) can help the Bitshares ecosystem be more resilient to 51% attacks. BTS, MUSE, PLAY, Etc... (which I hereinafter refer to as Bitshares chains) can "backup" each other. I edited the original post to cut out the opinion pieces, for readability reasons, and to make it easier to understand as far as how it would work in the Bitshares ecosystem. Obviously, all of the below subject to change after review from those smarter than I, and honestly I wrote this without giving it much thought but I am positive it could be made to work. I am busy with other things- I just wanted to make sure the Bitshares community knew of this idea.
A General Overview:
I believe I have thought of an idea that would make each Bitshares chain more secure, and far more important & relevant in the Bitshares/cryptocurrency ecosystem... by each Bitshares chain being ready in wait in case any certain Bitshares chain experiences a 51% attack. Add a mandatory "merge-mining" feature to each Bitshares chain so that it is always "merge-mining" all other Bitshares chains. All chains should have the option of "let's subscribe to a different Bitshares chain(s)" as a secondary means of block validation, which in turn would be a way to resolve future 51% attack on any certain Bitshares chain.
How It May Work:
1. Add a new requirement to all Bitshares chains, such that a valid Bitshares chain's block must contain either a record of the most recent block header hash of all other Bitshares chains, or a repeat of the hash found in the prior Bitshares chain's block (with a limit of repetitions.) Bitshares blocks that contain outdated Bitshares chains' intelligence should be disfavored by nodes and/or delegates capable of detecting that. Further impose the requirement that all Bitshares chains' block headers must be represented contiguously in each Bitshares chain. Each Bitshares chains' blocks cannot be skipped by all other chains and must be recorded in each chain's blockchain.
2. In the event there is an active block chain fork on any certain Bitshares chain, the requirement is loosened such that the block header hash requirement of the Bitshares chain under attack can be satisfied by any leg of the chain, not just the leg that the Bitshares chain under attack considers valid.
3. Add a feature to all Bitshares chains' clients that allow Bitshares users to decide to prefer or not-prefer branches of a certain Bitshares chain's fork (while one is in progress.) The default for this should always favor the Bitshares leg with the most longevity, and should disfavor long chains that suddenly appear to replace a large amount of the known Bitshares chains' block chain that's under attack. The stakeholders/delegates should always have an easy way to have the final say, such as by pasting in a preformatted message either exiling or checkpointing a certain Bitshares chains' blocks.
Anticipated Benefits:
1. Each Bitshares chains' stakeholders would have a ready made remedy to a 51% attack that they can switch to, and thus be far more resilient to 51% attacks.
2. Each Bitshares chain would be seen as far more important and valuable (by those who do not see it that way.)
Topic: [VoterApathy] How To Make 51% Attacks A Lot Harder (without more people voting) (Read 14335 times)
