RBF: Allow replacements to pay for minRelayFee(replaced)+minRelayFee(replacement) rather than actualFee(replaced)+minRelayFee(replacement) #7220

This logic seems more reasonable?

Couldn't the minRelayFee be smaller than the actual though? Isn't the point of this to follow rational incentives?

There is another check for the economically-rational fee comparison before this one.

NACK on both commits

It's necessary to pay for actual fees of the previously transmitted tx otherwise you could do the following attack. Sent tx A of size 100k, paying 100,000 satoshis fee. Send tx B of size 1k paying 101,000 satoshis fee which evicts tx A due to full mempool. Send tx C of size 100k, paying 101,001 satoshis fee which RBF's tx B. At this point you have now sent 201k bytes but only paid the minimum relay rate for barely half of that.

(Edited again, because thats not the way mempool eviction works any more, oops)

Sorry. Bad example.

Anyway more simply, if tx A pays 2000 satoshis for 1000 bytes. Then you can keep replacing it in a chain of txs that each pay only 1 satoshi higher for an effective relay cost of 1 satoshi per 1000 bytes.

NACK, as morcos stated the purpose of requiring a larger fee is to prevent DoS attacks on the transaction relay network, and not just to make sure that all transactions have paid their fair amount of fee.

@morcos, so we'd have to consider all previously replaced TXs in the chain to accurately calculate the correct min fee? Is that heavy?

Concept ACK, I like the idea, if it's possible to do securely.

@GIJensen you only have to consider the transaction that is being replaced and the transaction that is replacing it. The transaction that is being replaced can be assumed to have already paid the correct minimum fee, so as long as you are paying the minimum above that it's guaranteed to be sufficient.

@DavidVorick with RBF right now you have a guarantee that the previous TX paid a sufficient fee as its always previous actualFee(replaced)+whatever. Using minimum fees is different though because if you replace 20 transactions the minfee of the previous is still always the same regardless of how many it replaced. So you could increase by 1 satoshi to get minRelayFee+minRelayFee usually.

If you factored in that it replaced 20 TXs, suddenly you're doing minRelayFee*20+minRelayFee and paying the proper fee.

Edit: Some typos. I hope this is clear.

A simpler explanation. Right now RBF only looks at the previous TX and that's fine. With this change it makes more sense to look at the entire chain (as it's now relevant).

@GIJensen Opt-in RBF already considers the fees paid by all transactions being removed from the mempool. (Otherwise there would be a free relay attack, where descendant transactions get relayed for free simply by replacing their parent, causing them to be evicted.)

This isn't terribly expensive to calculate, as we conservatively limit the number of transactions that a new transaction can replace at 100.

@sdaftuar then I don't understand @morco's concerns. If all previous minimum fees are considered, then you can't pay less than the sum of all replaced transaction's minimum fees, no?

@GIJensen The example @morcos gave is correct. The current logic prevents free relay attacks by requiring that the new transaction still have enough to pay for its own relay, even after paying for all the fees being evicted -- so the total fee in the mempool is now at least minRelayFee higher after the replacement.

As @morcos pointed out, this pull would allow the total fee in the mempool to increase by as little as 1 satoshi as the result of a replacement. This allows someone to relay transactions for less than the minRelayFee as long as they're evicting something else. NACK.

@sdaftuar but doesn't that ignore what I was saying? I already said this doesn't work in It's current state and it could only work if it can/will factor in the minimum fees for all transactions replaced in the chain (making it literally impossible to pay any less than the sum of all minimum fees) I guess that's impossible if they're completely dropped from mempool.

I still agree with the concept so I'm hesitant to NACK this. If considering all minfees for all previously replaced TXs is impossible then NACK but I don't think it is. The node could even keep some information about the dropped TXs (size, and anything relevant for future fee calcs maybe) lingering for such calculations until the final TX is mined, it'd be fast, and wouldn't allow anyone to pay under the minimum fee. Is that outside of the scope of this PR though?

@GIJensen Your suggestion is to sum the minRelayFee for all transactions what would be evicted, including descendants of transactions that conflict with the replacement, right? That is actually what this PR does. But the free relay attack @morcos described is still correct; note that his example didn't have anything to do with chains. Say you have a transaction in the mempool with no descendants that pays 2 times the minRelayFee. Then this PR would allow you to evict it by sending a new transaction that pays 1 satoshi more, which you could then repeat over and over again...

@morcos The problem you describe is exactly what the second commit was indended to fix. But I see that in more complex scenarios it wouldn't actually be a complete fix. I think the CTxMemPoolEntry would need to cache the minimums required for this to work, and it's probably not worth it, so closing.

For the benefit of readers:

• <@GIJensen&gt; @Luke-Jr, PR 7220 for my sanity, you closed it because it doesn't cache the minimums (so the proper min can't be calculated)? That's what I thought but two other people disagreed with me :S
• <@GIJensen&gt; @Luke-Jr I'm just asking for clarity on the comments previous to your final one. I was trying to convey the issue is the PR as is didn't account for all the minimum fees of past transactions. Is that correct, or no?
• <@GIJensen&gt; You mentioned a cache, so that made me believe I'm correct. I just want to know to be sure I properly understand what's happening.
• <@Luke-Jr&gt; yes, if A is replaced by B, and C might replace B, we need C to pay for A+B+C, but we no longer have A
• <@GIJensen&gt; Thank you!
• <@Luke-Jr&gt; so to fix this, we would need to store the size of A (and anything it replaced) with B
• <@Luke-Jr&gt; nTotalRelaySize or smth
• <@GIJensen&gt; Okay, yes I understand completely. Do you still plan on trying to work on the concept? Or just axe it for now?
• <@Luke-Jr&gt; I think the benefits do not outweigh the costs now
• <@GIJensen&gt; I was worried about that, okay