|eip||title||author||discussions-to||status||type||category (*only required for Standard Track)||created||requires (*optional)||replaces (*optional)|
<to be assigned>
Martin Holst Swende (@holiman)
<Standards Track (Core, Networking, Interface, ERC) | Informational | Meta>
<Core | Networking | Interface | ERC>
<date created on, in ISO 8601 (yyyy-mm-dd) format>
This EIP proposes adding a 'temporal' replay protection to transactions, in the form of a
There are a couple of different motivators for introducing a timebased transaction validity.
- If any form of dust-account clearing is introduced, e.g. (https://github.com/ethereum/EIPs/issues/168), it will be necessary to introduce a replay protection, such as https://github.com/ethereum/EIPs/issues/169 . Having temporal replay protection removes the need to change nonce-behaviour in the state, since transactions would not be replayable at a later date than explicitly set by the user.
- In many cases, such as during ICOs, a lot of people want their transactions to either become included soon (within a couple of hours) or not at all. Currently, transactions are queued and may not execute for several days, at a cost for both the user (who ends up paying gas for a failing purchase) and the network, dealing with the large transaction queues.
- Node implementations have no commonly agreed metric for which transactions to keep, discard or propagate. Having a TTL on transactions would make it easier to remove stale transactions from the system.
- Add an optional field
valid-untilto the RLP-encoded transaction, defined as a
- If the field is present in transaction
tis only eligible for inclusion in a block if
valid-untilmandatory, and consider any transaction without
valid-untilto be invalid.
For the dust-account clearing usecase,
- This change is much less invasive in the consensus engine.
- No need to maintain a consensus-field of 'highest-known-nonce' or cap the number of transactions from a sender in a block.
- Only touches the transaction validation part of the consensus engine
- Other schemas which uses the
noncecan have unintended side-effects,
- such as inability to create contracts at certain addresses.
- more difficult to integrate with offline signers, since more elaborate nonce-schemes requires state access to determine.
- More intricate schemes like
highest-nonceare a lot more difficult, since highest-known-nonce will be a consensus-struct that is incremented and possibly reverted during transaction execution, requireing one more journalled field.
This EIP means that all software/hardware that creates transactions need to add timestamps to the transactions, or will otherwise be incapable of signing transactions after block
Copyright and related rights waived via CC0.