Skip to content

Limited and sorted mempool #6449

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
morcos wants to merge 6 commits into from
Closed

Limited and sorted mempool #6449

morcos wants to merge 6 commits into from

Conversation

@morcos
Copy link
Contributor

@morcos morcos commented Jul 16, 2015

Here are a couple of suggested improvements to #6421.

Feel free to cherry-pick back into that pull if you want to maintain it. Or if you'd like this pull to take over, that's fine too..

I built them on a rebased #6421 and I lost a few comment changes that differed between that pull's NO_QT_KEYWORDS commit and the one in master.

ashleyholman and others added 6 commits July 16, 2015 09:22
@ashleyholman @morcos
TxMemPool: Change mapTx to a boost::multi_index_container
5850a75 
Indexes on:
- Tx Hash
- Fee Rate (fee-per-kb)
@sipa @morcos
Move orphan tx handling to a separate log class
d223671
@sipa @morcos
Implement on-the-fly mempool size limitation.
afba799
@morcos
Make StageTrimToSize aware of any minimum relay fee.
56b67ba 
StageTrimToSize will make several attempts to find a set of transactions it can evict from the mempool to make room for the new transaction.  It should be aware of any required minimum relay fee that needs to be paid for by the new transaction after accounting for the fees of the deleted transactions.
@morcos
Modify StageTrimToSize logic
cea215c 
Always be willing to try at least 5 different starting transactions so hitting a long chain you can't evict on your first try doesn't eliminate any chance of success.
@morcos
Add a fast check to make sure tx could pay for some eviction
bb4657a
@jtimon jtimon mentioned this pull request Jul 17, 2015
Closed
@morcos
Copy link
Contributor Author

morcos commented Jul 17, 2015

Unfortunately this PR doesn't actually improve performance. cea215c appears to be the culprit, and with some tweaks to allow more fails it can do better than #6421 but not so much better that I think this is the right approach.
Some very high fee rate transactions up to 400k satoshis/kB get rejected by both pulls. Once you start cleaning stuff out from the mempool, there is a tendency for the bottom to become occupied by large transactions with very low fee rate. Small transactions then have no chance of evicting these even with much higher fee rates because they fail the total fee test. I believe some combination of one of these approaches is necessary:

  1. Allowing high fee rate transactions to exceed the mempool cap via a multiplier based on size.
  2. Aggregating the fees of small high fee rate transactions to collectively evict large low fee rate transactions
  3. Attempting to evict by lowest total fee transactions as well as lowest fee rate.
  4. Using a packaging approach which combines dependent chains of transactions for a total feerate (or fee) to sort on.

Closing until something is actually materially better.

@morcos morcos closed this Jul 17, 2015
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@morcos @jtimon @ashleyholman @sipa