Removes support for legacy transactions.

EIPS/eip-2718.md

@@ -14,21 +14,29 @@ requires (*optional): 155
 Defines a new transaction type that is an envelope for future transaction types.
 
 ## Abstract
-As of `FORK_BLOCK_NUMBER`, `rlp([TransactionType, [...])` will be a valid transaction where `TransactionType` is a number identifying the format of the transaction and `[...]` is the transaction, whose definition is defined in future EIPs.  The first new transaction will be just a wrapped legacy transaction with the format `rlp([0, [nonce, gasPrice, gasLimit, to, value, data, senderV, senderR, senderS]])`.
+As of `FORK_BLOCK_NUMBER`, `rlp([TransactionType, payload])` will be a valid transaction where `TransactionType` is a number identifying the format of the transaction and `payload` is the transaction, whose definition is defined in future EIPs.  The first new transaction type will be just a wrapped legacy transaction with the format `rlp([0, rlp([nonce, gasPrice, gasLimit, to, value, data, senderV, senderR, senderS])])`.
 
 ## Motivation
 In the past, when we have wanted to add new transaction types we have had to ensure they were backward compatible with all other transactions, meaning that you could differentiate them based only on the encoded payload, and it was not possible to have a transaction that matched both types.  This was seen in [EIP-155](./eip-155.md) where the new value was bit-packed into one of the encoded fields.  There are multiple proposals in discussion that define new transaction types such as one that allows EOA accounts to execute code directly within their context, one that enables someone besides `msg.sender` to pay for gas, and proposals related to layer 0 multi-sig transactions.  These all need to be defined in a way that is mutually compatible, which quickly becomes burdensome to EIP authors and to clients who now have to follow complex rules for differentiating transaction type.
 
 By introducing an envolope transaction type, we only need to ensure backward compatibility with existing transactions and from then on we just need to solve the much simpler problem of ensuring there is no numbering conflict between `TransactionType`s.
 
 ## Specification
-As of `FORK_BLOCK_NUMBER`, `rlp([nonce, gasPrice, gasLimit, to, value, data, senderV, senderR, senderS])` will continue to be a valid transaction as defined in EIP-155.  As of `FORK_BLOCK_NUMBER`, `rlp([0, [nonce, gasPrice, gasLimit, to, value, data, senderV, senderR, senderS]])` will be functionally equivalent where the second item of the outer array will be handled exactly the same as an EIP-155 transaction is handled.
+As of `FORK_BLOCK_NUMBER`, `rlp([nonce, gasPrice, gasLimit, to, value, data, senderV, senderR, senderS])` will no longer be a valid Ethereum transaction over the devp2p protocol.
+
+As of `FORK_BLOCK_NUMBER`, `rlp([0, rlp([nonce, gasPrice, gasLimit, to, value, data, senderV, senderR, senderS])])` will be a valid transaction over the devp2p protocol where the second item of the outer array will be processed/handled exactly the same as a pre `FORK_BLOCK_NUMBER` transaction was processed/handled.
+
+Future EIPs **MAY** define new transaction types by choosing an unused `TransactionType` number.  This number will be the first item of the RLP encoded array.  The second item of the RLP encoded array will be interpreted based on the EIP that defines the new transaction type.
 
 ## Rationale
 ### TransactionType high bit
 Setting the high bit of the `TransactionType` so that a decoder could identify transaction type early on in the decoding process was discussed, but decided against.  The problem with this solution is that due to the way RLP encoding works, this would result in the `TransactionType` being 5 bytes long rather than 1 byte long.  RLP decoders also do not need to know the shape of the result before decoding, and thus in most (possibly all) clients it will be just be a matter of first decoding the RLP transaction, and then checking to see if the decoded result is a 2 item array or a 9 item array, which is likely simpler than checking the high bit of the first item.
 ### 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.  A future EIP may introduce a standard for TransactionType identifier assignment if it is deemed necessary.
+### Opaque second item rather than an array
+By having the second item of the array just be opaque bytes, rather than a list, we can support different encoding formats for the transaction payload in the future, such as SSZ or a fixed width format.
+### `n`-item list instead of 2-item list
+We could have chosen the format `rlp([TransactionType, ...])` where `...` represents whatever items the transaction wants.  This format however would require us to remain vigilant in the future about using the shape of the transaction to identify its type, as it is possible that there could be an overlap between an EIP-2718 transaction type and a legacy transaction type with a nonce that matches the `TransactionType`.  By having a strict 2-item array with the second item potentially being an encoded list, we avoid needing to worry about any conflict between TransactionTypes beyond choosing uinque numbers.
 
 ## 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.