<p>That seems possible, but I'm not aware of any instances of it being done before.</p>

<p>You have three major problems:</p>

<ul>
<li>Bitcoin generally assumes that there is one single ordering of transactions. That ordering can change, but there's always only one. The danger is that your two blockchains contain transactions that are mutually exclusive: transaction A and transaction B both spend the same coins, so only one can exist in the new master chain.</li>
<li>Everyone needs to upgrade to a client that supports the new merged blockchain, and the algorithms in both chains. Some people might have been screwed over by the previous step in the process (because a transaction they relied upon was essentially reversed,) so they might be a little reluctant to do this.</li>
<li>You need to avoid introducing any subtle security bugs while doing this.</li>
</ul>

CC BY-SA 3.0
2015-09-17T00:40:43.957Z
awesome answer (I would upvote if i had more rep lol), and thank you for the explanation. However, I dont think i properly explained my question, or I'm possibly misinterpreting your answwer. I have  edited my OP for better clarification.
L8NIT3TR0UBL3
CC BY-SA 3.0
2015-09-17T22:12:37.307Z
You're describing a hardfork, which is much easier to do correctly the first time than merging the chains after the fact.
Nick ODell
CC BY-SA 3.0
2015-09-15T23:55:14.640Z
2015-09-15T23:55:14.640Z
Nick ODell
<p>When a cryptocoin changes algorithm (eg. scrypt to X11), how does one achieve the merging of the two blockchains? </p>

<p>I'm assuming that they couldn't be directly compatible based on being completely different algorithms, it would cause a <code>loadBlock()</code> error. They also couldn't just make two blockchains, as all of the scrypt mined coins would be unspendable on the x11 blockchain and vice versa.</p>

<p>I have seen instances of crypto developers having a v1 to v2 exchange (usually at some ratio like 0.8:1), however that would require the v2 blockchain to have a premine for the conversion distribution.</p>

<p>Hopefully I'm not too far off on my thoughts here, any clarification would be greatly appreciated.</p>

<p>I should specify that by merging I don't mean running both algorithms on one coin (saffron-style), I mean how to implement something along the lines of </p>

<pre><code>if blockNumber &lt;= (maxScryptBlock) do
    {block.readHash(scrypt);
    }
else if blockNumber &gt;= (maxScryptBlock) do
    {block.readhash(x11);
    }
</code></pre>

<p>I can't seem to find any writings anywhere on how a developer makes the switch from one algorithm to another, or really any for cloning any non-scrypt/sha256 coin.</p>

<blockchain><algorithms><blockchain-fork>
Merging blockchains after algorithm change
L8NIT3TR0UBL3
# Merging blockchains after algorithm change

(Asked by: username_0 on 2015-09-13)

When a cryptocoin changes algorithm (eg. scrypt to X11), how does one achieve the merging of the two blockchains? 
I'm assuming that they couldn't be directly compatible based on being completely different algorithms, it would cause a loadBlock() error. They also couldn't just make two blockchains, as all of the scrypt mined coins would be unspendable on the x11 blockchain and vice versa.
I have seen instances of crypto developers having a v1 to v2 exchange (usually at some ratio like 0.8:1), however that would require the v2 blockchain to have a premine for the conversion distribution.
Hopefully I'm not too far off on my thoughts here, any clarification would be greatly appreciated.
I should specify that by merging I don't mean running both algorithms on one coin (saffron-style), I mean how to implement something along the lines of 
if blockNumber <= (maxScryptBlock) do
    {block.readHash(scrypt);
    }
else if blockNumber >= (maxScryptBlock) do
    {block.readhash(x11);
    }

I can't seem to find any writings anywhere on how a developer makes the switch from one algorithm to another, or really any for cloning any non-scrypt/sha256 coin.

**Tags:** blockchain, algorithms, blockchain-fork


---

## 1 answers

### Answer by username_1 on 2015-09-15. Score: 1

That seems possible, but I'm not aware of any instances of it being done before.

You have three major problems:

* Bitcoin generally assumes that there is one single ordering of transactions. That ordering can change, but there's always only one. The danger is that your two blockchains contain transactions that are mutually exclusive: transaction A and transaction B both spend the same coins, so only one can exist in the new master chain.
* Everyone needs to upgrade to a client that supports the new merged blockchain, and the algorithms in both chains. Some people might have been screwed over by the previous step in the process (because a transaction they relied upon was essentially reversed,) so they might be a little reluctant to do this.
* You need to avoid introducing any subtle security bugs while doing this.

> **Comments:**
> **username_0**: awesome answer (I would upvote if i had more rep lol), and thank you for the explanation. However, I dont think i properly explained my question, or I'm possibly misinterpreting your answwer. I have  edited my OP for better clarification.  
> **username_1**: You're describing a hardfork, which is much easier to do correctly the first time than merging the chains after the fact.  

---

