This PR improves on the method introduced in #5354 for detecting prioritized transactions in mined blocks.

Background

That naive algorithm assumed that transactions would only ever have their priority increased out-of-band, and so simply iterated over the set of transactions and marked anything positioned higher than expected as "prioritized".

However, if any transactions in the block had actually been deprioritized, this approach could produce (potentially very many) false positives.

For example, Ocean block 856119 includes several small inscriptions, which Ocean's default template deprioritizes by applying a datacarriercost penalty. The previous algorithm interpreted the large number of subsequent "normal" transactions as prioritized, since they had lower apparent fee rates than the later inscriptions:

Solution

The new algorithm implemented in this PR broadens the assumptions to allow for deprioritization, and efficiently figures out the most likely sets of prioritizations and deprioritizations to explain the composition of the block.

The precise details are a little complicated, but essentially the algorithm involves computing the Longest Increasing Subsequence of transactions in the block, which represents the most likely set of "normal" transactions without any out-of-band fee adjustments. Any other transactions falling outside of that set have probably been prioritized or penalized, depending whether they appear higher or lower than expected based on their simple in-band effective fee rates.

here, the dark blue transactions represent deprioritized inscriptions in the same Ocean block (see the "Other changes" section below)

Effects

In practice, the new algorithm produces exactly the same results as the old one for the 99%+ blocks constructed using default Bitcoin Core settings.

But for the occasional block constructed with, e.g, datacarriercost penalties, it very effectively mitigates the false positive issue.

Other changes

The new algorithm is capable of efficiently detecting both prioritized and deprioritized transactions, and only requires the block summary data which is already available on the block page.

So this PR also runs the calculation in the frontend, and (where appropriate), identifies and highlights any deprioritized transactions in the block audit.

Once the algorithm is a bit more battle-tested, we can start saving those lists of deprioritized transactions to the block audits DB table so that the data is also available on the transaction page etc.

DB migration

Since only four five blocks were affected by false positives from the previous algorithm, this PR adds a database migration to directly fix those specific audits in the DB (if present).