[DEFUNCT] Post-clustermempool Package RBF

[sipa]

@instagibbs

I think this links back to our conversation yesterday. If you have two same-unit-size txs, A and B, where A is 0-fee, B is 1 fee, and mempoolminfee is 1, then B would be accepted when submitted by itself, but rejected as a package A+B. In this scenario of course, we’re only considering “chunks” since we’re not connecting the package to the mempool clusters.

I’m not sure I understand the example. Do A and B depend on each other? Is one in the mempool already?

@instagibbs

I assume this is where scripts are being run as well?

Indeed.

@instagibbs

What kind of failures are possible here if any?

None, if all goes well. The consensus checks are there for (a) priming the script/validation cache and (b) being absolutely sure that no cases exist where standardness checks permit something that consensus does not.

@instagibbs

I assume TimeToSize is another step we want, after 12.

Indeed.

@ajtowns

Anything done before script-validation isn’t really DoS protection, it’s just an optimisation?

Do you mean doing this pre-eviction here (as opposed to later) is an optimization? If so, I may agree. But not removing (and not otherwise outlawing) sub-mempoolminfee stuff in packages would constitute a DoS risk, I believe (free relay by continuously replacing the bottom tx in the mempool at \epsilon feerate increments). This gets stopped by increasing mempoolminfee above the evicted transactions’ feerate when eviction happens, so that anything new accepted into it is (for the time being) strictly higher feerate.

@ajtowns

“At this point the package is desirable” perhaps? We’ve established it’s got a nice feerate, etc, but not done the consensus checks from 12, so it may actually be garbage.

Unless our code is broken, standardness checks (done in (10)) are strictly more restrictive than the consensus checks in (12). These last ones are just for priming the validation cache and a last-ditch protection against bugs in standardness validation that could make it less restrictive than consensus.

@ajtowns

Maybe you can do ancestor-first package acceptance via chunking? Once you linearise NEW go through the chunks with new txs in order, and add just those txs to the mempool; updating OLD, NEW and CON as you go? If you get a chunk that’s not worth adding to the mempool (or that fails validation), abort completely.

There are many things that can be done to find a better combination of OLD and NEW things than exactly the package as relayed indicates. They include:

• Running an O(n^2) chunk merging algorithm on the old and new linearization.
• Running an actual conflict-aware O(2^n) linearization algorithm that finds the best (or approximation thereof) feerate subset in the combination.
• Requiring the peer to give us their full cluster linearization, which we could just accept if it looks good.
• …

But all of these are either incomplete, high-bandwidth, or computationally infeasible for all but the smallest cases. We could do relatively cheap improvements, but they will still permit “undesirable” more complex situations like this. Or we can restrict cluster/replacement sizes so much that we can always find the optimal combination.

However, I’d rather not get into a discussion of what approaches to consider without knowing what good enough is. Are there attacks possible without any improvements over the package relayed as-is? Note that if the peer is malicious, it’s ok to do something suboptimal as long as it doesn’t prevent us from accepting the “right” solution later from an honest peer. And if it’s good enough, maybe we don’t need to bother with patching up simple and obvious suboptimalities. And if it’s not good enough, then patching only the simple cases likely still leaves other cases that are still not enough.