Quote from: hosseinamin on February 01, 2019, 07:16:05 PM

Quote from: d5000 on February 01, 2019, 02:19:14 PM

Quote from: hosseinamin on January 31, 2019, 10:16:34 PM

1. pow is verified from main chain and re-org is possible if main chain had one
2. There should some pre-defined genesis fingerprint, This is block zero with no transaction in it
3. From there on if next block of main chain contains hash of sidechain block with hash of prevblock, Then verify the validity of block. And accept only if its valid.
4. After that any attempt to attach another block to a that prevblock would fail. even though the created block is invalid.
5. If there exist a main chain block with multiple block of the same sidechain. Accept the one with greater or less than all the others. (hash of it)

If I understand you correctly, then this is a sidechain model where the sidechain nodes follow the main chain closely and only produce blocks when the main chain produces blocks, and re-orgs when the main chain re-orgs.

The big advantage is, obviously, that cross-chain transaction management (important for 2-way-pegs) is much easier. But a couple of questions come up:

1) How do you prevent conflicts between sidechain nodes? If you use some sort of mining (e.g. merged mining) then there can be 51% attacks, by definition, because conflicts are solved with the "longer chain/more PoW rule". If you don't use mining, then which chain is correct if a part of the network is on a different "tip" than the rest?

2) What is the incentive to add blocks to the sidechain and to add all transactions correctly?

Regarding Ardor and similar models where the main chain secures the child/sidechains, in Ardor you preserve part of the scalability advantage, but sidechain structure is tied to the main chain protocol, so you can't "experiment" with child chains. That child chains are currently not easily added without action of the main chain devs (Jelurida, in Ardor's case) is not mandatory, that can be changed. Another disadvantage of this model is that the main chain protocol must support it explicitly, so you can't create a Bitcoin child-chain currently.

I don't know about two-way-pegs. I've not thought about it.

1. The 51% attack (re-org) is already solved at main chain. My point being it should not be solved again for sidechain (merge mined).
And conflicts are solved with other means. Which i did discuss in my earlier post.

2. There should an incentive to mine blocks. Like inflation, moving BTC or other means. At the end there should be competition at inserting the new block. Still if the block is invalid it won't be added to UTXO set of sidechain. But still is added to chain of block headers.

I hope i did described it well.

I realized this is not going to work. re-org on sidechain is also needed. Which essentially it may obsolete merge mine in first place.
The reason is that one can create a block and don't publish the content of it. Then sidechain is dead.