[bitcoin-dev] Thoughts on fee bumping

[Billy Tetrud]

With respect to the disagreement/misunderstanding about the  "<1vMB in the
mempool" case, I think it's important to be clear about what the goals of
relay policy are. Should the goal be to only relay transactions that
increase miner revenue? Sure ideally, because we want to minimize load on
the network. But practically, getting that goal 100% probably involves
tradeoffs of diminishing returns.

The only way to ensure that a transaction is only relayed when it increases
miner revenue is to make relay rules exactly match miner inclusion rules.
And since we don't want to (nor can we) force miners to do transaction
inclusion the same as each other, we certainly can't realistically produce
an environment where relay rules exactly match miner inclusion rules.

So I think the goal should *not *be strictly minimal relay, because it's
not practical and basically not even possible. Instead the goal should be
some close-enough approach.

This relates to the  "<1vMB in the mempool" case because the disagreement
seems to be related to what trade offs to make. A simple rule that the
fee-rate must be bumped by at least X satoshi would indeed allow the
scenario darosior describes, where someone can broadcast one large
low-feerate transaction and then subsequently broadcast smaller but
higher-feerate transactions. The question is: is that really likely be a
problem? This can be framed by considering a couple cases:

* The average case
* The adversarial worst case

In the average case, no one is going to be broadcasting any transactions
like that because they don't need to. So in the average case, that scenario
can be ignored. In the adversarial case however, some large actor that
sends lots of transactions could spam the network any time blockchain
congestion. What's the worst someone could do?

Well if there's really simply not enough transactions to even fill the
block, without an absolute-fee bump requirement, a malicious actor could
create a lot of spam. To the tune of over 8000 transactions (assuming a 1
sat/vb relay rule) for an empty mempool where the malicious actor sends a
2MB transaction with a 1 sat/vb fee, then a 1MB transaction with a 2
sat/vb, then 666KB transaction for 3 sat/vb etc. But in considering that
this transaction would already take up the entire block, it would be just
as effective for an attacker to send 8000 minimal sized transactions and
have them relayed. So this method of attack doesn't gain the attacker any
additional power to spam the network. Not to mention that nodes should be
easily able to handle that load, so there's not much of an actual "attack"
happening here. Just an insignificant amount of avoidable extra spent
electricity and unnecessary internet traffic. Nothing that's going to make
running a full node any harder.

And in the case that there *are* enough transactions to fill the block
(which I think is the normal case, and it really should become a rarity for
this not to the case in the future), higher feerate transactions are always
better unless you already overpaid for fees. Sure you can overpay and then
add some spam by making successively higher feerate but smaller
transactions, but in that case you've basically paid for all that spam up
front with your original fee. So is it really spam? If you've covered the
cost of it, then its not spam as much as it is stupid behavior.

So I'm inclined to agree with O'Beirne (and Lisa Neigut) that valid
transactions with feerate bumps should never be excluded from relay as long
as the amount of the feerate bump is more than the node's minimum
transaction fee. Doing that would also get rid of the spectre of
transaction pinning.

*I'm curious if there's some other type of scenario where removing the
absolute fee bump rule would cause nodes to relay more transactions than
they would relay in a full/congested mempool scenario*. We shouldn't care
about spam that only happens when the network is quiet and can't bring
network traffic above normal non-quiet loads because a case like that isn't
a dos risk.

On Fri, Feb 11, 2022 at 3:13 AM darosior via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Well because in the example i gave you this decreases the miner's reward.
> The rule of increasing feerate you stated isn't always economically
> rationale.
>
>
> Note how it can also be extended, for instance if the miner only has
> 1.5vMB of txs and is not assured to receive enough transactions to fill 2
> blocks he might be interested in maximizing absolute fees, not feerate.
>
>
> Sure, we could make the argument that long term we need a large backlog of
> transactions anyways.. But that'd be unfortunately not in phase with
> today's reality.
>
>
> -------- Original Message --------
> On Feb 11, 2022, 00:51, James O'Beirne < james.obeirne at gmail.com> wrote:
>
>
> > It's not that simple. As a miner, if i have less than 1vMB of
> transactions in my mempool. I don't want a 10sats/vb transaction paying
> 100000sats by a 100sats/vb transaction paying only 10000sats.
>
> I don't understand why the "<1vMB in the mempool" case is even worth
> consideration because the miner will just include the entire mempool in the
> next block regardless of feerate.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220212/a4ddf265/attachment.html>