Fixed most broken links

packages/docs/src/spec/index.rst

@@ -49,6 +49,7 @@ This website documents the entirety of the Plasma Group design, from the inner w
    src/03-client/synchronization
    src/03-client/query-expressions
    src/03-client/rpc-methods
+   src/03-client/rpc-error-messages
 
 .. toctree::
    :maxdepth: 1
@@ -63,11 +64,12 @@ This website documents the entirety of the Plasma Group design, from the inner w
    src/04-client-architecture/wallet
    src/04-client-architecture/predicate-plugin
    src/04-client-architecture/plugin-manager
+   src/04-client-architecture/history-proof-structure
    src/04-client-architecture/history-db
    src/04-client-architecture/history-manager
    src/04-client-architecture/state-db
    src/04-client-architecture/state-manager
-   src/04-client-architecutre/sync-db
+   src/04-client-architecture/sync-db
    src/04-client-architecture/sync-manager
    src/04-client-architecture/rpc-client
    src/04-client-architecture/rpc-server
@@ -95,9 +97,10 @@ This website documents the entirety of the Plasma Group design, from the inner w
    :maxdepth: 1
    :caption: #07: Predicate Specifications
 
-   src/07-predicates/ownership-predicate
+   src/07-predicates/simple-ownership
 
 
+.. References
+
 .. _`Plasma Group`: https://plasma.group
 .. _`generalized plasma`: https://medium.com/plasma-group/plapps-and-predicates-understanding-the-generalized-plasma-architecture-fc171b25741
-

packages/docs/src/spec/src/00-introduction/contributors.rst

@@ -1,3 +1,6 @@
 ############
 Contributors
 ############
+
+
+.. References

packages/docs/src/spec/src/00-introduction/glossary.rst

@@ -94,3 +94,6 @@ Asset Tree
 
 State Tree
 ==========
+
+
+.. References

packages/docs/src/spec/src/00-introduction/introduction.rst

@@ -42,7 +42,7 @@ Users need to run client software in order to interact with the plasma chain. We
 
 #04: Operator
 =============
-Plasma chains typically have an `operator`_ who aggregates transactions into a single block. Our operator design is an extension of the client design. We specify the functions that an operator must provide on top of the base client and the actual components that enable those functions.
+Plasma chains typically have an operator who aggregates transactions into a single block. Our operator design is an extension of the client design. We specify the functions that an operator must provide on top of the base client and the actual components that enable those functions.
 
 ************
 Housekeeping
@@ -61,17 +61,18 @@ Most pages within this specification will continue to evolve as we develop `our
 Our semantic versioning strategy is pretty simple. Changes to this specification that would make an implementation incompatible with implementations of previous versions are split into different `major versions`_. Changes that simply add functionality but don't break backwards compatibility bump the `minor version`_. Finally, fixes that don't add or remove functionality (layout edits, grammatical fixes, typo fixes) bump the `patch version`_.
 
 
-.. _`Lightning BOLT specifications`: https://github.com/lightningnetwork/lightning-rfc
-.. _`Plasma Group monorepo`: https://github.com/plasma-group/pigi/tree/master/packages/docs/src/spec
-.. _`our implementation`: https://github.com/plasma-group/pigi/tree/master/packages/core
-.. _`issue on GitHub`: https://github.com/plasma-group/pigi/issues
-.. _`pull request`: https://github.com/plasma-group/pigi/pulls
+.. References
+
 .. _`#00: Introduction`: ./introduction.html
 .. _`#01: Core Components`: ../01-core/state-system.html
 .. _`#02: Contracts`: ../02-contracts/deposit-contract.html
 .. _`#03: Client`: ../03-client/introduction.html
 .. _`#04: Operator`: ../04-client/introduction.html
-.. _`operator`: TODO
+.. _`Lightning BOLT specifications`: https://github.com/lightningnetwork/lightning-rfc
+.. _`Plasma Group monorepo`: https://github.com/plasma-group/pigi/tree/master/packages/docs/src/spec
+.. _`our implementation`: https://github.com/plasma-group/pigi/tree/master/packages/core
+.. _`issue on GitHub`: https://github.com/plasma-group/pigi/issues
+.. _`pull request`: https://github.com/plasma-group/pigi/pulls
 .. _`semantic versioning`: https://semver.org/
 .. _`minor version`: https://semver.org/#spec-item-7
 .. _`patch version`: https://semver.org/#spec-item-6

packages/docs/src/spec/src/01-core/double-layer-tree.rst

@@ -43,14 +43,16 @@ We've provided a diagram of the double-layer Merkle Interval Tree below. The dia
    <img src="../../_static/images/double-layer-tree/double-layer-tree.svg" alt="Double-Layer Merkle Interval Tree">
 
 
-.. _`Plasma Cashflow`: TODO
-.. _`ranges`: TODO
-.. _`state objects`: TODO
-.. _`Plasma Cash`: TODO
+.. References
+
+.. _`ranges`: ./state-object-ranges.html
+.. _`state objects`: ./state-system.html#state-objects
+.. _`ID of a state object`: ./state-system.html#state-objects
+.. _`Merkle Interval Tree`: ./merkle-interval-tree.html
+.. _`deposit contract`: ../02-contracts/deposit-contract.html
+.. _`Plasma Cashflow`: https://hackmd.io/DgzmJIRjSzCYvl4lUjZXNQ?view#
+.. _`Plasma Cash`: https://www.learnplasma.org/en/learn/cash.html
+.. _`WETH`: https://weth.io/
 .. _`defragmenting`: TODO
 .. _`outside of this page`: TODO
-.. _`ID of a state object`: TODO
-.. _`WETH`: TODO
-.. _`deposit contract`: TODO
 .. _`block root`: TODO
-.. _`Merkle Interval Tree`: TODO

packages/docs/src/spec/src/01-core/json-rpc.rst

@@ -124,8 +124,10 @@ Description
 Either a success response or an error response.
 
 
+.. References
+
+.. _`RPC methods`: ../03-client/rpc-methods.html
 .. _`JSON RPC`: https://www.jsonrpc.org/specification
-.. _`RPC methods`: TODO
 .. _`TypeScript`: https://www.typescriptlang.org/
 .. _`Ethereum also uses JSON RPC`: https://github.com/ethereum/wiki/wiki/JSON-RPC
 .. _`JSON RPC request`: https://www.jsonrpc.org/specification#request_object

packages/docs/src/spec/src/01-core/merkle-interval-tree.rst

@@ -131,7 +131,7 @@ Our tree generation process allows us to create an efficient **proof** that for
 
 Proof Generation
 ================
-Proofs can be generated after the full Merkle tree has been generated as per thealgorithm `described above`_. Proofs consist of a list of `internal nodes`_ within the Merkle tree.
+Proofs can be generated after the full Merkle tree has been generated as per the algorithm `described above`_. Proofs consist of a list of `internal nodes`_ within the Merkle tree.
 
 The proof for a given leaf node is computed as follows:
 
@@ -206,11 +206,13 @@ A diagram of the Merkle Interval Tree is provided below. We've highlighted the n
    <img src="../../_static/images/merkle-interval-tree/merkle-interval-tree.svg" alt="Merkle Interval Tree">
 
 
-.. _`internal nodes`: TODO
-.. _`described above`: TODO
-.. _`hash function`: TODO
-.. _`leaf nodes`: TODO
-.. _`binary tree`: TODO
-.. _`Plasma Cash`: TODO
-.. _`ranges of state objects`: TODO
-.. _`Plasma Cashflow`: TODO
+.. References
+
+.. _`described above`: #tree-generation
+.. _`ranges of state objects`: ./state-object-ranges.html
+.. _`internal nodes`: https://en.wikipedia.org/wiki/Tree_(data_structure)#external_node_(not_common)
+.. _`hash function`: https://en.wikipedia.org/wiki/Hash_function
+.. _`leaf nodes`: https://en.wikipedia.org/wiki/Tree_(data_structure)#leaf
+.. _`binary tree`: https://en.wikipedia.org/wiki/Binary_tree
+.. _`Plasma Cash`: https://www.learnplasma.org/en/learn/cash.html
+.. _`Plasma Cashflow`: https://hackmd.io/DgzmJIRjSzCYvl4lUjZXNQ?view#

packages/docs/src/spec/src/01-core/state-object-ranges.rst

@@ -32,7 +32,7 @@ Transactions
 ************
 The `transaction format`_ described in our `generalized state system`_ specifies that a transaction **MUST** provide a reference to the `state object`, or set of state objects, from which it spends. Conveniently, this allows us to create transactions over **ranges** of state objects.
 
-The specification for a transaction over a range is very simple. Remember that each ``objectId`` in our system is a `unique 32 byte identifier`_. We therefore require that the ``objectIds`` field be a 64 byte value. The first 32 bytes of this value represents the start of the transacted range and the last 32 bytes represents the end of the transacted range. Transactions over ranges are, in effect, transactions on each individual state object where ``object.id`` falls within the specified range.
+The specification for a transaction over a range is very simple. Remember that each ``objectId`` in our system is a unique 32 byte identifier. We therefore require that the ``objectIds`` field be a 64 byte value. The first 32 bytes of this value represents the start of the transacted range and the last 32 bytes represents the end of the transacted range. Transactions over ranges are, in effect, transactions on each individual state object where ``object.id`` falls within the specified range.
 
 Rationale
 =========
@@ -45,10 +45,12 @@ Requirements
    - **MUST** begin with a 32 byte value that represents that start of the transacted range.
    - **MUST** end with a 32 byte value that represents the end of the transacted range.
 
-.. _`deposited`: TODO
-.. _`Plasma Cash`: TODO
-.. _`generalized state system`: TODO
-.. _`transaction format`: TODO
-.. _`unique 32 byte identifier`: TODO
-.. _`Plasma Cashflow`: TODO
-.. _`background`: TODO
+
+.. References
+
+.. _`deposited`: ../03-client/deposit-generation.html
+.. _`Plasma Cash`: https://www.learnplasma.org/en/learn/cash.html
+.. _`generalized state system`: ./state-system.html
+.. _`transaction format`: ./state-system.html#transactions
+.. _`Plasma Cashflow`: https://hackmd.io/DgzmJIRjSzCYvl4lUjZXNQ?view#
+.. _`background`: #background

packages/docs/src/spec/src/01-core/state-system.rst

@@ -242,6 +242,8 @@ Requirements
 Transactions
 ************
 
+.. _`Transaction`:
+
 Transaction Model
 =================
 Mutations to state objects are carried out by **transactions**. Transactions specify:
@@ -336,6 +338,8 @@ State Updates
 
    Explain state updates at a high level.
 
+.. _`StateUpdate`:
+
 State Update Model
 ==================
 
@@ -378,23 +382,25 @@ Test Vectors
 
    Add test vectors for computing state update hash.
 
-.. _`computed`: TODO
+
+.. References
+
+.. _`computed`: #method-identifiers
+.. _`predicate`: #predicates
+.. _`predicate contract`: ../02-contracts/predicate-contract.html
+.. _`SimpleOwnership`: ../07-predicates/simple-ownership.html
 .. _`RLP encoded`: https://github.com/ethereum/wiki/wiki/RLP
-.. _`predicate contract`: TODO
 .. _`abi encoding`: https://solidity.readthedocs.io/en/v0.5.8/abi-spec.html
 .. _`rlp encoding`: https://github.com/ethereum/wiki/wiki/RLP
 .. _`rlp decoded`: https://github.com/ethereum/wiki/wiki/RLP#rlp-decoding
 .. _`Solidity`: https://solidity.readthedocs.io/en/v0.5.8/
 .. _`native support for ABI decoding`: https://solidity.readthedocs.io/en/v0.5.8/units-and-global-variables.html?highlight=abi.encode#abi-encoding-and-decoding-functions
 .. _`native support for RLP decoding`: https://vyper.readthedocs.io/en/v0.1.0-beta.8/built-in-functions.html#rlplist
 .. _`audited RLP decoding libraries`: https://github.com/hamdiallam/Solidity-RLP
-.. _`Predicate API`: TODO
-.. _`primitive types in Solidity`: TODO
-.. _`keccak256`: TODO
-.. _`SimpleOwnership`: TODO
-.. _`Ethereum contract ABI`: TODO
-.. _`Ethereum ABI JSON format`: TODO
-.. _`ABI encoded and decoded`: TODO
-.. _`Vyper`: TODO
-.. _`native support for ABI encoding and decoding`: TODO
-.. _`predicate`: TODO
+.. _`primitive types in Solidity`: https://solidity.readthedocs.io/en/latest/types.html
+.. _`keccak256`: https://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use
+.. _`Ethereum contract ABI`: 
+.. _`Ethereum ABI JSON format`: https://solidity.readthedocs.io/en/latest/abi-spec.html
+.. _`ABI encoded and decoded`: https://solidity.readthedocs.io/en/latest/abi-spec.html
+.. _`Vyper`: https://github.com/ethereum/vyper
+.. _`native support for ABI encoding and decoding`: https://solidity.readthedocs.io/en/latest/units-and-global-variables.html#abi-encoding-and-decoding-functions

packages/docs/src/spec/src/02-contracts/commitment-contract.rst

@@ -5,7 +5,7 @@ Commitment Contract
 ***********
 Description
 ***********
-Each plasma chain **MUST** have at least one **commitment contract**. Commitment contracts hold the block headers for the plasma chain. Whenever the `operator`_ creates a new plasma block, they **MUST** publish this block to the commitment contract.
+Each plasma chain **MUST** have at least one **commitment contract**. Commitment contracts hold the block headers for the plasma chain. Whenever the operator creates a new plasma block, they **MUST** publish this block to the commitment contract.
 
 
 -------------------------------------------------------------------------------
@@ -106,9 +106,9 @@ Rationale
 ^^^^^^^^^
 It's obviously necessary to expose some functionality that allows a user to submit a block header. However, the rationale around authentication logic is more interesting here. 
 
-Authentication in our original construction was handled by checking that `msg.sender`_ was the operator. This works well in a single-operator construction, but it doesn't work if we wanted some more complex system. In order to solve this problem, we initinally wanted to add a ``witness: bytes`` parameter to the method which could then be used to authenticate the submitted header. Fortunately, we stumbled on an even better solution.
+Authentication in our original construction was handled by checking that msg.sender was the operator. This works well in a single-operator construction, but it doesn't work if we wanted some more complex system. In order to solve this problem, we initinally wanted to add a ``witness: bytes`` parameter to the method which could then be used to authenticate the submitted header. Fortunately, we stumbled on an even better solution.
 
-Conveniently, if a contract calls another contract, then `msg.sender`_ within that second contract will be the address of the first contract. We can therefore outsource verification of a given block to some external contract and simply check that ``msg.sender`` is that contract.
+Conveniently, if a contract calls another contract, then msg.sender within that second contract will be the address of the first contract. We can therefore outsource verification of a given block to some external contract and simply check that ``msg.sender`` is that contract.
 
 Requirements
 ^^^^^^^^^^^^
@@ -118,5 +118,4 @@ Requirements
 - **MUST** emit a ``BlockSubmitted`` event.
 
 
-.. _`msg.sender`: TODO
-.. _`operator`: TODO
+.. References

packages/docs/src/spec/src/02-contracts/deposit-contract.rst

@@ -687,21 +687,22 @@ Rationale
 Exit finalization is the step which actually allows the assets locked in plasma to be used on the main chain again.  Finalization requires that the exit and checkpoint games have completed successfully.
 
 
-.. _`state objects`: TODO
-.. _`state object`: TODO
-.. _`predicate contract`: TODO
-.. _`state update`: TODO
-.. _`checkpoint`: TODO
+.. References
+
+.. _`state object`:
+.. _`state objects`: ../01-core/state-system.html#state-objects
+.. _`state update`: ../01-core/state-system.html#state-updates
+.. _`inclusion proofs`: ../01-core/merkle-interval-tree.html#merkle-proofs
+.. _`predicate contract`: ./predicate-contract.html
+.. _`commitment contract`: ./commitment-contract.html
+.. _`ERC-20 token`: https://en.wikipedia.org/wiki/ERC-20
 .. _`withholds data`: TODO
 .. _`deprecated`: TODO
 .. _`partially spent`:
 .. _`state update may be partially spent`: TODO
-.. _`commitment contract`: TODO
-.. _`inclusion proofs`: TODO
-.. _`ERC-20 token`: TODO
 .. _`defragmentation`: TODO
 .. _`ID of a checkpoint`:
-.. _`ID of the checkpoint`:
+.. _`ID of the checkpoint`: TODO
 .. _`ID of an exit`:
 .. _`ID of the exit`: TODO
 .. _`ID of a challenge`:

packages/docs/src/spec/src/02-contracts/limbo-exit-predicate.rst

@@ -432,3 +432,6 @@ Requirements
 Justification
 ^^^^^^^^^^^^^
 The target of a limbo exit must be able to handle the money arbitrarily, this logic is called by the source predicate on the target to perform that logic.
+
+
+.. References

packages/docs/src/spec/src/02-contracts/predicate-contract.rst

@@ -30,3 +30,6 @@ If the predicate contract has custom/stateful exit logic, it may not know who to
 -------------------------------------------------------------------------------
 
 These are the only real requirements for a predicate contract to be compatible with the deposit contract spec.  However,  it lacks a useful abstraction usually made by blockchains and plasma implementations: the notion of transactions and state transitions.  In the next section, we define a standard predicate baase which is used throughout the rest of the spec, that treats deprecations, exits, etc. in terms of transactions and state transitions.
+
+
+.. References

packages/docs/src/spec/src/02-contracts/transaction-based-predicate.rst

@@ -74,3 +74,6 @@ Requirements
 - **MUST** check that the transaction is valid with a call to ``verifyTransaction(_deprecatedExit.stateUpdate, _transaction, _witness, _postState``.
 - **MUST** check that the ``_postState.range`` intersects the ``_deprecatedExit.subrange``
 - **MUST** call ``deprecateExit(_deprecatedExit)`` on the ``_deprecatedExit.stateUpdate.state.predicateAddress``.
+
+
+.. References

packages/docs/src/spec/src/03-client/deposit-generation.rst

@@ -22,10 +22,13 @@ Where ``StateObject`` is the following struct:
 
 ``deposit`` requires that users specify the ``_amount`` the asset being deposited and an **initial state object**, ``_state``, that controls ownership of the asset. For example, users might use the `SimpleOwnership`_ predicate to control their asset.
 
-.. _`plasma deposit contract`: TODO
-.. _`plasma chain transactions`: TODO
-.. _`range`: TODO
-.. _`state object`: TODO
-.. _`predicate contract`: TODO
-.. _`SimpleOwnership`: TODO
+
+.. References
+
+.. _`plasma chain transactions`: ../01-core/state-system.html#transactions
+.. _`range`: ../01-core/state-object-ranges.html
+.. _`state object`: ../01-core/state-system.html#state-objects
+.. _`predicate contract`: ../02-contracts/predicate-contract.html
+.. _`plasma deposit contract`: ../02-contracts/deposit-contract.html
+.. _`SimpleOwnership`: ../07-predicates/simple-ownership.html
 .. _`ABI encoded`: https://solidity.readthedocs.io/en/v0.5.8/abi-spec.html

packages/docs/src/spec/src/03-client/event-handling.rst

@@ -15,3 +15,6 @@ Exit Game Events
 .. todo::
 
    Explain how to handle exit game events.
+
+
+.. References

packages/docs/src/spec/src/03-client/exit-guarding.rst

@@ -33,3 +33,6 @@ Challenge Submission
 .. todo::
 
    Explain how predicate plugins actually send the challenge to Ethereum.
+
+
+.. References