Automatically merged updates to draft EIP(s) 2718 (ethereum#2971)

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

@@ -35,7 +35,7 @@ As of `FORK_BLOCK_NUMBER`, the transaction root in the block header **MUST** be
 * `TransactionPayload` is an opaque byte array whose interpretation is dependent on the `TransactionType` and defined in future EIPs
 * `LegacyTransaction` is `rlp([nonce, gasPrice, gasLimit, to, value, data, v, r, s])`
 
-All signatures for future transaction types **MUST** include the `TransactionType` as the first byte of the signed data.
+All signatures for future transaction types **SHOULD** include the `TransactionType` as the first byte of the signed data.
 This makes it so we do not have to worry about signatures for one transaction type being used as signaturese for a different transaction type.
 
 ### Receipts
@@ -50,7 +50,12 @@ The `TransactionType` of the receipt **MUST** match the `TransactionType` of the
 
 ## Rationale
 ### TransactionType only goes up to 0x7f
-For the forseable future, 0x7f is plenty and it leaves open a number of options for extending the range such as using the high bit as a continuation bit.  This also prevents us from colliding with legacy transaction types, which always start with a byte `>= 0xc0`.
+For the forseable future, 0x7f is plenty and it leaves open a number of options for extending the range such as using the high bit as a continuation bit.
+This also prevents us from colliding with legacy transaction types, which always start with a byte `>= 0xc0`.
+### **SHOULD** instead of **MUST** for the TransactionType being first byte of signed data
+While it is strongly recommended that all future transactions sign the first byte to ensure that there is no problem with signature reuse, the authors acknowledge that this may not always make sense or be possible.
+One example where this isn't possible is wrapped legacy transactions that are signature compatible with the legacy signing scheme.
+Another potential situation is one where transactions don't have a signature in the traditional sense and instead have some other mechanism for determining validity.
 ### TransactionType selection algorithm
 There was discussion about defining the `TransactionType` identifier assignment/selection algorithm in this standard.
 While it would be nice to have a standardized mechanism for assignment, at the time of writing of this standard there is not a strong need for it so it was deemed out of scope.