Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Dust account replay security #169
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.
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.
a. Newly created account entries get a nonce equal to the current block number.
Exactly as Variant A with additional rules:
e. Transactions include an additional pre-signature field,
a. Newly created account entries get a nonce equal to the current block number times
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.
I think there may be a simpler way to do this:
We could set
There may be another two ways:
The first way add nothing new to account/transaction, while the second adds ~2 bytes to account data.
Possible downside of this I see: fast sync after downloading the state trie would need to go over all accounts to find the current