Pegged Sidechains [PDF Whitepaper]

<< < (17/23) > >>

Boussac:
Quote from: Luke-Jr on November 05, 2014, 07: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.

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

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

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

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.

Luke-Jr:
Quote from: DumbFruit on November 06, 2014, 01:20:31 PM

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

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

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, 01:20:31 PM

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

Navigation

 Message Index