Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Limit mempool by throwing away the cheapest txn and setting min relay fee to it #6722
One thing that I think is maybe not great about the behavior of this, is let's say we have:
If A and B are the min in the set, submitting C should kick them out. Now, let's say B wanted to increase their fee, they would need to go above 21 to get in. As implemented, it doesn't seem to me that two TX's could both raise by 1 to, combined, provide more fee (because it seems tx's get added one at a time?)
Perhaps a better compromise between these two behaviors would be to have a two part mempool, the inclusion set and the to-be ousted set and trigger a "GC" with some frequency. The to be ousted-set can be RBF'd or something.
Lastly justification on who might take advantage of such a behavior, perhaps a major exchange with a bunch of settlements out at once would want to make sure they all go through expediently and can coordinate increasing them all a hair.
I think that my earlier comment is not fully needed, because mempool is a large multiple of block size, currently. Perhaps a more future proof implementation would allow setting:
@JeremyRubin No, you're right, this breaks relaying of child-pays-for-parent when mempool grows large (assuming the package is not already present). The easy solution is to allow fee calulation of packages together when processing orphans, and then you send your package in reverse-dependancy order.
@TheBlueMatt re: my comment on high fee txs. I see now, you aren't doing the overall fee check in order to boot a package. I just assumed the StageTrimToSize logic was the same. So how do you think about free relay then? Could you write up a quick intro describing the algorithm as it would help to know how you think about it. Is the idea that all even though the tx causing the eviction hasn't covered the fees to pay for the evicted packages relay, by boosting the minRelayRate you're essentially forcing all future transactions to do so?
It's an interesting idea, one question is how big a sweet spot there is between having the half-life too long and worrying about the "cram relayFee high all of a sudden" attack vs having it too low and perhaps having some vague concern about free relay.
Why does your increased relay fee only apply to low priority transactions? I think it has to apply to all.
@morcos see the description of the main commit:
The minimum -maxmempool size is 10*-limitdescendantsize, as it is
Note that this effectively disables high-priority transaction relay
As for your specific questions: Yes, the idea is that you can relay some cheap crap for a bit, driving up the min relay fee by the default min relay fee each time (which was always meant as a "this is what it costs to send a transaction around the network" constant, though it hasn't always done a good job of being accurate there).
The increased relay fee will effectively apply to low priority transactions, as they will be the package selected by the final TrimToSize call. Thus, priority-based relay will effectively remain enabled until people's mempools fill up.
Hmm, indeed, there is an attack there where you can cause lots of relay for free there. You cant really get much into the mempool (only up to the max package size) and you do have to increase the feerate each time, but only by one satoshi per kb...
I think the
From the point of view of the bandwidth attack:
As soon as the
Since the decay is exponential, you'll actually take a lot longer than 53 mins to repeat the attack if the prevailing fee rate multiple X is considerably less than 20. However as the prevailing fee rate climbs the attack could be considered a bigger concern. This should be addressed by having a default minimum relay rate that is higher. It seams reasonable that over the long term the default minimum relay rate will not be much less than 1/20th of the prevailing fee rate at the bottom of mempools.
From the point of view of stuffing the mempool:
In this case access to the network will be blocked for all txs less than 100k feerate for 5 hours while those transactions are mined anyway. The additional gain the
Since the attacker could have stopped anything under 50K feerate anyway for 10 hours by just issuing 60MB worth of transactions at that fee rate. This attack is not significantly worse.
So I think 12 hours strikes about the right balance.
@sipa I believe I have raised substantial technical issues in my past and present comments. I think it is unfair of you to attempt to diminish my participation. Instead, please let me know if the issues I have raised have been addressed, and if so, please cite a basic message as to how they have been addressed. Thank you for your consideration of my comments.
(a) If you're talking about accessibility of on blockchain transactions: no. We can't guarantee that every possible useful transaction will have a negligable fee for every person on earth. If that was the case, DoS attacks that intervene with everyone's ability to use it would also be negligable in cost for every person on earth. This is a philosophical question, and not something that changes in this pull request. Miners are already incentivized to choose the transactions that grant them the highest profits, and this PR merely extends that behaviour to the mempool.
(b) Yes, see (c)
(c) Yes, read the title of this pull request please.
You're very welcome to discuss these issues, but not here as I don't think they are related to this pull request. This is about dealing active problems on the network in line of existing behaviour.
58254aa Fix stale comment in CTxMemPool::TrimToSize. (Matt Corallo) 2bc5018 Fix comment formatting tabs (Matt Corallo) 8abe0f5 Undo GetMinFee-requires-extra-call-to-hit-0 (Matt Corallo) 9e93640 Drop minRelayTxFee to 1000 (Matt Corallo) 074cb15 Add reasonable test case for mempool trimming (Matt Corallo) d355cf4 Only call TrimToSize once per reorg/blocks disconnect (Matt Corallo) 794a8ce Implement on-the-fly mempool size limitation. (Matt Corallo) e6c7b36 Print mempool size in KB when adding txn (Matt Corallo) 241d607 Add CFeeRate += operator (Matt Corallo) e8bcdce Track (and define) ::minRelayTxFee in CTxMemPool (Matt Corallo) 9c9b66f Fix calling mempool directly, instead of pool, in ATMP (Matt Corallo) 49b6fd5 Add Mempool Expire function to remove old transactions (Pieter Wuille) 78b82f4 Reverse the sort on the mempool's feerate index (Suhas Daftuar)
@ABISprotocol what specific question do you want to ask?
I'll try to answer, paraphrasing you:
If you classify access as the ability to run a full node, then, this PR, which will allow users to adjust the software to meet the capabilities of their hardware, does increase access.
If there isn't spam, why should we maintain the higher static parameter?
The implementation isn't so straightforward due to complications that arise when you account for CPFP and descendants, but, that is the base concept AFAIK.
-----BEGIN PGP SIGNED MESSAGE-----
By access, I didn't mean necessarily the ability to run a full node.
See, for example, this, cited previously here in (a), which discusses
As stated there, "In observing this sad trend of gradual fee increases
As a consequence, a large number of people in the developing and
This is the concern which focuses on access, and it has to do with
Note here that there are a large number of persons in the world
Thus the inclusion or exclusion of persons in the developing world
So, does this PR affect the ability of people in the developing world