Automatically merged updates to draft EIP(s) 2711 (#2716)

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

@@ -30,12 +30,12 @@ Currently, a signed transaction is 9 RLP encoded fields (`[nonce, gasPrice, gasL
 I'm open to discussion on whether we should enforce EIP-155 chain IDs or not.  It feels like we might as well since we are creating a new transaction type here.
 ### Transaction Versioning
 It would be *better* if we developed a mechanism for enveloping arbitrary new transaction types rather than just relying on "if it has 13 items then it is of this type, if it has 9 it is of that type".  However, while there has been a lot of talk about creating a transaction envelope layer that allows us to more freely add new transaction types, no action has been taken on that front and I am loathe to wait for someone to develop such a standard for it first.
-### `GAS_PAYER` chooses `gasLimit` and `gasPrice`
-Allowing the gas payer to choose limit and price means that the gas payer can take measures to ensure that the transaction is mined and is successful.  The `SENDER` may wish to allow the `GAS_PAYER` to execute some code as part of the transaction (e.g., through a cross-contract callback).  In such cases, the `SENDER` will not know the amount of gas that the `GAS_PAYER` will need so they cannot craft a transaction with `gasLimit` hard-coded.  The assumption is that the gas payer/payee relationship is semi-trusted (they have extra-protocol mechanisms in place to protect against DoS attacks) and if not enough gas is supplied the only harm done to the `SENDER` is that their `nonce` is incremented.
+### `GAS_PAYER` `gasPrice`
+Allowing the gas payer to choose gas price means that the gas payer can take measures to ensure that the transaction is mined and is successful.  This allows for workflows where the `GAS_PAYER` is fully in charge of getting the transaction to land on-chain, such as utilizing replace-by-fee mechanics, setting gas price appropriately at time of submission, etc.
 ### Nonces
 The inner transaction needs a nonce to protect themselves from replay attacks.  Since the inner transaction has a nonce, we get replay protection on the outer transaction as well, so it is not critical for security to have multiple parties provide a nonce.
 
-We could have the `GAS_PAYER` provide a second nonce, but this would increase the payload size and require `GAS_PAYER` to do replace-by-fee (noisy for gossip) if they want to slip in a new (different inner) transaction with a higher gas price.  It would also create the possibility of a deadlock if the `SENDER` nonces aren't ordered the same as the `GAS_PAYER` nonces, and if the `SENDER` nonce isn't the lowest valid nonce for the `SENDER` then the `GAS_PAYER` can't sign and submit yet.
+We could have the `GAS_PAYER` provide a second nonce, but this would increase the payload size and require `GAS_PAYER` to do replace-by-fee (noisy for gossip) if they want to slip in a new (different inner) transaction with a higher gas price.  It would also create the possibility of a deadlock if the `SENDER` nonces aren't ordered the same as the `GAS_PAYER` nonces, and if the `SENDER` nonce isn't the lowest valid nonce for the `SENDER` then the `GAS_PAYER` can't sign and submit yet.  Finally, client complexity increases slightly if a transaction has two nonces because you have to protect yourself from deadlocks and do more work to determine validity.
 
 ## Backwards Compatibility
 Legacy transactions, both EIP-155 and not, would continue to function as normal.  Clients will need to implement support for the new trantsaction based on the number of RLP elements present in the transaction.