Topic: Pegged Sidechains [PDF Whitepaper] - page 5. (Read 14570 times)

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.

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

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

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?

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

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.

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?

No, this is the reason for the contest period.

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?

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.

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.

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

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)

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.

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.

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

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.

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?

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.

:-)

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.