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

[Silas]

Hey so I am researching sidechains, I see how useful they can be for new coins that want to remain independent but still draw power from an already established network, but one problem I saw is that "Sidechains are responsible for securing their own network". Does this mean that it's impossible for a side chain to use the securing power of it's main chain to secure itself and it's transactions or is there a way around this?

EDIT: I was doing more research and I read more about Ardor, in which I saw that Ardor claims that their child chains ARE secured by the main chain and that those who create child-chains do not have to worry about security. How does that work?

 

[Jeremiah]

Hey so I am researching sidechains, I see how useful they can be for new coins that want to remain independent but still draw power from an already established network, but one problem I saw is that "Sidechains are responsible for securing their own network". Does this mean that it's impossible for a side chain to use the securing power of it's main chain to secure itself and it's transactions or is there a way around this?

Hey there. I did thought about the same thing. It should not be like that. look at my tweet to @TruthCoin

https://twitter.com/i/web/status/1090459542364848133

Edit: I'm wrong here,

Take a look at page to for the explanation

 

[Ezekiel]

Hey so I am researching sidechains, I see how useful they can be for new coins that want to remain independent but still draw power from an already established network, but one problem I saw is that "Sidechains are responsible for securing their own network". Does this mean that it's impossible for a side chain to use the securing power of it's main chain to secure itself and it's transactions or is there a way around this?

Regardless of re-org rules. All nodes should reach consensus. This is the main point.

 

[Angel]

Hey so I am researching sidechains, I see how useful they can be for new coins that want to remain independent but still draw power from an already established network, but one problem I saw is that "Sidechains are responsible for securing their own network". Does this mean that it's impossible for a side chain to use the securing power of it's main chain to secure itself and it's transactions or is there a way around this?

Hey there. I did thought about the same thing. It should not be like that. look at my tweet to @TruthCoin

https://twitter.com/i/web/status/1090459542364848133

It should not or is not? Are you saying that it should be changed or that sidechains are not like that inherently?

 

[Roman]

Your side chain needs enough nodes and hashing power to counter 51% attacks.

You're pegging your side-chain coin value to the main-chain, but your transactions, blockchain, basically everything becomes independent. It's obvious that in the case someone gets control over 51% of the nodes or hashing power of your chain, they could pick transactions to double spend, or through a sybil attack if they control too many nodes. Your problems are exactly the same of every other chain, with only 2 differences :

1. The initial coins you used to create the side-chain are what you would hypothetically call your "genesis block".
2. You can exchange those coins to main-chain coins at the designed rate when you distribute your side-chain coins

 

[Easton]

Hey so I am researching sidechains, I see how useful they can be for new coins that want to remain independent but still draw power from an already established network, but one problem I saw is that "Sidechains are responsible for securing their own network". Does this mean that it's impossible for a side chain to use the securing power of it's main chain to secure itself and it's transactions or is there a way around this?

Hey there. I did thought about the same thing. It should not be like that. look at my tweet to @TruthCoin

It should not or is not? Are you saying that it should be changed or that sidechains are not like that inherently?

I'm saying re-org structure made by @truthcoin at twitter is not a necessity.

Edit: I'm wrong here

 

[Connor]

Your side chain needs enough nodes and hashing power to counter 51% attacks.

You're pegging your side-chain coin value to the main-chain, but your transactions, blockchain, basically everything becomes independent. It's obvious that in the case someone gets control over 51% of the nodes or hashing power of your chain, they could pick transactions to double spend, or through a sybil attack if they control too many nodes. Your problems are exactly the same of every other chain, with only 2 differences :

1. The initial coins you used to create the side-chain are what you would hypothetically call your "genesis block".
2. You can exchange those coins to main-chain coins at the designed rate when you distribute your side-chain coins

So there really is no way to use the main chain that a side chain would be linked to secure it's transactions? Not at all?

 

[Miles]

Not at all certain about non-Bitcoin sidechains, and not even 100% certain about Bitcoin ones, especially because I'm only "familiar" with Bitcoin sidechains because of Rootstock (and maybe if you consider Counterparty a sidechain?) but KingZee probably summarised it in his first line, you absolutely need to secure it on its own. As a general incentive to do so, normally miners are given option to merge mine the sidechain with Bitcoin.

 

[Robert]

Not at all certain about non-Bitcoin sidechains, and not even 100% certain about Bitcoin ones, especially because I'm only "familiar" with Bitcoin sidechains because of Rootstock (and maybe if you consider Counterparty a sidechain?) but KingZee probably summarised it in his first line, you absolutely need to secure it on its own. As a general incentive to do so, normally miners are given option to merge mine the sidechain with Bitcoin.

Correct. What i was talking about is re-org within a the sidechain's merge mine without the need to re-org the main chain. Which was described in here.
http://www.truthcoin.info/blog/blind-merged-mining/

 

[Jameson]

Not at all certain about non-Bitcoin sidechains, and not even 100% certain about Bitcoin ones, especially because I'm only "familiar" with Bitcoin sidechains because of Rootstock (and maybe if you consider Counterparty a sidechain?) but KingZee probably summarised it in his first line, you absolutely need to secure it on its own. As a general incentive to do so, normally miners are given option to merge mine the sidechain with Bitcoin.

Correct. What i was talking about is re-org within a the sidechain's merge mine without the need to re-org the main chain. Which was described in here.
http://www.truthcoin.info/blog/blind-merged-mining/

That's beyond my depth of understanding unfortunately. My own experience with mining (POW anyway, I've done plenty of POS staking which didn't take a single effort other than opening the wallet) is with already dead chains. At any rate, it's more than 2 years since that's proposed. My guess is by now something's been done already similar to it... or with Lightning well in midst of rollout, the motivation behind the post (scaling) is no longer primary?

btw, you're an old hand...

 

[Nicholas]

It's crucial to first know what you want to achieve with your sidechain. But most of the time you would like to create a sidechain mainly to preserve some protocol independence from the main chain (e.g. Rootstock, which offers some enhancements to Bitcoin's scripting abilities) and obviously because of the scalability advantage. Otherwise, you could simply use a coloured coin.

If you want both advantages, then you need a mechanism to counter sidechain 51% attacks, like KingZee already wrote.

I'm however not sure if - apart from merged mining - a mechanism like Komodo's "Delayed Proof of Work" could not work with sidechains, too. However, this requires a semi-centralized design with specialized "notary nodes", which may have the same problems and drawbacks of all masternode/DPoS-based systems.

What you could also do is to let the main chain nodes validate the newest blocks of the sidechain without requiring to store or validate them entirely. But in this case you sacrifice some of the scalability and independence advantages. And, obviously, this can only be done if the feature is supported by the main chain protocol

 

[Cooper]

It's crucial to first know what you want to achieve with your sidechain. But most of the time you would like to create a sidechain mainly to preserve some protocol independence from the main chain (e.g. Rootstock, which offers some enhancements to Bitcoin's scripting abilities) and obviously because of the scalability advantage. Otherwise, you could simply use a coloured coin.

If you want both advantages, then you need a mechanism to counter sidechain 51% attacks, like KingZee already wrote.

I'm however not sure if - apart from merged mining - a mechanism like Komodo's "Delayed Proof of Work" could not work with sidechains, too. However, this requires a semi-centralized design with specialized "notary nodes", which may have the same problems and drawbacks of all masternode/DPoS-based systems.

What you could also do is to let the main chain nodes validate the newest blocks of the sidechain without requiring to store or validate them entirely. But in this case you sacrifice some of the scalability and independence advantages. And, obviously, this can only be done if the feature is supported by the main chain protocol

I want to point out that sidechain 51% attack is not a problem at the first place. Because it shouldn't be in the consensus of it.
I don't know how Rootstock works. I've just studied truthcoin. It did describe how re-org can happen in sidechain without doing re-org on main chain.

This is how sidechain should work.

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)

That's almost all is needed to not have re-org of sidechain and still all nodes will reach consensus.
Is there any issue in it?


Edit: This is not going to work. And here's the reason.


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

 

[Carson]

What you could also do is to let the main chain nodes validate the newest blocks of the sidechain without requiring to store or validate them entirely. But in this case you sacrifice some of the scalability and independence advantages. And, obviously, this can only be done if the feature is supported by the main chain protocol

Would this work with the main chain such as Stellar? Also could this be controlled to the point in which you could gradually move away from the main chain once you gain enough securing power to secure your own network? Like, say design the smart contracts on your front-end platform so that the transactions that go through them are validated with the main chain?

 

[Ian]

What you could also do is to let the main chain nodes validate the newest blocks of the sidechain without requiring to store or validate them entirely. But in this case you sacrifice some of the scalability and independence advantages. And, obviously, this can only be done if the feature is supported by the main chain protocol

Would this work with the main chain such as Stellar? Also could this be controlled to the point in which you could gradually move away from the main chain once you gain enough securing power to secure your own network? Like, say design the smart contracts on your front-end platform so that the transactions that go through them are validated with the main chain?

I suppose it can be done in any blockchain. The security given by that blockchain will apply to the sidechain. My view is the only sensible scheme is proof-of-work. proof-of-stake does already exists. It's the traditional banking

 

[Axel]

EDIT: I was doing more research and I read more about Ardor, in which I saw that Ardor claims that their child chains ARE secured by the main chain and that those who create child-chains do not have to worry about security. How does that work?

I looked up ardor, searched around for a few minutes.

1. How are you going to make this child chain? I only found information which says "Contact Jerulida, and file an application."
That sounds hilariously centralised, but it makes sense because :

2. Your child chain is only some sort of partially mirrored chain on the main chain. When a transaction happens in your child chain, it's technically validated by main chain nodes. Your blocks are blocks created on the main chain, and so on.
You can even transact coins between different child chains.

You can read : https://www.jelurida.com/child-chains-and-side-chains

So to sum it up, if you only want your own blockchain, to be able to create your own transactions, peg the coin value to another one, and not worry about node security, sure, you can make a child chain of this ardor. From what I read, your child chain is secure because ardor nodes keep the utxo and the blockchain of your child chain, but it gets pruned by default after n blocka, unless the node wants to keep the full history of your child chain on purpose.

51% attacks are reduced because your child chain blocks belong to the main chain. All the nodes are not technically just holding txes for you, but for every child chain.

The weird concept is how centralised this is.. you can't create a child chain unless you ask jerulida, and they create the sidechain for you, and have the nodes start storing your txes. I couldnt find anything about the "how" that works. But thats as far as I'm willing to go.