How do fees affect tx priority and how did these specific high fee tx's sit unconfirmed for > 1hr

Question

Can anyone explain to me why several high fee (0.1-0.15) RingCT tx's, that did not look abnormal, sat in the mempool for over an hour unconfirmed, while lower fee (.025 ish) similar looking RingCT tx's got processed in front of them and 5 empty blocks were mined?

Unless I am missing something, this seems highly irratonal as far as miners are concerned, and suboptimal in terms of how the network is performing. It was my understanding that that there was such thing as 'fee priority', but in this instance that does not appear to be the case / is not working as it should.

The tx's concerned were eventually mined in blocks 1226464 and 1226465, and the first 3 characters of the ones i was watching were 230, 2ac, d76 and 56c. The latter was mined in 1226465 and had a fee of 0.15 for a size of 14kb, the others in 1226464 with a fee of 0.1 and sizes of 13kb. Input/output were 2/2,9/2,3/2 and 6/2 respectively.

http://blox.supportxmr.com/block/1226464

http://blox.supportxmr.com/block/1226465

https://i.stack.imgur.com/hUVC8.jpg - mempool screenshot

Looking forward to an explanation that will deepen my understanding of how the network functions

Thanks

Answer 1

I asked the same question over on reddit, and although I did not get to the bottom of why these particular txs sat there so long, I did learn several things which may be helpful/interesting for others...

As mentioned by samwellj above and nanoakron on reddit, the PR to prioritise txs by age has only just been merged, so unless all miners have already updated or are using custom software, it is likely that it is not in full effect yet (and was not at the time of these txs), but it is on its way. Nice work, I look forward to seeing it fully implemented in due course.

That answers one aspect of the question - why 'time in mempool' was not a factor in tx processing.

The second aspect regarding fees is a bit murkier. Monero has had a 'prioritise by fee' algorithm for a while now and it functions on a fee per byte basis (thanks smooth for your patience on that one). Currently there are 3 presets in the GUI/CLI to prioritise txs using a fee multiplier of 1x, 20x and 166x. The reasons for the 'super multiplier' of 166 is to pay a fee high enough at times of high load to compensate /incentivise miners to take a block reward penalty and increase the block size above the permitted % over the median, thus allowing the block size to increase faster if people are prepared to pay for it, and allowing any backlog to clear quicker. Very cool.

No firm answer on why these tx's did not get prioritised by fee, and it looks like we are not going to get one, but hey, I learnt plenty along the way and I hope this information is useful to others too.

One question that is raised for me now is how do the 'prioritise by time' and 'prioritise by fee' algorithms interact with each other. Do fees trump time, or is there something more complex at play?

Obviously tx prioritisation has only really come into focus since the HF due to the larger size of RingCT txs and the more frequent though relatively small mempool backlogs. I imagine we have not yet arrived at a final destination here (will we ever!), and that things will be optimised as the system is observed.