Merge pull request #7218 from ethereum-optimism/aj/invalid-byte

op-challenger: Include note in docs that the root claim must start with 0x01

docs/fault-proof-alpha/manual.md

@@ -29,7 +29,8 @@ determine the root claim to use when creating the game. In simple cases, where t
 arbitrary hash can be used for claim values. For more advanced cases [cannon can be used](./cannon.md) to generate a
 trace, including the claim values to use at specific steps. Note that it is not valid to create a game that disputes an
 output root, using the final hash from a trace that confirms the output root is valid. To dispute an output root
-successfully, the trace must resolve that the disputed output root is invalid.
+successfully, the trace must resolve that the disputed output root is invalid. This is indicated by the first byte of
+the claim value being set to the invalid [VM status](../../specs/cannon-fault-proof-vm.md#state-hash) (`0x01`).
 
 The game can then be created by calling the `create` method on the `DisputeGameFactory` contract. This requires three
 parameters:

op-challenger/README.md

@@ -103,6 +103,10 @@ Starts a new fault dispute game that disputes the latest output proposal in the
 * `RPC_URL` - the RPC endpoint of the L1 endpoint to use (e.g. `http://localhost:8545`).
 * `GAME_FACTORY_ADDRESS` - the address of the dispute game factory contract on L1.
 * `ROOT_CLAIM` a hex encoded 32 byte hash to use as the root claim for the created game.
+    * The root claim must have the high-order byte set to the
+      invalid [VM status](../specs/cannon-fault-proof-vm.md#state-hash) (`0x01`) to indicate that the trace concludes
+      that the disputed output root is invalid.
+      e.g. `0x0146381068b59d2098495baa72ed2f773c1e09458610a7a208984859dff73add`
 * `SIGNER_ARGS` the remaining args are past as arguments to `cast` when sending transactions.
   These arguments must specify a way for `cast` to sign the transactions.
   See `cast send --help` for supported options.