Bitcoin Forum

I'm not involved at all but posting for discussion.

http://www.blockstream.com/sidechains.pdf

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

People expected something extraordinary, not an obvious utilization of SPV, so I think majority is a little bit upset.

really?

on the contrary I think that the simplicity of the solution should regarded as positive.

It's not simple. The authors explicitly state that

Maybe I misunderstood you I thought you've said "simple" whereas you've actually used "obvoius".

SPV is pretty much the only way to get things to work.

If you want to distribute validation of the blockchain, then you need some way for validators to trust that other parts of the system are doing their job.

I glanced over the paper and have a couple of perhaps naive questions:
1. As bitcoin has economic value, I don't quite understand how this would work with sidechains. Suppose I transfer 1000BTC to a sidechain, but whatever changes i make will result in a loss of purchasing power of the "new bitcoin" in my sidechain. However, since I have a two way peg, i would be able to transfer my "new bitcoin" back to parental bitcoin chain at the 1:1 ratio?
2. Alternatively, if my "new bitcoin" chain will be successful, then bitcoins will 'evaporate' from the parental chain toward my chain, but it is intuitively unfair that initial coins in the "new bitcoin" will have the same value as latecomers 'new bitcoins' that will 'evaporate' later from the parental bitcoin. If no equal value, then how that difference in value would be determined?
3. Will parental bitcoins acquire more and more value as sidechains accumulate or will they lose value toward zero as value is transferred to sidechains?
4. I think that authors might need to introduce some value "entanglement" between 'locked' bitcoins (that moved to sidechains) and the rest of bitcoins in the parental chain. This way, if sidechains acquire additional value this value will be reflected in "non-locked" parental bitcoins, otherwise parental bitcoins will be unaffected by sidechains growth and will eventually lose value.

1. Not sure why you think bitcoins will lose purchasing power on your sidechain. Because coins can always be transferred between chains, the value will be roughly equal. Any difference in value will be small and will just compensate for the delay in moving them.

2. Not sure why you think coins on both chains having the same value is "unfair." But again, the values will be roughly equal, because if they weren't there would be a profit opportunity in buying coins on the lower value chain, transferring them to the higher value chain, and selling them. Similar to why bitcoins on (functioning) exchanges tend to be about the same price.

3. As described above, the value of coins will be roughly equal between chains.

4. This is unnecessary. Market forces will make the values approximately equal without needing any help.

Purely economic discussion about sidechains should probably be on the 'Economics' subforum.

They introduce some additional complexity, but sidechains are exciting because when you look at the relative complexity that they introduce (compared to other technical changes) vs. the relative benefit that they give, that ratio is probably more favorable than any other technical proposal that I'm aware of.

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://bitcointalk.org/index.php?topic=819901.0)
https://github.com/cornwarecjp/amiko-pay/blob/master/doc/pay%20with%20blockchain%20knowledge.md (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.

The value cannot be equal if the properties are different because one coin/sidechain will be more attractive than another, and this is exactly the point I am making.
Alternatively, if a sidechain becomes more attractive than a parental blockchain and no direct value is assigned to this (and by definition to the remaining old blockchain bitcoin), essentially ALL bitcoins will migrate/diffuse to this more attractive sidechain.
Are economic considerations have to place in bitcoin development? This would be surprising all things considered.

Have you read the paper?

The coins can be transferred between chains at essentially no cost so, as go1111111 says, any differences can/will be arbitraged out. If you could buy Bitcoin and BitcoinSidechain for different amounts of fiat you'd do so.

Regarding your #2, I don't see anything intuitively unfair about it since the two chains are both limited to the same equivalent number of bitcoins outstanding. Eg. Whether your 1000 BTC are on the main chain or the side chain, no one can increase the number of coins available.

:-)

So as I understand SPV(simplified payment verification proof), every single miner in this other network would need to run a copy of the Bitcoin blockchain in order for this to work?

I think that where you are missing the boat is that different sidechains would be expected to have vastly different characteristics.  One man's trashcoin is another man's treasurecoin.  This makes it perfectly possible for significant interest in many different sidechains and many holders thereof.  In straight monetary terms everything would be normalized to Bitcoin (which itself would continue to be normalized to fiat) and arbitrage would ensure this (via modulation of inflows and outflows through the two-way peg in most implementations I'd expect.)  But that does not impact on other forms of value individual users might find in a given sidechain crypto-currency solution.

As for 'bitcoin development' I'd breath a giant sigh of relief if Bitcoin went into maintenance mode.  Continued 'enhancement' is by far the biggest threat to my stash and this has already contributed to my selling a decent chunk around the 2013/2014 timeframe.  Sidechains, when they are up-n-running, make this slush mode a logical course of action.  Bitcoin can then be counted upon as a solid and reliable foundation with progress happening (at a much faster rate) on sidechain efforts.

PDF on Sidechains: Sidechained Bitcoin Substitutes by Konrad S. Graf
http://konradsgraf.squarespace.com/storage/Monetary%20analsyis%20of%20sidecoins%20KG%2024Oct2014.pdf

I've read the paper, and my first impression is that it's very promising, but a lot depends on the details. I'm most interested in the detailed functioning of OP_SIDECHAINPROOFVERIFY.

It looks like it solves an issue that has a considerable overlap with the issue I have in developing a fully trust-free Amiko Pay. So, if OP_SIDECHAINPROOFVERIFY is designed in a thoughtful way, it might enable Amiko Pay on Bitcoin's block chain itself (where OP_SIDECHAINPROOFVERIFY would verify a past section of Bitcoin's own block chain, instead of a side chain); otherwise, I might design a side chain that would support a fully trust-free Amiko Pay.

One thing I couldn't solve so far in Amiko Pay is how to prove absence of something in a block chain, without providing the full block chain (including all its transactions). This also seems to be necessary for the side chains concept (sidechains.pdf, line 207):
(emphasis added)
What does such a proof look like? Is it ever necessary to include such a proof (e.g. as a scriptSig) in a block chain, as input for OP_SIDECHAINPROOFVERIFY? It seems to me that a proof of absence has to be huge.

It sounds to me like the details of OP_SIDECHAINPROOFVERIFY limit the kind of things that can be done in a side chain, esp. w.r.t. the structure of blocks and block headers. OTOH, maybe this is not a big issue, if a side chain can have its own, modified rules for OP_SIDECHAINPROOFVERIFY, to support a second-degree side chain with rules that are not supported by the original OP_SIDECHAINPROOFVERIFY.

It's trivial to prove an absence in a ordered data-structure (like the linked list of blocks): You just reveal whatever is at the position the missing data would have to be at.  It's only the revealing of absent data in an unordered datastructure which is space infeasible.

WRT limiting in the implementation route of an opcode, ... you already see one reason it's less important: the ability to nest sidechains,  the other reason is that the verifier only needs to understand the transaction releasing coins back, everything else in the other blocks that isn't on the hash-tree path can be formated differently.

Vitalik Buterin wrote an article about sidechains in April (http://bitcoinmagazine.com/12349/side-chains-challenges-potential/), in which he says that


Do people working on sidechains agree with this? In general, what limitations exist on the consensus mechanism of a sidechain? I was under the impression that as long as a sidechain was in fact a "chain", and competing subchains vying to be considered the consensus chain had a concept of length, then that's all that was needed to be easily implementable as a sidechain.

(Not that proof of stake is desirable at all)

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.

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

Serious discussion doesn't usually take place on BitcoinTrollTalk.

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

(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

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?

No, this is the reason for the contest period.

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?

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.

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

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.

Yes, what else could it mean?  :P
So that could mean BTC could conceivably be stolen, as BTC could be pegged in the "Donkeycoin" blockchain?

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

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?

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?

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

Yes, they can have that.

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.

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.

 

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

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.

I assume these prices will be equal because of the peg, making fiat exchange prices irrelevant.  If they are not equal or nearly equal then the peg is not working and the system is broken anyway. 

to assume they are always equal i don't think represents reality.  there will be an ebb and flow of the relative price relationships as the chains are purposely designed to be different from a tech standpoint.  price movements also never move linearly in one direction.  i would expect that there would be times when one or the other price will be higher.

and all that is to ignore volatility induced by a speculative attack attempting to move markets.  see here:

https://bitcointalk.org/index.php?topic=68655.msg9372075#msg9372075

My scenario assumes a working peg through arbitrage.  You are correct that if fiat prices diverge, then it no longer applies.  However if fiat prices diverge, then the side chain itself is a failure anyway. 

but a scBTC could diverge to a higher price vs BTC.  or it can be manipulated to rise at a faster pace than BTC.  both could be a result of a speculative pump by a whale thru the peg.  and why not?  the 2 way peg in a 1:1 scenario acts like a risk free put.  remember, it's all upside and no downside being on the SC.  both scenarios would result in volatility and doubt about whether the SC is taking over.  

i would be really interested to hear some of your responses to my posts in my thread.

Being the guy who first (to my knowledge) proposed this nature of attack, I'll just say that the first thing which comes to mind would be some sort of progressive use fee on the sidechain itself somehow.  I anticipate using primarily sidechains that impose some sort of a use cost (even if there are options) mostly because they they can be used in a variety of healthy ways.  As always, if the sidechain is not a transparent box I'm not playing.

Actually, the attack I was thinking of was your simplistic form applied in such a way as to produce a resonance.  The normal engineering method of dealing with such issues is to introduce some method of dampening.

Good idea. The "use fee" could be reversible, like a deposit. That way, normal users are not penalized.

actually, i had a whole new thread post describing this attack written and prepared to put up on Sunday but decided to have Melbustus look at for review.  we had been discussing it back and forth when i saw your post mentioning a whale on the plane coming home Monday.  i didn't respond to you at the time b/c i've been thinking about it alot and changing it up (as you can see from the detail described in my thread and the concept of a risk free put).

not that it matters.

There seems to be some confusion about floating rates, sidechains are algorithmically pegged not floating.

Lets try a thought experiment.  Say you can directly move a bitcoin to a sidechain or move it back to the mainchain with either direction taking 10minutes and normal bitcoin fees.

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.

Now we introduce the concept of time-preference.  For security reasons (rather similar to coinbase maturity which sees you unable to spend freshly mined coins for 100 blocks) the algorithmic peg has a time-delay.

Now if you planned to hold anyway for that period or longer, then you dont care and the situation is unchanged.

But if you want to do a sidechain BTC transaction faster, you swap it for a small premium with someone who already has BTC on the sidechain and is planning to long term hold, or swap with someone trying to go the other direction.  What you pay them will be small due to the mechanics of arbitrage.  They'll just look for some small fee because to them if they're already long term BTC holders its basically free money, like interest on BTC to move funds back and forth and provide liquidity service for sidechains.  The $ exchange rate is immaterial, the best candidate for sidechain liquidity provider is someone who is anyway holding their own or other peoples BTC for long term storage.

Anyone who tried to sell  BTC on one chain for a lower than time-preference cost on another chain would just lose money.

I think the above logic and economic concept & precedent is extremely simple.  It seems like some people misunderstood Konrad Graf's comments, he's just talking about the mechanics of the low arbitrage spread.

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

The remaining non-imaginary risk is side-chain implementation defect, but the point of side-chains is to allow experimentation on new features to occur outside of bitcoin core.  This is actually a good thing for bitcoin core's risk because it doesnt have to take as much new development risk itself.  Sidechain development will also be rigorous like bitcoin, and you should look at the reputation of the authors of the sidechain you are considering using and have others review it or certify it before you dump your lifesavings into it.  You can still do long term holding on bitcoin if you prefer, and benefit from the even lower than current mainchain risk.

The current pattern in bitcoin infrastructure is most transactions are offchain (in exchanges and other offchain accounting).  Much of that code is not open, or inexpertly written or relying on firewalls and host security and hot wallet ratios plus you're vulnerable to governance failures, operator theft and or blackmail.  Most bitcoin lost to date has been for these reasons.  If, using sidechains, we get more innovation and more onchain transactions, its better to be onchain in a sidechain than offchain from bitcoin.  You dont even own bitcoins offchain, you have an IOU for a bitcoin from a human who typically has no banking governance nor operational security experience, though with better capitalization and management things are improving.

I would think more transactions, more transaction types and more uses for bitcoin, and faster innovation on bitcoin and more onchain transactions and zerotrust/smart-contract based infrastructure are all positive things for bitcoin, and it seems to be that most people with a technical understanding hold the same view.

Its not that a sidechain displaces bitcoin hypothetically and that this is bad; a sidechain is bitcoin, its the mechanism to internetwork bitcoin, to build on it.  Sidechains no more displace bitcoin than HTTP displaces the TCP and IP protocol it is transported on.  Alt-coins and alt-shares are in nominal competition with bitcoin, though it seems highly unlikely they would catchup with bitcoin's network effect nor reach an appreciable real-life usage; but sidechains are not in competition.

Bitcoin has one advantage over sidechains - it has the subsidy, and full node security, so I'm sure it'll be able to defend itself against abandonment or insecurity, and sidechains depend on bitcoin anyway so all bitcoin users on which ever chains have a meta-incentive to see bitcoin main remain secure.   We have decades of subsidy ahead to deal with fee-only security for bitcoin, and sidechains may move forward the ways to do that because the sidechain by default has only fee security from the start.

Anyway one potential use for a sidechain is to host a beta for a major new bitcoin version.  If that version after say $1b value running in it for a year, gets upgraded into bitcoin, that hasnt displaced bitcoin, its facilitated its feature and performance upgrade, which is a good thing for everyone.

The exciting thing about the internet wasnt just the ability to send IP packets, but all the applications and permissionless innovation that could be built using that transport.  Same for bitcoin.

Adam

If, on a normally functioning sidechain, a 'whale' decides to arbitrarily inflate the price of sidechaincoin (SCC) by buying up the order book on some exchange platform, so that let's say SCC are temporarily trading at 1.3 BTC / SCC on said exchange, any existing holder of SCC will simply sell their SCC for BTC, realising the 30% risk free profit (arbitrage), and then if desired, transferring those 1.3 BTC back to 1.3 SCC (because there is an algorithmic peg enforced at the cryptographic level that allows you to make this transfer - you do understand that this is the concept, right?). There is no put or call here, there is just arbitrage.

The principle of no arbitrage gives you the approximate stable price - 1 to 1. Any delta from that is due to second order effects of the type that Back refers to in the above post. Only in cases of catastrophic failure would there be a large divergence (and that's OK too, because "joining" a sidechain is entirely voluntary), and such an eventuality can only be temporary (either the sidechain 'crashes' entirely, or it comes back into quasi-equilibrium).

Is it possible to get this kind of architecture ?
https://i.imgur.com/dXIg1bk.png

Yes, but BTC-via-SC1 and BTC-via-SC2 would be different assets on SC3.
Although you can treat them identical if you want to (ie, if you trust SC1 and SC2 equally).

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.

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

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.

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://bitcointalk.org/index.php?topic=826263.0).

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

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.

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

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.

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 ?

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?

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.

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?  

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.
https://ip.bitcointalk.org/?u=http%3A%2F%2Fi.imgur.com%2FdXIg1bk.png&t=545&c=PTKEWUS-odMfyg
- 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.

What? SC1 is a blockchain, not an entity.

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

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.

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

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.

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

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

On my side, I would add this question:

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

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.

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.

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.

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

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.

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

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

@Luke: Thanks for the answers !

You're 100% right that it's a big corner-case. Unfortunately it was the first example which came to my mind :D ...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:
Does it seem correct ?

Thanks for the clarification that is worth adding at least a footnote in the white paper.
Also a sample transfer script sequence would help.

Sorry for off-topic, but could anyone point me to a practical implementation (even if it's still in development)?

Maybe I misunderstood, but I thought that this thing needed to have it's own hash-power in order to avoid attacks from the main blockchain. Therefore, unless the sidechain has enormous hashpower it would be trivial for a party to break away from the primary chain to do a 51% attack.

I say it's few use cases because I'm not convinced that there are alot of uses that would be preferred to be in a sidechain, rather than a totally separate solution. Though I'm not financier or whatever, so I'm probably just ignorant of all the potential.

Merged mining solved this a long time ago.

I can't think of any uses that would prefer a totally separate solution (other than scams).

"First, the miner must assemble a transaction set for both block chains."
http://bitcoin.stackexchange.com/questions/273/how-does-merged-mining-work

So if I'm reading that right, merge mining would mean that miners would need to assemble a different transaction set for every sidechain and then mine them? Then for every successful block for any sidechain the miner would send that work to the sidechain.

I'm very confused about how the hashing calculation can be independent of both Bitcoin and the sidechain, I thought PoW built on top of a hash of the latest block, in which case the hashes from one blockchain can't be used to secure another blockchain (Except by total coincidence).

Yes, this is where I saw that;
"For a block to be valid it must hash to a value less than the current target; this means that each block indicates that work has been done generating it. Each block contains the hash of the preceding block, thus each block has a chain of blocks that together contain a large amount of work."
https://en.bitcoin.it/wiki/Proof_of_work

The PoW algorithm for <sidechain> would include a Bitcoin block header in it.
But we're now somewhat off-topic for this thread, which is about sidechains, not merged mining...

Fair enough, I still have some questions, but I'll find some other place for them.

That highly depends on what the cost is going to be for moving stuff around on the Bitcoin blockchain, which in turn depends on how many sidechains, how decentralized the system is, how large the block size limit is, what the legal status is, and how much demand otherwise there is for bitcoin transactions.


Speaking of which, how would fees work here? The paper talks about how it's most beneficial to the miners to mine on every sidechain they can, but how do sidechains provide a reward? When users are using a sidechain do they need to provide fees to the network with their own bitcoins?

Yes, just like any bitcoin transaction...
Sidechains might also use things like demurrage to give miners a subsidy.

I'm sorry if this is off-topic (I hope it is not)... but I still can't get a clear understanding of what makes pegged side chains fundamentally better than merged mining? I see some benefits but not a single one that won't be attainable within merged mining concept:

a. Ease of implementation and spawning a new chain? Can be done with merged mining with some alterations to bitcoin scripting language (pegged chains require that also)

b. Robustness? Looks to be the same, more or less, between pegged and merge mined chains

c. Blockchain pollution? Merged mining takes just 40 bytes (slightly less) per block for arbitrary, unlimited number of merged chains.

d. Atomic conversion and swap? I'm not sure if the side chain needs to be pegged for that. Again, peg or not can be done with merge mined chains. No?

What's left then?

Pegged Sidechains and Merged Mining are to different concepts which can work together - but they dont need to.

Pegged Sidechain:
You can transfer a bitcoin to the sidechain and back to the btc blockchain.
-> not in the sense of trading but in the sense of moving: the moved btc is only available in the sidechain OR in the bitcoin blockchain

Merged Mining:
Just mine to chains at once. if they have a reward for finding a block you get both rewards (see namecoin for example: you can mine btc and nmc simultanously)

sidechains CAN be merged mined: this would make them more secure (if pools would support it though - otherwise its the opposit). but you can also make a sidechain which uses POS.

Thanks for the comment! It makes sense, but also makes me wonder about the value of "transfer a bitcoin to the sidechain and back to the btc blockchain" - what would be the real world example when moving is superior to cross-coin trading? Not to be critical, just a genuine attempt to understand. In other words, what can't be done in a world where there are only merge mined coins (chains)  and no pegged coins? I couldn't think of anything...

but aren't private keys created on the SC that are specific to a certain scBTC?  and when redeeming back to BTC, wouldn't the owner of those same scBTC have to come back thru the same SPV proof where they originated from?

atomic transfer?
afaik this is not possibly with other chains. it could be very useful for many things.. first thing which pops in my mind is a chain for micropayments which has a different security model than bitcoin and maybe less blockchain space requirements.

the most most exciting use SC-crypto's I can imagine:
free transaction fees with almost instant confirmation, demurrage fees 5% per year for saving in your own private keys, and interest for saving on a Centralized server 2% (determined by money in circulation ie block processing demurrage); instant access to funds with centralized server; and 2% inflation (server revenue = 0% cost for saving); a 1:1 peg with Bitcoin, miners receive 1% of all transactions that incur demurrage for MM. The intervals and percentages are not set but are amortized over the year and just represent an incentive split for the - per block demurrage. throw in a 3 days of clearing to exchange out BTC to encourage users to take advantage of the almost instant network with no risk of loosing Bitcoin as its secured with a 2wp.     

i am a nobody (laimen/enduser/speculator what ever you want to call it) around here. Just reading up on this.

This doesn't look ready at all. This is not coming soon, is it?
I have to ask myself: why implement that in bitcoin without testing? Is an altcoin-experiment planned to simulate for some time before moving to bitcoin itself?

Would be interesting to see what alts join that. Shitcoins for sure. So Bitcoin opens itself up to accomodate shitcoins that can't live on their own? Will enable people with no coding skills to pull scams. Watching, ordered the big bag of popcorn already. Can't wait for you to screw this up royally. Introduce more complexity, go ahead  :D
Provide fertile ground for every possible crap on earth to be secured with bitcoin hashpower that couldn't survive on its own, good idea. Your blockchain will be full of utter shit in no time and then you cry about the bloat.  :P
To prevent it you have to introduce central control very likely in the end.


you big boys are probably better off to play around with new tech in altcoins before moving to bitcoin but very likely everyone is on their high horse and doesn't want to listen. Not that i would care too much.  :D

I have been personally reading around for hours about this, yet i don't see what sidechains should be able to do what an altcoin isn't able to do or what real benefits they provide. I think right now of it as an elegant way to calm down the bitcoin hardcore-hoarders/believers/cultists from the potential threat that an altcoin could be for their investement. If i am right on that one this whole idea is likely a fascist one. I'll continue to read. I just hope i can find the huge benefits that couldn't be achieved by any other means in this whole idea.

Sidechain-coins don't have an independant value from what i read here because of the arb and because they are basically bitcoin. So what's the point? Experimenting? lol. Why do that on the bitcoin-chain? If you got experiments to do, why not do it with a bitcoin-clone that doesn't carry that marketcap?

what most people are missing: 'features are not money' and bitcoin is mainly money. The more you ad unnecessary stuff the more problems you will create. I'd recommend to keep it basic to money and play around with features and other possibilities of the blockchain-tech on other platfoms to not put the main purpose of bitcoin in joepardy (to be currency that is). But as i already stated: i am relatively uneducated

Quote from a wise man:
"Perfection is achieved not when nothing can be added, but when nothing can be left out"

That's the only irrelevant part of your post.
As for the idea that this benefits existing Bitcoin whales. It doesn't. It's a proposal that benefits those who have spent a large part their Bitcoin and those who have yet to invest.

Sidechains are a bad idea. 

Why, because of your imaginary 'put'?

If it is algorithmically guaranteed that you can convert 1:1 from a parent chain to a sidechain, then the fiat exchange rates for each can not diverge, aside from a small spread reflecting time preference (because it may take days to transfer between chains unless you use atomic swaps. But then market makers will happily offer atomic swaps for a spread).

I don't understand why you find this concept difficult. I think you are getting confused by Altcoins.

wow you're profound today :-)

at least you should have added a link to your own thread where sidechain's economic is debated at length

don't worry I'll do it for you:

https://bitcointalk.org/index.php?topic=68655.msg9292756#msg9292756

starting from the above, the thread turns its focus mainly on sidechains with a lot a valuable
inputs from a lot of people, of course there's also a lot of noise along the way.

edit: fix grammar

I'm still searching for a good justification for this myself

This thread seems to be dead.  Is there a live discussion of sidechains anywhere?  On reddit or other forum perhaps?

There are so many presumptions about what a pegged side chain to BTC would look like.

That is to presume the security of the SC would be equal or greater than the current BTC master chain. I highly doubt that will ever be the case.

If there was ever equal or greater security on a SC then why not have everyone just switch to the more secure chain?

To peg them and say they are "equal" and coins are transferrable between them makes little sense as one chain will always be more secure or have more infrastructure to support it.

Seems like a broken idea to me.

Is it set in stone yet? Or just a proposal?

You know that the proper thread to discuss sidechains is this one (https://bitcointalk.org/index.php?topic=68655.msg9967284#msg9967284), right?  :)
I think sidechains became the topic around that point, plus or minus a few pages.

The discussion around the potential economic impact of SideChain started hundreds of pages back
https://bitcointalk.org/index.php?topic=68655.14260 some good insight hidden in the many pages of name calling and trolling  ;)

sony xperia z2 hülle (http://www.hulle6.com/category-sony-xperia-z2-zubehoer-145.html)

It is a broken idea, but switching to another chain is either done via proof of burn, two way peg, or a hard fork. Either way it's a serious change. The SC idea isn't that bad an idea, but in the end, they would probably lead to more security issue due to added complexity. If it can be done, it will be done, but honey-badger don't care, and I'm tired of the whining from SC folks. Just do it.

Amir Taaki wants to bring complete anonymity to Bitcoin. First he has to demonstrate it on other blockchains. The SC developers can demonstrate it on an altcoin and if it works, then Bitcoin can adopt it. If they come up with a two-way peg that works, then the trade-off for whatever benefit the SC offers may be worth some sacrifice, like security or functionality. It's unlikely it can be more secure than Bitcoin AND have other benefits. If they did, then just hard fork Bitcoin.

One way in which a side-chain would not be identical to bitcoin is it has different features.  Unless we have provable security the added complexity would tend to make a side-chain less secure.  (And thats a reason for side-chains .. so that people can get access to more features without exposing other people to the risks relating to their feature).

For now there are also security tradeoffs in the 2wp mechanism, so that is another source of difference.

But in the future, if for example snarks or some other innovation becomes a proven secure cryptographic construct, then we can have security-equal sidechains (and security-equal smart-phones).  And then it may be possible to have a more secure side-chain: make a simplified side-chain that doesnt include bitcoin-script, p2sh, etc ie strips a bunch of stuff for pure cold storage.  Of course you also have the incentive compatibility issue, however over time the difference erodes as volume & hence fees increase and reward decreases as we get through more halvings.

Adam

Once the genie is out of the bottle and someone creates a new technology, expect the bad actors to be first in line.

Indeed the scammers are out in force in bitcoin land, as I said on the other chain:

its caveat emptor, you shouldnt put money into a chain unless there is some assurance that security & bitcoin protocol knowledgeable people have audited it.  People could certify chains (like sign them - "my name is blah and I'm a security researcher with reputation and I and my buddies audited this code and its good") or wallets could etc.  Its good and a feature that people can opt to use uncertified chains.  You want a situation where there is real open possibility for technical innovation & competition in chain features.

You also want no central control so no chains can get black listed.

Adam

Forgive me for resurrecting an old thread, but better late than never, right? The ideas in this paper are good, 95% of the way there, I'd say.

Section 3 describes the SPV proof method, essentially requiring us to trust miners not to collude to steal the funds mid-withdrawal, which they could very easily do. This solution, I think, flies a little too close to the sun; requiring this much trust in miners would, for me, break Bitcoin.

Appendix A describes a federated peg method. This requires us to trust federated servers. This would be fine for a laboratory experiment, but this solution is not trustless enough for actual use. No sale!

But it occurs to me, that there's a workable example of something that's not federated, but that resembles a federation enough to make collective decisions. You might even say it's already proven somewhat successful. I'm referring to the super node/master node concept, generically, collateralized nodes. The super nodes decide things in similar way to members of a federation, but membership is fluid. Anyone with enough collateral will be accepted into the federation as a matter of protocol. I'm more comfortable with this model; it makes the system open. Anyone materially invested in the chain can run a node and get a vote. Does the system have vulnerabilities? Having participated in working examples (Dash and others) myself gives me confidence that this system can be stable and robust against potential attack vectors. Bitcoin itself had to stand the test of time before people became confident that it was safe.

The next question: could collateralized "super nodes" on a side chain function to approve those critical Withdrawal Transactions? I think they could, and in a straightforward manner, too. Main chain coins could be held in safekeeping collectively in a multisig address, just as they are in the federated approach. (m of n) keys would be required to move coins out of that address. Each super node holds a key. As super nodes go offline and come online, the remaining nodes sign transactions to move all funds into new (m1 of n1) addresses and share them among all super nodes. It is not necessary to submit these to the blockchain immediately, as long as any single super node remains, the funds cannot be lost. It should be more than sufficient to submit the latest one every 10 minutes or once per Bitcoin block, or at least once per Withdrawal Transaction. The ratio of m to n should be as high as necessary to prevent a single actor or coalition from controlling m supernodes, but be low enough to be reasonably certain that (n-m) / n of the nodes will not go offline simultaneously. We can look at empirical data from Dash to debate and determine an ideal ratio.

In combination with SPV proofs, I would be confident enough in such a sidechain to actually put my bitcoin there.