<blockquote>
  <p>she submits a SPV proof to S2.</p>
</blockquote>

<p>The way this worked in the first implementation of the sidechains paper by the same authors (called Elements Alpha, now <a href="https://github.com/ElementsProject/elements" rel="nofollow noreferrer">elements</a>) is as follows: The genesis block of the sidechain S2 creates a bunch of outputs with a new opcode <code>OP_WPV</code> that can be spent with an SPV proof showing that some amount on S1 has been "sent to a certain-locked output". Note that S2 follows the UTXO model of Bitcoin and there's no global state that <code>OP_WPV</code> could look up. That means that it's possible to provide exactly the same SPV proof to another <code>OP_WPV</code> locked output and effectively transfer your coins from S1 twice. That's why there needs to be a contest period where honest nodes have the opportunity to provide a fraud proof and lock the coins back into the <code>OP_WPV</code>.</p>

<p><a href="https://i.sstatic.net/8i50J.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/8i50J.png" alt="fraud proof"></a></p>

<p>Now if there needs to be a contest period anyway, we can make the confirmation period shorter than what we would assume to be secure against reorgs. Instead, the contest period is used to provide a window for reorganization proofs.</p>

<p>You can find more information about how this mechanism worked in this article: <a href="https://github.com/jonasnick/elementsproject.github.io/blob/master/source/_posts/The-Federated-Peg-in-Elements-Alpha.md" rel="nofollow noreferrer">https://github.com/jonasnick/elementsproject.github.io/blob/master/source/_posts/The-Federated-Peg-in-Elements-Alpha.md</a>.</p>

CC BY-SA 4.0
2020-03-26T13:01:32.420Z
2020-03-26T13:01:32.420Z
nickler
<p>According to the first sidechain article (<a href="http://kevinriggen.com/files/sidechains.pdf" rel="nofollow noreferrer">Link</a>), the cross chain transaction process can be briefly describe as follows:</p>

<ol>
<li><p>Alice has a wallet on sidechain S1. She wants to send some coins to sidechain S2. So she makes a transaction containing some coins, send it to a certain locked-output on S1. </p></li>
<li><p>Wait for confirmation period to end.</p></li>
<li><p>After the transaction is confirmed, she submits a SPV proof to S2.</p></li>
<li><p>Again, she has to wait for a contest period.</p></li>
<li><p>After the contest period ends, an equivalent amount of coins is created and sent to her wallet on S2.</p></li>
</ol>

<p>I assume that both the sidechains are secure, otherwise there is not much left to discuss. If they are secure,  then after the confirmation period in step 2 above, the sidechain S2 already knows that the transaction is confirmed on sidechain S1. For example, if Alice purchases something using Bitcoins, step 3 is where she can get the product she purchased from a normal store.</p>

<p>In my opinion, after the confirmation period, the transaction is already in a stable part of S1. Thus, there cannot be any valid SPV proof that contradicts the SPV proof Alice sent, unless S1 does not satisfy the persistence property.</p>

<p>Therfore, I would like to ask, why is the contest period necessary? Is there something I am missing in my argument? Thank you.</p>

<spv><sidechains><liquid>
Is the contest period really necessary for cross-chain transactions in 2-way-peg sidechains?
Cong
# Is the contest period really necessary for cross-chain transactions in 2-way-peg sidechains?

(Asked by: username_0 on 2020-03-24)

According to the first sidechain article ([Link](http://kevinriggen.com/files/sidechains.pdf)), the cross chain transaction process can be briefly describe as follows:

1. Alice has a wallet on sidechain S1. She wants to send some coins to sidechain S2. So she makes a transaction containing some coins, send it to a certain locked-output on S1.
2. Wait for confirmation period to end.
3. After the transaction is confirmed, she submits a SPV proof to S2.
4. Again, she has to wait for a contest period.
5. After the contest period ends, an equivalent amount of coins is created and sent to her wallet on S2.

I assume that both the sidechains are secure, otherwise there is not much left to discuss. If they are secure, then after the confirmation period in step 2 above, the sidechain S2 already knows that the transaction is confirmed on sidechain S1. For example, if Alice purchases something using Bitcoins, step 3 is where she can get the product she purchased from a normal store.

In my opinion, after the confirmation period, the transaction is already in a stable part of S1. Thus, there cannot be any valid SPV proof that contradicts the SPV proof Alice sent, unless S1 does not satisfy the persistence property.

Therfore, I would like to ask, why is the contest period necessary? Is there something I am missing in my argument? Thank you.

**Tags:** spv, sidechains, liquid


---

## 1 answers

### Answer by username_1 on 2020-03-26. Score: 1

> she submits a SPV proof to S2.

The way this worked in the first implementation of the sidechains paper by the same authors (called Elements Alpha, now [elements](https://github.com/ElementsProject/elements)) is as follows: The genesis block of the sidechain S2 creates a bunch of outputs with a new opcode `OP_WPV` that can be spent with an SPV proof showing that some amount on S1 has been "sent to a certain-locked output". Note that S2 follows the UTXO model of Bitcoin and there's no global state that `OP_WPV` could look up. That means that it's possible to provide exactly the same SPV proof to another `OP_WPV` locked output and effectively transfer your coins from S1 twice. That's why there needs to be a contest period where honest nodes have the opportunity to provide a fraud proof and lock the coins back into the `OP_WPV`.

[![fraud proof](https://i.sstatic.net/8i50J.png)](https://i.sstatic.net/8i50J.png)

Now if there needs to be a contest period anyway, we can make the confirmation period shorter than what we would assume to be secure against reorgs. Instead, the contest period is used to provide a window for reorganization proofs.

You can find more information about how this mechanism worked in this article: <https://github.com/jonasnick/elementsproject.github.io/blob/master/source/_posts/The-Federated-Peg-in-Elements-Alpha.md>.


---

