Add Transaction Type List

[ricmoo]

Following up on a conversation from the typed-transaction, here is a first draft of a list of "Transaction Types" to include in the specifications, including version byte prefixes which are reserved, with motivation and historic context.

CC: @timbeiko @lightclient

[lightclient]

I'd like to move away from thinking of these as "transaction types" and more as "signatures prefixes". That's really what we're concerned with and why we want a list. We don't want non-txs (EIP-191, EIP-3074) to conflict with txs (legacy, EIP-1559, EIP-2930).

[ricmoo]

@lightclient committing your change closed the conversation; I was hoping to continue on that convo. :)

Do you have a change in filenames or titles you want made then? I’m pretty open. :)

[lightclient]

I was thinking something along these lines, mainly replacing "transaction type" with "signature type":

--- a/lists/transaction-types/README.md
+++ b/lists/transaction-types/README.md
@@ -1,51 +1,46 @@
-Transaction Type List
+Signature Types
 =====================

-This is a list of existing, reserved and tentative
-[EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) Transaction Types.
+This is a list of existing, reserved and tentative signature types.

-Transaction Types
+Signature Types
 -----------------

 See the sections below for additional notes on Version Bytes marked
 Reserved or Tentative.

-| Version Byte | Specs or Purpose |
+| Prefix byte | Specs or Purpose |
 |--------------|------------------|
 | 0x00  | Reserved: indicates legacy (untyped) trancactions |
-| 0x01  | [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) *(available in Berlin)* |
-| 0x02  | [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) *(available in London)* |
+| 0x01  | Reserved: [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) *(available in Berlin)* |
+| 0x02  | Reserved: [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) *(available in London)* |
 | 0x03  | Tentative: prevents collision with [EIP-3074](https://eips.ethereum.org/EIPS/eip-3074) |
 | 0x18  | Reserved: prevents collision with [EIP-191](https://eips.ethereum.org/EIPS/eip-191) |
-| 0x80 - 0xff  | Invalid; collides with the initial byte of valid RLP encoded transactions |
+| 0xc0 - 0xff  | Reserved; collides with the initial byte of valid RLP encoded legacy transactions |


-Reserved Transaction Types Motivation and History
+Reserved Signature Types Motivation and History
 -------------------------------------------------

-Reserved version bytes cannot be used as an [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718)
-TransactionType and should never be used as a typed transaction prefix.
-
-We disallow prefixing with reserved bytes to prevent encoded transactions from
-colliding with data that may otherwise be signed to prevent unintentionally
-authorizing unintended transactions.
-
+Reserved prefix bytes are currently in use and should never be reused. This
+avoids signature collisions that could have unintentional consequences, such as
+authorizing unintended actions.

 ### Type 0x00 (0)

-The TransactionType `0x00` is reserved to identify transactions which
-are untyped legacy transactions. It is not prefixed, but allows
-software to use a numeric enum value to indicate a legacy transaction.
+The prefix byte `0x00` is reserved to identify transactions which are untyped legacy
+transactions. It is not prefixed, but allows software to use a numeric enum
+value to indicate a legacy transaction.

-This was an unintentional consequence of the internal type of 0 being
-exposed in early JSON-RPC implementations, but is convenient as a
-canonical value to use within APIs or databases.
+This was an unintentional consequence of the internal type of 0 being exposed
+in early JSON-RPC implementations, but is convenient as a canonical value to
+use within APIs or databases.


 ### Type 0x19 (25)

-The TransactionType `0x19` is reserved to prefix data payloads to be
-signed according to [EIP-191](https://eips.ethereum.org/EIPS/eip-191).
+The prefix byte `0x19` is reserved for data payloads to be signed according to
+[EIP-191](https://eips.ethereum.org/EIPS/eip-191).

 The initial byte of `0x19` has long been used for the purpose of
 prefixing a series of bytes to be signed, rather than a transaction
@@ -61,15 +56,14 @@ allowing new types of data and structures to be safely signed with
 the same prefix byte.


-Tentative Transaction Types
+Tentative Signature Types
 ---------------------------

-Proposed TransactionTypes to reserve for upcoming purposes, but
-still subject to change.
+Proposed signature types to reserve for upcoming purposes, but still subject to
+change.


 ### Type 0x03 (3)

-The TransactionType `0x03` is reserved to prefix data payload operand
-to be signed for the [EIP-3074](https://eips.ethereum.org/EIPS/eip-3074)
-`AUTH` opcode.
+The prefix byte `0x03` is reserved for
+[EIP-3074](https://eips.ethereum.org/EIPS/eip-3074) `AUTH` payloads.

Signature type is consistent with RFC-4880, which is where I believe the 0x18 prefix in Bitcoin came from. The types denote the possible "meaning" of the signature. This is much less iron-clad than our signature types, as we are using them as a domain separator for safety. It still seems like an okay name to me, despite the difference. I welcome other suggestions though.

[MicahZoltu]

I think the actual collision range is much smaller. Legacy transactions are always a list, so that limits to [0xc0, 0xff]. Also, there is a shortest possible length legacy transaction which I think is a 0 ETH transfer to address 0 at 0 gas price from a constructed signature of 0 (which means from a random address). I suspect that in reality this is shorter than is practically possible, but it gives us a lower bound of cb for the leading byte:
0xcb8080825208808080808080

For the upper bound, we know that it is not possible in the real world to submit a transaction that is 2^56 bytes long, so at the least we can free up 0xff. I don't know what the last constraint on transaction length would be, but at the least we could use current gas cost per calldata byte times the current block gas limit and then multiply that result by something like 100 or 1000 to get a "reasonable" upper bound (which will probably free up several more version bytes off the end).

[ricmoo]

I was thinking the same, but the EIP seemed to imply that was the reason. I can update that 0xc0 - 0xff are invalid and 0x80 - 0xbf are “just reserved”.

I don’t think we should take practical size into account. Freeing up 0xff (and ilk) seems to provide very little gain.

[MicahZoltu]

At the very least I think we should only reserve 0xc0-0xff. I see no reason to mark 0x80-0xbf as reserved. I can appreciate the argument against freeing up the last few bytes, at least until we need them.

[ricmoo]

I was basing this mostly on the EIP-2718, "TransactionType is a positive unsigned 8-bit number between 0 and 0x7f that represents the type of the transcation". So, there should probably be some mention of 0x80-0xc0.

[MicahZoltu]

That constraint just limits 2718 transactions to 0-7f. It doesn't limit signature prefixes to that range. Maybe we can mention that in this document? 0x80-0xff can be used for non-2718 transactions?

[ricmoo]

Maybe mark 0x80-0xbf as "Preferred; as 0x00-0x7f are possible EIP-2718 transaction envelope types"?

[MicahZoltu]

Might be good to make it clear what they are "preferred" for?

[ricmoo]

I've made your changes, @lightclient as well as moved the list so the filename better reflects the title. :)

[lightclient]

One small nit, otherwise looks good to me!

[timbeiko]

@ricmoo any objections to merging this?

[lightclient]

I fixed the prefix issue.