Opt-in transaction policies for anti-pinning

[instagibbs]

@ajtowns

I guess the concern I have with this is some rules we have that create pinning vectors align with “miner incentives”, and if miners are incentivised to enforce those rules, then they’ll just work around any rules we create to reintroduce those pinning vectors?

Part of my thinking on this priority based system is that it seems to be closer to compatible than V3 style, in that if it profits the next N blocks(let’s say very small numbers only), I think it basically approximates the type of selective relay you suggest, just in an opt-in manner? Bonus is a user can’t complain their tx isn’t showing up on their block explorer, they opted into not being relayed if miners don’t want to bother!

@ajtowns

This approach would perhaps be incompatible with non-consensus “prior restraint” features though: miners and users could easily just remove those features and maintain a network like this.

I don’t see what’s incompatible? Miners would include a tx if it’s in the top, and not include if not. 1MvB is the strictest possible setting, and better for the user that doesn’t want to be pinned as long as they’re aggressively bumping fees on whatever schedule they need. The problem would be if miners decide to relax this restriction, allowing a potentially junkier backlog build. I don’t know why miners would want to do that.

@ajtowns

One approach to allowing a backlog while reducing the impact of free relay might be to make backlog relay unreliable.

I’d have to think way harder on this, but I don’t think this is a crazy direction, no. I am not sure I’d even call it free relay, if we’re relaying less. We might need a more concrete definition, but pushing down how much we relay to prevent free relay seems right!

@ajtowns

I really feel like “pinning” is a fundamental design bug…

handwave cluster mempool into existence

An alternative and unbaked selective relay take could be to not only weigh the “depth” it is in the mempool/backlog, but also “how many vbytes away from top block” it is with respect to its preceding chunks in the cluster.

If a newly proposed chunk in a cluster linearizes to “just after” top block chunks, and the new chunk itself is below Y kvB, where the size is not >> “smallest reasonable package attempts”, we accept and relay it. Taking V3 magic values for this example, we could allow 1 kvB “extra” in clusters. An adversary pays top block to stuff a cluster, or pays minfee to fill up the last 1 kvB which can be efficiently RBF’d, at least as well as V3 child txns can.

In this scenario, we could just make “large” lower fee chunks relay unreliably. Casual users making smaller txns would not be effected unless they do consolidations or longer chains, depending on the Y you pick which directly influences the amount of pinning possible.