forked from bitcoin/bitcoin
-
Notifications
You must be signed in to change notification settings - Fork 1.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
Avoid propagating InstantSend related old recovered sigs #3145
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This makes AlreadyHave() return true even when the recovered sig is deleted locally. This avoids re-requesting and re-processing of old recovered sigs.
UdjinM6
reviewed
Oct 11, 2019
UdjinM6
approved these changes
Oct 14, 2019
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.
utACK
barrystyle
pushed a commit
to PACGlobalOfficial/PAC
that referenced
this pull request
Jan 22, 2020
* More/better logging for InstantSend * Implement CRecoveredSigsDb::TruncateRecoveredSig * Truncate recovered sigs for ISLOCKs instead of completely removing them This makes AlreadyHave() return true even when the recovered sig is deleted locally. This avoids re-requesting and re-processing of old recovered sigs. * Also truncate recovered sigs for freshly received ISLOCKs * Fix comment
panleone
pushed a commit
to panleone/PIVX
that referenced
this pull request
Nov 15, 2024
* More/better logging for InstantSend * Implement CRecoveredSigsDb::TruncateRecoveredSig * Truncate recovered sigs for ISLOCKs instead of completely removing them This makes AlreadyHave() return true even when the recovered sig is deleted locally. This avoids re-requesting and re-processing of old recovered sigs. * Also truncate recovered sigs for freshly received ISLOCKs * Fix comment
panleone
pushed a commit
to panleone/PIVX
that referenced
this pull request
Nov 15, 2024
* More/better logging for InstantSend * Implement CRecoveredSigsDb::TruncateRecoveredSig * Truncate recovered sigs for ISLOCKs instead of completely removing them This makes AlreadyHave() return true even when the recovered sig is deleted locally. This avoids re-requesting and re-processing of old recovered sigs. * Also truncate recovered sigs for freshly received ISLOCKs * Fix comment
Fuzzbawls
added a commit
to PIVX-Project/PIVX
that referenced
this pull request
Jan 11, 2025
a85b450 Merge pull request dashpay#3399 from codablock/pr_speedups2 (Alexander Block) 136f900 cherry-pick dashpay#2833 (Alexander Block) d942439 Merge pull request dashpay#3389 from codablock/pr_concentrated_recovery (Alexander Block) 36790d2 cherry pick dashpay#3368 (Author Alexander Block) dac01a9 cherry-pick dashpay#2780 (Alexander Block) 39d0ed9 cherry-pick dashpay#3367 (Alexander Block) 5084bbf Allow re-signing of IS locks when performing retroactive signing (dashpay#3219) (Alexander Block) 802c006 Only track last seen time instead of first and last seen time (dashpay#3165) (Alexander Block) 479b64b Avoid propagating InstantSend related old recovered sigs (dashpay#3145) (Alexander Block) 27fa2af cherry-pick dashpay#3117 (Pasta) cf138e0 cherry-pick dashpay#3097 (Pasta) 23b140e Introduce getbestchainlock rpc and fix llmq-is-cl-conflicts.py (dashpay#3094) (UdjinM6) Pull request description: as usual each commit backports a different PR ACKs for top commit: a85b450 Duddino: utACK a85b450 Liquid369: uTACK a85b450 Fuzzbawls: ACK a85b450 Tree-SHA512: e9024d180888d8a6cc300ba9df74fc15929e3ade1773e5d312bd8cc93f6c9fd3898c5bf2d14672abf4faba576575c33936708e6e1dfd01a393479d264d3f2c57
Liquid369
pushed a commit
to Liquid369/PIVX
that referenced
this pull request
Jan 14, 2025
* More/better logging for InstantSend * Implement CRecoveredSigsDb::TruncateRecoveredSig * Truncate recovered sigs for ISLOCKs instead of completely removing them This makes AlreadyHave() return true even when the recovered sig is deleted locally. This avoids re-requesting and re-processing of old recovered sigs. * Also truncate recovered sigs for freshly received ISLOCKs * Fix comment
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR implements "truncating" of recovered sigs in the LLMQ DB. Truncating means that the sig itself is deleted from the DB, but the hash of it is left in the DB so that we won't re-request it later. It also avoids reprocessing of the sig when another node sends it to us after we've already got it from another node.
This fixes issues when other nodes are unable to keep up with the network. In this case requesting sigs from them will timeout and cause us to re-request from another node. When we then get the sig from the second node, we'll process and relay it. If an InstantSend lock comes in which uses that sig, the code in
CInstantSendManager
causes the recovered sig to be deleted by callingRemoveRecoveredSig
. After some time, the first node might end up sending us the same sig again, causing us to re-process and re-propagate the recovered signature. Neighbor nodes will now get the same sig from us, even thought they also have seen it already, which makes them re-process and re-propagate it as well. This then continues until the whole network has seen and processed the sig twice.Changing the removal to "truncating" fixes this issue as it stops re-processing and re-propagation.