Merge branch 'ethereum:master' into master

Author: Ameralameri

EIPS/eip-1.md

@@ -24,7 +24,7 @@ There are three types of EIP:
 - A **Standards Track EIP** describes any change that affects most or all Ethereum implementations, such as—a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Ethereum. Standards Track EIPs consist of three parts—a design document, an implementation, and (if warranted) an update to the [formal specification](https://github.com/ethereum/yellowpaper). Furthermore, Standards Track EIPs can be broken down into the following categories:
   - **Core**: improvements requiring a consensus fork (e.g. [EIP-5](./eip-5.md), [EIP-101](./eip-101.md)), as well as changes that are not necessarily consensus critical but may be relevant to [“core dev” discussions](https://github.com/ethereum/pm) (for example, [EIP-90], and the miner/node strategy changes 2, 3, and 4 of [EIP-86](./eip-86.md)).
   - **Networking**: includes improvements around [devp2p](https://github.com/ethereum/devp2p/blob/readme-spec-links/rlpx.md) ([EIP-8](./eip-8.md)) and [Light Ethereum Subprotocol](https://ethereum.org/en/developers/docs/nodes-and-clients/#light-node), as well as proposed improvements to network protocol specifications of [whisper](https://github.com/ethereum/go-ethereum/issues/16013#issuecomment-364639309) and [swarm](https://github.com/ethereum/go-ethereum/pull/2959).
-  - **Interface**: includes improvements around client [API/RPC](https://github.com/ethereum/execution-apis#README) specifications and standards, and also certain language-level standards like method names ([EIP-6](./eip-6.md)) and [contract ABIs](https://docs.soliditylang.org/en/develop/abi-spec.html). The label “interface” aligns with the [interfaces repo] and discussion should primarily occur in that repository before an EIP is submitted to the EIPs repository.
+  - **Interface**: includes improvements around language-level standards like method names ([EIP-6](./eip-6.md)) and [contract ABIs](https://docs.soliditylang.org/en/develop/abi-spec.html).
   - **ERC**: application-level standards and conventions, including contract standards such as token standards ([ERC-20](./eip-20.md)), name registries ([ERC-137](./eip-137.md)), URI schemes, library/package formats, and wallet formats.
 
 - A **Meta EIP** describes a process surrounding Ethereum or proposes a change to (or an event in) a process. Process EIPs are like Standards Track EIPs but apply to areas other than the Ethereum protocol itself. They may propose an implementation, but not to Ethereum's codebase; they often require community consensus; unlike Informational EIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Ethereum development. Any meta-EIP is also considered a Process EIP.
@@ -326,6 +326,18 @@ Permitted Bitcoin Improvement Proposal URLs must anchor to a specific commit, an
 ^(https://github.com/bitcoin/bips/blob/[0-9a-f]{40}/bip-[0-9]+\.mediawiki)$
 ```
 
+### National Vulnerability Database (NVD)
+
+Links to the Common Vulnerabilities and Exposures (CVE) system as published by the National Institute of Standards and Technology (NIST) may be included, provided they are qualified by the date of the most recent change, using the following syntax:
+
+```markdown
+[CVE-2023-29638 (2023-10-17T10:14:15)](https://nvd.nist.gov/vuln/detail/CVE-2023-29638)
+```
+
+Which renders to:
+
+[CVE-2023-29638 (2023-10-17T10:14:15)](https://nvd.nist.gov/vuln/detail/CVE-2023-29638)
+
 ### Digital Object Identifier System
 
 Links qualified with a Digital Object Identifier (DOI) may be included using the following syntax:

EIPS/eip-223.md

@@ -4,8 +4,7 @@ title: Token with transaction handling model
 description: Token with transaction handling model designed to behave identical to native currency (ether)
 author: Dexaran (@Dexaran) <dexaran@ethereumclassic.org>
 discussions-to: https://ethereum-magicians.org/t/erc-223-token-standard/12894
-status: Last Call
-last-call-deadline: 2023-09-03
+status: Final
 type: Standards Track
 category: ERC
 created: 2017-05-03
@@ -19,7 +18,7 @@ The following describes an interface and logic for fungible tokens that supports
 
 This token introduces a communication model for contracts that can be utilized to straighten the behavior of contracts that interact with such tokens. Specifically, this proposal:
 
-1. Informs receiving contracts of tokens, as opposed to [ERC-20](./eip-20.md) where the recipient of a token transfer gets no notification.
+1. Informs receiving contracts of incoming token transfers, as opposed to [ERC-20](./eip-20.md) where the recipient of a token transfer gets no notification.
 2. Is more gas-efficient when depositing tokens to contracts.
 3. Allows for `_data` recording for financial transfers.
 
@@ -36,15 +35,15 @@ Token transfers to contracts not implementing `tokenReceived` as described below
 ##### `totalSupply`
 
 ```solidity
-function totalSupply() view returns (uint256 totalSupply)
+function totalSupply() view returns (uint256)
 ```
 
 Returns the total supply of the token. The functionality of this method is identical to that of ERC-20.
 
 ##### `name`
 
 ```solidity
-function name() view returns (string _name)
+function name() view returns (string memory)
 ```
 
 Returns the name of the token.  The functionality of this method is identical to that of ERC-20.
@@ -54,7 +53,7 @@ OPTIONAL - This method can be used to improve usability, but interfaces and othe
 ##### `symbol`
 
 ```solidity
-function symbol() view returns (string _symbol)
+function symbol() view returns (string memory)
 ```
 
 Returns the symbol of the token. The functionality of this method is identical to that of ERC-20.
@@ -64,7 +63,7 @@ OPTIONAL - This method can be used to improve usability, but interfaces and othe
 ##### `decimals`
 
 ```solidity
-function decimals() view returns (uint8 _decimals)
+function decimals() view returns (uint8)
 ```
 
 Returns the number of decimals of the token. The functionality of this method is identical to that of ERC-20.
@@ -84,7 +83,7 @@ OPTIONAL - This method can be used to improve usability, but interfaces and othe
 ##### `balanceOf`
 
 ```solidity
-function balanceOf(address _owner) view returns (uint256 balance)
+function balanceOf(address _owner) view returns (uint256)
 ```
 
 Returns the account balance of another account with address `_owner`. The functionality of this method is identical to that of ERC-20.
@@ -99,7 +98,9 @@ This function must transfer tokens, and if `_to` is a contract, it must call the
 If `_to` is an externally owned address, then the transaction must be sent without executing `tokenReceived` in `_to`.
  `_data` can be attached to this token transaction, but it requires more gas. `_data` can be empty.
 
- The `tokenReceived` function of `_to` MUST be called after all other operations to avoid re-entrancy attacks.
+The `tokenReceived` function of `_to` MUST be called after all other operations to avoid re-entrancy attacks.
+ 
+NOTE: If `transfer` function is `payable` and ether was deposited then the amount of deposited ether MUST be delivered to `_to` address alongside tokens. If ether was sent alongside tokens in this way then ether MUST be delivered first, then token balances must be updated, then `tokenReceived` function MUST be called in `_to` if it is a contract.
 
 ##### `transfer(address, uint, bytes)`
 
@@ -111,7 +112,7 @@ This function must transfer tokens and invoke the function `tokenReceived (addre
 If `_to` is an externally owned address (determined by the code size being zero), then the transaction must be sent without executing `tokenReceived` in `_to`.
  `_data` can be attached to this token transaction, but it requires more gas. `_data` can be empty.
 
-NOTE: A possible way to check whether the `_to` is a contract or an address is to assemble the code of `_to`. If there is no code in `_to`, then this is an externally owned address, otherwise it's a contract.
+NOTE: A possible way to check whether the `_to` is a contract or an address is to assemble the code of `_to`. If there is no code in `_to`, then this is an externally owned address, otherwise it's a contract. If `transfer` function is `payable` and ether was deposited then the amount of deposited ether MUST be delivered to `_to` address alongside tokens.
 
 The `tokenReceived` function of `_to` MUST be called after all other operations to avoid re-entrancy attacks.
 
@@ -133,11 +134,11 @@ Triggered when tokens are transferred. Compatible with and similar to the ERC-20
 function tokenReceived(address _from, uint _value, bytes calldata _data) returns (bytes4)
 ```
 
-A function for handling token transfers, which is called from the token contract, when a token holder sends tokens. `_from` is the address of the sender of the token, `_value` is the amount of incoming tokens, and `_data` is attached data similar to `msg.data` of Ether transactions. It works by analogy with the fallback function of Ether transactions and returns nothing.
+A function for handling token transfers, which is called from the token contract, when a token holder sends tokens. `_from` is the address of the sender of the token, `_value` is the amount of incoming tokens, and `_data` is attached data similar to `msg.data` of ether transactions. It works by analogy with the fallback function of Ether transactions and returns nothing.
 
 NOTE: `msg.sender` will be a token-contract inside the `tokenReceived` function. It may be important to filter which tokens were sent (by token-contract address). The token sender (the person who initiated the token transaction) will be `_from` inside the `tokenReceived` function. The `tokenReceived` function must return `0x8943ec02` after handling an incoming token transfer. The `tokenReceived` function call can be handled by the fallback function of the recipient contact (and in this case it may not return the magic value 0x8943ec02).
 
-IMPORTANT: This function must be named `tokenReceived` and take parameters `address`, `uint256`, `bytes` to match the function signature `0x8943ec02`.
+IMPORTANT: This function must be named `tokenReceived` and take parameters `address`, `uint256`, `bytes` to match the function signature `0x8943ec02`. This function can be manually called by a EOA.
 
 ## Rationale
 
@@ -149,13 +150,13 @@ This standard sticks to the push transaction model where the transfer of assets
 
 - ERC-223 deposit: `transfer` and handling on the receivers side ~54K gas
 
-This standard introduces the ability to correct user errors by allowing to handle ANY transactions on the recipient side and reject incorrect or improper transactions. This tokens utilize ONE transferring method for both types of interactions with tokens and externally owned addresses which can simplify the user experience and allow to avoid possible user mistakes.
+This standard introduces the ability to correct user errors by allowing to handle ANY transactions on the recipients side and reject incorrect or improper transfers. This tokens utilize ONE transferring method for both types of interactions with contracts and externally owned addresses which can simplify the user experience and allow to avoid possible user mistakes.
 
-One downside of the commonly used [ERC-20](./eip-20.md) standard that ERC-223 is intended to solve is that [ERC-20](./eip-20.md) implements two methods of token transferring: (1) `transfer` function and (2) `approve + transferFrom` pattern. Transfer function of [ERC-20](./eip-20.md) standard does not notify the receiver and therefore if any tokens are sent to a contract with the `transfer` function then the receiver will not recognize this transfer and the tokens can become stuck in the receivers address without any possibility of recovering them.
+One downside of the commonly used [ERC-20](./eip-20.md) standard that ERC-223 is intended to solve is that [ERC-20](./eip-20.md) implements two methods of token transferring: (1) `transfer` function and (2) `approve + transferFrom` pattern. Transfer function of [ERC-20](./eip-20.md) standard does not notify the receiver and therefore if any tokens are sent to a contract with the `transfer` function then the receiver will not recognize this transfer and the tokens can become stuck in the receivers address without any possibility of recovering them. [ERC-20](./eip-20.md) standard places the burden of determining the transferring method on the user and if the incorrect method is chosen the user can lose the transferred tokens. ERC-223 automatically determines the transferring method, preventing the user from losing tokens due to chosing wrong method.
 
 ERC-223 is intended to simplify the interaction with contracts that are intended to work with tokens. ERC-223 utilizes a "deposit" pattern, similar to that of plain Ether. An ERC-223 deposit to a contract is a simple call of the `transfer` function. This is one transaction as opposed to two step process of `approve + transferFrom` depositing.
 
-This standard allows payloads to be attached to transactions using the `bytes calldata _data` parameter, which can encode a second function call in the destination address, similar to how `msg.data` does in an Ether transaction, or allow for public logging on chain should it be necessary for financial transactions.
+This standard allows payloads to be attached to transactions using the `bytes calldata _data` parameter, which can encode a second function call in the destination address, similar to how `msg.data` does in an ether transaction, or allow for public logging on chain should it be necessary for financial transactions.
 
 ## Backwards Compatibility
 
@@ -164,18 +165,18 @@ The interface of this token is similar to that of ERC-20 and most functions serv
 
 ERC-20 tokens can be delivered to a non-contract address with `transfer` function. ERC-20 tokens can be deposited to a contract address with `approve` + `transferFrom` pattern. Depositing ERC-20 tokens to the contract address with `transfer` function will always result in token deposit not being recognized by the recipient contract.
 
-Here is an example of the contract code that handles ERC-20 token deposit. The following contract can accepts `tokenA` deposits. It is impossible to prevent deposits of tokenA or any other ERC-20 token to this contract that are made with `transfer` function.
+Here is an example of the contract code that handles ERC-20 token deposit. The following contract can accepts `tokenA` deposits. It is impossible to prevent deposits of non-tokenA to this contract. If tokenA is deposited with `transfer` function then it will result in a loss of tokens for the depositor because the balance of the user will be decreased in the contract of tokenA but the value of `deposits` variable in the `ERC20Receiver` will not be increased i.e. the deposit will not be credited. As of 5/9/2023 **$201M worth of 50 examined ERC-20 tokens are already lost** in this way on Ethereum mainnet.
 
 ```solidity
 contract ERC20Receiver
 {
-    event Deposit();
     address tokenA;
+    mapping (address => uint256) deposits;
     function deposit(uint _value, address _token) public
     {
         require(_token == tokenA);
         IERC20(_token).transferFrom(msg.sender, address(this), _value);
-        emit Deposit();
+        deposits[msg.sender] += _value;
     }
 }
 ```
@@ -187,19 +188,20 @@ Here is an example of the contract code that handles ERC-223 token deposit. The
 ```solidity
 contract ERC223Receiver
 {
-    event Deposit();
     address tokenA;
-    function tokenReceived(address _from, uint _value, bytes memory _data) public
+    mapping (address => uint256) deposits;
+    function tokenReceived(address _from, uint _value, bytes memory _data) public returns (bytes4)
     {
         require(msg.sender == tokenA);
-        emit Deposit();
+        deposits[_from] += _value;
+        return 0x8943ec02;
     }
 }
 ```
 
 ## Security Considerations
 
-This token utilizes the model similar to plain Ether behavior. Therefore replay issues must be taken into account.
+This token utilizes the model similar to plain ether behavior. Therefore replay issues must be taken into account.
 
 ### Reference Implementation