Proposal for blockchain upgrade algorithm to avoid hard forks

[randomocean]

Given all of the discussion around the potential need for larger block sizes, it occurred to me that the current state of the blockchain does not have a secure algorithm to support a smooth upgrade to a different block format.     I propose the following scenario to create a new blockchain with a new format and transition transactions from the old chain into the new chain securely and smoothly without relying on a central authority or affecting the number of bits available.

The basic premis is this - a whole new blockchain will be created for the upgraded blocks.   Included in this blockchain will be a secure mechanism to transfer bitcoin from the old chain to the new chain.   This mechanism works by having 'origin' wallets on the new chain.  An origin wallet will be algorithmically tied to a 'burn address' on the old chain - functionally, a hash of the origin wallet will create a valid public key on the old chain, with no corresponding private key.   Bitcoin sent to the 'burn address' on the old chain will not be spendable.    The new chain, however will function with knowledge of the old chain.   The transactions issued on the new 'origin' wallet will be considered valid if they add up to the value contained in the old chain at the deterministic 'burn' address associated with the origin.

A 'full node' will need to track both chains in the upgrade path, but as the transition occurs, there will be fewer and fewer transactions in the 'old' chain.   Overall, it does not create any 'duplicate' effort.

The benefit to this system is that it allows a smooth upgrade path.   Nodes that choose to upgrade will be able to conduct transactions on the old chain and convert bits up to the new chain at will.   Users who find old bits in the distant future will always be able to upgrade them because the old chain is retained as an origin record for bits.  A hard fork is avoided because new blockchain and old blockchain will exist side by side, without duplication of bits.

Some thought remains to be made concerning mining rewards, It could certainly happen that mining on the old block would eventually become loose competition and become a lucrative place to mine new blocks for the reward without supporting any new transactions.  I imagine an algorithm in the new blockchain that doesn't recognize mining rewards generated after the majority of transactions have shifted to the new blockchain might solve the problem.

[InceptionCoin]

With your system we need to support with PoW 2 blockchains, so we will have halve less security. When old blockchain will stop to pay mining subsidy security will be significantly decreased and double spend attack become very probable.
So we have a few major problems with your solution. But i don't know the benefits.

[person]

You are basically proposing creating an alt-coin with a Proof-of-burn mechanism. I wouldn't call that "smooth". Did I miss something?

[cheako]

This is still a hard fork, older clients will not be able to participate.  It smells like the MS Office upgrades.  We don't avoid hard forks, we avoid forcing a new client onto existing users.  Earlier I proposed moving the 'this is something we'd like to change in the future' into a configuration file so that upgrading would be simple.  Perhaps changes to this config file can be placed onto the block chain and after a large number of confirmations clients switch over.

In the next release add in a warning for changing a configuration variable that doesn't exist.  Miners can place a 'we don't support feature' into the blocks they generate, so the effect of the fork is clear.  A variable change only passes if at least 5/6th the hash rate confirm the change.  Miners should have to implicitly add the change into their setup, requiring at least 2/3rds of the hash rate to do this.

[Bitware]

No.