Can you secure a sidechain with it's main chain? EDIT: Ardor does this.

[KingZee]

I don’t want to use or clone Ardor, I was just showing them as an example that it’s possible to secure a side chain from the main chain. I actually want to side chain Stellar.

To sum it up, it depends 100% on the main chain technology, and if it can implement this.

You can create a side chain of ANY coin, if you plan to provide the nodes & hashing power to maintain it.

If you want to transfer that burden to the main chain, there needs to be some way for you to tell the main chain nodes to validate your sidechain transactions, and mine the blocks that contain these transactions for you.
Not every coin has the technology for this, and if it does, you need to figure out how to achieve it (like ardors centralised way to broadcast your child chain to the nodes).

Do you (or anyone else) think that that would be a good solution? I thought of ways to do that but would it be easier just to clone our own, completely independent chain and then just figure out great incentives for nodes? Also does merge mining require a 2 way peg?

I don't think I can answer any of those 2 questions, they all depend on the type of project you want to launch. For the last question, merge mining just needs for your coin to have the same algorithm as the 2nd coin. There is some work involved in making the miners try to find a solution for both your pow problem and the 2nd coin's, but you don't necessarily need to peg your coin's value to it.

[d5000]

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.

[hosseinamin]

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.

[hosseinamin]

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.

[spartacusrex]

There have been some musings on recent bitcoin-dev emails about using your main-chain stake to secure a POS side-chain.

Normally you imagine using the internal currency of the side-chain to determine consensus.. but since that is self-reflexive poo poo.. using main-stake coins makes sense. Main stake coins have base value, whether the sidechain works or not.  

Now Bitcoin is POW and this is POS, so the exact security connection / implication is not straight forward, but there is certainly a correlation between the strength of BTC the POW currency and the POS systems built on top of it.

It's still a POS chain with all that _that_ entails - but backed by BTC.