Merging alt chains?

[lunarboy]

nice article on coindesk about UNOCS

Coindesk UNOCS

I'm not a coder or cryptographer so bear with me a little if this has an obvious answer... but it got me thinking, would it be theoretically possible to merge three or more blockchains together?

 say calculate a future block point for each of the chains create 'NewCOIN' now with the best features selected from all three chains. ?
 Obviously you'd have to get a massive % consensus from all miners on each chain. I was thinking 'newCOIN' would represent proportional value ratio of each 'oldCOIN' based various preordained coefficients.

I see the alt coin space as very fascinating but obviously getting new coins off the ground can be a challenge. The ability to merge chains and thus create a development and mining coalition to keep dying but promising alt chains/features alive, would be useful indeed.

[DeathAndTaxes]

You could.  Understand that you can't force the original chains to stop functioning so someone who has 1,000 xCoins would still have 1,000 xCoins in the existing fork AND 1,000 newCoins unless the user does something to destroy the xCoins.  Remember there is no off switch to a blockchain.  Even if the original developer(s) quit the blockchain will still continue (and thus coins will still be usable) as long as there is a single mining node.   Case in point Satoshi left the Bitcoin project.  Today Satoshi couldn't "stop" Bitcoin and force everyone to upgrade to newCoin. 

There are a couple of methods you could use depending on what you are looking to accomplish.

Method 1: Snapshot of existing chains (simplest)
To save space the developer would decide on a "cutoff" block for each of the existing chains (and make this publicly known well in advance).  On the cutoff block, analyze the blockchains and record the UXTO ( the unspent transactions) as of the cutoff block.  This can be considered a pruned version of the full blockchain (for example Bitcoin blockchain = ~9GB but UXTO is ~240MB).  In the genesis block of the newCoin record the UXTO set for the merged coin(s).  If users are willing to partially trust a central authority in the bootstrapping process you can compact this by reducing the UXTO to just a ledger (public key hash and balance) which would be about 24 bytes per address (not output).  I call this partially trusted as any user who wishes could validate the ledger using open source software to ensure it matches the UXTO at the time of the cutoff block.  If enough users independently validated the ledger it would have robust "enough" security.  An attempted fraud would kill newCoin in the craddle, what you really want to avoid is nobody double checks and 5 years from now when newCoin is worth a fortune someone realizes someone snuck in a bonus 10,000 coins.

So for Bitcoin (as of July 2013)
Full blockchain = ~9,000 MB (~3 million spent and unspent transactions)
UXTO = ~250 MB (~800,000 transactions with unspent outputs)
Compact ledger of UXTO = ~13 MB (~600,000 funded addresses)

Method 2: Destroy coins on existing chain prior to genesis block (more complex)
 Now like I said xCoin, yCoin, zCoin will still exist.  Once launched in the wild you can't "stop" a cryptocurrency (that is kinda the point).  If you wanted a person getting 1,000 newCoins to no longer have 1,000 xCoins it is a slightly more complicated process.

The simplest way would be to require users of xCoin, yCoin, and zCoin to destroy their coins by sending them to a "dead end" address which is one where the coins are provably unspendable.  This would need to be done BEFORE the launch of newCoin.  You would set a cutoff block for xCoin (and yCoin, zCoin, etc).  After the cutoff block you would locate all the "destroyed" xCoins and premise an equivalent amount directly to addresses the user controls in the genesis block.  So a user with 1,000 xCoins would provably destroy them BEFORE the cutoff.  After the cutoff the genesis block for newCoin would be created which has 1,000 coins newCoins going to this user.  The obvious advantage over the prior method is no duplication of coins.  1,000 newCoins = 1,000 xCoins destroyed.  The obvious disadvantage is that users would need to destroy their xCoins before newCoin launched which is a risk and some may not (either don't like the risk, don't learn about newCoin until after cutoff, etc).

Method 3: "transfer" (well technically destroy & create) after genesis block (more complex)
The major disadvantage over the second method is that you are forcing users to make a choice before the launch of the new coin. If you want to allow "transfer" of coins from xCoin to newCoin AFTER the genesis block well it gets more complicated.  Nodes would need to run a node for both newCoin and xCoin (and yCoin and zCoin etc).  You could have a special transfer transaction where users would send their xCoins to an "dead end" address (one which is known to be unspendable) and simultaneously create a "transfer Coin" transaction on newCoin.  A miner would need to validate this across both chains (that user destroyed their coins on xCoin AND user made a createTx on newCoin and the two are linked). The obvious disadvantage of this is that newCoin now relies on nodes running both newCoin AND xCoin (and yCoin, zCoin, etc).  You could limit this for a certain timeframe.  For example transfer Tx are only possible through block 100,000.  This would allow nodes to stop running the older coin nodes after block 100,000.



Notes:
For simplicity I just used 3 chains and a 1:1 relationship (i.e. 1,000 xCoins = 1,000 newCoins and 1,000 yCoins = 1,000 newCoins).  This isn't required.  One could easily implement different ratios depending on number of coins outstanding for each chain (i.e. 1,000 xCoins = 100 newCoins and 1,000 yCoins = 5 newCoins).

You could combine these methods if you wanted to.  For example maybe one chain has enough support that you go through the more complex process of allowing method 3 but for 6 other smaller chains you just use method 2.  Another example would be to combine methods 1 & 2 with different ratios.  i.e. if you destroy your xCoins you will get 1 newCoin for 1 xCoin however as a backup the UXTO is also included in the genesis block so even if you DON'T destroy your xCoins you get 1 newCoin for every 1,000 xCoins.

[lunarboy]

Thanks DeathAndTaxes for your time.

My initial scenario was only on dead or dying coins that had a valid use case, but taking it further, does seem an interesting train of thought. The three methods you describe all obviously require huge levels of co-operation between coin holders and miners; some more than others. However the potential here seems huge teams of developers and miners who don't want to give up on their beloved coins could join forces.

Its a truly complex subject way beyond my pay grade, but i'm imagining almost a league system with teams of equal here and in many cases the whole may never equal sum of the parts xCoin,  yCoin, and zCoin but if a coin was dying, joining forces and taking the best features from both might work out very beneficial.

The dichotomy is that any method here seems to require huge consensus and could really only be solved with a centralised 'Union' for want of a better term, something cryptocoins struggle with.

To my mind any method of merger would need to kill the original chains. I wonder if it could be weaponised?? if the consensus was high enough and there was sufficient motive a 51% attack could be performed as a kind of scorched earth policy on the chains. Anyone who had not already sent their coins to the 'dead end' and hence registered for the 'newCoin' would have serious motive to do so before the final deadline.

These Unions of coins and developers may be onto something here?