'Valid until block' field for transactions

[Arachnid]

This EIP adds a new field to transactions, valid_until_block. Transactions containing this field may only be included in blocks with numbers less than or equal to the value in this field. This improves the transaction eviction strategies available to nodes, which improves spam handling, while also making it possible for users to issue transactions that expire if not included by a certain time.

[axic]

I think it may make sense coordinating this with #232.

[Arachnid]

Agreed.

[Gustav-Simonsson]

👍

Also useful for many types of DAPPs during congestion, including those who interface with Ethereum in the background where txs are (mostly) abstracted from the user.

Can also be very useful for wallets, e.g. enabling easier sending of txs at low gasPrice. For example if a user indicates their tx is not urgent the wallet can prepare & sign several txs with increasing gasPrice and set valid_until_block to e.g. 20. Then in the background try one tx in turn until one is mined.

[nicksavers]

There would need to be a discovery mechanism to figure out what nodes find the most excessively high setting in order for them to refuse to relay it.

On the other hand it adds a new economic value to the protocol: TTL, which could perhaps also be translated into a gas cost per block.

For example for a the validity duration of 1 block you pay 3 gas * words (keeping size of the transaction in memory into a account). So if you send it to a node at block 2000 and your valid_until_block is 2500, you pay 500 * 3 * words otherwise there is no guarantee it is propagated.

However, since the block height during relay can't be measured after it's mined, this would make it difficult to validate the calculate the correct gas price and validate the transaction.

One way would be to reduce the gas cost down to the block it's included. So if it's included in block 2300, you only pay 200 * 3 * words, which might give miners an incentive to increase the gasLimit to empty the pool temporarily.

Another would be to also include a valid_from_block. Which would keep it simple and that way you know exactly what you will be paying.

[Arachnid]

There would need to be a discovery mechanism to figure out what nodes find the most excessively high setting in order for them to refuse to relay it.

Why? Can't each node just decide on its own threshold?

[karalabe]

Ok, this issue came up in relation with dust accounts too. I didn't find this PR so I created a new issue #773, but I'll just close that and copy-paste my text from there to expand on this EIP with the dust account aspects:

---

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 :)

[karalabe]

@nicksavers @Arachnid I would drop the clauses with the txpool filtering stuff. Currently we have IMHO a performant enough pool to keep thousands of active transactions and filter based on price. There's no particular value in filtering based in TTL.

[pirapira]

I would guess a missing valid_until_block means a nine-element transaction without the new valid_until_block element. That would be the backward compatible behavior. Read on and convinced that the default behavior should be some valid_until_block.

[pirapira]

Take 599, and please move this file to EIPS/eip-599.md.

[beether]

Is there any reason this couldn't also include valid_after_block ?

[nicksavers]

@beether You could just withhold that transaction until after the block.

[kevinsimper]

I find this issue really interesting as it will help beginners make fewer mistakes times when the network is high load. The fact that a transaction can linger for more than 24 hours is not easy to understand or manage.

Some transaction could even have a max time for 10 minutes so that you know it will be included or not, and if not, you can react accordingly.

@karalabe Did you look at this more?

[kevinsimper]

What is missing from this? Is there something that can be done to move this forward? 😄

[nicksavers]

@kevinsimper It still requires a discussions-to URL before it can be merged as Draft

[kevinsimper]

@nicksavers I created a discussion, will post it as soon as my post has been approved https://ethereum-magicians.org/

[kevinsimper]

@nicksavers Can you update the discussion url to https://ethereum-magicians.org/t/eip-599-valid-until-block-field-for-transactions/3440 ? 😄

[github-actions]

There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[carver]

Whoever has permissions to edit, can you add https://ethereum-magicians.org/t/eip-599-valid-until-block-field-for-transactions/3440 as the discussion url, so it can be merged as a draft?

[MicahZoltu]

This EIP is bundled up in 2711. Consider pursuing that one instead.

[github-actions]

There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.

[kevinsimper]

@MicahZoltu I read it but the functionality to be sure that a transaction is not valid anymore was not clear to me. Do you have more information or what section should I focus on? :)

[MicahZoltu]

I read it but the functionality to be sure that a transaction is not valid anymore was not clear to me. Do you have more information or what section should I focus on? :)

This is one of the reasons that 2711 is struggling to gain traction. There are potential DoS vectors for expiring transactions. I recommend continuing this conversation over at the 2711 discussions-to URL, or creating a new 2718 based EIP that only introduces expiring transactions.

[xinbenlv]

Hello from 2022
Looking at this proposal from 2022 and its relevant proposals

• Creates EIP-2711: Separate gas payer from msg.sender #2711, it's withdrawn, and
• Creates EIP-2718: Typed Transaction Envelope #2718 diverted from the purpose of expiring transactions.
• add temporal replay protection #1681 stagnant and I don't think there is a reliable way to use clock/ timestamp

Is anyone still looking at a way to ensure block-number expiration?

@Arachnid @kevinsimper, @MicahZoltu would consider revive this proposal? If you are not at capacity, I am interested in following up on this. Because I think the possibility to protect against replay attack on a signed message is as critical as what #155 was trying to do, if not even more critical.

[xinbenlv]

Just wanna bump this request to authors because this is such an important and critical issue. Without a fix, one needs a more gas fee tx to "cancel" on-chain. e.g.

Hello from 2022 Looking at this proposal from 2022 and its relevant proposals

• Creates EIP-2711: Separate gas payer from msg.sender #2711, it's withdrawn, and
• Creates EIP-2718: Typed Transaction Envelope #2718 diverted from the purpose of expiring transactions.
• add temporal replay protection #1681 stagnant and I don't think there is a reliable way to use clock/ timestamp

Is anyone still looking at a way to ensure block-number expiration?

@Arachnid @kevinsimper, @MicahZoltu would consider revive this proposal? If you are not at capacity, I am interested in following up on this. Because I think the possibility to protect against replay attack on a signed message is as critical as what #155 was trying to do, if not even more critical.

[xinbenlv]

I emailed @Arachnid and received response:

I'd be very happy for you to take it over if you're interested. And I'm happy to answer any questions you have.

In that case, I personally happy to step up and take over if no other former authors have bandwidth to drive forward.

[MicahZoltu]

The big problem is the denial of service attack vector that expiring transactions opens up. We want to ensure that any transaction that is gossiped over the network must cost something significant to the signer.

One way you could achieve this and still have expiring transactions is to have a new transaction type that includes an expiration, but the transaction is still includable after the expiration. If the transaction is included after the expiration, then it would just cost 21,000 gas (maybe a bit less), bump the nonce, but otherwise do nothing. This would at least make it so expired transactions were relatively inexpensive for users, but it wouldn't open up denial of service attack vectors.

[MicahZoltu]

@xinbenlv If you want to pursue something like this, just create a new EIP. You can copy/paste this one (except the number) as a way to bootstrap the process, but you'll want to make sure your EIP follows the latest EIP template.

[xinbenlv]

The big problem is the denial of service attack vector that expiring transactions opens up. We want to ensure that any transaction that is gossiped over the network must cost something significant to the signer.

One way you could achieve this and still have expiring transactions is to have a new transaction type that includes an expiration, but the transaction is still includable after the expiration. If the transaction is included after the expiration, then it would just cost 21,000 gas (maybe a bit less), bump the nonce, but otherwise do nothing. This would at least make it so expired transactions were relatively inexpensive for users, but it wouldn't open up denial of service attack vectors.

That's very helpful insight of a potential security challenge. Thank you @MicahZoltu

[xinbenlv]

Original author: @Arachnid @kevinsimper and editor @MicahZoltu thank you for suggestion,

FYI I have started a #5081 to pursue this EIP.