Merge branch 'ethereum:master' into master

.github/workflows/ci.yml

@@ -65,7 +65,7 @@ jobs:
           cd $GITHUB_WORKSPACE
           rm -rf ERCs
       - name: Setup Ruby
-        uses: ruby/setup-ruby@55283cc23133118229fd3f97f9336ee23a179fcf # v1.146.0
+        uses: ruby/setup-ruby@f26937343756480a8cb3ae1f623b9c8d89ed6984 # v1.196.0
         with:
           ruby-version: '3.1' # Not needed with a .ruby-version file
           bundler-cache: true # runs 'bundle install' and caches installed gems automatically
@@ -136,7 +136,7 @@ jobs:
       - name: Checkout EIP Repository
         uses: actions/checkout@47fbe2df0ad0e27efb67a70beac3555f192b062f
 
-      - uses: ethereum/eipw-action@6785fa283773db4819cb0abf17a185a1d9b6eb9f
+      - uses: ethereum/eipw-action@be3fa642ec311d0b8e1fdb811e5c9b4ada3d3d93
         id: eipw
         with:
           token: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/jekyll-label-bot.yml

@@ -14,7 +14,7 @@ jobs:
     runs-on: ubuntu-latest
 
     steps:
-      - uses: Pandapip1/jekyll-label-action@d0fd82c3cd118140a50843906845fca8e59a8b9e
+      - uses: Pandapip1/jekyll-label-action@4b7cce7588a8686f5146a8e12aab7269042057ce
         with:
           token: ${{ secrets.GITHUB_TOKEN }}
           config-path: config/.jekyll-labels.yml

.github/workflows/jekyll.yml

@@ -34,7 +34,7 @@ jobs:
       - name: Checkout
         uses: actions/checkout@v3
       - name: Setup Ruby
-        uses: ruby/setup-ruby@55283cc23133118229fd3f97f9336ee23a179fcf # v1.146.0
+        uses: ruby/setup-ruby@f26937343756480a8cb3ae1f623b9c8d89ed6984 # v1.196.0
         with:
           ruby-version: '3.1' # Not needed with a .ruby-version file
           bundler-cache: true # runs 'bundle install' and caches installed gems automatically

.github/workflows/stale.yml

@@ -20,16 +20,16 @@ jobs:
         repo-token: ${{ secrets.GITHUB_TOKEN }}
         ascending: true # Since we have so many issues, the stale bot finds it hard to keep track. This makes sure that at least the oldest are removed.
         # Issue config
-        stale-issue-message: There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.
+        stale-issue-message: There has been no activity on this issue for six months. It will be closed in 7 days if there is no new activity. 
         close-issue-message: This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback.
-        days-before-issue-stale: 7
-        days-before-issue-close: 49 # 49 + 7 weeks = 3 months
+        days-before-issue-stale: 183
+        days-before-issue-close: 190
         exempt-issue-labels: discussions-to
         stale-issue-label: w-stale
         # PR config
-        stale-pr-message: There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.
+        stale-pr-message: There has been no activity on this issue for six months. It will be closed in 7 days if there is no new activity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.
         close-pr-message: This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.
-        days-before-pr-stale: 14
-        days-before-pr-close: 42 # 42 + 14 weeks = 3 months
+        days-before-pr-stale: 183
+        days-before-pr-close: 190
         exempt-pr-milestones: "Manual Merge Queue"
         stale-pr-label: w-stale

ERCS/eip-1.md

@@ -431,17 +431,17 @@ If you are interested in assuming ownership of an EIP, send a message asking to
 
 The current EIP editors are
 
-- Alex Beregszaszi (@axic)
-- Greg Colvin (@gcolvin)
 - Matt Garnett (@lightclient)
 - Sam Wilson (@SamWilsn)
 - Zainan Victor Zhou (@xinbenlv)
 - Gajinder Singh (@g11tech)
 
 Emeritus EIP editors are
 
+- Alex Beregszaszi (@axic)
 - Casey Detrio (@cdetrio)
 - Gavin John (@Pandapip1)
+- Greg Colvin (@gcolvin)
 - Hudson Jameson (@Souptacular)
 - Martin Becze (@wanderer)
 - Micah Zoltu (@MicahZoltu)

ERCS/erc-1066.md

@@ -236,7 +236,7 @@ Currently unspecified. (Full range reserved)
 
 #### `0x7*` TBD
 
-Currently unspecifie. (Full range reserved)
+Currently unspecified. (Full range reserved)
 
 #### `0x8*` TBD
 

ERCS/erc-1077.md

@@ -85,7 +85,7 @@ The fields **MUST** be constructed as this method:
 
 The first and second fields are to make it [EIP-191] compliant. Starting a transaction with `byte(0x19)` ensure the signed data from being a [valid ethereum transaction](https://github.com/ethereum/wiki/wiki/RLP). The second argument is a version control byte. The third being the validator address (the account contract address) according to version 0 of [EIP-191]. The remaining arguments being the application specific data for the gas relay: chainID as per [EIP-1344], execution nonce, execution data, agreed gas Price, gas limit of gas relayed call, gas token to pay back and gas relayer authorized to receive the reward.
 
-The [EIP-191] message must be constructed as following:
+The [EIP-191] message must be constructed as follows:
 ```solidity
 keccak256(
 	abi.encodePacked(

ERCS/erc-1078.md

@@ -17,7 +17,7 @@ This presents a method to replace the usual signup/login design pattern with a m
 
 ## Simple Summary
 
-The unique identifier of the user is a contract that implements both Identity and the Executable Signed Messages ERCs. The user should not need provide this address directly, only a ens name pointing to it. These types of contracts are indirectly controlled by private keys that can sign messages indicating intents, which are then deployed to the contract by a third party (or a decentralized network of deployers).  
+The unique identifier of the user is a contract that implements both Identity and the Executable Signed Messages ERCs. The user should not need to provide this address directly, only a ENS name pointing to it. These types of contracts are indirectly controlled by private keys that can sign messages indicating intents, which are then deployed to the contract by a third party (or a decentralized network of deployers).  
 
 In this context, therefore, a device "logging into" an app using an identity, means that the device will generate a private key locally and then request an authorization to add that key as one of the signers of that identity, with a given set of permissions. Since that private key is only used for signing messages, it is not required to hold ether, tokens or assets, and if lost, it can be simply be replaced by a new one – the user's funds are kept on the identity contract.
 
@@ -37,13 +37,13 @@ If the user doesn’t have an identity, the app should provide the option to cre
 
 1. Generate a private key which it will keep saved locally on the device or browser, the safest way possible.
 2. Create (or set up) an identity contract which supports both ERC720 and ERC1077
-3. Register the private key created on step 1 as the *only* admin key of the contract (the app must not add any app-controlled key, except as recovery option - see 5)
+3. Register the private key created on step 1 as the *only* admin key of the contract (the app must not add any app-controlled key, except as a recovery option - see 5)
 4. Register the requested subdomain and transfer its ownership to the contract (while the app controls the main domain and may keep the option to reassign them at will, the ownership of the subdomain itself should belong to the identity, therefore allowing them to transfer it)
 5. (Optionally) Register a recovery method on the contract, which allows the user to regain access to the contract in case the main key is lost.
 
 All those steps can be designed to be set up in a single ethereum transaction. Since this step is not free, the app reserves the right to charge for registering users, or require the user to be verified in a sybil resistant manner of the app’s choosing (captcha, device ID registration, proof of work, etc)
 
-The user shouldn’t be forced to wait for transaction confirmation times. Instead, have an indicator somewhere on the app the shows the progress and then allow the user to interact with your app normally. It’s unlikely that they’ll need the identity in the first few minutes and if something goes wrong (username gets registered at the same time), you can then ask the user for an action.
+The user shouldn’t be forced to wait for transaction confirmation times. Instead, have an indicator somewhere on the app that shows the progress and then allow the user to interact with your app normally. It’s unlikely that they’ll need the identity in the first few minutes and if something goes wrong (username gets registered at the same time), you can then ask the user for an action.
 
 **Implementation note:** in order to save gas, some of these steps can be done in advance. The app can automatically deploy a small number of contracts when the gas price is low, and set up all their main variables to be 0xFFFFFF...FFFFF. These should be considered ‘vacant’ and when the user registers one, they will get a gas discount for freeing up space on the chain. This has the added benefit of allowing the user a choice in contract address/icon.
 
@@ -102,7 +102,7 @@ If the transaction need to collect more signatures or the app doesn't have a dep
 
 The goal is to keep broadcasting signatures via whisper until a node that is willing to deploy them is able to collect all messages.
 
-Once you've followed the above steps, watch the transaction pool to any transaction to that address and then take the user to your app. Once you seen the desired transaction, you can stop showing the QRcode and proceed with the app, while keeping some indication that the transaction is in progress. Subscribe to the event `ExecutedSigned` of the desired contract: once you see the transaction with the nonce, you can call it a success. If you see a different transaction with the same or higher nonce (or timestamp) then you consider the transaction permanently failed and restart the process.
+Once you've followed the above steps, watch the transaction pool to any transaction to that address and then take the user to your app. Once you seen the desired transaction, you can stop showing the  QR code and proceed with the app, while keeping some indication that the transaction is in progress. Subscribe to the event `ExecutedSigned` of the desired contract: once you see the transaction with the nonce, you can call it a success. If you see a different transaction with the same or higher nonce (or timestamp) then you consider the transaction permanently failed and restart the process.
 
 
 ### Implementation
@@ -111,7 +111,7 @@ No working examples of this implementation exists, but many developers have expr
 
 ### Conclusion and future improvements
 
-This scheme would allow much more lighter apps, that don't require to hold ether, and can keep unlocked private keys on the device to be able to send messages and play games without requesting user prompt every time. More work is needed to standardize common decentralized messaging protocols as well as open source tools for deployment nodes, in order to create a decentralized and reliable layer for message deployment.
+This scheme would allow much more lighter apps, that don’t require holding ether, and can keep unlocked private keys on the device to be able to send messages and play games without requesting user prompt every time. More work is needed to standardize common decentralized messaging protocols as well as open source tools for deployment nodes, in order to create a decentralized and reliable layer for message deployment.
 
 ### References
 

ERCS/erc-1081.md

@@ -28,7 +28,7 @@ After studying bounties as they've existed for thousands of years (and after imp
 To implement these steps, a number of functions are needed:
 - `initializeBounty(address _issuer, address _arbiter, string _data, uint _deadline)`: This is used when deploying a new StandardBounty contract, and is particularly useful when applying the proxy design pattern, whereby bounties cannot be initialized in their constructors. Here, the data string should represent an IPFS hash, corresponding to a JSON object which conforms to the schema (described below).
 - `fulfillBounty(address[] _fulfillers, uint[] _numerators, uint _denomenator, string _data)`: This is called to submit a fulfillment, submitting a string representing an IPFS hash which contains the deliverable for the bounty. Initially fulfillments could only be submitted by one individual at a time, however users consistently told us they desired to be able to collaborate on fulfillments, thereby allowing the credit for submissions to be shared by several parties. The lines along which eventual payouts are split are determined by the fractions of the submission credited to each fulfiller (using the array of numerators and single denominator). Here, a bounty platform may also include themselves as a collaborator to collect a small fee for matching the bounty with fulfillers.
-- `acceptFulfillment(uint _fulfillmentId, StandardToken[] _payoutTokens, uint[] _tokenAmounts)`: This is called by the `issuer` or the `arbiter` to pay out a given fulfillment, using an array of tokens, and an array of amounts of each token to be split among the contributors. This allows for the bounty payout amount to move as it needs to based on incoming contributions (which may be transferred directly to the contract address). It also allows for the easy splitting of a given bounty's balance among several fulfillments, if the need should arise.
+- `acceptFulfillment(uint _fulfillmentId, StandardToken[] _payoutTokens, uint[] _tokenAmounts)`: This is called by the `issuer` or the `arbiter` to pay out a given fulfillment, using an array of tokens, and an array of amounts of each token to be split among the contributors. This allows for the bounty payout amount to move as it needs to be based on incoming contributions (which may be transferred directly to the contract address). It also allows for the easy splitting of a given bounty's balance among several fulfillments, if the need should arise.
    - `drainBounty(StandardToken[] _payoutTokens)`: This may be called by the `issuer` to drain a bounty of it's funds, if the need should arise.
 - `changeBounty(address _issuer, address _arbiter, string _data, uint _deadline)`: This may be called by the `issuer` to change the `issuer`, `arbiter`, `data`, and `deadline` fields of their bounty.
 - `changeIssuer(address _issuer)`: This may be called by the `issuer` to change to a new `issuer` if need be

ERCS/erc-1129.md

@@ -49,9 +49,9 @@ struct Announcement{
 
 
 ### Methods
-#### the number of ammouncements
+#### the number of announcements
 
-Returns the number of announcement currently active.
+Returns the number of announcements currently active.
 
 OPTIONAL - this method can be used to provide quicker information for the UI, but could also be retrieved from `numberOfMessages` variable.
 

ERCS/erc-3668.md

@@ -1,6 +1,6 @@
 ---
 eip: 3668
-title: "CCIP Read: Secure offchain data retrieval"
+title: CCIP Read—Secure offchain data retrieval
 description: CCIP Read provides a mechanism to allow a contract to fetch external data.
 author: Nick Johnson (@arachnid)
 discussions-to: https://ethereum-magicians.org/t/durin-secure-offchain-data-retrieval/6728
@@ -295,8 +295,8 @@ A client that supports CCIP read MUST make contract calls using the following pr
  5. If the `sender` field does not match the address of the contract that was called, return an error to the caller and stop.
  6. Construct a request URL by replacing `sender` with the lowercase 0x-prefixed hexadecimal formatted `sender` parameter, and replacing `data` with the 0x-prefixed hexadecimal formatted `callData` parameter. The client may choose which URLs to try in which order, but SHOULD prioritise URLs earlier in the list over those later in the list.
  7. Make an HTTP GET request to the request URL.
- 8. If the response code from step (5) is in the range 400-499, return an error to the caller and stop.
- 9. If the response code from step (5) is in the range 500-599, go back to step (5) and pick a different URL, or stop if there are no further URLs to try.
+ 8. If the response code from step (7) is in the range 400-499, return an error to the caller and stop.
+ 9. If the response code from step (7) is in the range 500-599, go back to step (5) and pick a different URL, or stop if there are no further URLs to try.
  10. Otherwise, replace `data` with an ABI-encoded call to the contract function specified by the 4-byte selector `callbackFunction`, supplying the data returned from step (7) and `extraData` from step (4), and return to step (1).
 
 Clients MUST handle HTTP status codes appropriately, employing best practices for error reporting and retries.

ERCS/erc-3770.md

@@ -4,16 +4,16 @@ title: Chain-specific addresses
 description: Prepending chain-specific addresses with a human-readable chain identifier
 author: Lukas Schor (@lukasschor), Richard Meissner (@rmeissner), Pedro Gomes (@pedrouid), ligi <ligi@ligi.de>
 discussions-to: https://ethereum-magicians.org/t/chain-specific-addresses/6449
-status: Stagnant
+status: Draft
 type: Standards Track
 category: ERC
 created: 2021-08-26
 ---
 
 ## Abstract
 
-[ERC-3770](./eip-3770.md) introduces a new address standard to be adapted by wallets and dApps to display chain-specific addresses by using a human-reacable prefix.
-  
+[ERC-3770](./eip-3770.md) introduces a new address standard to be adapted by wallets and dApps to display chain-specific addresses by using a human-readable prefix.
+
 ## Motivation
 
 The need for this proposal emerges from the increasing adoption of non-Ethereum Mainnet chains that use the Ethereum Virtual Machine (EVM). In this context, addresses become ambiguous, as the same address may refer to an EOA on chain X or a smart contract on chain Y. This will eventually lead to Ethereum users losing funds due to human error. For example, users sending funds to a smart contract wallet address which was not deployed on a particular chain.
@@ -36,13 +36,8 @@ Chain-specific address = "`shortName`" "`:`" "`address`"
 
 ### Semantics
 
-```
-
-`shortName` is mandatory and MUST be a valid chain short name from https://github.com/ethereum-lists/chains
-  
-`address` is mandatory and MUST be a [ERC-55](./eip-55.md) compatible hexadecimal address
-
-```
+* `shortName` is mandatory and MUST be a valid chain short name from https://github.com/ethereum-lists/chains
+* `address` is mandatory and MUST be a [ERC-55](./eip-55.md) compatible hexadecimal address
 
 ### Examples
 
@@ -58,7 +53,7 @@ Ethereum addresses without the chain specifier will continue to require addition
 
 ## Security Considerations
 
-The Ethereum List curators must consider how similar looking chain short names can be used to confuse users.
+Similar looking chain short names can be used to confuse users.
 
 ## Copyright