Transaction prioritization

[hackaugusto]

Abstract

Expirable transactions must have a higher priority then other transactions.

Motivation

The Transactions that update transfer and register a secret on-chain can expire, meaning that after a given block height these transactions will be rejected by the smart contract (either because the settlement window was over or the lock expired). To increase the likelihood of mining these transactions, they should be prioritized.

Specification

The prioritization should not be part of the core logic, because it will require some sort of policy to order the transactions, one possible policy is to order transactions based on the token value, which would require updating the token's value to some price oracle.

Backwards Compatibility

• This doesn't change the off-chain protocol, so there is no backwards/forwards compatibility there.
• This will require changes to the ContractSend events, which will require upgrade transactions.

Related

Cancel in-flight transactions #2801

[LefterisJP]

Prioritizing would be only in the order at which we send them to the ethereum client? Or also to increase gas price for the prioritized transactions?

[hackaugusto]

Prioritizing would be only in the order at which we send them to the ethereum client? Or also to increase gas price for the prioritized transactions?

IMO It doesn't make sense to do something which doesn't increase the gas price.

To have the option of not increasing the gas price we must have a queue of transactions which have not been sent. To have a queue of such transactions we would have to intentionally delay some, and this would include high priority transactions, which is the opposite of what I'm arguing for in this issue.

[LefterisJP]

IMO It doesn't make sense to do something which doesn't increase the gas price.

These are two different ways to prioritize transactions. I am fine with both -- just wanted to know what form of prioritization your were thinking about.

To have a queue of such transactions we would have to intentionally delay some, and this would include high priority transactions, which is the opposite of what I'm arguing for in this issue.

Perhaps I misunderstand but isn't this yet another way of prioritizing. Have a queue of all transactions that are going to be sent to the node and send them in a particular order depending on some rules? High priority transactions would be at the top of the queue.

[hackaugusto]

Have a queue of all transactions that are going to be sent to the node and send them in a particular order depending on some rules?

Yes, I understand, but I don't think this approach makes sense.

For this to work, we must have a queue of not sent transactions (if the transaction is sent we need to play with the gasprice). If the transactions are not sent, it means they are in the queue waiting. If they are in the queue waiting, it means the latency will increase (by at least confirmation blocks, otherwise what would we wait for?). The high priority transaction we have are time sensitive, that's what define them as high priority. If we are trying to increase the likelihood of it being mined in time, we should not introduce a queue which increases latency.

IOW, I don't think that having only prioritization without playing with the gas price is useful. It can be useful if we use it in addition to the prioritization with the gas price (It wouldn't make sense to send 20 transaction at the same time and rewrite them all).

[LefterisJP]

It can be useful if we use it in addition to the prioritization with the gas price (It wouldn't make sense to send 20 transaction at the same time and rewrite them all).

Yes this is what I meant. But this is probably also quite more complicated than simply playing with the gas price.