<p>This particular proposal only requires one change to Bitcoin: Simplified Payment Verification (SPV) proving. </p>

<p>SPV proving is required when you want to move Bitcoins from the sidechain to the mainchain. The idea is that rather than putting all of the rules to validate transactions on the other chain into the original Bitcoin client, Bitcoin clients would look at how much hashpower was used to secure the transaction. It's pretty clever, actually.</p>

<p>The sidechain proposal described in that paper glosses over the changes to make SPV proofs work:</p>

<blockquote>
  <p>To use Bitcoin as the parent chain, an extension to script which can recognize and validate such SPV proofs would be required. At the very least, such proofs would need to be made compact enough to fit in a Bitcoin transaction. However, this is just a soft-forking change, without effect on transactions which do not use the new features.</p>
</blockquote>

<p>It would be more than an extension to script. Script currently has no way of looping or signaling to other scripts, which you would need. I'm pretty sure this would require a hard-fork. (Could someone more familiar with Bitcoin's internals chime in here? Could adding looping/signalling be done without a hardfork?)</p>

<p>I think it would make a lot more sense to not track the UTXO's of the coins moved to the sidechain at all, and just keep a running total. Then, have a hardcoded validator for each sidechain.</p>

<p>One issue that I see is that I don't think there would be enough hashpower to secure the network from double spending; merged mining could probably fix that though.</p>

CC BY-SA 3.0
2014-10-28T15:57:34.617Z
2014-10-28T19:18:25.207Z
2014-10-28T19:18:25.207Z
Nick ODell
<p>Regarding the concept of side chains or "pegged" chains which has been discussed since as early as 2011 and explored in <a href="http://www.blockstream.com/sidechains.pdf" rel="nofollow">this white paper</a>, how can these negatively affect the security of Bitcoin?</p>

<p>Before answering that question, I think it's important to determine if these concepts are possible without any change to the Bitcoin protocol.  Assuming changes are required, would Bitcoin suffer from side chains?  If no changes are required then the Bitcoin protocol should be as solid as it ever was and, it would seem that it would benefit from the usage, support and attention that side chains bring.  Perhaps different implementations of side chains matter and it's important to look at examples.</p>

CC BY-SA 3.0
2014-10-28T16:12:54.830Z
Related: http://bitcoin.stackexchange.com/questions/32185/what-are-pegged-side-chains-are-and-how-they-will-be-useful-for-bitcoin
Nick ODell
<blockchain><security><sidechains>
Can side chains or "pegged" chains negatively affect the security of Bitcoin?
Scott
# Can side chains or "pegged" chains negatively affect the security of Bitcoin?

(Asked by: username_0 on 2014-10-28)

Regarding the concept of side chains or "pegged" chains which has been discussed since as early as 2011 and explored in [this white paper](http://www.blockstream.com/sidechains.pdf), how can these negatively affect the security of Bitcoin?

Before answering that question, I think it's important to determine if these concepts are possible without any change to the Bitcoin protocol. Assuming changes are required, would Bitcoin suffer from side chains? If no changes are required then the Bitcoin protocol should be as solid as it ever was and, it would seem that it would benefit from the usage, support and attention that side chains bring. Perhaps different implementations of side chains matter and it's important to look at examples.

**Tags:** blockchain, security, sidechains

> **Comments:**
> **username_1**: Related: http://bitcoin.stackexchange.com/questions/32185/what-are-pegged-side-chains-are-and-how-they-will-be-useful-for-bitcoin  

---

## 1 answers

### Answer by username_1 on 2014-10-28. Score: 2 | Accepted answer

This particular proposal only requires one change to Bitcoin: Simplified Payment Verification (SPV) proving.

SPV proving is required when you want to move Bitcoins from the sidechain to the mainchain. The idea is that rather than putting all of the rules to validate transactions on the other chain into the original Bitcoin client, Bitcoin clients would look at how much hashpower was used to secure the transaction. It's pretty clever, actually.

The sidechain proposal described in that paper glosses over the changes to make SPV proofs work:

> To use Bitcoin as the parent chain, an extension to script which can recognize and validate such SPV proofs would be required. At the very least, such proofs would need to be made compact enough to fit in a Bitcoin transaction. However, this is just a soft-forking change, without effect on transactions which do not use the new features.

It would be more than an extension to script. Script currently has no way of looping or signaling to other scripts, which you would need. I'm pretty sure this would require a hard-fork. (Could someone more familiar with Bitcoin's internals chime in here? Could adding looping/signalling be done without a hardfork?)

I think it would make a lot more sense to not track the UTXO's of the coins moved to the sidechain at all, and just keep a running total. Then, have a hardcoded validator for each sidechain.

One issue that I see is that I don't think there would be enough hashpower to secure the network from double spending; merged mining could probably fix that though.


---

