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?
How about imagining an alternative relay network structured like this:
- nodes maintain a mempool consisting of up to 1MvB of txs that’s the predicted next block
- new txs/package are accepted when they improve the mempool’s total fee
- txs/packages are relayed on if they’re accepted
Such an approach would be obnoxious in some ways: when a new block comes in, your entire mempool becomes invalid, and you need to validate a new block’s worth of transactions ASAP in order to be able to produce new block templates, eg. Handwave that problem away for now.
Would such a relay network work? I think so:
- node operators: the risk of free relay here becomes minimal, because blocks will contain every tx in the mempool, and blocks are found probabilistically, so your bandwidth is unlikely to be used for spam
- miners: this directly optimises for the next block fee
- users: pinning vectors are minimised; though there’s no provision for adding your tx to the backlog and getting it mined eventually
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.
Because such a network would be optimal for miners/users, I think that implies that it will be implemented (eventually), so node operators will (eventually) need to design around the problems/limitations such a network would create.
Could you add some sort of a backlog back into this approach?
The most significant problem with doing so is that any given block could invalidate up to about 1GvB of txs from the backlog, by replacing many maximum size txs (100kvB) in the backlog by minimum size txs in the block (100vB):
graph LR;
A[UTXO: A]-.->B[Backlog Tx: 100kVB];
A-->C[Block Tx: 100vB];
This is already possible, though it requires actually mining a block. With a relay network of the type described here it would become easier in two ways: you don’t need to manually find a cooperating miner, and when there is a long delay between blocks you could cycle multiple GvB of replacement transactions through the backlog, while only having to actually pay once a block is found.
One approach to allowing a backlog while reducing the impact of free relay might be to make backlog relay unreliable. For example: for a tx that’s in the top x% of the backlog, relay it with (100-x)% probability. If an unrelayed tx moves up from position x to position y, perhaps relay it with probability (1-y/x)%. In that case, when replacing 1GB of mempool you’ve likely only actually relayed 50% of those txs. Choosing a different relay distribution (ie, biassing towards relaying at the top of the backlog, and against relaying at the bottom of the backlog) could reduce that amount further.
Presuming nodes aggressively rebroadcast txs once they move from the backlog into the next-block-mempool, that likely provides good protection against pinning: it makes it easy to find a node that doesn’t have a conflicting tx already in its backlog (since the conflicting tx has low fee, and is thus less likely to be relayed); once the tx is accepted into some node’s backlog, it’ll remain there; and once the tx becomes acceptable for the next block, it will be aggressively relayed and removed the attempted pin from other nodes’ backlogs.
Perhaps a way of thinking about this would be:
- nodes will aggressively try to sync the top MvB to maximise fee revenue
- txs that don’t pay a high enough fee get considered for the backlog; in that case they must be “polite” – smoothly incresing the fees of the total backlog, etc
- but the backlog is deliberately non-uniform, so that it’s easy to send a double-spend to some peer, provided the tx it’s double-spending is relatively low in the backlog
- conflicts amongst different peers’ backlogs are resolved when one of the double-spends makes it to the top of the backlog, and a block gets mined
Max tx size, ancestor count/size, min incremental fee, etc are still enforced both for next-block txs as well as backlog txs.
Would something along those lines be crazy? I really feel like “pinning” is a fundamental design bug…