EIP1681 - Temporal Replay Protection

# Simple Summary

This EIP proposes adding a 'temporal' replay protection to transactions, in the form of a valid-until timestamp. This EIP is very similar to https://github.com/ethereum/EIPs/pull/599 by Nick Johnson and Konrad Feldmeier, the main difference being that this EIP is based on clock-time / walltime instead of block numbers.

# Motivation

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.

# Specification

The roll-out would be performed in two phases, X (hardfork), and Y (softfork).

At block X,

Add an optional field valid-until to the RLP-encoded transaction, defined as a uint64 (same as nonce).
If the field is present in transaction t, then
- t is only eligible for inclusion in a block if block.timestamp < t.valid-until.

At block Y,

Make valid-until mandatory, and consider any transaction without valid-until to be invalid.

# Rationale

# Rationale for this EIP

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 nonce can 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-nonce are a lot more difficult, since highest-known-nonce will be a consensus-struct that is incremented and possibly reverted during transaction execution, requiring one more journalled field.

# Rationale for walltime

Why use walltime instead of block numbers, as proposed in https://github.com/ethereum/EIPs/pull/599 ?

The UTC time is generally available in most settings, even on a computer which is offline. This means that even a setup where blockchain information is unavailable, the party signing a transaction can generate a transaction with the desired properties.
The correlation between time and block number is not fixed; even though a 14s blocktime is 'desired', this varies due to both network hashrate and difficulty bomb progression.
The block number is even more unreliable as a timestamp for testnets and private networks.
UTC time is more user-friendly, a user can more easily decide on reasonable end-date for a transaction, rather than a suitalbe number of valid blocks.

# Backwards Compatibility

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 Y. Note: this EIP does not introduce any maximum valid-until date, so it would still be possible to create transactions with near infinite validity.

# Test Cases

todo

# Implementation

None yet

# Security considerations

The most notable security impact is that pre-signed transactions stored on paper backups, will become invalid as of block Y. There are a couple of cases where this might be used

Pregenerated onetime 'bootstrap' transactions, e.g. to onboard a user into Ethereum. Instead of giving a user a giftcard with actual ether on it, someone may instead give the person a one-time pregenerated transaction that will only send those ether to the card once the user actively wants to start using it.
If a user has an offline paper-wallet, he may have pregenerated transactions to send value to e.g. an exchange. This is sometimes done to be able to send ether to an exchange without having to go through all the hoops of bringing the paper wallet back to 'life'.

Secondary security impacts are that the addition of a timestamp would make the transactions a little bit larger.