<ol>
<li>No, Rootstock does not need segregated witness.</li>
<li>Yes, Rootstock does need another Bitcoin improvement not currently available on mainnet.</li>
</ol>

<p>Details below:</p>

<h2>Rootstock &amp; segregated witness</h2>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<h2>Rootstock &amp; other Bitcoin improvements</h2>

<p>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.</p>

<p>Broadly speaking, there are a few different proposed approaches to enable this:</p>

<ol>
<li><p><strong>Extend Script's flexibility:</strong> 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.</p></li>
<li><p><strong>Add a special SPV proof opcode:</strong> 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.</p></li>
<li><p><strong>Add a special reverse peg opcode (drivechain):</strong> 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.</p></li>
</ol>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-08-16T17:19:33.607Z
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.
Erik Aronesty
CC BY-SA 4.0
2019-09-05T19:24:27.127Z
"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
CC BY-SA 4.0
2019-09-09T23:15:35.830Z
@fiatjaf Trusting miners over thousands of blocks is obviously a subset of trusting miners.
David A. Harding
CC BY-SA 4.0
2019-09-09T23:51:53.630Z
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
CC BY-SA 4.0
2019-09-10T05:34:06.620Z
@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.
David A. Harding
CC BY-SA 3.0
2016-11-06T12:44:05.140Z
2016-11-06T12:44:05.140Z
David A. Harding
<p>Does Rootstock need segregated witness or any other bitcoin improvements not currently included for it to work?</p>

<blockchain><sidechains>
Does rootstock need segregated witness to work?
Mike White
# Does rootstock need segregated witness to work?

(Asked by: username_0 on 2016-11-06)

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

**Tags:** blockchain, sidechains


---

## 1 answers

### Answer by username_1 on 2016-11-06. Score: 6

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.

> **Comments:**
> **username_2**: 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.  
> **username_3**: "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.  
> **username_1**: @username_3 Trusting miners over thousands of blocks is obviously a subset of trusting miners.  
> **username_3**: 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.  
> **username_1**: @username_3 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.  

---

