Closed karalabe closed 6 years ago
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.
Seems to be a duplicate of https://github.com/ethereum/EIPs/pull/599, will close this to keep discussions at one place.
@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.
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.
Currently an Ethereum transaction has an infinite lifetime to be included in the chain. This has a few problematic corner cases:
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:BTL
values, submitting bad transactions can be corrected simply by waiting for the deadline to pass.BTL
field becomes mandatory, all previous transactions become invalid, so very old dust account transactions cannot be replayed. New accounts should already useBTL
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 toBTL
transactions at an instance, so this EIP might actually need two phases: one fork to enableBTL
transactions and a second fork to disable non-BTL
ones.Discuss :)