Avoid propagating InstantSend related old recovered sigs #3145
Conversation
This file contains hidden or 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
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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
CInstantSendManagercauses 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.