Skip to content
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

Merged
merged 3 commits into from
Nov 30, 2015
Merged

Lower bound priority #7008

merged 3 commits into from
Nov 30, 2015

Conversation

morcos
Copy link
Member

@morcos morcos commented Nov 13, 2015

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)

@sdaftuar
Copy link
Member

utACK

@sipa
Copy link
Member

sipa commented Nov 17, 2015

Concept ACK

@morcos
Copy link
Member Author

morcos commented Nov 17, 2015

This was rebased now that #7020 was merged, and I removed the concept of default arguments from the CTxMemPoolEntry constructor.

@morcos morcos mentioned this pull request Nov 18, 2015
@luke-jr
Copy link
Member

luke-jr commented Nov 18, 2015

What are the benefits of this over #6357 ?

@sipa
Copy link
Member

sipa commented Nov 18, 2015 via email

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) {
Copy link
Contributor

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?

Copy link
Contributor

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, but indeed :)

@petertodd
Copy link
Contributor

utACK, modulo comment nit.

@jtimon
Copy link
Contributor

jtimon commented Nov 23, 2015

utACK

@dcousens
Copy link
Contributor

Is it worth changing this in light of the eventual removal of priority?
If it is, ACK.

@sdaftuar
Copy link
Member

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.

@jtimon
Copy link
Contributor

jtimon commented Nov 24, 2015

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.

@sipa
Copy link
Member

sipa commented Nov 26, 2015

utACK

@sipa sipa added this to the 0.12.0 milestone Nov 28, 2015
@morcos morcos force-pushed the lowerBoundPriority branch 2 times, most recently from 40a0e82 to c035306 Compare November 30, 2015 13:18
@morcos
Copy link
Member Author

morcos commented Nov 30, 2015

rebased

@laanwj laanwj merged commit c035306 into bitcoin:master Nov 30, 2015
laanwj added a commit that referenced this pull request Nov 30, 2015
c035306 Change GetPriority calculation. (Alex Morcos)
71f1d9f Modify variable names for entry height and priority (Alex Morcos)
5945819 Remove default arguments for CTxMemPoolEntry() (Alex Morcos)
@@ -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
Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Contributor

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 ?

random-zebra added a commit to PIVX-Project/PIVX that referenced this pull request Jul 6, 2020
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
@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.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants