Reentrancy in sendMessage by a miner

The toll will be sent to the miner, but a miner that is block.coinbase can be a contract address.

The concern was raised that if a malicious miner were to reenter the sendMessage emitting the MessageSent event, it could potentially exploit a reentrancy vulnerability in the sendMessage function, leading to out-of-order event processing.

For example, if the expected event sequence is 1, 2, 3, 4, 5, 6, a reentrancy attack could result in an event queue like 1, 3, 2, 4, 5, 6, disrupting the intended sequential order.

The warp.green team provided the following response:

We considered this vector during the design phase. For applications that require strict sequential processing of messages, we recommend including a sequence number within the message payload itself. It's important to note that Ethereum nonces are incremental primarily for convenience. If you examine the messages from XCH, you'll notice that the nonces are non-sequential. As long as the nonces are unique for a given chain, the system will function correctly.