Merge branch 'master' into ulerdogan/add-eip

EIPS/eip-1.md

@@ -213,7 +213,7 @@ Which renders to:
 Permitted Execution Client Specifications URLs must anchor to a specific commit, and so must match this regular expression:
 
 ```regex
-^(https://github.com/ethereum/execution-specs/blob/[0-9a-f]{40}/.*|https://github.com/ethereum/execution-specs/tree/[0-9a-f]{40}/.*)$
+^(https://github.com/ethereum/execution-specs/(blob|commit)/[0-9a-f]{40}/.*|https://github.com/ethereum/execution-specs/tree/[0-9a-f]{40}/.*)$
 ```
 
 ### Consensus Layer Specifications
@@ -231,7 +231,7 @@ Which renders to:
 Permitted Consensus Layer Specifications URLs must anchor to a specific commit, and so must match this regular expression:
 
 ```regex
-^https://github.com/ethereum/consensus-specs/blob/[0-9a-f]{40}/.*$
+^https://github.com/ethereum/consensus-specs/(blob|commit)/[0-9a-f]{40}/.*$
 ```
 
 ### Networking Specifications
@@ -249,7 +249,81 @@ Which renders as:
 Permitted Networking Specifications URLs must anchor to a specific commit, and so must match this regular expression:
 
 ```regex
-^https://github.com/ethereum/devp2p/blob/[0-9a-f]{40}/.*$
+^https://github.com/ethereum/devp2p/(blob|commit)/[0-9a-f]{40}/.*$
+```
+
+### World Wide Web Consortium (W3C)
+
+Links to a W3C "Recommendation" status specification may be included using normal markdown syntax. For example, the following link would be allowed:
+
+```markdown
+[Secure Contexts](https://www.w3.org/TR/2021/CRD-secure-contexts-20210918/)
+```
+
+Which renders as:
+
+[Secure Contexts](https://www.w3.org/TR/2021/CRD-secure-contexts-20210918/)
+
+Permitted W3C recommendation URLs MUST anchor to a specification in the technical reports namespace with a date, and so MUST match this regular expression:
+
+```regex
+^https://www\.w3\.org/TR/[0-9][0-9][0-9][0-9]/.*$
+```
+
+### Web Hypertext Application Technology Working Group (WHATWG)
+
+Links to WHATWG specifications may be included using normal markdown syntax, such as:
+
+```markdown
+[HTML](https://html.spec.whatwg.org/commit-snapshots/578def68a9735a1e36610a6789245ddfc13d24e0/)
+```
+
+Which renders as:
+
+[HTML](https://html.spec.whatwg.org/commit-snapshots/578def68a9735a1e36610a6789245ddfc13d24e0/)
+
+Permitted WHATWG specification URLs must anchor to a specification defined in the `spec` subdomain (idea specifications are not allowed) and to a commit snapshot, and so must match this regular expression:
+
+```regex
+^https:\/\/[a-z]*\.spec\.whatwg\.org/commit-snapshots/[0-9a-f]{40}/$
+```
+
+Although not recommended by WHATWG, EIPs must anchor to a particular commit so that future readers can refer to the exact version of the living standard that existed at the time the EIP was finalized. This gives readers sufficient information to maintain compatibility, if they so choose, with the version referenced by the EIP and the current living standard.
+
+### Internet Engineering Task Force (IETF)
+
+Links to an IETF Request For Comment (RFC) specification may be included using normal markdown syntax, such as:
+
+```markdown
+[RFC 8446](https://www.rfc-editor.org/rfc/rfc8446)
+```
+
+Which renders as:
+
+[RFC 8446](https://www.rfc-editor.org/rfc/rfc8446)
+
+Permitted IETF specification URLs MUST anchor to a specification with an assigned RFC number (meaning cannot reference internet drafts), and so MUST match this regular expression:
+
+```regex
+^https:\/\/www.rfc-editor.org\/rfc\/.*$
+```
+
+### Bitcoin Improvement Proposal
+
+Links to Bitcoin Improvement Proposals may be included using normal markdown syntax, such as:
+
+```markdown
+[BIP 38](https://github.com/bitcoin/bips/blob/3db736243cd01389a4dfd98738204df1856dc5b9/bip-0038.mediawiki)
+```
+
+Which renders to:
+
+[BIP 38](https://github.com/bitcoin/bips/blob/3db736243cd01389a4dfd98738204df1856dc5b9/bip-0038.mediawiki)
+
+Permitted Bitcoin Improvement Proposal URLs must anchor to a specific commit, and so must match this regular expression:
+
+```regex
+^(https://github.com/bitcoin/bips/blob/[0-9a-f]{40}/bip-[0-9]+\.mediawiki)$
 ```
 
 ### Digital Object Identifier System

EIPS/eip-1153.md

@@ -17,8 +17,8 @@ requires: 2200, 3529
 This proposal introduces transient storage opcodes, which manipulate state that behaves identically to storage, except that transient storage is discarded after every transaction. In other words, the values of transient storage are never deserialized from storage or serialized to storage. Thus transient storage is cheaper since it never requires disk access. Transient storage is accessible to smart contracts via 2 new opcodes, `TLOAD` and `TSTORE`, where “T” stands for "transient:"
 
 ```
-TLOAD  (0xb3)
-TSTORE (0xb4)
+TLOAD  (0x5c)
+TSTORE (0x5d)
 ```
 
 ## Motivation
@@ -33,7 +33,7 @@ Potential use cases enabled or improved by this EIP include:
 
 1. Reentrancy locks
 2. On-chain computable CREATE2 addresses: constructor arguments are read from the factory contract instead of passed as part of init code hash
-3. Single transaction [EIP-20](./eip-20.md) approvals, e.g. `#temporaryApprove(address spender, uint256 amount)`
+3. Single transaction [ERC-20](./eip-20.md) approvals, e.g. `#temporaryApprove(address spender, uint256 amount)`
 4. Fee-on-transfer contracts: pay a fee to a token contract to unlock transfers for the duration of a transaction
 5. "Till" pattern: allowing users to perform all actions as part of a callback, and checking the "till" is balanced at the end
 6. Proxy call metadata: pass additional metadata to an implementation contract without using calldata, e.g. values of immutable proxy constructor arguments  
@@ -42,7 +42,7 @@ These opcodes are more efficient to execute than the `SSTORE` and `SLOAD` opcode
 
 ## Specification
 
-Two new opcodes are added to EVM, `TLOAD` (`0xb3`) and `TSTORE` (`0xb4`). Note that previous drafts of this EIP specified the values `0x5c` and `0x5d` for `TLOAD` and `TSTORE` respectively, but these have been modified so as not to conflict with other draft EIPs.
+Two new opcodes are added to EVM, `TLOAD` (`0x5c`) and `TSTORE` (`0x5d`). (Note that previous drafts of this EIP specified the values `0xb3` and `0xb4` for `TLOAD` and `TSTORE` respectively to avoid conflict with other EIPs. The conflict has since been removed.)
 
 They use the same arguments on stack as `SLOAD` (`0x54`) and `SSTORE` (`0x55`).
 
@@ -70,7 +70,7 @@ Another option to solve the problem of inter-frame communication is repricing th
 
 Another approach is to keep the refund counter for transient storage separate from the refund counter for other storage uses, and remove the refund cap for transient storage. However, that approach is more complex to implement and understand. For example, the 20% refund cap must be applied to the gas used _after_ subtracting the uncapped gas refund. Otherwise, the refund amount available subject to the 20% refund cap could be increased by executing transient storage writes. Thus it is preferable to have a separate mechanism that does not interact with the refund counter. Future hard forks can remove the complex refund behavior meant to support the transient storage use case, encouraging migration to contracts that are more efficient for the Ethereum clients to execute.
 
-There is a known objection to the word-addressed storage-like interface of the `TSTORE` and `TLOAD` opcodes since transient storage is more akin to memory than storage in lifecycle. A byte-addressed memory-like interface is another option. The storage-like word-addressed interface is preferred due to the usefulness of mappings in combination with the transaction-scoped memory region. Often times, you will need to keep transient state with arbitrary keys, such as in the [EIP-20](./eip-20.md) temporary approval use case which uses a mapping of `(owner, spender)` to `allowance`. Mappings are difficult to implement using linear memory, and linear memory must also have dynamic gas costs. It is also more complicated to handle reverts with a linear memory. It is possible to have a memory-like interface while the underlying implementation uses a map to allow for storage in arbitrary offsets, but this would result in a third memory-storage hybrid interface that would require new code paths in compilers.
+There is a known objection to the word-addressed storage-like interface of the `TSTORE` and `TLOAD` opcodes since transient storage is more akin to memory than storage in lifecycle. A byte-addressed memory-like interface is another option. The storage-like word-addressed interface is preferred due to the usefulness of mappings in combination with the transaction-scoped memory region. Often times, you will need to keep transient state with arbitrary keys, such as in the [ERC-20](./eip-20.md) temporary approval use case which uses a mapping of `(owner, spender)` to `allowance`. Mappings are difficult to implement using linear memory, and linear memory must also have dynamic gas costs. It is also more complicated to handle reverts with a linear memory. It is possible to have a memory-like interface while the underlying implementation uses a map to allow for storage in arbitrary offsets, but this would result in a third memory-storage hybrid interface that would require new code paths in compilers.
 
 Some think that a unique transaction identifier may obviate the need for transient storage as described in this EIP. This is a misconception: a transaction identifier used in combination with regular storage has all the same issues that motivate this EIP. The two features are orthogonal.  
 

EIPS/eip-1185.md

@@ -4,7 +4,7 @@ title: Storage of DNS Records in ENS
 description: A system to store and retrieve DNS records within the ENS contract.
 author: Jim McDonald (@mcdee)
 discussions-to: https://ethereum-magicians.org/t/eip1185-dns-resolver-profile-for-ens/1589
-status: Draft
+status: Review
 type: Standards Track
 category: ERC
 created: 2018-06-26

EIPS/eip-2015.md

@@ -47,7 +47,7 @@ The `chainId` is the `0x`-prefixed [EIP-155](./eip-155.md)-compliant chain ID. T
 
 All keys other than the `chainId` are optional. All keys other than `chainId` are suggestions to the wallet. Wallets can choose to ignore or display other data to users. Wallets should prompt the user before switching or adding chains. Wallets should also store a default list of data for commonly-used chains, in order to avoid phishing attacks. Wallets MUST sanitize each RPC url before using it to send other requests, including ensuring that it responds correctly to the `net_version` and `eth_chainId` methods.
 
-The `wallet_updateEthereumChain` method returns `true` if the chain was successfully added or switched to, and an error with code `4001` if the user rejected the request.
+The `wallet_updateEthereumChain` method returns `true` if the active chain matches the requested chain, regardless of whether the chain was already active or was added to the wallet previously. If the user rejects the request, it must return an error with code `4001`.
 
 ## Rationale
 

EIPS/eip-2612.md

@@ -12,45 +12,49 @@ requires: 20, 712
 ---
 
 ## Abstract
+
 Arguably one of the main reasons for the success of [EIP-20](./eip-20.md) tokens lies in the interplay between `approve` and `transferFrom`, which allows for tokens to not only be transferred between externally owned accounts (EOA), but to be used in other contracts under application specific conditions by abstracting away `msg.sender` as the defining mechanism for token access control.
 
 However, a limiting factor in this design stems from the fact that the EIP-20 `approve` function itself is defined in terms of `msg.sender`. This means that user's _initial action_ involving EIP-20 tokens must be performed by an EOA (_but see Note below_). If the user needs to interact with a smart contract, then they need to make 2 transactions (`approve` and the smart contract call which will internally call `transferFrom`). Even in the simple use case of paying another person, they need to hold ETH to pay for transaction gas costs.
 
-This ERC extends the EIP-20 standard with a new function `permit`, which allows users to modify the `allowance` mapping using a signed message, instead of through `msg.sender`. 
+This ERC extends the EIP-20 standard with a new function `permit`, which allows users to modify the `allowance` mapping using a signed message, instead of through `msg.sender`.
 
 For an improved user experience, the signed data is structured following [EIP-712](./eip-712.md), which already has wide spread adoption in major RPC providers.
 
 **_Note:_** EIP-20 must be performed by an EOA unless the address owning the token is actually a contract wallet. Although contract wallets solves many of the same problems that motivates this EIP, they are currently only scarcely adopted in the ecosystem. Contract wallets suffer from a UX problem -- since they separate the EOA `owner` of the contract wallet from the contract wallet itself (which is meant to carry out actions on the `owner`s behalf and holds all of their funds), user interfaces need to be specifically designed to support them. The `permit` pattern reaps many of the same benefits while requiring little to no change in user interfaces.
 
 ## Motivation
+
 While EIP-20 tokens have become ubiquitous in the Ethereum ecosystem, their status remains that of second class tokens from the perspective of the protocol. The ability for users to interact with Ethereum without holding any ETH has been a long outstanding goal and the subject of many EIPs.
 
 So far, many of these proposals have seen very little adoption, and the ones that have been adopted (such as [EIP-777](./eip-777.md)), introduce a lot of additional functionality, causing unexpected behavior in mainstream contracts.
 
-This ERC proposes an alternative solution which is designed to be as minimal as possible and to only address _one problem_: the lack of abstraction in the EIP-20 `approve` method. 
+This ERC proposes an alternative solution which is designed to be as minimal as possible and to only address _one problem_: the lack of abstraction in the EIP-20 `approve` method.
 
 While it may be tempting to introduce `*_by_signature` counterparts for every EIP-20 function, they are intentionally left out of this EIP-20 for two reasons:
 
- - the desired specifics of such functions, such as decision regarding fees for `transfer_by_signature`, possible batching algorithms, varies depending on the use case, and,
- - they can be implemented using a combination of `permit` and additional helper contracts without loss of generality.
+- the desired specifics of such functions, such as decision regarding fees for `transfer_by_signature`, possible batching algorithms, varies depending on the use case, and,
+- they can be implemented using a combination of `permit` and additional helper contracts without loss of generality.
 
 ## Specification
+
 Compliant contracts must implement 3 new functions in addition to EIP-20:
+
 ```sol
 function permit(address owner, address spender, uint value, uint deadline, uint8 v, bytes32 r, bytes32 s) external
 function nonces(address owner) external view returns (uint)
 function DOMAIN_SEPARATOR() external view returns (bytes32)
 ```
+
 The semantics of which are as follows:
 
-For all addresses `owner`, `spender`, uint256s `value`, `deadline` and `nonce`, uint8 `v`, bytes32 `r` and `s`, 
-a call to `permit(owner, spender, value, deadline, v, r, s)` will set 
+For all addresses `owner`, `spender`, uint256s `value`, `deadline` and `nonce`, uint8 `v`, bytes32 `r` and `s`,
+a call to `permit(owner, spender, value, deadline, v, r, s)` will set
 `approval[owner][spender]` to `value`,
 increment `nonces[owner]` by 1,
-and emit a corresponding `Approval` event, 
+and emit a corresponding `Approval` event,
 if and only if the following conditions are met:
 
-
 - The current blocktime is less than or equal to `deadline`.
 - `owner` is not the zero address.
 - `nonces[owner]` (before the state update) is equal to `nonce`.
@@ -71,9 +75,11 @@ keccak256(abi.encodePacked(
             deadline))
 ))
 ```
+
 where `DOMAIN_SEPARATOR` is defined according to EIP-712. The `DOMAIN_SEPARATOR` should be unique to the contract and chain to prevent replay attacks from other domains,
 and satisfy the requirements of EIP-712, but is otherwise unconstrained.
 A common choice for `DOMAIN_SEPARATOR` is:
+
 ```solidity
 DOMAIN_SEPARATOR = keccak256(
     abi.encode(
@@ -86,7 +92,7 @@ DOMAIN_SEPARATOR = keccak256(
 ```
 
 In other words, the message is the EIP-712 typed structure:
-    
+
 ```js
 {
   "types": {
@@ -129,6 +135,7 @@ In other words, the message is the EIP-712 typed structure:
         "type": "uint256"
       }
     ],
+  },
     "primaryType": "Permit",
     "domain": {
       "name": erc20name,
@@ -143,26 +150,27 @@ In other words, the message is the EIP-712 typed structure:
     "nonce": nonce,
     "deadline": deadline
   }
-}}
+}
 ```
 
 Note that nowhere in this definition we refer to `msg.sender`. The caller of the `permit` function can be any address.
 
-
 ## Rationale
-The `permit` function is sufficient for enabling any operation involving EIP-20 tokens to be paid for using the token itself, rather than using ETH. 
+
+The `permit` function is sufficient for enabling any operation involving EIP-20 tokens to be paid for using the token itself, rather than using ETH.
 
 The `nonces` mapping is given for replay protection.
 
 A common use case of `permit` has a relayer submit a `Permit` on behalf of the `owner`. In this scenario, the relaying party is essentially given a free option to submit or withhold the `Permit`. If this is a cause of concern, the `owner` can limit the time a `Permit` is valid for by setting `deadline` to a value in the near future. The `deadline` argument can be set to `uint(-1)` to create `Permit`s that effectively never expire.
 
 EIP-712 typed messages are included because of its wide spread adoption in many wallet providers.
 
-
 ## Backwards Compatibility
+
 There are already a couple of `permit` functions in token contracts implemented in contracts in the wild, most notably the one introduced in the `dai.sol`.
 
 Its implementation differs slightly from the presentation here in that:
+
 - instead of taking a `value` argument, it takes a bool `allowed`, setting approval to 0 or `uint(-1)`.
 - the `deadline` argument is instead called `expiry`. This is not just a syntactic change, as it effects the contents of the signed message.
 
@@ -185,4 +193,5 @@ The standard EIP-20 race condition for approvals (SWC-114) applies to `permit` a
 If the `DOMAIN_SEPARATOR` contains the `chainId` and is defined at contract deployment instead of reconstructed for every signature, there is a risk of possible replay attacks between chains in the event of a future chain split.
 
 ## Copyright
+
 Copyright and related rights waived via [CC0](../LICENSE.md).