Pegged Sidechains [PDF Whitepaper] - page 2.

securedolphin

newbie

Activity: 4

Merit: 0

Quote from: onemorebtc on November 06, 2014, 02:18:47 PM

Quote from: securedolphin on November 06, 2014, 02:13:09 PM

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

onemorebtc

sr. member

Activity: 266

Merit: 250

Quote from: securedolphin on November 06, 2014, 02:13:09 PM

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.

securedolphin

newbie

Activity: 4

Merit: 0

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?

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: DumbFruit on November 06, 2014, 10:28:04 AM

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.

DumbFruit

sr. member

Activity: 433

Merit: 263

Quote from: Luke-Jr on November 06, 2014, 09:45:40 AM

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.

Quote from: Luke-Jr

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

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?

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: DumbFruit on November 06, 2014, 09:34:09 AM

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

The PoW algorithm for 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...

DumbFruit

sr. member

Activity: 433

Merit: 263

"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

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: DumbFruit on November 06, 2014, 09:20:31 AM

Quote from: Luke-Jr on November 05, 2014, 06:06:52 PM

Quote from: DumbFruit on November 05, 2014, 06: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

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.

Merged mining solved this a long time ago.

Quote from: DumbFruit on November 06, 2014, 09:20:31 AM

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.

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

DumbFruit

sr. member

Activity: 433

Merit: 263

Quote from: Luke-Jr on November 05, 2014, 06:06:52 PM

Quote from: DumbFruit on November 05, 2014, 06: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

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.

Come-from-Beyond

legendary

Activity: 2142

Merit: 1009

Newbie

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

Boussac

legendary

Activity: 1220

Merit: 1015

e-ducat.fr

Quote from: Luke-Jr on November 05, 2014, 03:24:26 PM

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.

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

laurentmt

sr. member

Activity: 384

Merit: 258

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

Quote from: laurentmt on November 05, 2014, 01: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, 02: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 Cheesy

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

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: DumbFruit on November 05, 2014, 06: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

DumbFruit

sr. member

Activity: 433

Merit: 263

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

legendary

Activity: 2576

Merit: 1186

Quote from: DumbFruit on November 05, 2014, 03: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

sr. member

Activity: 433

Merit: 263

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

legendary

Activity: 2576

Merit: 1186

Quote from: Boussac on November 05, 2014, 02:21:50 PM

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

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

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:

Quote

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 ?

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.

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.

Boussac

legendary

Activity: 1220

Merit: 1015

e-ducat.fr

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

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

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:

Quote

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 ?

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.

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 ?

tvbcof

legendary

Activity: 4592

Merit: 1276

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

Quote from: laurentmt on November 05, 2014, 01: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.

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.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

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

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:

Quote

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 ?

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.

Quote from: laurentmt on November 05, 2014, 01: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.

Topic: Pegged Sidechains [PDF Whitepaper] - page 2. (Read 14558 times)