Pegged Sidechains [PDF Whitepaper]

[waxwing]

yeah, sorry i'm not so clear.  but in the scenario where a SC advertises a bogus innovation, the whale can pump BTC thru the 2wp, which is acting like a risk free put (if the SC fails, he can get this BTC back as advertised).  the mere appearance of large #scBTC on the SC may cause a price rise originating on the SC which then drags up the price of BTC as well in arb.  if he can sustain this then he could sell of scBTC on an exchange for profit (the dump).

If someone buys SCcoin and the SC fails, they don't get it back. (unless they do, in some weird scenario? i'm pretty sure that by default that coin would be permanently lost). I don't think there's any risk free put (it seems more like a call that you're thinking of - unlimited upside, no downside) here.

in the case of a SC with a true innovation, like faster tx times, it seems to me with time, all tx's would be incented to move to the SC as the block rewards diminish on the MC, depriving BTC miners of badly needed revenue.  yes, MM is a possiblity to harvest those SC fees but lots of miners nowadays are losing money.  they might be more than willing to primarily direct mine a SC if they can scoop up large tx fees (assuming of course MM is only a % of the BTC hashrate).

Transactions moving to a sidechain doesn't deprive BTC miners of their primary source of revenue; I guess you're already in this paragraph talking about far future when block reward is insignificant. So, fold into the below.

in 2140 when all block rewards are gone and the MC and SC (with its innovation) only mine tx fees, which chain would you rather be on?  if you say that MC core dev will upgrade Bitcoin before that, what metrics will they use before they feel pressure or panic by a SC beginning to take over?

I'm not sure we need to be analysing what happens so far into the future. But indeed if there are no longer mining rewards, then the 'classic' blockchain is no longer special. It's just one of many. But this is so far away from where we are today it seems pointless analysing it.

[1715648288]

1715648288

[1715648288]

1715648288

[1715648288]

1715648288

[cypherdoc]

yeah, sorry i'm not so clear.  but in the scenario where a SC advertises a bogus innovation, the whale can pump BTC thru the 2wp, which is acting like a risk free put (if the SC fails, he can get this BTC back as advertised).  the mere appearance of large #scBTC on the SC may cause a price rise originating on the SC which then drags up the price of BTC as well in arb.  if he can sustain this then he could sell of scBTC on an exchange for profit (the dump).

If someone buys SCcoin and the SC fails, they don't get it back. (unless they do, in some weird scenario? i'm pretty sure that by default that coin would be permanently lost). I don't think there's any risk free put (it seems more like a call that you're thinking of - unlimited upside, no downside) here.

maybe. but i'm just going along with what's being advertised here.  a well vetted, tested SC thru a federated system that is then brought online as a Bitcoin linked SC is "unlikely" to fail.  given that, the 2wp is acting like a risk free put.  maybe a call is a better term, i don't know.  but then, my question about manipulation still stands unanswered.  to assume a stable 1:1 price relationship of BTC to scBTC seems naive i think.  there's always volatility and we see signif disparities btwn exchanges today that fluctuate sometimes wildly.

in the case of a SC with a true innovation, like faster tx times, it seems to me with time, all tx's would be incented to move to the SC as the block rewards diminish on the MC, depriving BTC miners of badly needed revenue.  yes, MM is a possiblity to harvest those SC fees but lots of miners nowadays are losing money.  they might be more than willing to primarily direct mine a SC if they can scoop up large tx fees (assuming of course MM is only a % of the BTC hashrate).

Transactions moving to a sidechain doesn't deprive BTC miners of their primary source of revenue; I guess you're already in this paragraph talking about far future when block reward is insignificant. So, fold into the below.

in 2140 when all block rewards are gone and the MC and SC (with its innovation) only mine tx fees, which chain would you rather be on?  if you say that MC core dev will upgrade Bitcoin before that, what metrics will they use before they feel pressure or panic by a SC beginning to take over?

I'm not sure we need to be analysing what happens so far into the future. But indeed if there are no longer mining rewards, then the 'classic' blockchain is no longer special. It's just one of many. But this is so far away from where we are today it seems pointless analysing it.

true, it's into the future.  but how far?  there will be a transition point and if a risk free put (on BTC) exists today, why not move a major portion of your BTC to the SC today and leave it there?  

[laurentmt]

I am wondering also about sidecoins fungibility and redemption:
let's say I have locked one bitcoin to release one sidecoin. To release the locked bitcoin, does my sidechain-enabled wallet simply collect one sidecoin (plus tx fee) worth of sidechain unspent outputs or  are there other constraints on my sidechain transaction transferring the coin back to the bitcoin blockchain ?

My understanding of the white paper was that there must be a link between the initial coin unlocked on the SC and the coins used to exit the SC. Therefore, my questions about fungibility.

While locked on the parent chain, the coin can be freely transferred within the sidechain without further interaction with the parent chain. However, it retains its identity as a parent chain coin, and can only be transferred back to the same chain that it came from.

But I must confess that I'm still not sure to get it right. For example, how to track this link if the SC implements some anonymity features like the unlinkability of utxos ? (or does it means that there could be some kind of incompatibility between this required link and anonymity ?).

Another hypothesis is that any SC coin can be used to escape the SC. The peg just checks that the global amount ever transfered from the SC to its parent is lower than what was transfered from the parent to the SC. In that case, parent chains are protected against the creation of "fake" coins coming from a SC and fungibility in the SC is not such an issue.

But with this hypothesis, we may imagine some "funny" scams:
- Let's take again the diamond architecture and let's imagine that SC1 is a legit SC but SC2 and SC3 are scam chains working together.

- Honest users transfer coins into SC3 via SC1
- Attackers transfer coins from SC2 to SC3
- Attackers transfer coins from SC3 to BTC via SC1
- At a moment, it becomes apparent that there may be a problem with SC3 (creators appear to be shady actors or whatever). SC1 decides to "cut the link" with this chain. Users of SC1 gradually stop transferring SC1 coins to SC3.
- Honest users still holding coins in SC3 can redeem them in SC2 but can't get back to BTC...

Well, seems better to wait for answers from the experts.

[Luke-Jr]

SC1 decides to "cut the link" with this chain.

What? SC1 is a blockchain, not an entity.

[laurentmt]

SC1 decides to "cut the link" with this chain.

What? SC1 is a blockchain, not an entity.

Sorry for the shortcut. When I say "SC1 decides to cut the link" I mean the community behind it (devs, users, ...).

But this is a good point. As we talk about an asymmetric schema (parents and sidechains) I've assumed that the decision to peg 2 chains (one being the parent, the other being the sidechain) is a one-time decision made by the 2 communities. Therefore, I assume that unlinking the 2 chains could also be a decision made by the communities. Is there an error in these assumptions ?

EDIT: After some more thoughts, I guess it's not realistic to imagine that the bitcoin community would have to explicitly accept every new sidechain.
Therefore, the hypothesis of the parent community "cutting the link" is not realistic. I've modified my previous post and replaced this hypothesis with another one.

[securedolphin]

The paper suggests creating a new opcode.
Isn't it, by pure accident (I assume), also possible to do it with existing opcodes, along the lines of my proposal here?:
https://bitcointalk.org/index.php?topic=819901.0
https://github.com/cornwarecjp/amiko-pay/blob/master/doc/pay%20with%20blockchain%20knowledge.md

I'm not saying that my approach is necessarily better: one obvious disadvantage is that it's a monstrous script (but then, opcodes only take a single byte of storage). I'm just saying it might be an option to be considered.

From what I understand, there is general aversion to OP_CAT due to inherent vulnerabilities that are hard to contain in the script interpreter (potential stack explosion). It may be safer and simpler to introduce an OP_FIND instead. OP_FINE would A better option may be to re-code your transaction with something like OP_FIND -1 if the substring is not found or the index of the beginning if it is. The return value will be numeric, i.e. CScriptNum type.

If OP_FIND was available and OP_HASH256 variant that would take two arguments rather than one, it would be possible to code p2sh transaction to validate headers of alternative chains. Here is an example for NameCoin. This is just an illustration of the concept. It is likely not to cover all possible malicious inputs.

Input:
<push merge mined header> <-- This is a header that does not satisfy BitCoin difficulty but is good enough for alt chain(s)
<push merkle hashN>,
<push merkle hashN-1>,
..
<push merkle hash2>,
<push merkle hash1>,
<push the merkle root of merge mined chain headers> <-- Obtained through getAuxWork from alt chains or through some other means.
<push the merge mined coinbase> 

Script:
OP_TUCK                          //// Save the merge mining coinbase for subsequent check for inclusion in the merge mined block
OP_FIND                          //// Check that the merkle root of merge mined chain headers is in the coinbase, i.e. that this is indeed a valid proof of work
-1
OP_EQUALVERIFY             //// Exit if the merkle root of side chains is not present in the merge mined coinbase
OP_HASH256_2               ////  Compute HASH256(<merge mined coinbase>, <merkle hash1>), i.e. move up one level in the merkle tree of transactions
OP_TUCK                        ////  Save the result to save it for computation of the next level if needed.
OP_EQUAL                      ////   If the result is equal to the next item then we've reached the top of the merkle tree and it is valid
OP_IF
OP_TRUE                        ///    Push TRUE and do nothing else - essentially finish the script with TRUE
OP_ELSE

OP_HASH256_2               ////  Compute HASH256(<merge mined coinbase>, <merkle hash1>), i.e. move up one level in the merkle tree of transactions
OP_TUCK                        ////  Save the result to save it for computation of the next level if needed.
OP_EQUAL
OP_IF
OP_TRUE
OP_ELSE

OP_HASH256_2               ////  Compute HASH256(<merge mined coinbase>, <merkle hash1>), i.e. move up one level in the merkle tree of transactions
OP_TUCK                        ////  Save the result to save it for computation of the next level if needed.
OP_EQUAL
OP_IF
OP_TRUE
OP_ELSE

...

...

OP_HASH256_2               ////  Compute HASH256(<merge mined coinbase>, <merkle hash1>), i.e. move up one level in the merkle tree of transactions
OP_TUCK                        ////  Save the result to save it for computation of the next level if needed.
OP_EQUAL
OP_IF
OP_TRUE
OP_ELSE

OP_ENDIF   ///
OP_ENDIF   ///
OP_ENDIF   /// Close all IF blocks
OP_ENDIF   ///
OP_FALSE   //// Merkle tree is invalid


Obviously this won't work if the merkle tree is deeper than the number of check blocks. However, that shouldn't be a concern as very deep trees can be accommodated withing the 520 byte script size limit.

Both, OP_FIND and OP_HASH256_2 produce fixed size input, which make them safe from the perspective of causing potential memory/stack explosion.

[johnyj]

I stopped reading when I see the word IOU in the white paper

[brg444]

maybe. but i'm just going along with what's being advertised here.  a well vetted, tested SC thru a federated system that is then brought online as a Bitcoin linked SC is "unlikely" to fail.  given that, the 2wp is acting like a risk free put.  maybe a call is a better term, i don't know.  but then, my question about manipulation still stands unanswered.  to assume a stable 1:1 price relationship of BTC to scBTC seems naive i think.  there's always volatility and we see signif disparities btwn exchanges today that fluctuate sometimes wildly.

No it is not naive and Adam has explained exactly why. The peg being algorithmic, it creates even more efficient arbitrage. There are very good reasons for why the 1:1 price exchange will remain stable. You need to propose a reason why it will not because from my point of view and many others here it is clear as day.

Clearly given that this is the best case confirmation time for bitcoins, and the peg protocol is algorithmic there will be effectively ZERO spread, because the algorithmic peg is an unlimited standing offer at parity (plus per KB fees) and is in direct competition to any market offer, and rational actors take the lowest offer.

...

One can look to other bitcoin arbitrage scenarios for a hint at how it works.  Look at the spread between btc-e & bitstamp now that multiple people are systematically arbitraging it.  That is a far riskier arbitrage because you are relying on governance and security management of bitstamp & btc-e in the face of 50% failure rate of bitcoin exchanges.  Ok these ones are survivors and better than full history average no doubt but still there is non zero risk there and yet the spread is basically 0, this is because of competition amongst arbitrators.  Compare to a 2wp, where there is an algorithmic arbitrage.  A bot can take that all-day long at zero risk (using smart-contracts).

true, it's into the future.  but how far?  there will be a transition point and if a risk free put (on BTC) exists today, why not move a major portion of your BTC to the SC today and leave it there? 

2140 is how far. Until then, block subsidy will entice miners to stay on the mainchain. Meanwhile they will merge mine any sidechain that will gain significant traction and value AND the mainchain. Your argument about smaller miners losing money and mining only the sidechain holds no ground. First smaller miners will soon be extinct and as long as the most important majority of the mining power does not defect there is no danger for the mainchain.

[Boussac]

Well, seems better to wait for answers from the experts.

Still waiting. The way this fungibility issue is ignored in this otherwise awesome white paper is puzzling with so many bright minds as co-signers.

I assume for simplicity a 1:1 peg between bitcoin and sidecoin.
Perfect fungibility would mean I can redeem any set of unspent outputs totalling one sidecoin on the sidechain to release any locked bitcoin on the blockchain.

To illustrate this notion, suppose there is perfect fungibility and the sidechain is used as a mixer for the blockchain.
I assume for simplicity a 1:1 peg between bitcoin and sidecoin.

"Dirty" BTCs are transferred to the sidechain and come back clean as sidecoins but with a 10% laundering fee: in the off-chain market  I can only get one sidecoin for 1.1 BTC because I would need 1.1 BTC to get a clean sidecoin in a sidechain transaction.
The point is  that, with fungibility, the spread between the pegged rate and the market rate can be significant.

I could have taken any example where the function of the sidechain requires fungibility and commands a transaction fee.
Transaction fees on a sidechain are not necessarily market driven because of market imperfections.
Therefore fungibility is an important design parameter for sidechains.

[Luke-Jr]

Well, seems better to wait for answers from the experts.

Still waiting. The way this fungibility issue is ignored in this otherwise awesome white paper is puzzling with so many bright minds as co-signers.

I assume for simplicity a 1:1 peg between bitcoin and sidecoin.
Perfect fungibility would mean I can redeem any set of unspent outputs totalling one sidecoin on the sidechain to release any locked bitcoin on the blockchain.

To illustrate this notion, suppose there is perfect fungibility and the sidechain is used as a mixer for the blockchain.
I assume for simplicity a 1:1 peg between bitcoin and sidecoin.

"Dirty" BTCs are transferred to the sidechain and come back clean as sidecoins but with a 10% laundering fee: in the off-chain market  I can only get one sidecoin for 1.1 BTC because I would need 1.1 BTC to get a clean sidecoin in a sidechain transaction.
The point is  that, with fungibility, the spread between the pegged rate and the market rate can be significant.

I could have taken any example where the function of the sidechain requires fungibility and commands a transaction fee.
Transaction fees on a sidechain are not necessarily market driven because of market imperfections.
Therefore fungibility is an important design parameter for sidechains.

Can you come up with an example that is plausable? Having a hard time following enough to figure out what the actual question is...

[laurentmt]

Can you come up with an example that is plausable? Having a hard time following enough to figure out what the actual question is...

@Luke:
Thanks for your patience. Let's forget the examples which are just extrapolations on our side.
Boussac and I are trying to better figure out the details of the peg mechanism and their consequences at a higher level (economic).
Basically, the question is the one asked by Boussac:

Let's say I have locked one bitcoin to release one sidecoin. To release the locked bitcoin, does my sidechain-enabled wallet simply collect one sidecoin (plus tx fee) worth of sidechain unspent outputs or  are there other constraints on my sidechain transaction transferring the coin back to the bitcoin blockchain ?

On my side, I would add this question:

Am I right if I say that parent chains don't choose their sidechains but sidechains (devs, community) choose their parents ?

Still waiting. The way this fungibility issue is ignored in this otherwise awesome white paper is puzzling with so many bright minds as co-signers.
...
Therefore fungibility is an important design parameter for sidechains.

@Boussac:
TBH, I don't think this point has been ignored by the team.
In fact it has been stated that coins received from different chains should be treated as different types of assets (in the WP, in this thread, ...).
I fear that we (the community) might have underestimated the implications of this point for sidechains design.
I don't see that as a flaw, but as you state, it's an important factor to consider while designing a sidechain and it's also why I'm wondering if sidechains choose their parents (how many, which ones, ...) because this question about fungibility is really related to sidechains with several parents.

[Luke-Jr]

Boussac and I are trying to better figure out the details of the peg mechanism and their consequences at a higher level (economic).
Basically, the question is the one asked by Boussac:

Let's say I have locked one bitcoin to release one sidecoin. To release the locked bitcoin, does my sidechain-enabled wallet simply collect one sidecoin (plus tx fee) worth of sidechain unspent outputs or  are there other constraints on my sidechain transaction transferring the coin back to the bitcoin blockchain ?

Once a bitcoin is locked to a sidechain, it is entirely up to the sidechain rules what the terms are for the release.
The obvious case is 1:1 equivalence, but there's nothing saying a sidechain must do it that way.

On my side, I would add this question:

Am I right if I say that parent chains don't choose their sidechains but sidechains (devs, community) choose their parents ?

Yes, that's correct. The parent chain could try to prevent sidechains below it, but even then as long as there is multisig you can always do a federated peg sidechain.

[tvbcof]

On my side, I would add this question:

Am I right if I say that parent chains don't choose their sidechains but sidechains (devs, community) choose their parents ?

Yes, that's correct. The parent chain could try to prevent sidechains below it, but even then as long as there is multisig you can always do a federated peg sidechain.

It does seem to me on a theoretical basis that if a child chain is not a complete black-box, a parent chain could analyze it and kill the peg in a targeted manner.  It seems to me a corner-case threat, though, since a parent chain which would do it would probably be so degenerate that it itself would not have many fans.

[Boussac]

Boussac and I are trying to better figure out the details of the peg mechanism and their consequences at a higher level (economic).
Basically, the question is the one asked by Boussac:

Let's say I have locked one bitcoin to release one sidecoin. To release the locked bitcoin, does my sidechain-enabled wallet simply collect one sidecoin (plus tx fee) worth of sidechain unspent outputs or  are there other constraints on my sidechain transaction transferring the coin back to the bitcoin blockchain ?

Once a bitcoin is locked to a sidechain, it is entirely up to the sidechain rules what the terms are for the release.
The obvious case is 1:1 equivalence, but there's nothing saying a sidechain must do it that way.

Thanks but my (very basic) question is about the fungibility of the sidecoins.
I rephrase the question.
Is the release of a locked bitcoin (or any fraction thereof)  tied to a specific sidechain transaction OR is there flexibility in the choice of the unspent outputs on the sidechain to release the locked bitcoin?

Pratical use case: suppose I have locked one bitcoin in tx A to release one sidecoin in tx A' on the sidechain.
Later, I lock another bitcoin in tx B to release another sidecoin in tx B'.
Can I redeem the second sidecoin to release the first bitcoin ?

[Luke-Jr]

Boussac and I are trying to better figure out the details of the peg mechanism and their consequences at a higher level (economic).
Basically, the question is the one asked by Boussac:

Let's say I have locked one bitcoin to release one sidecoin. To release the locked bitcoin, does my sidechain-enabled wallet simply collect one sidecoin (plus tx fee) worth of sidechain unspent outputs or  are there other constraints on my sidechain transaction transferring the coin back to the bitcoin blockchain ?

Once a bitcoin is locked to a sidechain, it is entirely up to the sidechain rules what the terms are for the release.
The obvious case is 1:1 equivalence, but there's nothing saying a sidechain must do it that way.

Thanks but my (very basic) question is about the fungibility of the sidecoins.
I rephrase the question.
Is the release of a locked bitcoin (or any fraction thereof)  tied to a specific sidechain transaction OR is there flexibility in the choice of the unspent outputs on the sidechain to release the locked bitcoin?

Pratical use case: suppose I have locked one bitcoin in tx A to release one sidecoin in tx A' on the sidechain.
Later, I lock another bitcoin in tx B to release another sidecoin in tx B'.
Can I redeem the second sidecoin to release the first bitcoin ?

If tx A and tx B are transferring from the same parent blockchain, they should be the same asset on the sidechain.
Obviously you can redeem any "sidecoin" of the same asset type using any of the locked coins, since as soon as you do a transaction on the sidechain the original transferred-in coin is consumed.

[DumbFruit]

If SIDECHAIN1 binds to some output on the Bitcoin chain, how can you guarantee that I can't run an otherwise duplicate SIDECHAIN2 that grants all bitcoins to myself and then I just turn around and take the coins on the output of Bitcoin?

"4.2 Fraudulent transfers" is apparently talking about this issue, but I still wonder what prevents a total reorganization from the genesis of the sidechain by whoever made it and having the flexibility of deciding to do this anytime in the the future?

It seems like no matter what you have to trust whoever created the side-chain for as long as the side-chain exists.

Edit: Removed some meandering...

[Luke-Jr]

If SIDECHAIN1 binds to some output on the Bitcoin chain, how can you guarantee that I can't run an otherwise duplicate SIDECHAIN2 that grants all bitcoins to myself and then I just turn around and take the coins on the output of Bitcoin?

"4.2 Fraudulent transfers" is apparently talking about this issue, but I still wonder what prevents a total reorganization from the genesis of the sidechain by whoever made it and having the flexibility of deciding to do this anytime in the the future?

It seems like no matter what you have to trust whoever created the side-chain for as long as the side-chain exists.

You have to trust the miners on the sidechain not to 51% attack it with a "SIDECHAIN2", yes. Just like Bitcoin*.

* Not exactly "just like" if you're using SPV proofs.

[DumbFruit]

Ok, that makes sense. The small space available for configuring the SPV proofs, the ease of 51% attacks, the high resource costs, fairly high complexity, and few use cases ends up making me very skeptical that the thing should be in Bitcoin, but I think it's a neat protocol.

There seems to be a common idea that the way to make a Unit of Account more valuable is to make it do more things, but I think that's actually the opposite of the truth. If adding more bells and whistles makes the underlying currency more expensive to move around, then I think it's not the right way to go. I guess that subject could use it's own thread though...

[Luke-Jr]

The small space available for configuring the SPV proofs, the ease of 51% attacks, the high resource costs, fairly high complexity, and few use cases ends up making me very skeptical that the thing should be in Bitcoin, but I think it's a neat protocol.

Uh, what "ease" of 51% attacks? Or high resource costs?
And only few use cases? O.o

[laurentmt]

On my side, I would add this question:

Am I right if I say that parent chains don't choose their sidechains but sidechains (devs, community) choose their parents ?

Yes, that's correct. The parent chain could try to prevent sidechains below it, but even then as long as there is multisig you can always do a federated peg sidechain.

@Luke: Thanks for the answers !

It does seem to me on a theoretical basis that if a child chain is not a complete black-box, a parent chain could analyze it and kill the peg in a targeted manner.  It seems to me a corner-case threat, though, since a parent chain which would do it would probably be so degenerate that it itself would not have many fans.

You're 100% right that it's a big corner-case. Unfortunately it was the first example which came to my mind ...Mea culpa.
It seems definitely more realistic to imagine users deserting a scam chain than a ban organized and approved by a whole community.

@Boussac:
WRT fungibility, I come to these conclusions:

- If there is a unique path between a SC and bitcoin (the "root" chain), and if the chain (and none of its ancestors except bitcoin) doesn't issue its own coins, then fungibility is guaranteed (all coins are as good as bitcoin).

- If there's multiple paths between the SC and bitcoin, or if a chain on the path issues its own coins, then fungibility is not guaranteed per se.

A good use case for this kind of architecture would be a chain acting as a decentralized exchange. On this SC, coins are not fungible but are considered as different types of assets. If this chain has a scam chain as a parent and if I trade some "good" assets for these scam assets, it's likely that I may lose money. I guess we will see scam chains as we've seen scam coins but it's not a problem at protocol level.

A chain with several parents could try to maintain fungibility for all the coins received from its parents. My understanding is that this fungibility relies on the perceived security of the different parents and ancestors. Thus, this fungibility could be true for a while but change later (miners leaving en masse a parent chain,...). That sounds like a risky bet for a chain having fungibility as one of its core principles.

Does it seem correct ?