Does Rootstock need segregated witness or any other bitcoin improvements not currently included for it to work?

1 Answer 1

  1. No, Rootstock does not need segregated witness.
  2. Yes, Rootstock does need another Bitcoin improvement not currently available on mainnet.

Details below:

Rootstock & segregated witness

Segregated witness (segwit) eliminates all known third-party transaction malleability, which is an extremely useful feature but something that's only required in cases where a transaction has to be created before all of its parent transactions have confirmed.

For example, in a Spillman-style payment channel, the refund transaction is created and signed before the deposit transaction is broadcast---which is dangerous because if the deposit transaction is mutated (malleated), the refund transaction becomes invalid.

However, for a two-way pegged merged-mined sidechain like Rootstock is planning to use, the design makes the peg transactions robust against double spending (by waiting for many confirmations) in a way that also makes them robust against malleability.

Segwit also increases the maximum possible transaction size, which can make it more a bit more affordable to use sidechains, but not in any significant way and it isn't a requirement.

Rootstock & other Bitcoin improvements

Rootstock wants to use a two-way-peg merge-mined sidechain (also called a decentralized sidechain). There is no current know way to do this with just the opcodes currently enabled on Bitcoin mainnet, so this is not possible today.

Broadly speaking, there are a few different proposed approaches to enable this:

  1. Extend Script's flexibility: add one or more generic opcodes to the Bitcoin Script language to allow it to validate what are called SPV proofs or merkle proofs---the kind of data that SPV clients use today to determine if a transaction is part of a chain of block headers.

  2. Add a special SPV proof opcode: give Bitcoin Script the ability to directly validate SPV proofs. This would make the sidechain contracts simpler and cheaper, but to some engineers it feels a bit weird to add opcodes specialized for one purpose.

  3. Add a special reverse peg opcode (drivechain): give Bitcoin Script a special opcode that says, "I trust miners". Anyone who pays this opcode allows miners to spend those funds however they would like; then arrangements could be made with miners to only spend that money if they followed the sidechains rules.

At least one of the approaches above would need to be enabled for Rootstock to follow their plan; Rootstock's current preference is for #3, drivechains.

It's worth noting that if Rootstock wanted to use federated-pegged (fedpeg) sidechains, such as those implemented in the Elements Project, then no changes would be required to Bitcoin today. However, fedpeg sidechains rely on trusted signers for every block and so are not decentralized.

  • 1
    Fed peg is fine for smart contracts because you need to have trust in oracles or other federated groups for smart contracts anyway. I see no pressing need to remove this constraint. Commented Aug 16, 2017 at 17:19
  • "Add a special reverse peg opcode (drivechain): give Bitcoin Script a special opcode that says, I trust miners". That's not how Drivechain works at all. Drivechain is a consensus upgrade that adds a special type of output which is escrowed by hashrate over the course of dozens of thousands of blocks. Saying it's trust-miners kind of output is the most misleading thing possible. You don't need an opcode to trust miners.
    – fiatjaf
    Commented Sep 5, 2019 at 19:24
  • @fiatjaf Trusting miners over thousands of blocks is obviously a subset of trusting miners. Commented Sep 9, 2019 at 23:15
  • If you are going to say that then you must concede that Bitcoin is entirely based on trust in miners -- and there's no "I trust miners" opcode in Bitcoin.
    – fiatjaf
    Commented Sep 9, 2019 at 23:51
  • @fiatjaf Users have the choice of fully trusting miners (e.g. accepting reorgs of any length) or of enforcing rules that were not previously specified (e.g. using invalidateblock on a too-long reorg). That means security depends on what we expect users to do, and I expect that users in general will not choose to reorg a block chain where miners steal from drivechain users. If my guess is correct, that means a drivechain opcode is equivalent to trusting miners not to steal your funds. If you want to continue this argument, feel free to ping me in the B.SE chatroom. Commented Sep 10, 2019 at 5:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.