Would it be possible to build a drivechain that is blind merge-mined with RSK, either with the existing protocol or a modified version of it?
Since it could be a while until the Drivechain BIPs are activated on bitcoin (if ever) I was thinking, what would be the best way to test Drivechain in a real-money environment? Could activate it on an altcoin. But could also activate it on RSK, which is already merge mined by bitcoin miners, so one step closer to a real bitcoin drivechain?
Your question is if it is possible to build a sidechain of RSK that is merge-mined with RSK or a sidechain of Bitcoin that is merge-mined with RSK ?
Both things are possible, but a sidechain of RSK being blind merge-mined is the easiest. We designed a subsystem of RSK called Universal Merge-mining for doing that, but since we didn’t have a use case, it wasn’t fully implemented.
Option A: Currently you could put your sidechain hash in a RSK contract state, and use a Merkle-trie inclusion proof as the merge-mining proof. The only problem with that is that the proof ends up being quite long (320 bytes of Bitcoin coinbase Merkle-proof, plus 128 bytes of bitcoin coinbase, plus 400 bytes of RSK header, plus 500 bytes of contract state inclusion proof. RSK has a feature to make blind-merge mining more efficient.
Option B: The RSK auxpow tag has space for a lateral tree of RSK sidechains (right next to the RSK block hash) and we have a design to use an RSK smart contract to bid for the slots on this auxpow tree.
The option (A) you can do it yourself without any hard-fork, and I can help you with that.
For option (B) if you have time , a project or a real use-case, I can help you to 1) to code it 2) push it as an RSKIP 2) Help the community to understand the value of it 3) help the core developers to implement it. The only important change is to make the auxpow root tree consensus-enforced to that if you buy a space you are assured that miners will not change that.
A big benefit of option B is that it becomes RSK-header format agnostic, so in the future you could talk directly with Bitcoin miners, and won’t need to interpret RSK data structures.
Interesting question and answer, would be more interesting if any project or development was pursued based on this idea, if you had the resources @light
No, my attention has been focused elsewhere. Right now I’m thinking the approach I described is not worth my effort for a couple of reasons:
The peg back to bitcoin mainchain would still rely on the federated Powpeg
RSK is merge-mined with bitcoin mainchain by a slim majority of hashrate so the security for RSK miners re-orging the drivechain bmm blocks by re-orging RSK blocks is not as high as it would be if the blocks were bmm’d by mainchain miners
That said I don’t think the idea is a complete lost cause, and if building a drivechain was my main focus I would probably pursue this route and just try to get more bitcoin miners to merge-mine RSK to close the security gap. But building a drivechain is not my main focus now, so I have set the idea aside and leave it to more motivated and focused people than myself to evaluate and maybe implement
