Pegged Sidechains [PDF Whitepaper]

[TierNolan]

How does the parent chain know the current difficulty of the side chain (without observing it) in order to validate the proofs of work?

SPV validation means scanning the block headers.  You can get the difficulty just from monitoring the headers.  This doesn't tell you if all the transactions in the sidechain are valid.

The risk is that the main chain might accept back a coin from a sidechain and then a re-org happens on the sidechain and the coin appears back on the side chain.

Handling that in a "fair" way is hard.  As far as the parent is concerned, the coin was recovered.

This means that a sidechain might have 100,000 BTC on it, but think it has 100,500 BTC.

They suggest three possible solutions:

- Do nothing

The odds of more than 100,000 of the 100,500 BTC being withdrawn is low.  The risk is that as more BTC are lost, a run might occur on the side chain.  Only the first 100k withdrawn gets anything.

- Exchange rate

All coins on the sidechain are re-computed.  You only get 99.5% of your BTC back.  This treats all users equally and eliminates the problem of a run.

- Reverse all transactions

If the side-chain re-orgs, then that causes the parent to re-org.  This would cause chaos.  It also breaks the separation of the altchain vs parent chain.

For example, if the parent chain was the main bitcoin system and the sidechain was some altcoin, then bitcoin isn't going to reverse blocks due to problems with the altcoin.

[1714115781]

1714115781

[1714115781]

1714115781

[1714115781]

1714115781

[1714115781]

1714115781

[Luke-Jr]

Sidechains could also be implemented with SNARKs, and probably will be in the future. This takes you from SPV security to full node security - but it doesn't remove the risk of a reorg...

Is it me or this is actually the only thread in bitcointalk about sidechains and has no replies whatsoever?  

Serious discussion doesn't usually take place on BitcoinTrollTalk.

[Crowex]

How does the parent chain know the current difficulty of the side chain (without observing it) in order to validate the proofs of work?

SPV validation means scanning the block headers.  You can get the difficulty just from monitoring the headers. 

Ok, so are you saying that the bitcoin client has to query network nodes from all of the side chains?

A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain,

(from the Satoshi white paper about SPV's)

From my understanding of the quote from the side chain paper it's not going to do that

In summary, we propose to make the parent chain and sidechains do SPV validation of data on each other. Since the parent chain clients cannot be expected to observe every sidechain, users import proofs of work from the sidechain into the parent chain in order to prove possession.

But if the bitcoin client doesn't query the nodes of the side chains can it rely on information provided by the users who are the ones trying to establish the proofs? If it's not monitoring the nodes how does it know if a block has just been orphaned?

Maybe I'm misunderstanding it?

[Matt Corallo]

How does the parent chain know the current difficulty of the side chain (without observing it) in order to validate the proofs of work?

SPV validation means scanning the block headers.  You can get the difficulty just from monitoring the headers. 

Ok, so are you saying that the bitcoin client has to query network nodes from all of the side chains?

No, this is the reason for the contest period.

[Crowex]

Ok, so in order to game the system I would have to wait until the end of the contest period and provide the parent chain with a greater proof of work for the side chain (which validates my transaction) than it is currently aware of.
This proof of work isn't necessarily equivalent to the current proof of work on the side chain since it relies on user fed information included in transactions and is only as current as the last proof of work information received.
 But  with a long enough contest period and the parent chain receiving enough proof of work information this extra risk will be minimal.
 Is that correct?

[cjp]

I realize I still don't understand how a symmetric two-way peg is supposed to work.
On page 10, Figure 1 is supposed to clarify this.
Now, if we focus on the Parent Chain (let's call it Bitcoin), how is that part supposed to work?

• First, bitcoins are sent to an "SPV-locked output"; I suppose this is a ScriptPubKey of a special type.
• Then, a lot of things happen outside of Bitcoin itself, such as sending the SPV Proof to the side chain, transactions on the side chain, and finally sending some coins on the side chain to a SPV-locked output on the side-chain.
• Then, an SPV proof is sent to the Parent Chain. What does this mean? Does this mean that somebody makes a Bitcoin transaction which spends the SPV-locked output? Can miners immediately put such a transaction into the block chain? I suppose they shouldn't, at least until the contest period ends: otherwise, they risk making an orphan chain.
• Apparently, others can send "SPV reorganization proofs" inside the contest period, which invalidate "SPV proofs"; I assume that, whichever ends up having the most Proof of Work at the end of the contest period wins the "contest". So, after the contest period, a transaction spending the "SPV-locked output" can be inserted into the Bitcoin block chain, right?

I suppose that, in the absence of "SPV reorganization proofs", the data in the "SPV proof" should be sufficient to spend the "SPV-locked output.
How can an "SPV reorganization proof" stop the spending of the "SPV-locked output"? Why won't such a spend end up in the Bitcoin block chain, even when an "SPV reorganization proof" with higher proof of work is published inside the contest period? Are miners supposed to look for such proofs?

I think this means that a spend of an "SPV-locked output" can not be verified long after it happened, since there's no way to see whether "SPV reorganization proofs" with higher difficulty were published inside or outside the contest period. This is not necessarily bad, since history can be reconstructed by assuming that most of the miners at the time of spending were honest, but it is different from other types of scripts.

You have to take a close look at all the possible consequences for Bitcoin's reliability, before implementing this.

[laurentmt]

I've just reread the whitepaper and I wonder what is the impact of SPV on fungibility in sidechains.

Since pegged sidechains may carry assets from many chains, and cannot make assumptions about the security of these chains, it is important that different assets are not interchangeable (except by an explicit trade). Otherwise a malicious user may execute a theft by creating a worthless chain with a worthless asset, move such an asset to a sidechain, and exchange it for something else. To combat this, sidechains must effectively treat assets from separate parent chains as separate asset types.

[adhitthana]

I expect that preventing a 51% style attack on any alt coin used will be necessary?
So that would mean that any coin used in the sidechain would have to be a coin that is potential competition for BTC too?

[Luke-Jr]

I expect that preventing a 51% style attack on any alt coin used will be necessary?
So that would mean that any coin used in the sidechain would have to be a coin that is potential competition for BTC too?

51% attacks only affect blockchains, not assets/"coins".

[adhitthana]

I expect that preventing a 51% style attack on any alt coin used will be necessary?
So that would mean that any coin used in the sidechain would have to be a coin that is potential competition for BTC too?

51% attacks only affect blockchains, not assets/"coins".

Ok so lest say "donkeycoin's" blockchain was being used, and there was a 51% attack on "donkeycoin". What are the possible implications?

[Luke-Jr]

I expect that preventing a 51% style attack on any alt coin used will be necessary?
So that would mean that any coin used in the sidechain would have to be a coin that is potential competition for BTC too?

51% attacks only affect blockchains, not assets/"coins".

Ok so lest say "donkeycoin's" blockchain was being used, and there was a 51% attack on "donkeycoin". What are the possible implications?

You mean a 51% attack on donkeycoin's blockchain?
Then assets within donkeycoin's blockchain are susceptible to reversal and/or oversight/control by the 51% attacker.
If the attacker achieves 66% (or whatever the configurable threshold is for the sidechain), then they can also begin to steal outside assets pegged into that blockchain.
The donkeycoin asset/coin itself is irrelevant to this, and may or may not exist.

[adhitthana]

I expect that preventing a 51% style attack on any alt coin used will be necessary?
So that would mean that any coin used in the sidechain would have to be a coin that is potential competition for BTC too?

51% attacks only affect blockchains, not assets/"coins".

Ok so lest say "donkeycoin's" blockchain was being used, and there was a 51% attack on "donkeycoin". What are the possible implications?

You mean a 51% attack on donkeycoin's blockchain?

Yes, what else could it mean? 

Then assets within donkeycoin's blockchain are susceptible to reversal and/or oversight/control by the 51% attacker.
If the attacker achieves 66% (or whatever the configurable threshold is for the sidechain), then they can also begin to steal outside assets pegged into that blockchain.
The donkeycoin asset/coin itself is irrelevant to this, and may or may not exist.

So that could mean BTC could conceivably be stolen, as BTC could be pegged in the "Donkeycoin" blockchain?

[Luke-Jr]

I expect that preventing a 51% style attack on any alt coin used will be necessary?
So that would mean that any coin used in the sidechain would have to be a coin that is potential competition for BTC too?

51% attacks only affect blockchains, not assets/"coins".

Ok so lest say "donkeycoin's" blockchain was being used, and there was a 51% attack on "donkeycoin". What are the possible implications?

You mean a 51% attack on donkeycoin's blockchain?

Yes, what else could it mean? 

For some reason, some people seem to have the misconception that a 51% attack is holding 51% of bitcoins.

Then assets within donkeycoin's blockchain are susceptible to reversal and/or oversight/control by the 51% attacker.
If the attacker achieves 66% (or whatever the configurable threshold is for the sidechain), then they can also begin to steal outside assets pegged into that blockchain.
The donkeycoin asset/coin itself is irrelevant to this, and may or may not exist.

So that could mean BTC could conceivably be stolen, as BTC could be pegged in the "Donkeycoin" blockchain?

Conceivably, but the Donkey-blockchain must have been created with a higher-than-50% limit on what an attacker would need to steal.
It's a tradeoff against censorship risk: So, in one example, the attacker might need 90% to steal, but then he only needs 10% to censor return transactions.

[adhitthana]

Conceivably, but the Donkey-blockchain must have been created with a higher-than-50% limit on what an attacker would need to steal.
It's a tradeoff against censorship risk: So, in one example, the attacker might need 90% to steal, but then he only needs 10% to censor return transactions.

Thanks for the replies. I guess I was thinking that for a blockchain to be part of the sidechain experiment, it would probably be helpful to have many active users and hopefully not be dominated by large mining ventures?

[Skoupi]

Then assets within donkeycoin's blockchain are susceptible to reversal and/or oversight/control by the 51% attacker.
If the attacker achieves 66% (or whatever the configurable threshold is for the sidechain), then they can also begin to steal outside assets pegged into that blockchain.
The donkeycoin asset/coin itself is irrelevant to this, and may or may not exist.

Wait where did that 66% come from? You mean that a sidechain can have a completely different consensus system where the larger chain is beign somehow decided by more than 66% of the total hashing power?

[Luke-Jr]

Then assets within donkeycoin's blockchain are susceptible to reversal and/or oversight/control by the 51% attacker.
If the attacker achieves 66% (or whatever the configurable threshold is for the sidechain), then they can also begin to steal outside assets pegged into that blockchain.
The donkeycoin asset/coin itself is irrelevant to this, and may or may not exist.

Wait where did that 66% come from?

It's a sidechain parameter; see sidechains.pdf section 6.1 (page 16, line 479-480).

6.1 Hashpower attack resistance
The main thrust of this paper surrounds two-way peg using SPV proofs, which are forgeable by a 51%-majority and blockable by however much hashpower is needed to build a sufficiently-long proof during the transfer’s contest period. (There is a tradeoff on this latter point — if 33% hashpower can block a proof, then 67% is needed to successfully use a false one, and so on.)

You mean that a sidechain can have a completely different consensus system...

Yes, they can have that.

...where the larger chain is beign somehow decided by more than 66% of the total hashing power?

The sidechain's consensus is always a simple majority balance like Bitcoin (unless someone invents some other algorithm) - the 66% requirement applies only to transfers out of it.

[Crowex]

6.1 Hashpower attack resistance
The main thrust of this paper surrounds two-way peg using SPV proofs, which are forgeable by a 51%-majority and blockable by however much hashpower is needed to build a sufficiently-long proof during the transfer’s contest period. (There is a tradeoff on this latter point — if 33% hashpower can block a proof, then 67% is needed to successfully use a false one, and so on.)

This is the bit that I don't really agree with (or don't understand properly). The hashpower to block a proof and the hashpower to successfully use a false one will only add up to 100% if the bitcoin client knows the current greatest proof of work on the side chain.

 The parent chain won't be monitoring all nodes of all side chains because this would be too burdensome on the bitcoin nodes so it won't always know the longest proof of work chain on the side chain. This will reduce the percentage of hashpower needed to double spend.

 Say I try to double spend a coin on the side chain by redeeming it to the parent chain and spending it on the side chain. A block is found with my transaction redeeming it to the parent chain so I produce this to the parent chain with an spv proof and the contest period begins.
 Now this block is orphaned and my other transaction, spending on the side chain is valid.

 Somebody supplies the block chain with details of the re-org and it now invalidates my transaction redeeming to the parent chain. Now my question is do I have from now until the end of the contest period to try and better this re-org proof? If so I am not trying to better the length of proof of work on the side chain at the end of the contest period, I am trying to better the length of the sidechain proof of work at the time the re-org proof is submitted. I have the whole of the contest period to work away building a proof of work that includes my transaction redeeming the coin to the parent chain but I don't have to beat the longest side chain proof of work I only have to beat the proof of work when the re-org was submitted. Then just before the contest period ends I submit my re-org and validate the transaction redeeming the coin on the parent chain that has been spent on the side chain.

 Or does the redemption transaction have to be re-submittted to the parent chain if a re-org is submitted and the contest period starts again? (but then maybe bad actors could submit false re-orgs to cancel redemptions because the parent chain doesn't know the current longest side chain pow)

 I'm also concerned that checking the re-org proofs for all side chains would be an extra burden on the parent chain nodes.

 Anyway I realise that many of these details might still be being worked out by the designers or have been considered and aren't an issue.
 Also I might be completely misunderstanding it.

 I don't think that any of these problems could not be overcome and I think side chains are a great idea, I'm just trying to analyse where weak points might be  (because this will definitely get analysed by people trying to beat the system anyway) and improve my understanding.

 

[virtualx]

I haven't read all yet but the paper looks very interesting. Would the network get any slower with say 50 sidechains?

[HeliKopterBen]

What are the chances that a side chain becomes the dominant chain?  To answer this, we need to determine at what point miners will likely point more processing power at the side chain than at the main chain.  At this point, the side chain will be more highly secured by processing power than the main chain and the side chain can be considered dominant over the main chain.  So at what point will the reward for mining the side chain be higher than the reward for mining the main chain?

Currently, the average tx fee per transaction is roughly 0.0002 and the average tx fee reward per block is roughly 0.1 btc (I can show how I calculated this and/or show sources if needed).  The current block reward for newly created coins is 25 btc.  The side chain will have to achieve a reward of greater than 25 btc per block to overtake the main chain (I did not include the tx fee reward because this is currently negligible and will likely be negligible if a side chain has many more txs.  Also, this is a conservative estimate).  To achieve a reward of greater than 25 btc per block, the side chain will have to generate 125,000 txs per block (25/0.0002) assuming tx fees on the side chain are equal to tx fees on the main chain (these fees will likely be lower but this is a conservative estimate).  Therefore, the rate at which the side chain overtakes the main chain is 208 txs per second.

This estimate also does not take into account the possibility that the side chain can issue a secondary coin as a block reward, which can further reduce the number of transactions needed to overtake the main chain.  Also, halving of the bitcoin block reward over time will reduce the number of transactions needed to overtake the main chain.  With discussion of side chains being used for everyday transactions and bitcoin being used for long-term storage, I can see this overtaking as a real possibility.

There are a few assumptions about future conditions in this analysis.  However, at current rates and with the only assumption being that side chain tx fee rates = bitcoin tx fee rates, then the side chain will need to achieve a tx rate of roughly 200 txs per second to overtake bitcoin in terms of processing power through miner arbitrage. 

Also,
when side chain tx fee rates  = 50% (0.0001) of bitcoin tx fee rates:  bitcoin overtaken @ 400 txs per second
when side chain tx fee rates  = 10% (0.00002) of bitcoin tx fee rates:  bitcoin overtaken @2000 txs per second (roughly that of visa and mastercard)

When the block reward eventually drops to 0, then the side chain will only have to generate more tx fees than bitcoin to become the dominant chain. 

Please point out the flaw in my logic.


tl;dr
Roughly, the point at which a side chain can overtake bitcoin as the dominant chain at current rates is 200 tx/sec.

[cypherdoc]

What are the chances that a side chain becomes the dominant chain?  To answer this, we need to determine at what point miners will likely point more processing power at the side chain than at the main chain.  At this point, the side chain will be more highly secured by processing power than the main chain and the side chain can be considered dominant over the main chain.  So at what point will the reward for mining the side chain be higher than the reward for mining the main chain?

Currently, the average tx fee per transaction is roughly 0.0002 and the average tx fee reward per block is roughly 0.1 btc (I can show how I calculated this and/or show sources if needed).  The current block reward for newly created coins is 25 btc.  The side chain will have to achieve a reward of greater than 25 btc per block to overtake the main chain (I did not include the tx fee reward because this is currently negligible and will likely be negligible if a side chain has many more txs.  Also, this is a conservative estimate).  To achieve a reward of greater than 25 btc per block, the side chain will have to generate 125,000 txs per block (25/0.0002) assuming tx fees on the side chain are equal to tx fees on the main chain (these fees will likely be lower but this is a conservative estimate).  Therefore, the rate at which the side chain overtakes the main chain is 208 txs per second.

This estimate also does not take into account the possibility that the side chain can issue a secondary coin as a block reward, which can further reduce the number of transactions needed to overtake the main chain.  Also, halving of the bitcoin block reward over time will reduce the number of transactions needed to overtake the main chain.  With discussion of side chains being used for everyday transactions and bitcoin being used for long-term storage, I can see this overtaking as a real possibility.

There are a few assumptions about future conditions in this analysis.  However, at current rates and with the only assumption being that side chain tx fee rates = bitcoin tx fee rates, then the side chain will need to achieve a tx rate of roughly 200 txs per second to overtake bitcoin in terms of processing power through miner arbitrage. 

Also,
when side chain tx fee rates  = 50% (0.0001) of bitcoin tx fee rates:  bitcoin overtaken @ 400 txs per second
when side chain tx fee rates  = 10% (0.00002) of bitcoin tx fee rates:  bitcoin overtaken @2000 txs per second (roughly that of visa and mastercard)

When the block reward eventually drops to 0, then the side chain will only have to generate more tx fees than bitcoin to become the dominant chain. 

Please point out the flaw in my logic.


tl;dr
Roughly, the point at which a side chain can overtake bitcoin as the dominant chain at current rates is 200 tx/sec.

the problem i see with your analysis is that it leaves out the relative fiat exchange prices for BTC and scBTC which play a large psychological factor.