matter-labs-forks · shamatar · Mar 8, 2021 · Sep 26, 2020 · Sep 27, 2020 · Sep 27, 2020
diff --git a/.travis.yml b/.travis.yml
@@ -30,7 +30,7 @@ matrix:
     - language: rust
       cache: cargo
       before_script:
-        - cargo install eipv --version=0.0.5
+        - cargo install eipv --version=0.1.1
       env: TASK='eip-validator'
     - python: 3.3
       env: TASK='codespell'

diff --git a/EIPS/eip-1.md b/EIPS/eip-1.md
diff --git a/EIPS/eip-1011.md b/EIPS/eip-1011.md
@@ -400,7 +400,7 @@ Normal block transactions cannot affect casper `vote` validation results, but ca
 The call to `initialize_epoch` at the beginning of each epoch requires 0 gas so that this protocol state transition does not take any gas allowance away from normal transactions.
 
 #### NULL_SENDER and Account Abstraction
-This EIP implements a limited version of account abstraction for validators' `vote` transactions. The general design was borrowed from [EIP 86](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-86.md). Rather than relying upon native transaction signatures, each validator specifies a signature contract when sending their `deposit` to `CASPER_ADDR`. When casting a `vote`, the validator bundles and signs the parameters of their `vote` according to the requirements of their signature contract. The `vote` method of the casper contract checks the signature of the parameters against the validator's signature contract, exiting the transaction as unsuccessful if the signature is not successfully verified.
+This EIP implements a limited version of account abstraction for validators' `vote` transactions. The general design was borrowed from [EIP-86](./eip-86.md). Rather than relying upon native transaction signatures, each validator specifies a signature contract when sending their `deposit` to `CASPER_ADDR`. When casting a `vote`, the validator bundles and signs the parameters of their `vote` according to the requirements of their signature contract. The `vote` method of the casper contract checks the signature of the parameters against the validator's signature contract, exiting the transaction as unsuccessful if the signature is not successfully verified.
 
 This allows validators to customize their own signing scheme for votes. Use cases include:
 * quantum-secure signature schemes

diff --git a/EIPS/eip-1013.md b/EIPS/eip-1013.md
@@ -22,11 +22,11 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Cons
   - `Block >= 9_200_000` on the Kovan testnet
   - `Block >= 3_660_663` on the Rinkeby testnet
 - Included EIPs:
-  - [EIP 145](https://eips.ethereum.org/EIPS/eip-145): Bitwise shifting instructions in EVM
-  - [EIP 1014](https://eips.ethereum.org/EIPS/eip-1014): Skinny CREATE2
-  - [EIP 1052](https://eips.ethereum.org/EIPS/eip-1052): EXTCODEHASH Opcode
-  - [EIP 1234](https://eips.ethereum.org/EIPS/eip-1234): Delay difficulty bomb, adjust block reward
-  - [EIP 1283](https://eips.ethereum.org/EIPS/eip-1283): Net gas metering for SSTORE without dirty maps
+  - [EIP-145](./eip-145.md): Bitwise shifting instructions in EVM
+  - [EIP-1014](./eip-1014.md): Skinny CREATE2
+  - [EIP-1052](./eip-1052.md): EXTCODEHASH Opcode
+  - [EIP-1234](./eip-1234.md): Delay difficulty bomb, adjust block reward
+  - [EIP-1283](./eip-1283.md): Net gas metering for SSTORE without dirty maps
 
 ## References
 

diff --git a/EIPS/eip-1014.md b/EIPS/eip-1014.md
@@ -42,13 +42,13 @@ Since address calculation depends on hashing the `init_code`, it would leave cli
 
 The `init_code` is the code that, when executed, produces the runtime bytecode that will be placed into the state, and which typically is used by high level languages to implement a 'constructor'.
 
-This EIP makes collisions possible. The behaviour at collisions is specified by [EIP 684](https://github.com/ethereum/EIPs/issues/684):
+This EIP makes collisions possible. The behaviour at collisions is specified by [EIP-684](https://github.com/ethereum/EIPs/issues/684):
 
 > If a contract creation is attempted, due to either a creation transaction or the `CREATE` (or future `CREATE2`) opcode, and the destination address already has either nonzero nonce, or nonempty code, then the creation throws immediately, with exactly the same behavior as would arise if the first byte in the init code were an invalid opcode. This applies retroactively starting from genesis.
 
 Specifically, if `nonce` or `code` is nonzero, then the create-operation fails. 
 
-With [EIP 161](https://eips.ethereum.org/EIPS/eip-161) 
+With [EIP-161](./eip-161.md) 
 
 > Account creation transactions and the `CREATE` operation SHALL, prior to the execution of the initialisation code, increment the nonce over and above its normal starting value by one
 

diff --git a/EIPS/eip-1015.md b/EIPS/eip-1015.md
@@ -24,20 +24,20 @@ Moving to PoS has been on the roadmap since day 0 for ethereum, along with a red
 
 #### Issuance Cap at 120 Million
 
-[EIP 960](https://github.com/ethereum/EIPs/issues/960), Vitalik's not so jokey april's fool has been taken seriously. It proposes the issuance to be slowly reduced until it reaches 120 million ether. One of the main counterpoints by Vlad can be simplified by [we don't know enough to know what that ether can be used for](https://medium.com/@Vlad_Zamfir/against-vitaliks-fixed-supply-eip-eip-960-18e182a7e5bd) and Vitalik's counterpoint is that [reducing emissions can be a way to reduce future abuse of these funds by finding a schelling point at 0](https://medium.com/@VitalikButerin/to-be-clear-im-not-necessarily-wedded-to-a-finite-supply-cap-a7aa48ab880c). Issuance has already been reduced once, from 5 ether to the current 3 ether per block. The main point of a hard cap is that a lot of people consider *not issuing* as having a positive contribution, that can outweigh other actions. Burning ether is also a valid issuance decision.
+[EIP-960](https://github.com/ethereum/EIPs/issues/960), Vitalik's not so jokey april's fool has been taken seriously. It proposes the issuance to be slowly reduced until it reaches 120 million ether. One of the main counterpoints by Vlad can be simplified by [we don't know enough to know what that ether can be used for](https://medium.com/@Vlad_Zamfir/against-vitaliks-fixed-supply-eip-eip-960-18e182a7e5bd) and Vitalik's counterpoint is that [reducing emissions can be a way to reduce future abuse of these funds by finding a schelling point at 0](https://medium.com/@VitalikButerin/to-be-clear-im-not-necessarily-wedded-to-a-finite-supply-cap-a7aa48ab880c). Issuance has already been reduced once, from 5 ether to the current 3 ether per block. The main point of a hard cap is that a lot of people consider *not issuing* as having a positive contribution, that can outweigh other actions. Burning ether is also a valid issuance decision.
 
 #### Asics and advantadges of PoW
 
-[EIP 960](https://eips.ethereum.org/EIPS/eip-969) proposes a change in algorithm to avoid mining being dominated by ASICS. Counter arguments by Phil Daian argue among others than [resisting economies of scale is futile and there might be specific security advantadges to specialized hardware](https://pdaian.com/blog/anti-asic-forks-considered-harmful/). One of the main arguments for PoW mining, even when it doesn't provide security, it is useful as a fair distribution mechanism, that **PoW allows any person with a computer, internet access and electricity to obtain currency without having to deal with government imposed currency controls**.
+[EIP-960](https://eips.ethereum.org/EIPS/eip-969) proposes a change in algorithm to avoid mining being dominated by ASICS. Counter arguments by Phil Daian argue among others than [resisting economies of scale is futile and there might be specific security advantadges to specialized hardware](https://pdaian.com/blog/anti-asic-forks-considered-harmful/). One of the main arguments for PoW mining, even when it doesn't provide security, it is useful as a fair distribution mechanism, that **PoW allows any person with a computer, internet access and electricity to obtain currency without having to deal with government imposed currency controls**.
 
 #### Recovery Forks
 
-After the Parity Multisig library self destruction, three different strategies have been attempted to recover the funds: [a general protocol improvement to allow reviving self destructed contracts](https://gist.github.com/5chdn/a9bb8617cc8523a030126a3d1c60baf3) (which was considered dangerous), a [general process to recover funds](https://github.com/ethereum/EIPs/pull/867) and a [specific recovery of the multisig library](https://eips.ethereum.org/EIPS/eip-999). The latter two are finding a lot of resistance from the community, but it's unlikely that these issues are going away soon. The affected parties have a large incentive (fluctuating at almost half a billion dollars) to keep trying, and it's an issue that is likely to occur again in the future. If they get reimbursed, [there are many other special cases of ether provably burnt or stuck](https://github.com/ethereum/EIPs/issues/156) that might deserve the same treatment. If they get shut down, they have an incentive to move forward a fork implementation: even if they are a minority chain, it's likely they'll recover an amount larger than 0, which is what they would otherwise, and it means the main ethereum community might lose a valuable team of developers. 
+After the Parity Multisig library self destruction, three different strategies have been attempted to recover the funds: [a general protocol improvement to allow reviving self destructed contracts](https://gist.github.com/5chdn/a9bb8617cc8523a030126a3d1c60baf3) (which was considered dangerous), a [general process to recover funds](https://github.com/ethereum/EIPs/pull/867) and a [specific recovery of the multisig library](./eip-999.md). The latter two are finding a lot of resistance from the community, but it's unlikely that these issues are going away soon. The affected parties have a large incentive (fluctuating at almost half a billion dollars) to keep trying, and it's an issue that is likely to occur again in the future. If they get reimbursed, [there are many other special cases of ether provably burnt or stuck](https://github.com/ethereum/EIPs/issues/156) that might deserve the same treatment. If they get shut down, they have an incentive to move forward a fork implementation: even if they are a minority chain, it's likely they'll recover an amount larger than 0, which is what they would otherwise, and it means the main ethereum community might lose a valuable team of developers. 
 
 
 #### Other Public Goods
 
-There are many other types of public goods that could be funded by issuance. By *Public Good*, I'm using a strict definition of something that brings value to everyone, both those who funded it and free-loaders, making it hard to fund it exclusively by traditional private incentives. They can be research, whole network security, [incentivize full clients and networking](https://eips.ethereum.org/EIPS/eip-908), fair distribution of tokens etc.
+There are many other types of public goods that could be funded by issuance. By *Public Good*, I'm using a strict definition of something that brings value to everyone, both those who funded it and free-loaders, making it hard to fund it exclusively by traditional private incentives. They can be research, whole network security, [incentivize full clients and networking](./eip-908.md), fair distribution of tokens etc.
 
 ## Proposed Solution
 ### Issuance Contract

diff --git a/EIPS/eip-1052.md b/EIPS/eip-1052.md
@@ -25,7 +25,7 @@ takes one argument from the stack, zeros the first 96 bits
 and pushes to the stack the keccak256 hash of the code of the account 
 at the address being the remaining 160 bits. 
 
-In case the account does not exist or is empty (as defined by [EIP-161](https://eips.ethereum.org/EIPS/eip-161)) `0` is pushed to the stack.
+In case the account does not exist or is empty (as defined by [EIP-161](./eip-161.md)) `0` is pushed to the stack.
 
 In case the account does not have code the keccak256 hash of empty data
 (i.e. `c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470`)

diff --git a/EIPS/eip-1056.md b/EIPS/eip-1056.md
@@ -19,7 +19,7 @@ This ERC describes a standard for creating and updating identities with a limite
 
 ## Motivation
 
-As we have been developing identity systems for the last couple of years at uPort it has become apparent that the cost of identity creation is a large issue. The previous Identity proposal [ERC725](https://eips.ethereum.org/EIPS/eip-725) faces this exact issue. Our requirements when creating this ERC is that identity creation should be free, and should be possible to do in an offline environment (e.g. refugee scenario). However it must also be possible to rotate keys without changing the primary identifier of the identity. The identity system should be fit to use off-chain as well as on-chain.
+As we have been developing identity systems for the last couple of years at uPort it has become apparent that the cost of identity creation is a large issue. The previous Identity proposal [ERC-725](./eip-725.md) faces this exact issue. Our requirements when creating this ERC is that identity creation should be free, and should be possible to do in an offline environment (e.g. refugee scenario). However it must also be possible to rotate keys without changing the primary identifier of the identity. The identity system should be fit to use off-chain as well as on-chain.
 
 ## Definitions
 

diff --git a/EIPS/eip-1057.md b/EIPS/eip-1057.md
@@ -3,7 +3,7 @@ eip: 1057
 title: ProgPoW, a Programmatic Proof-of-Work
 author: Greg Colvin <greg@colvin.org>, Andrea Lanfranchi (@AndreaLanfranchi), Michael Carter (@bitsbetrippin), IfDefElse <ifdefelse@protonmail.com>
 discussions-to: https://ethereum-magicians.org/t/eip-progpow-a-programmatic-proof-of-work/272
-status: Accepted
+status: Review
 type: Standards Track
 category: Core
 created: 2018-05-02

diff --git a/EIPS/eip-1066.md b/EIPS/eip-1066.md
@@ -33,7 +33,7 @@ Status codes convey a much richer set of information [than Booleans](https://exi
 
 _End users get little to no feedback, and there is no translation layer._
 
-Since ERC1066 status codes are finite and known in advance, we can leverage [ERC1444](https://eips.ethereum.org/EIPS/eip-1444) to provide global, human-readable sets of status messages. These may also be translated into any language, differing levels of technical detail, added as `revert` messages, natspecs, and so on.
+Since ERC1066 status codes are finite and known in advance, we can leverage [ERC-1444](./eip-1444.md) to provide global, human-readable sets of status messages. These may also be translated into any language, differing levels of technical detail, added as `revert` messages, natspecs, and so on.
 
 Status codes convey a much richer set of information than Booleans, and are able to be reacted to autonomously unlike arbitrary strings.
 
@@ -45,7 +45,7 @@ At time of writing, other than stepping through EVM execution and inspecting mem
 
 Having a fixed set of codes also makes it possible to write common helper functions to react in common ways to certain signals. This can live off- or on-chain library, lowering the overhead in building smart contracts, and helping raise code quality with trusted shared components.
 
-We also see a desire for this [in transactions](https://eips.ethereum.org/EIPS/eip-658), and there's no reason that these status codes couldn't be used by the EVM itself.
+We also see a desire for this [in transactions](./eip-658.md), and there's no reason that these status codes couldn't be used by the EVM itself.
 
 ### Smart Contract Autonomy
 
@@ -506,7 +506,7 @@ While this repository includes helper enums, we have found working directly in t
 
 #### Localizations
 
-One commonly requested application of this spec is human-readable translations of codes. This has been moved to its own proposal: [ERC-1444](https://github.com/ethereum/EIPs/pull/1444/), primarily due to a desire to keep both specs focused.
+One commonly requested application of this spec is human-readable translations of codes. This has been moved to its own proposal: [ERC-1444](./eip-1444.md), primarily due to a desire to keep both specs focused.
 
 ### Extensibility
 

diff --git a/EIPS/eip-1077.md b/EIPS/eip-1077.md
@@ -197,7 +197,7 @@ Other version is implemented as Gnosis Safe variant in: https://github.com/statu
 
 The idea of using signed messages as executable intent has been around for a while and many other projects are taking similar approaches, which makes it a great candidate for a standard that guarantees interoperability:
 
-* [EIP 877](https://github.com/ethereum/EIPs/pull/877) An attempt of doing the same but with a change in the protocol
+* [EIP-877](https://github.com/ethereum/EIPs/pull/877) An attempt of doing the same but with a change in the protocol
 * [Status](https://github.com/status-im/ideas/issues/73)
 * [Aragon](https://github.com/aragonlabs/pay-protocol) (this might not be the best link to show their work in this area)
 * [Token Standard Functions for Preauthorized Actions](https://github.com/ethereum/EIPs/issues/662)
@@ -223,7 +223,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 
 * [Universal Logins talk at UX Unconf, Toronto](https://www.youtube.com/watch?v=qF2lhJzngto)
 
-[EIP-20]: https://eips.ethereum.org/EIPS/eip-20
-[EIP-191]: https://eips.ethereum.org/EIPS/eip-191
-[EIP-1271]: https://eips.ethereum.org/EIPS/eip-1271
-[EIP-1344]: https://eips.ethereum.org/EIPS/eip-1344
+[EIP-20]: ./eip-20.md
+[EIP-191]: ./eip-191.md
+[EIP-1271]: ./eip-1271.md
+[EIP-1344]: ./eip-1344.md
diff --git a/EIPS/eip-1078.md b/EIPS/eip-1078.md
@@ -64,7 +64,7 @@ Once the desired level is known, the app must take these steps:
 3. **Generate the bytecode** for a transaction calling the function `addKey(PUBLICKEY,LEVEL)`.
 4. **Broadcast a transaction request on a whisper channel** or some other decentralized network of peers. Details on this step require further discussions
 1. **If web3 is available** then attempt calling web3.eth.sendTransaction. This can be automatic or prompted by user action.
-1. **Attempt calling a URI** if the app supports [URL format for transaction requests EIP](https://eips.ethereum.org/EIPS/eip-681) then attempt calling this. This can be automatic or prompted by user action.
+1. **Attempt calling a URI** if the app supports [URL format for transaction requests EIP](./eip-681.md) then attempt calling this. This can be automatic or prompted by user action.
 1. **Show a QR code**: with an EIP681 formatted URL. That QR code can be clickable to attempt to retry the other options, but it should be done last: if step 1 works, the user should receive a notification on their compatible device and won't need to use the QR code.
 
 Here's an example of a EIP681 compatible address to add a public key generated locally in the app:

diff --git a/EIPS/eip-1102.md b/EIPS/eip-1102.md
@@ -1,7 +1,7 @@
 ---
 eip: 1102
 title: Opt-in account exposure
-author: Paul Bouchon <mail@bitpshr.net>, Erik Marks <rekmarks@protonmail.com>
+author: Paul Bouchon <mail@bitpshr.net>, Erik Marks (@rekmarks)
 discussions-to: https://ethereum-magicians.org/t/eip-1102-opt-in-provider-access/414
 status: Draft
 type: Standards Track