Mempool Incentive Compatibility

[sdaftuar]

@rustyrussell

Fortunately, the actual divergence from miner incentives here is fairly narrow in practice, as these extreme examples do not regularly occur. Bitcoin software also doesn’t mine backwards even in the case of a large fee double-spend, and I haven’t seen anyone complaining about that. Similarly, I suggest leaving this door firmly closed.

I imagine you’re right, and I certainly am not proposing that anyone write software that would do anything differently in this regard. However I think it’s important to understand that if protocols are implicitly creating mechanisms where miners would get paid more overall if they censor a transaction in order to wait for a later one, that we know under what assumptions this is incentive compatible, so that we don’t stray into territory where the system falls apart (either because miners independently decide its in their interest to wait, or because it creates incentives for miners to cooperate because they collect more total fee this way).

So I view this as an area for theoretical research to be done to figure out how the incentives work out and what the game theoretic implications are.

@rustyrussell

If it were a simple collection of potentially incompatible but all possibly-valid transactions, and selection were made at block creation time, we would be able to trade some problems for others. We would need, however, some other mechanism for DoS protection.

Agreed – though my intuition is that this is an insurmountable DoS problem to solve.

@rustyrussell

I wanted to mention what is still my current favorite solution in the replacement wars: that RBF rules be bypassed in favor of a simpler “higher feerate” iff all the replaced txs would not have been in the successive block, and all new ones are. This addresses both the sharp end of RBF complaints in a multi-party scenario (blocking progress) and the sharp end of miner incentive (getting those juicy fees). [Aside: ISTR someone had a critique of this approach, but I can’t find the link? Help?!]

So I had hoped that the reasoning from my post shows why this is an insufficient criteria by itself, even putting aside potential DoS issues and only considering miner incentive compatibility, but I can try to come up with a more concrete example to make my point clearer.

Suppose in our mempool we have the following:

• 1000 transactions, A_1, ... A_{1000}, each of which pays 10k sats in fees, and is 1k vbytes in size (so 10 sats/vbyte feerate).
• 500 transactions, B_1, ..., B_{500}, each of which pays 9k sats in fees, and also 1k vbytes in size (9 sats/vbyte feerate)
• 500 transactions, C_1, ..., C_{500}, each of which pays 1k sats in fees, and also 1k vbytes in size (1 sat/vbyte feerate)
• 1 transaction, D, which pays 900k sats in fees, and is 100k vbytes in size (9 sat/vbyte feerate).

At this point, the next block would consist of all the A_i transactions and pay 10M sats in fees, while the second block would consist of [B_1, ..., B_{500}, D, C_1, ..., C_{400}] and pay 5.8M sats in fees.

Imagine we have a replacement transaction, D', which conflicts with D, pays a feerate of 10.001 sats/vbyte, and is 1000 vbytes^[1] in size. Under your proposed rule, D' would be in the top block and accepted as a replacement – indeed, it would be the highest feerate transaction in the whole mempool – but it only increases the fees in the top block by 1 satoshi.

Meanwhile, the result of taking D' and evicting D would be that the second block in the mempool will now consist of: [A_{1000}, B_1, ..., B_{500}, C_1, ..., C_{499}], which has a total fee of 5.009M sats, a reduction of 791k sats.

I think this raises two immediate questions:

1. Are there any miners that would find it incentive compatible to work on a block that pays 1 sat more, if it means giving up 791k sats in the next block? (Note that in the future when fees are the only thing rewarding miners, that this would seem to create an additional incentive to reorg out such blocks.) I believe that in today’s network, the answer is no.
2. Even if there are, is it bad for the network to promote policies that try to exploit this kind of behavior, because it might create an incentive for miners to centralize to try to maximize total fees collected? I don’t know how strong this effect might be, but I think we should notice that this would seem to rely on (extreme) decentralization of mining in order to work, and we should determine if we might be undermining that important property with a usage pattern that incentives subverting it.

My overall takeaway from this is that (a) at the least, the distribution of fees in the mempool seems to matter for what is incentive compatible, even when looking at “top block” replacement rules, and (b) even taking into account such distributions, more research is needed to figure out what is incentive compatible for miners, particularly in situations where total fees are going down.

Going further: even in situations where total fees are not going down, I think there is more room for research. I think there’s a rough intuition that when evaluating an RBF and looking at feerate diagrams, that probably what is happening in the top few blocks matters a lot more than what is happening further down in the mempool. But we lack any specifics on how we might characterize this – you could imagine an RBF that would increase the top block by 1 sat, decrease the second block by 100k sats, but increase the third block by 101k sats. Is that an RBF that we should accept? etc

---

1. In the initial post, I mistyped this as 1000 kvbytes – sorry for the error! ↩︎