Pegged Sidechains [PDF Whitepaper]

[dillpicklechips]

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

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

[Skoupi]

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

[Come-from-Beyond]

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.

[sickpig]

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.

[Come-from-Beyond]

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

Sidechains introduce additional complexity on several levels.

[sickpig]

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

Sidechains introduce additional complexity on several levels.

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

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

[TierNolan]

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.

[Biodom]

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.

[go1111111]

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.

[go1111111]

It's not simple. The authors explicitly state that

Sidechains introduce additional complexity on several levels.

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.

[cjp]

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

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

[Biodom]

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.

Because coins can always be transferred between chains, the value will be roughly equal.

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.

[cr1776]

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.

Because coins can always be transferred between chains, the value will be roughly equal.

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.

:-)

[mczarnek]

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?

[tvbcof]

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.

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.

[dillpicklechips]

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

[cjp]

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

Such a proof may be invalidated by another proof demonstrating the existence
of a chain with more work which does not include the block which created the output.

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

[gmaxwell]

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.

[go1111111]

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

However, [proof of stake] would be very difficult to implement into a side-chain, because the computations involved in validating proof-of-stake are likely too complex to effectively implement directly on a blockchain.

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)

[Crowex]

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

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