-
Notifications
You must be signed in to change notification settings - Fork 36.2k
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.
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
Lower bound priority #7008
Lower bound priority #7008
Conversation
0161cff
to
5112684
Compare
utACK |
Concept ACK |
5112684
to
bea369e
Compare
This was rebased now that #7020 was merged, and I removed the concept of default arguments from the CTxMemPoolEntry constructor. |
What are the benefits of this over #6357 ? |
It's simpler.
|
Compute the value of inputs that already are in the chain at time of mempool entry and only increase priority due to aging for those inputs. This effectively changes the CTxMemPoolEntry's GetPriority calculation from an upper bound to a lower bound.
@@ -239,8 +240,9 @@ double CCoinsViewCache::GetPriority(const CTransaction &tx, int nHeight) const | |||
const CCoins* coins = AccessCoins(txin.prevout.hash); | |||
assert(coins); | |||
if (!coins->IsAvailable(txin.prevout.n)) continue; | |||
if (coins->nHeight < nHeight) { | |||
if (coins->nHeight <= nHeight) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why was this line changed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh wait, I get it, never mind.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, but indeed :)
utACK, modulo comment nit. |
utACK |
Is it worth changing this in light of the eventual removal of priority? |
Added a commit to address @petertodd's comment nit. @dcousens Yes I think this change is needed for 0.12, since all the priority code won't be eliminated yet. This seems like the best compromise for 0.12. |
In any case, merging this makes other mempool related PRs more readable, it's small and it doesn't preclude the future elimination of the priority code (and there's currently no rebased version of a priority-removing PR that I know of). So even if I'm very much in favor of directly removing the priority, I would be happy to see this merged soon. I think some squashing could be done here though, at the very least for the comment fixup commit. |
utACK |
40a0e82
to
c035306
Compare
rebased |
@@ -63,9 +63,10 @@ class CTxMemPoolEntry | |||
size_t nModSize; //! ... and modified size for priority | |||
size_t nUsageSize; //! ... and total memory usage | |||
int64_t nTime; //! Local time when entering the mempool | |||
double dPriority; //! Priority when entering the mempool |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What was the motivation to bike-sheed dPriority and nHeight?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was originally the first part of the changes necessary for #6357 (now #7149)
It was necessary to distinguish between the two stored priorities and heights. The original "entry" priority and height and the latest calculated "cached" priority and the height that was calculated at.
It seemed logical to me to leave those changes in given that we didn't know whether the second half would be merged or not and given that they are more accurate names anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was necessary to distinguish between the two stored priorities and heights. The original "entry" priority and height and the latest calculated "cached" priority and the height that was calculated at.
I guess if the rename had been introduced when it was necessary instead of here I wouldn't have complained.
It seemed logical to me to leave those changes in given that we didn't know whether the second half would be merged or not and given that they are more accurate names anyway.
I'm confused, how are CTxMemPoolEntry::nHeight and CTxMemPoolEntry::dPriority "less accurate" than CTxMemPoolEntry::entryHeight and CTxMemPoolEntry::entryPriority ?
830eadf Solving rpc_fundrawtransaction.py amount rounding issue. (furszy) 6cf9778 ATMP: Do not try to get the inputs in zc tx. (furszy) 38efbb9 sync_blocks: Increase debugging to hunt down mempool_reorg intermittent failure (furszy) dd7855c sync_blocks: check that peer is connected when calling sync_*. (furszy) bc7d542 functional tests, sync_blocks only cleanup. (furszy) 1ae04e7 Fix mempool package tracking edge case (Suhas Daftuar) f4052aa Add test showing bug in mempool packages (furszy) 691749f rpc: Accept scientific notation for monetary amounts in JSON (furszy) b0f9051 Fix removeForReorg to use MedianTimePast (Suhas Daftuar) 92583c6 Don't call removeForReorg if DisconnectTip fails (Suhas Daftuar) bb77808 Track coinbase spends in CTxMemPoolEntry (furszy) f607f18 Change GetPriority calculation. (furszy) ac3c0f1 Remove default arguments for CTxMemPoolEntry() (furszy) 07eae9f Modify variable names for entry height and priority (furszy) 4356b31 Fix bug in mempool_tests unit test (Alex Morcos) f35ebe3 removeForReorg calls once-per-disconnect-> once-per-reorg (furszy) 7f5737f Fix comment in removeForReorg (furszy) 8ad82ca Fix removal of time-locked transactions during reorg (furszy) de74ab3 Move ProcessBlockFound reserveKey to optional. (furszy) Pull request description: More back ports and adaptations over the RPC values parsing and mempool. We need to get closer in this area :) . * bitcoin#6379 * bitcoin#6715 * bitcoin#6915 * bitcoin#7007 * bitcoin#7008 * bitcoin#12643 * bitcoin#18474 * bitcoin#18704 ACKs for top commit: Fuzzbawls: ACK 830eadf random-zebra: ACK 830eadf and merging... Tree-SHA512: 014b31008aaf09ebf838e21da59379a45565df440a77d66a0cd53e824a6d69673d6975d08243a43fb5a7ebd1a35c07d1d07412a87216b42e9d6f17a1c0bc5708
I think this is a good compromise with regards to priority for 0.12 release. It is a calculation of priority in which only inputs that are in the chain at the time the transaction enters the mempool are aged.
It is a minimal amount of code and changes the
CTxMemPoolEntry::GetPriority
function to return a lower bound of the correctly computed priority as opposed to an upper bound. This would allow the fast mining code in #6898 to use a priority calculation that at least ages the originally in chain inputs as opposed to using only starting priority.I believe this better strikes the right balance between preserving the ability to meet previous policy objectives and adding too much complication to the code for a concept that is deprecated. I plan to close #6357 in favor of this.
One caveat: In the event of a reorg, if one of the originally in-chain inputs is now no longer in chain (or has been moved to a different height) the calculation will no longer be a strict lower bound on priority because it will not take this into account.
It should be kept in mind though, that this is a clear improvement on the current calculation.
(Built on top of #7007 so the tests pass)
(EDIT: For anyone that has already reviewed #6357, this is almost a strict subset)