Sidechain without changing Bitcoin?

[SideChainFan]

Is it possible to implement sidechains for Bitcoin without changing Bitcoin? i.e. relying on the current OP codes?

I'd appreciate any thoughts, thanks!

[1715090341]

1715090341

[1715090341]

1715090341

[1715090341]

1715090341

[gmaxwell]

Is it possible to implement sidechains for Bitcoin without changing Bitcoin? i.e. relying on the current OP codes?
I'd appreciate any thoughts, thanks!

Yes/No.  A sidechain like functionality could be implemented using multisignature oracles where it's trusted that a majority of signers will abide by the rules and sign only when the sidechain says to sign.  This can be useful for some things— e.g. when there are few users of the sidechain and the signers can just be the users, or for testing.

But it's not possible implement the mining based decentralized version without some script enhancements.

[jgarzik]

Here's one side chain design that requires zero changes to bitcoin, and zero external parties such as oracles:

1. Put a block header for your side chain into an OP_RETURN output.
2. Core consensus rule:  Only one sidechain block header per bitcoin block.  If multiple sidechain TXs exist in a single bitcoin block, the winner is chosen based on highest transaction fees.

For any bitcoin miner, the transaction fee is returned to yourself, making it a very low cost proposition to mine this side chain.  Akin to merge mining, adding such side chains should be cheap and easy.

If you are not a bitcoin miner, mining involves competing with random other parties to see who will burn the most money.  A decidedly non-optimal scenario, particularly if bootstrapping without miners initially.  But it does produce an easily provable consensus, and it could be mitigated with further rules (complexity++).

Obviously, this is very miner centric.

This is not as efficient as some scheme to stuff N chains into a merge-mined merkle root in the coinbase.  It is also not a complete solution for the folks who want confirmations faster than once-per-bitcoin-block.

It does work within the current bitcoin ecosystem with zero changes, and at very low cost to existing miners.  Possibly lower setup & maintenance cost than some merged mining setups.  "Permission-less innovation"  It could be deployed today.

[kolinko]

To expand on what @gmaxwell said - you might want to check out our distributed oracles whitepaper: https://github.com/orisi/wiki/wiki/Orisi-White-Paper

We also have a working implementation of multisig oracles on this repo: https://github.com/orisi/orisi/ , and a discussion forum here: http://orisi.net/

[SideChainFan]

Jgarzik, how does that design enforce two-way pegging?

Gmaxwell, what would the new opcodes be? Would they verify that a program in C faithfully executed as described in SNARKs for C: Verifying Program Executions Succinctly and in Zero Knowledge, which was mentioned in this CoinWitness thread: https://bitcointalk.org/index.php?topic=277389.0    ?

[jgarzik]

Jgarzik, how does that design enforce two-way pegging?

There's no two-way pegging, which increases complexity.

It gives what a sidechain needs at a minimum:  Regularized block production, consensus on SidechainCoin's transaction timeline.

[eggdescrambler]

I just noticed this thread
How about this:
https://bitcointalk.org/index.php?topic=685028.0

But if this side chain has to be one per minute say, then the "winning miner" could be elected once every Bitcoin block and be responsible for the creation (of the next 10 side chain block, (one for every minute))