Challenge an Exit

Search…
Challenge an Exit
The process of challenging exits takes place during a defined 'challenge period' after an exit has started. The challenge period exists to provide time for other users to challenge dishonest exits.
Lifecycle
A challenge lifecycle includes the following:
1.
Standard exit or in-flight exit is initiated.
2.
The challenge period starts.
3.
If the exit is dishonest, the Watcher will report a byzantine event.
4.
Users on the network challenge and respond to reported byzantine events.
5.
The challenge period expires. Any exit that is unchallenged is finalized, while any exit that is successfully challenged is canceled. Bonds are rewarded to successful challengers or returned to users who committed them.
Watcher Alerts
The Watcher broadcasts any byzantine event it detects on the OMG Network. Users can decide whether or not to "challenge" said event based on the information provided.
These events are reported in the Watcher's /status.get endpoint providing an array of byzantine events. omg-js provides a helper function to get this report.
Challenging Standard Exits
The following is a byzantine event reported by the Watcher on invalid standard exits and requires action by users.
invalid_exit
Indicates that an invalid standard exit is occurring. It should be challenged.
Scenario
Alice sends UTXO1 to Bob. The associated transaction is included in a block.
Alice initiates a standard exit on UTXO1.
Event
Watcher reports an invalid_exit:
1
{
2
  "event": "invalid_exit",
3
  "details": {
4
    "amount": 12000000000000000000,
5
    "currency": "0x0000000000000000000000000000000000000000",
6
    "eth_height": 325,
7
    "name": "invalid_exit",
8
    "owner": "0xc29320f6a614edd1ffc8c7f8a7c8dd703761a68a",
9
    "root_chain_txhash": "0xee0d9e06dedf792d25c3d168fe1073c42039b49ddeffd76fc57e31201df8887b",
10
    "scheduled_finalization_time": 1588144725,
11
    "utxo_pos": 1000000000
12
  }
13
}
Copied!
Solution
Anyone can challenge Alice’s exit by proving that Alice has already spent the UTXO in another transaction.
If the challenge is successful, Alice does not exit the tokens and the challenger is awarded the exit bond that Alice put up when starting the exit.
Implementation
1. Install omg-js​
To access network features from your application, use our official libraries:
Requires Node >= 8.11.3 < 13.0.0
1
npm install @omisego/omg-js
Copied!
Add omg-js to a website using a script tag:
1
​
Copied!
Integrate omg-js with React Native projects. First, add this postinstall script to your project's package.json:
1
"scripts": {
2
    "postinstall": "omgjs-nodeify"
3
}
Copied!
Then install the react native compatible library:
1
npm install @omisego/react-native-omg-js
Copied!
2. Import dependencies
Challenging exits involves using 3 omg-js objects. Here's an example of how to instantiate them:
1
import Web3 from "web3";
2
import { ChildChain, RootChain, OmgUtil } from "@omisego/omg-js";const web3 = new Web3(new Web3.providers.HttpProvider(web3_provider_url));
3
const rootChain = new RootChain({ web3, plasmaContractAddress });
4
const childChain = new ChildChain({ watcherUrl });
Copied!
web3_provider_url - the URL to a full Ethereum RPC node (local or from infrastructure provider, e.g. Infura).
plasmaContractAddress - CONTRACT_ADDRESS_PLASMA_FRAMEWORK for defined environment.
watcherUrl - the Watcher Info URL for defined environment (personal or from OMG Network).
3. Challange invalid exit
We can use the byzantine event information reported by the Watcher to retrieve the data required to challenge the exit. We then can make a call to the Payment Exit Game contract calling challengeStandardExit().
In the example below, Bob has seen the reported invalid_exit event and proceeds to challenge the exit. He will receive Alice's posted bond if the challenge is successful.
1
async function challengeInvalidExit () {
2
  const challengeData = await childChain.getChallengeData(invalidExit.details.utxo_pos)
3
  return rootChain.challengeStandardExit({
4
    standardExitId: challengeData.exit_id,
5
    exitingTx: challengeData.exiting_tx,
6
    challengeTx: challengeData.txbytes,
7
    inputIndex: challengeData.input_index,
8
    challengeTxSig: challengeData.sig,
9
    txOptions: {
10
      from: "0xA9cc140410c2bfEB60A7260B3692dcF29665c254",
11
      privateKey: "0x1027c05dcc6dba6b8fb6bb6efc90e374fee7da73e1069279be61a2dcf533b856"
12
    }
13
  })
14
}
Copied!
Challenging In-Flight Exits
The following are byzantine events reported by the Watcher on invalid in-flight exits and require action by users.
noncanonical_ife
Indicates an in-flight exit of a non-canonical transaction has been started. It should be challenged.
Scenario
Alice creates a transaction TX1 to Bob, using UTXO1 as an input. TX1 is included in a block.
Alice then creates a non-canonical transaction TX2 to Carol with the same input UTXO1 (double spend). TX2 is not included in a block.
Alice initiates an in-flight exit on TX2.
Event
Watcher reports a noncanonical_ife:
1
{
2
  "event": "noncanonical_ife",
3
  "details": {
4
    "txbytes": "0xf3170101c0940000..."
5
  }
6
}
Copied!
Solution
Bob sees that Alice has initiated an in-flight exit on a non-canonical transaction.
Bob challenges Alice's in-flight exit by showing that UTXO1 was spent in TX1.
Alice is unable to exit UTXO1 and loses her exit bond to Bob.
Implementation
1
function challengeInFlightExitNonCanonical () {
2
  return rootChain.challengeInFlightExitNonCanonical({
3
    inputTx,
4
    inputUtxoPos,
5
    inFlightTx,
6
    inFlightTxInputIndex,
7
    competingTx,
8
    competingTxInputIndex,
9
    competingTxPos,
10
    competingTxInclusionProof,
11
    competingTxWitness,
12
    txOptions: {
13
      from: "0xA9cc140410c2bfEB60A7260B3692dcF29665c254",
14
      privateKey: "0x1027c05dcc6dba6b8fb6bb6efc90e374fee7da73e1069279be61a2dcf533b856"
15
    }
16
  })
17
}
Copied!
invalid_ife_challenge
Indicates a canonical in-flight exit has been challenged. The challenge should be responded to.
Scenario
Alice sends UTXO1 to Bob but Bob does not see the transaction TX1 get included in a block. He assumes the operator is withholding so he attempts to exit his output via an in-flight exit.
Bob starts his in-flight exit on TX1.
Alice sends a transaction TX2 to Carol using the same UTXO1 (double spend). This transaction is not included in a block.
TX1 is eventually included in a block.
Carol sees that Bob is trying to exit a transaction with the same input that Alice has sent her.
Carol uses TX2to challenge Bob's IFE as non-canonical.
Event
The Watcher reports an invalid_ife_challenge:
1
{
2
  "event": "invalid_ife_challenge",
3
  "details": {
4
    "txbytes": "0xf3170101c0940000..."
5
  }
6
}
Copied!
Solution
Bob uses TX1 (along with its inclusion proof) to prove that the challenge is invalid.
Implementation
1
async function respondToInvalidIFEChallenge () {
2
  const proof = await childChain.inFlightExitProveCanonical(invalidChallenge.details.txbytes)
3
  return rootChain.respondToNonCanonicalChallenge({
4
    inFlightTx: proof.in_flight_txbytes,
5
    inFlightTxPos: proof.in_flight_tx_pos,
6
    inFlightTxInclusionProof: proof.in_flight_proof,
7
    txOptions: {
8
      from: "0xA9cc140410c2bfEB60A7260B3692dcF29665c254",
9
      privateKey: "0x1027c05dcc6dba6b8fb6bb6efc90e374fee7da73e1069279be61a2dcf533b856"
10
    }
11
  })
12
}
Copied!
invalid_piggyback
Indicates an invalid piggyback is in process. Should be challenged.
Scenario
Alice sends UTXO1 to Bob in TX1. TX1 is included in a block.
Bob initiates an in-flight exit on TX1 and places an exit_bond.
Bob piggybacks onto the exit referencing UTXO1 and committing to a piggyback bond.
Bob sends UTXO1 to Carol in TX2. TX2 is included in a block.
Event
The Watcher reports an invalid_piggyback event:
1
{
2
  "event": "invalid_piggyback",
3
  "details": {
4
    "txbytes": "0xf3170101c0940000...",
5
    "inputs": [1],
6
    "outputs": [0]
7
  }
8
}
Copied!
Notes:
The Watcher does not report a noncanonical_ife event as TX1 is a canonical transaction included in a valid block.
The invalid_piggyback event can be reported only once TX2 has been detected by the Watcher, either as part of a valid block (as in the scenario above) or if referenced by another in-flight exit.
Solution
Carol uses TX2 to challenge Bob's piggyback.
Bob does not exit his output, Carol receives the piggyback bond committed by Bob.
Implementation
1
async function challengeInvalidPiggyback () {
2
  const challengeData = await childChain.inFlightExitGetOutputChallengeData(exitData.in_flight_tx, inputIndex)
3
  return rootChain.challengeInFlightExitOutputSpent({
4
    inFlightTx: challengeData.in_flight_txbytes,
5
    inFlightTxInclusionProof: challengeData.in_flight_proof,
6
    inFlightTxOutputPos: challengeData.in_flight_output_pos,
7
    challengingTx: challengeData.spending_txbytes,
8
    challengingTxInputIndex: challengeData.spending_input_index,
9
    challengingTxWitness: challengeData.spending_sig,
10
    txOptions: {
11
      from: "0xA9cc140410c2bfEB60A7260B3692dcF29665c254",
12
      privateKey: "0x1027c05dcc6dba6b8fb6bb6efc90e374fee7da73e1069279be61a2dcf533b856"
13
    }
14
  })
15
}
Copied!