2718: Adds receipt handling to specification.

EIPS/eip-2718.md

@@ -22,16 +22,27 @@ In the past, when we have wanted to add new transaction types we have had to ens
 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
+### Transactions
 As of `FORK_BLOCK_NUMBER`, `rlp([nonce, gasPrice, gasLimit, to, value, data, v, r, s])` (legacy transaction) will no longer be a valid Ethereum transaction over the devp2p protocol or in a block.
 
 As of `FORK_BLOCK_NUMBER`, all transactions sent over devp2p or included in a block **MUST** be of the form `rlp([TransactionType, Payload])` where `TransactionType` is a number that represents the type of the transcation and `Payload` is an opaque value (byte array) whose interpretation is dependent on the `TransactionType`.  Transactions **SHOULD** include the `TransactionType` in any signatures they include to minimize the chance of unintentional replay attacks between different transaction types.  The transaction hash of all transactions **MUST** be `keccak256(rlp([TransactionType, Payload]))`
 
 As of `FORK_BLOCK_NUMBER`, `rlp([0, rlp([nonce, gasPrice, gasLimit, to, value, data, v, r, s])])` will be a valid transaction where the `Payload` will be signed/processed/handled exactly the same as legacy transactions were processed/handled.
 
+### Receipts
+As of `FORK_BLOCK_NUMBER`, `rlp([status, cumulativeGasUsed, logsBloom, logs])` (legacy receipt) will no longer be a valid Ethereum transaction receipt over the devp2p protocol or in a block.
+
+As of `FORK_BLOCK_NUMBER`, all receipts sent over devp2p or included in a block **MUST** be of the form `rlp([TransactionType, Payload])` where `TransactionType` is a number that represents the type of the transaction and `Payload` is an opaque value (byte array) whose interpretation is dependent on the `TransactionType`.
+
+As of `FORK_BLOCK_NUMBER`, `rlp([0, rlp([status, cumulativeGasUsed, logsBloom, logs])])` will be a valid receipt where the `Payload` will be processed/handled exactly the same as legacy receipts were processed/handled.
+
+### Fork Block Transition
 Between `FORK_BLOCK_NUMBER - 1` and `FORK_BLOCK_NUMBER` clients **SHOULD** wrap all transactions in their local pending pool as type 0 transactions.  Clients **MAY** choose to flush their pending pool instead, if it is not possible to do the wrapping in time for the next block, though this is discouraged.
 
 As of `FORK_BLOCK_NUMBER`, clients **SHOULD** accept incoming transactions over user/application facing APIs such as JSON-RPC in both the new wrapped format and the legacy format.  If a legacy format transaction is received, the client **MUST** wrap it in a type 0 envelope before sending it over devp2p or including it in a block.
 
+As of `FORK_BLOCK_NUMBER`, clients **SHOULD** return type 0 receipts over user/application facing APIs such as JSON-RPC in the legacy format.  Clients **SHOULD** devise a long term strategy for deprecating the legacy format over APIs in favor of the typed receipt envelope format.
+
 ## 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.