Topic: Pegged Sidechains [PDF Whitepaper] - page 3. (Read 14648 times)

@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:
@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.

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

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.

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.



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.

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

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:
<-- This is a header that does not satisfy BitCoin difficulty but is good enough for alt chain(s)
,
,
..
,
,
<-- Obtained through getAuxWork from alt chains or through some other means.
 

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(, ), 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(, ), 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(, ), 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(, ), 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.

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.

What? SC1 is a blockchain, not an entity.

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.

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.

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.

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?  

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.

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.

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.

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 off scBTC on an exchange for profit (the dump).

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).

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 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 ?

It seems to me you're talking about two possibilities. 1, a whale drags BTC (both sc and not, since they're the same asset) upwards to try to effect a pump and dump. That's no different from today. Whether he buys one or another doesn't really matter, since they're fungible with each other. 2, the possibility of large amounts of BTC being sent over to a sc. This latter possibility is certainly interesting, and possible, but since bitcoin creation is still only possible on the main chain, mining would still be incented to stick there. So this doesn't create a 'bitcoin main chain dies out' scenario; although of course it could reduce transaction volume there.

An example is that people switch a lot of their coin onto a 'lightweight' sidechain that's better in some way for fast transactions, but the "backbone" main blockchain is preferred for big, industrial scale money transfer (i.e. it takes the role of SWIFT). Also, if in some distant future where block rewards were insignificant and people decided to store most of their coins on the sidechain, then yes, the bitcoin mainchain would start to die out, but it wouldn't matter, because people would have voted with their feet and digital scarcity would have been preserved. But this is all very sci fi in 2014.

There are also interesting speculations to be had about how a sidechain might factor into a future scenario where there was some critical flaw or failure in Bitcoin. Those are interesting, but what I don't see is how a new sidechain is going to *create* a failure scenario, because Bitcoin seignorage is never going to be removed from the main chain in this proposal. If you print things on these new chains, that's business for that new chain. That's not Bitcoin.

There isnt BTC denominated volatility because you're comparing BTC to BTC, unless the arbitrageur is not anyway a long term BTC holder, and so looking at BTCUSD volatility, in which case you would be right; however BTCUSD volatility is sufficiently high that holders of BTC could undercut non-holders taking BTCUSD exposure solely to gain the arbitrage profit.  As I said the best candidate for sidechain liquidity provider is someone who is anyway holding their own or other peoples BTC for long term storage.

Note also re your CoD rate comparison, you can buy forex forward contracts for below the interest cost of borrowing the money to exchange now.  This is because the market maker can discount by using interest to move in the other direction.  

The same thing would take place in a mature arbitrage environment between sidechain and bitcoin, the arbitrageur can do it below the amortised 2wp fee cost, because he can hold positions in both chains and cancel out the flows in opposite directions, just as the forex forward contracts.  If you're willing to wait for p2p trade you may even do it at bitcoin tx fee cost only using cross-chain atomic swaps (faster than 2wp but slower than via arbitrage agent).

Or do the 2wp yourself direct if you're willing to wait.  

The interesting thing is the arbitrage can be both faster and cheaper than the 2wp, and trustless via smart-contracts.  And because its a p2p blockchain on a technical* level anyone can do arbitrage without permission from anyone.  

(*Technical because there is also regulation: regulations may apply to arbitrage service; though I do think an interesting future potential is that regulators in more forward-looking jurisdictions will exempt zero-trust operations from regulation.)

Adam

are you saying that it's not possible for a rising scBTC price in fiat terms to drag upwards the BTC price in a pump and dump?  what might cause this is if a whale is persistent enough to transfer a signif number of BTC thru the peg into scBTC causing other speculators to follow thinking the SC may take over.  as more scBTC appear on the SC steadily over time, wouldn't/couldn't that drag up the price of both scBTC and BTC despite the fact that the relationship of the two remain close to 1:1?  what could drive this is the "illusion" that the SC is taking off in usage and utility.

I think this sidechain concept is very exciting and I hope that at least one dev might consider adopting AT (http://ciyam.org/at) to test Turing complete processing on a sidechain (there is already a 10 BTC bounty for a successful atomic cross-chain transfer between Qora and a Bitcoin clone on offer here: https://bitcointalksearch.org/topic/20-btc-bounty-for-first-at-atomic-cross-chain-transfer-with-script-clone-826263).

An AT for a *lottery* has already been developed so perhaps one idea might be to have a specific "lottery" side chain.

The longer the time-preference, the bigger the possible spread because of the increased risk of volatility over time. Your SC can offer varied time-preference risk for fee rates desired by different trading strategies. Like Certificates of Deposit offering different interest rates depending on deposit length.

Thanks Luke & Andy !

Indeed, I was wondering what are the consequences of this type of architecture (combined with security rules) on the fungibility in the deepest sidechain (SC3). I think that Luke's comment answers my question : with this kind of architecture, fungibility in deepest SC is not "given", it depends on the "homogeneity" of parents.

I was thinking to this kind of scenario
------------------------------------
SC1 and SC3 are well established sidechain with a good level of security.
SC1 provides some features for anonymity and SC3 some features for fast micropayments (or whatever).
Then SC2 comes up as a concurrent of SC1. It seems a promising tech, thus SC3 takes it as a new parent. But SC2 is young and its security is lower than SC1.
At last, I'm a retailer and a frequent user of SC2. Sometimes, I transfer SC2 "coins" to bitcoin for my "savings" (in two steps using pegs or atomic swaps).

Security associated to SC1 and SC2 is not equal and the risk is not equivalent.
Thus, as a user of SC3, can I consider the coins coming from SC1 and SC2 as really fungible ?
I guess that point is really related to this kind of architecture and doesn't apply to simpler models (chains of SC, "star" model, ...).
------------------------------------

laurentmt: definitely. This is sorta "allowed by default" by a sidechain design which lets you move coins from any chain to any other chain, but note that it does bring some complexity.

Let me expand on Luke-Jr's point a bit.

There is a blurb in the whitepaper around line 260 about sidechains "treating assets from different parent chains as different assets". This means that in your diamond picture, there are two ways for coins to move from Bitcoin to SC3 --- however, even though both are "Bitcoins", they are distinct. Ones that came through SC1 can only be moved back through SC1 and those that came through SC2 can only be moved back through SC2.

Of course, you can atomic-swap anything for anything (provided you can find a counterparty) so this might seem like an artificial distinction. And if both SC1 and SC2 are well-known, secure chains, maybe your wallet even treats the two types of Bitcoins as identical (from a UI point of view). However, there is a good reason that they are distinct on a low level: suppose this weren't the case, and SC3 just saw a bunch of Bitcoins with no idea where they came from. If SC2, say, were insecure (maybe it is totally a sham chain created by an attacker) such that it contained Bitcoins not backed by anything, then an attacker can create some unbacked Bitcoins on SC2, move them to SC3, redeem them on SC1 (all Bitcoins on SC1 are actually backed), then redeem them for Bitcoins.