Benefit of overpaying fees

Question

It is possible to specify an overpayment of network fees. For example, on the test network I paid 999 stroops instead of 100 for a single operation.

Does this benefit the sender under any circumstances?

Answer 1

I've asked a similar question on Slack a few months ago. After digging in the Stellar Core sources, I figured out that the fee is considered when Core decides what transactions to include into the next ledger.

It seems to me that the only situation when supplying larger fees may be handy is a period of loading spikes, when users submitted more than 50 transactions since the last ledger. In this case transactions with higher fees have preference.

Jed specifically mentioned that fee does not affect the order in which transactions are applied within the ledger, as they are applied in random (actually, pseudo-random) order. So, for example, larger fees do not prioritize trading operations, preventing Low Latency HFT manipulations.

EDIT
(Detailed explanation of the tx randomization process)

From /src/ledger/readme.md:

First the transaction set is reordered in apply order: during consensus, the transaction set was sorted by hash to keep things simple, but when it comes to actually applying them, they need to be sorted such that transactions for a given account are applied in sequence number order and also randomized enough so that it becomes unfeasible to submit a transaction and guarantee that it will be executed before or after another transaction in the set. See TxSetFrame::sortForApply for more detail.

Therefore once the SCP quorum agreed on what transactions are ready for the application in the current frame, all transactions are first ordered by the sequence numbers (to prevent applying transactions in the wrong order), and then randomized based of the seed derived from the hash of the particular transaction XORed with the hash of the entire tx set (see ApplyTxSorter).

One can predict the transactions application order only if she knows in advance the contents (or at least hashes) of all submitted transactions. While it is theoretically possible to monitor all transactions (in the simplest case the attacker may submit all transactions by himself), the information is effectively useless, as any new transaction submitted after the transactions frame was assembled, will be included into the next ledger. However, the tx application order and current ledger state will be publicly available only a few seconds later anyway, so the attacker has no competitive advantage in this case.