Topic: merged mining vs side-chains (another kind of merged mining) - page 2. (Read 6950 times)

I don't see problems as long as the sidechain rules are such that mined sidechain blocks payout some incentive to the miner within the sidechain.

This is the same situation as a temporary bitcoin chainfork, when two blocks were found roughly at the same time. The miner of the next block will then extend the sidechain which is longer, because this will give him the higher probability to create a sustainable side-chain block. If sidechain X and sidechain X' have the same sidechain-block-height, then it doesn't matter which one will be extended at the next block. It is exactly the same situation as it happens quite often with temporary bitcoin chains.

Everyone will neglect sidechain X because it is invalid. So also the next miner who wants to include the next sidechain block into a bitcoin block will extend the valid sidechain X', because otherwise he will not receive rewards in the sidechain.

SPV clients on the sidechain must have a bitcoin SPV client included. Then the client has to rely on the bitcoin block depth very similar to what a bitcoin SPV client would do... So nothing special...

I would say yes, almost as strong. Minor drawback is that in these special situations above, it might take one or two blocks more, to reach the same trustlevel as it would be the case in the bitcoin chain.

The obvious constructions have some problems.

What happens when Bitcoin block X  mines sidechain X  and bitcoin block X+1 mines sidechain X' (a fork)?

Okay, having answered that. Now answer what happens when Bitcoin block X  mines sidechain X  and bitcoin block X+1 mines sidechain X' (a fork), but sidechain X is _invalid_?

Okay, having answered that. What happens when its the sidechain along with bitcoin block X+1, X+2, etc. that are invalid? How do SPV clients on the sidechain work? 

Having answered that, can you still say that the consensus is 'almost as strong as Bitcoin consensus'?

Yes:

https://dianna-project.org/wiki/Merged_Mining#DIANNA_Implementation

I think in the proposal for DIANNA this mining approach was used.

Now let's compared these side-chains to "parasitic consensus systems" which were described in Peter Todd's (incomplete) article:


I think it's obvious that side-chain have same properties as parasitic consensus systems, except they have smaller footprint and need external storage.

This means that, for example, Mastercoin won't lose anything if it will be re-implemented in form of side chain, it would just need its own block storage and incentive system.

Currently merged mining mechanism is often recommended as a consensus mechanism for alt-currencies and whatnot: merged mining enables reuse of Bitcoin proof-of-work, which is nice.

However, it isn't the only way to re-use Bitcoin consensus. The alternative is to create a block chain which is fully dependent on Bitcoin.

It is usually called timestamping, see here: https://bitcointalksearch.org/topic/merkle-tree-service-for-coinbases-113337

Let's call a block chain based on timestamping a side-chain. (I don't know whether it's consistent with previous use, but at least side-chains were mentioned in a topic about timestamping.)

Side-chain is NOT an alternative chain as it doesn't use block chain algorithm, that is, rules for finding the best chain are different.

However, they share a lot of similarities with merged mining: they can use identical machinery on the Bitcoin side, as it's only necessary to reference a hash of side-chain block in the Bitcoin block, and it is what merged mining is about on the Bitcoin side.

The difference is in the rules used to validate blocks and to build the best chain:

• side-chain ignores blocks not references by Bitcoin blocks which are part of best-chain (and this means that Bitcoin reorg triggers side-chain reorg)
• side-chain ignore blocks which do not extend the longest chain
• otherwise, it is just a longest chain of blocks which are referenced from Bitcoin blocks which are part of the best chain

Let's summarize the difference between merged-mined chains and side-chains:

Merged-mined chains re-use Bitcoin proof-of-work, but their best chain is fully independent from Bitcoin best chain. Thus it is possible that merged-mined chain will have a reorganization when there is no Bitcoin chain reorganization; and vice-versa: Bitcoin reorganization has no effect on a merged-mined chain. Thus we can say that merged-mined chains constitute an independent consensus system which merely re-uses Bitcoin proof-of-work, but doesn't depend on Bitcoin chain.

On the other hand, side-chain consensus is fully dependent on Bitcoin consensus: side-chain reorganization is impossible without Bitcoin reorganization. (But Bitcoin reorgs can easily trigger side-chain reorgs.) This means that side-chain consensus is almost as strong as Bitcoin consensus.

I hope now you see why I brought up this topic: if only a fraction of Bitcoin miners uses merged-mining, side-chain s are more secure against double-spends and "51% attacks" than merged-mined chains!

Thus, side-chains are, in a way, superior. Then why merged-mining is the recommended method?

Well, of course, side-chain design has its own trade-offs, and probably the biggest one is longer confirmation times.

Let's compare two situations:

1. 10% of Bitcoin hashpower works on a certain side-chain: side-chain is as strong as Bitcoin, but delay until first confirmation is 10x bigger. (On the other hand, getting 6 confirmations on the side chain will require only 2.7 more time than getting 6 confirmations on Bitcoin chain.)
2. 10% of Bitcoin hashpower works on a certain merged-mined chain: confirmations are fast, but a Bitcoin mining pool having more than 10% of hashpower can brutally destroy it basically for free.