core/types: add MarshalBinary, UnmarshalBinary for Receipt

[i-norden]

These are analogous to the methods of the same name on the Transaction type. I think it is helpful to include methods for serializing/deserializing an individual Receipt to/from the expected consensus encoding whether it is a legacy or a 2718/2930 type receipt, since Encode/DecodeRLP no longer does this for 2718/2930 receipts. Also added to the comments to help clarify the subtle difference in output between these serialization methods.

[fjl]

The idea is pretty nice. Not sure if I like the verbosity in comments, especially for Transaction.

[i-norden]

Would you prefer I remove the comment changes? It was not immediately clear why my receipt and transaction encodings (using EncodeRLP) were suddenly breaking from consensus. Having to wrap a Receipt into a Receipts type and use EncodeIndex seems clunky to me.

Some of confusion around the EncodeRLP stemmed from the wording of EIP 2718.

The EncodeRLP method for an EIP-2718 tx is outputting rlp(TransactionType || TransactionPayload).

This makes sense from the definition of Transaction in EIP-2718:

"Transaction is either TransactionType || TransactionPayload or LegacyTransaction"

So the RLP encoding of Transaction is either rlp(TransactionType || TransactionPayload) or rlp(LegacyTransaction).

But EIP-2718 also states

"LegacyTransaction is rlp([nonce, gasPrice, gasLimit, to, value, data, v, r, s])"

So strictly following the same logic that is being used for a 2718 Transaction would suggest the output of EncodeRLP for a legacy Transaction should now be rlp(rlp([nonce, gasPrice, gasLimit, to, value, data, v, r, s])).

[fjl]

@i-norden During the process of adding typed transactions, everyone got very confused about RLP, and there were very long pointless debates about the exact notation that would express the intent correctly. Looks like they got it wrong in the end.

In practice it is really simple: legacy transactions are encoded exactly the same they always were, as an RLP list.
In RLP context, non-legacy transactions are encoded as RLP byte arrays.

Having to wrap a Receipt into a Receipts type and use EncodeIndex seems clunky to me.

You shouldn't do this anyway, the documentation of DerivableList says: "This is internal, do not use these methods.".
I think your change to add MarshalBinary and the inverse is great, but let's not add the confusing notation in comments.
It is sufficient to say that MarshalBinary returns the consensus encoding of a receipt.

[i-norden]

That makes sense @fjl, thanks! I'll look into opening a PR against the EIP doc to clarify things. I rolled back the verbose comments.

[fjl]

We can merge this after EIP-1559 is in.

[fjl]

EIP-1559 (tx type 2) has landed, so this needs a rebase.

[i-norden]

@fjl done, apologies for the delay!