Pegged Sidechains [PDF Whitepaper]

<< < (16/23) > >>

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

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

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

Edit: Removed some meandering...

Luke-Jr:
Quote from: DumbFruit on November 05, 2014, 07:42:53 PM

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

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

It seems like no matter what you have to trust whoever created the side-chain for as long as the side-chain exists.
You have to trust the miners on the sidechain not to 51% attack it with a "SIDECHAIN2", yes. Just like Bitcoin*.

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

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

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

Luke-Jr:
Quote from: DumbFruit on November 05, 2014, 10:04:38 PM

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

laurentmt:
Quote from: Luke-Jr on November 05, 2014, 05:47:58 PM

Quote from: laurentmt on November 05, 2014, 05:02:23 PM

On my side, I would add this question:
Quote

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

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

@Luke: Thanks for the answers !

Quote from: tvbcof on November 05, 2014, 06:13:52 PM

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

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

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

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

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

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

Navigation

 Message Index