Brief

EIP #168 allows for unused accounts to be reclaimed, freeing space in the state trie. However, these reclaimed accounts are now vulnerable to replay attacks. This is a proposal to ensure such accounts remain secure for reuse, against replay attacks, even after being reaped.

Description

Rather than having the account nonce begin at zero and increment, which is open to replay attacks if the nonce is reset during the lifetime of the account, instead it begins equal to the block number in which it is created.

We only increment the nonce at most once per block. This ensures that the range of nonce between resets is never repeated and thus avoids replay attacks, particularly on accounts which send more transactions than their lifetime measured in blocks.

Specification

Variant A

a. Newly created account entries get a nonce equal to the current block number.
b. Transactions do not result in the increment of the sender account by one.
c. At the end of the block, each account that sent at least one transaction has its nonce incremented by one.
d. A transaction of the same hash may not be included in the same block.

Variant B:

Exactly as Variant A with additional rules:

e. Transactions include an additional pre-signature field, ordering.
f. A transaction of ordering = O is only valid for inclusion in a block if either:

• O = 0; or
• there exists, in this block, at least one transaction of ordering = O - 1.

Variant C

a. Newly created account entries get a nonce equal to the current block number times MAX_TXS_PER_ACCT_PER_BLOCK.
b. Transactions can only be sent from a nonempty account.
c. If an account has nonzero nonce, then a transaction sent from it may be included in the current block iff:

• the transaction has the same nonce as the account nonce; and
• the nonce divided by MAX_TXS_PER_ACCT_PER_BLOCK is no greater than the current block number.
  The account nonce is incremented as normal if the transaction is included.

Example MAX_TXS_PER_ACCT_PER_BLOCK could be 64.

Critique

In general this mechanism leads to a fairly modest state trie increase of at most 3 bytes per account (which may be reducible through contextual compression) and around 4 bytes per transaction.

This mechanism, in the worst case, delivers a little more faff for transactors who make many transactions in a batch since any that are not included in the same block will necessarily need re-signing and re-submitting. This is mitigated by the fact that large batches are automated and relatively uncommon. Furthermore, large batch payments are better managed through a simple suiciding contract-creation transaction which guarantees they are all processed and largely moots the problem that they could be split with many transactions needing to be re-submitted.

Variant 2 exists to allow multiple transactions, possibly of equivalent content, to be included in the same block with a particular ordering. It would cost around an extra byte per transaction. If variant 2 were not adopted, similar functionality could alternatively be provided through a suiciding contract-creation transaction executing a batch.