Transaction deadline for chain inclusion

[karalabe]

Currently an Ethereum transaction has an infinite lifetime to be included in the chain. This has a few problematic corner cases:

• If a user signs and submits a transaction that is non-executable at that point in time (high nonce or low balance), the transaction may linger in some node in the network, and reappear at an arbitrary later point in time. This might cause unintended spending of funds, double payments, etc.
  • A typical scenario that appears every now and again is when a buggy script submits the same transaction multiple times. If the account has enough balance for all of them, it's just a painful error. If however account doesn't have enough balance, some nodes might still keep the non-executed transactions and resubmit them when the account receives funds, causing nasty surprises.
  • Similar scenarios may happen if users submit transactions with wrong nonces (offline wallets), where the only way to "stop" the transaction is to submit a noop one with higher gas price.
• In on-the-spot physical payments (e.g. buy a t-shirt during devcon), low priced transactions during high network traffic might take arbitrarily long to get included. The exchange cannot conclude until payment is confirmed due to replacement attacks, but currently it cannot be cancelled easily either due to the transaction linger + no guarantee that a replacement transaction will actually replace it.
• If dust account clearing gets implemented, that would require the network to remove all traces of the old accounts, including the old nonces. This makes every previously created transaction from said accounts all of a sudden re-executable given enough funds.

The proposal of this EIP is to extend the transactions with an additional block-to-live (BTL) field. Every transaction would become immediately invalid after the encoded block comes to pass. This solves the above scenarios in an elegant way:

• As long as users didn't sign transactions with insane BTL values, submitting bad transactions can be corrected simply by waiting for the deadline to pass.
• On the spot payments can specify that transactions should either succeed in N blocks, or fail altogether, giving reassurance both to the seller and buyer about the finality even in congested network conditions.
• If the BTL field becomes mandatory, all previous transactions become invalid, so very old dust account transactions cannot be replayed. New accounts should already use BTL meaningfully to prevent replays in the far future.

The caveat of this proposal is that reliably preventing dust account replays is to add the BTL as a hard requirement, but the ecosystem cannot do a hard switch-over from non-BTL transactions to BTL transactions at an instance, so this EIP might actually need two phases: one fork to enable BTL transactions and a second fork to disable non-BTL ones.

Discuss :)

[chriseth]

I assume the BTL field to represent an absolute block number. Is that correct?

Sounds very useful.

Perhaps this could be combined with an earlier proposal by @konradkonrad that (I think) specified the (optional) hash of a certain block to be a required ancestor block. This way we could force a transaction to be included only in a certain branch of the blockchain (and also A blockchain, i.e. it serves as a cross-chain-replay-protection) and only up to a certain point. Use-cases here are transactions that depend on each other or transactions that depend on a certain state.

[karalabe]

Seems to be a duplicate of #599, will close this to keep discussions at one place.

[karalabe]

@chriseth Btw, yes, absolute block number. Hash is a bit problematic because it requires chain lookups, which will get more and more expensive as the chain grows. Also validating a single transaction all of a sudden becomes a disk DoS vector.

[xinbenlv]

Hi @karalabe from 2022 hope you are doing well!
I started a new pull request EIP-#5081 to re-pursue the similar goal of #773 and #599. Feedback is very appreciated.