-
Notifications
You must be signed in to change notification settings - Fork 37.7k
Remove priority estimation #7730
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
Conversation
concept ACK |
So this essentially changes priority from "fully supported for usage" to "fallback only", at least from the perspective of Core's wallet. Concept ACK. |
utACK 2f3c306 |
Concept ACK, would be good to see this rebased. |
Concept ACK |
Needs rebase. |
trivial rebase |
utACK 9a936e3 |
nBestSeenHeight = nFileBestSeenHeight; | ||
if (nVersionRequired < 129900) { |
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.
nit: could be a const.
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.
Also needs bump
utACK 9a936e3 |
Rebase please? |
tx.vin[0].prevout.n = 10000*blocknum+100*j+k; | ||
uint256 hash = tx.GetHash(); | ||
mpool.addUnchecked(hash, entry.Fee(feeV[k/4][j]).Time(GetTime()).Priority(priV[k/4][j]).Height(blocknum).FromTx(tx, &mpool)); | ||
mpool.addUnchecked(hash, entry.Fee(feeV[j]).Time(GetTime()).Priority(0).Height(blocknum).FromTx(tx, &mpool)); | ||
CTransaction btx; | ||
if (mpool.lookup(hash, btx)) |
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.
Needs merge conflict solved here due to 288d85d
Do we want this for 0.14? |
Sorry for the delay.. I rebased including bumping the version numbers, and I just wanted to flag another minor change I made since the previous version had been acked. This seems like the correct way to handle reading old version files. |
utACK 9ea4ed9. Mind to reword or squash the "SQUASHME" commit? |
0bd581a add release notes for removal of priority estimation (Alex Morcos) b2322e0 Remove priority estimation (Alex Morcos)
Merged (and squashed) via 3c03dc2 |
0bd581a add release notes for removal of priority estimation (Alex Morcos) b2322e0 Remove priority estimation (Alex Morcos)
0bd581a add release notes for removal of priority estimation (Alex Morcos) b2322e0 Remove priority estimation (Alex Morcos)
0bd581a add release notes for removal of priority estimation (Alex Morcos) b2322e0 Remove priority estimation (Alex Morcos)
2da16f7 [Cleanup] Nuke estimate(smart)priority from the RPC interface (random-zebra) 041f62e [Core] Remove priority estimation (random-zebra) Pull request description: Based on top of - [x] #1787 This removes the functionality behind `estimatepriority` and `estimatesmartpriority` (from bitcoin#7730). Instead of just deprecating the relative RPC commands, I think we can outright remove them, as `estimatepriority` was added only in latest minor release (4.2), and `estimatesmartpriority` is introduced in a PR not even merged yet (#1787). ACKs for top commit: Fuzzbawls: utACK 2da16f7 furszy: utACK 2da16f7 Tree-SHA512: 7dc964c7627a08eae349df40f40c49bc85761171d97f3d7a828421f6dc46ca86dc7a410c75bd8025b7a684aa09d215a08ac6ae19b64617adac6365cfaee55afc
This removes the functionality behind
estimatepriority
andestimatesmartpriority
. The rpc calls are now deprecated.estimatepriority
will return -1 always andestimatesmartpriority
will return 1e24 if the mempool is currently limited and -1 otherwise. The result of this behavior is that free transactions (if selected using the now debug option-sendfreetransactions
) can be created and sent if the mempool is not currently limited and the transaction's priority is above the hard coded AllowFree threshold.This is effectively the behavior in place already as priority estimates do not appear until confirmation targets over 50 which aren't currently supported.
A side effect of this is that now all transactions (that aren't dependent on unformed inputs) are now considered data points for fee estimation. Even though some transactions may be mined due to their priority instead of fee, this is still safe because the threshold for fee estimation is very high (95%).