Automatically merged updates to draft EIP(s) 2711 (ethereum#2714)

Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing

EIPS/eip-2711.md

@@ -23,7 +23,7 @@ This EIP proposes a mechanism by which we can allow people to transact without e
 While it is possible to implement these sort of mechanisms at the individual contract layer, such solutions require integration by just about every contract and those solutions also end up depending on gas costs being stable with time in order to appropriately bake them into contracts without putting either party at risk of malicious participants in the system.  For this reason, it is deemed beneficial that separating out `GAS_PAYER` from `msg.sender` at the protocol layer is valuable.
 
 ## Specification
-Currently, a signed transaction is 9 RLP encoded fields (`[nonce, gasPrice, gasLimit, to, value, data, senderV, senderR, senderS]`).  As of `FORK_BLOCK_NUMBER`, that would continue to be a valid signed transaction and would operate as normal.  As of `FORK_BLOCK_NUMBER` a transaction containing 13 RLP encoded fields interpreted as `[nonce, to, value, data, chainId, senderV, senderR, senderS, gasPrice, gasLimit, gasPayerV, gasPayerR, gasPayerS]` would also be valid.  In such a transaction, `senderV, senderR, senderS` would be a signature of `rlp([nonce, to, value, data, chainId])` and `gasPayerV, gasPayerR, gasPayerS` would be a signature of `rlp([nonce, to, value, data, chainId, senderV, senderR, senderS, gasPrice, gasLimit])`.
+Currently, a signed transaction is 9 RLP encoded fields (`[nonce, gasPrice, gasLimit, to, value, data, senderV, senderR, senderS]`).  As of `FORK_BLOCK_NUMBER`, that would continue to be a valid signed transaction and would operate as normal.  As of `FORK_BLOCK_NUMBER` a transaction containing 13 RLP encoded fields interpreted as `[nonce, to, value, data, senderV, senderR, senderS, gasPrice, gasLimit, gasPayerV, gasPayerR, gasPayerS]` would also be valid.  In such a transaction, `senderV, senderR, senderS` is a signature of `rlp([nonce, to, value, data, chainId])` where `senderV` is `CHAIN_ID * 2 + 35` or `CHAIN_ID * 2 + 36` (see [EIP-155](./eip-155.md) for details on `senderV`) and `gasPayerV, gasPayerR, gasPayerS` is a signature of `rlp([nonce, to, value, data, chainId, senderV, senderR, senderS, gasPrice, gasLimit])`.
 
 ## Rationale
 ### EIP-155 ChainID