Automatically merged updates to draft EIP(s) 2718 (#2742)

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-2718.md

@@ -41,7 +41,7 @@ We could have chosen the format `rlp([TransactionType, ...])` where `...` repres
 There was discussion about having ORIGIN and CALLER opcodes be dependent on the transaction type, so that each transaction type could define what those opcodes returned.  However, there is a desire to make transaction type opaque to the contracts to discourage contracts treating different different types of transactions differently and there also were concerns over backward compatibility with existing contracts which make assumptions about ORIGIN and CALLER opcodes.  Going forward, we will assume that all transaction types will have an address that reasonably represents a `CALLER` of the first EVM frame and `ORIGIN` will be the same address in all cases.  If a transaction type needs to supply additional information to contracts, they will need a new opcode.
 
 ## Backwards Compatibility
-Clients can differentiate between the transaction types by noting that the RLP decoded transaction has 2 elements rather than 9 or by noting that the second element is a list rather than a value.
+Clients can differentiate between the transaction types by noting that the RLP decoded transaction has 2 elements rather than 9.
 
 ## Test Cases
 TBD
@@ -50,7 +50,7 @@ TBD
 TBD
 
 ## Security Considerations
-Due to the way RLP encoding works, the risk of a new transaction being mis-interpreted as a legacy transaction is deemed low.  The authors of this EIP consider it unlikely that there are any transaction decoders in production that will accept a transaction with not enough elements (perhaps reading off the end of the array), or read the second item as a value when it is encoded as an array.
+Due to the way RLP encoding works, the risk of a new transaction being mis-interpreted as a legacy transaction is deemed low.  The authors of this EIP consider it unlikely that there are any transaction decoders in production that will accept a transaction with not enough elements (perhaps reading off the end of the array).
 
 ## Copyright
 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).