feat(SpokePool): Permit historical fillDeadline on deposit

[pxrl]

This removes a sharp edge for pre-fill deposits, where the deposit comes after the fill. Permitting a historical fillDeadline gives more flexibility to the relayer around when they submit the deposit on the origin chain.

[mrice32]

LGTM! I second @nicholaspai's question.

[bmzig]

Just to be clear here, we are not going to allow fillDeadlines of 0. I would vote for this, since it would give more information to the dataworker over a fill deadline of 0, but am not necessarily opposed to it if we think it would really help relayers.

[nicholaspai]

I think there are some important considerations where the deposit is sent with a very low fill deadline: https://github.com/across-protocol/contracts/pull/870/files#r1926100789

Gonna write my thoughts here to explain my thinking:

• here we create an expiry refund for any deposit that falls in the current block range and who's fillDeadline is less than the current bundle end timestamp
• here we create any refunds for deposits that are newly expired in a bundle. This means that the expiry falls between the bundle start and end timestamps on the origin chain.

I think this means that there is no way someone could get refunded twice for a deposit expiry, right? It's trivial to set a fillDeadline low enough to get refunded in the current bundle, but there is no follow up bundle where that deposit will "newly" expire and a duplicate refund will get sent.

I just want someone to confirm my understanding here before I approve again

[mrice32]

I think this means that there is no way someone could get refunded twice for a deposit expiry, right? It's trivial to set a fillDeadline low enough to get refunded in the current bundle, but there is no follow up bundle where that deposit will "newly" expire and a duplicate refund will get sent.

I agree with your logic. (deposit ∈ { this block range } AND expiry ∈ { this block range, past block range }) OR (deposit ∈ { this block range, past block range } AND expiry ∈ { this block range }).

Each of these OR'd conditions requires one of these things (deposit or expiry) to be in the current block range, while the other could be at any past block range. This condenses down to exactly one block range where a refund can happen, which is the latest block range that at least one of them falls in.