Arbitrium sequencer fail could lead to relayers' payouts being unfairly split

[hats-bug-reporter]

Github username: @PlamenTSV
Twitter username: @p_tsanev
Submission hash (on-chain): 0x16f1442e6dfc61f70c14d7085c019803561fc459b9b959b304efe17a796d21b8
Severity: low

Description:
Description
As the described by the arb docs: https://docs.arbitrum.io/for-devs/concepts/differences-between-arbitrum-ethereum/block-numbers-and-time#block-timestamps-arbitrum-vs-ethereum
block timestamps can be varying, depending on the sequencer and if a transaction is force-included, basing it on the larger timestamp.
The only sensitive calculation derived directly from block.timestamp is the distribution of source and destination relayer rewards.

Attack Scenario
In case of a force-included block having a largely varying timestamp or if the sequencer adjusts 1 hour into the future (to prevent re-orgs), the calculation executionTime = uint64(block.timestamp) - uint64(bytes8(message[CTX1_EXECUTION_TIME_START:CTX1_EXECUTION_TIME_END])) which determines the destination and source fee distribution could be unfairly altered, unbenounced to the relayer.
An unfair advantage could be created for either of the 2 relayers and a disadvantage for the other one.

Attachments

1. Proof of Concept (PoC) File

2. Revised Code File (Optional)

I cannot really determine a potential fix to avoid this, I guess arbitrium has to be cauciously used. The calculation could be rewritten to use block numbers, but they too can deem unexpected values due to the nature of their generation.
Likelihood is low/med depending on the sequencer and the impact is low/med due to the potential unfairness generated.
So LOW severity.

[reednaa]

Thanks for the submit. I don't know how to respond to this. We will determine severity internally. Options: no / low.

[reednaa]

We have decided to classify this issue as won’t fix. Our decision is based on the following arguments:

• There is no fix or solution, this is an inherit property of Arbitrium.
• While the case is "undocumented", there is a very low impact. We also cannot contain every single chain edge case which only happens to annoy relayers. (Application's wouldn't care and this isn't an audit of a relayer)
• Relayers can protect themselves to acking quickly back to arbitrum (which they are encouraged to in case targetDelta != 0)

According to these arguments, the issue cannot be classified as low and is instead classified as won’t fix. We thank you for submitting the issue and will create an issue on our repo describing your findings but the issue itself is unfixable and would generally not be notisable even to explorative developers.