- 
                Notifications
    You must be signed in to change notification settings 
- Fork 1.2k
instantsend: deterministic lock using the same msg hash as islock #4381
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
5433630    to
    65dd0d2      
    Compare
  
    65dd0d2    to
    20a0485      
    Compare
  
            
          
                src/llmq/quorums_instantsend.cpp
              
                Outdated
          
        
      | const auto blockIndex = LookupBlockIndex(islock.cycleHash); | ||
| if (blockIndex == nullptr || blockIndex->nHeight % dkgInterval != 0) { | ||
| return false; | ||
| } | 
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 might be problematic.. We likely don't want to p2p ban a peer just because we don't have this block yet...
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.
I changed it to slightly penalize a peer in order to avoid the case when some peer spams an invalid cycleHash.
51124c9    to
    d096097      
    Compare
  
    3414356    to
    a049b9e      
    Compare
  
    When receiving an islock, propagate it as islock. When creating/receiving and isdlock, propagate it as isdlock to peers which support it and as islock to peers which don't. Functional tests to cover both islock and isdlock scenarios.
a049b9e    to
    0fd8235      
    Compare
  
    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.
LGTM utACK for squash merge
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
…shpay#4381) When receiving an islock, propagate it as islock. When creating/receiving and isdlock, propagate it as isdlock to peers which support it and as islock to peers which don't. Functional tests to cover both islock and isdlock scenarios.
…shpay#4381) When receiving an islock, propagate it as islock. When creating/receiving and isdlock, propagate it as isdlock to peers which support it and as islock to peers which don't. Functional tests to cover both islock and isdlock scenarios.
…shpay#4381) When receiving an islock, propagate it as islock. When creating/receiving and isdlock, propagate it as isdlock to peers which support it and as islock to peers which don't. Functional tests to cover both islock and isdlock scenarios.
…er functions a02e843 refactor: privatise `RequestObject` and `EraseObjectRequest` (Kittywhiskers Van Gogh) f95b50a refactor: privatise `RelayInvFiltered` and `AskPeersForTransaction` (Kittywhiskers Van Gogh) c93ade5 refactor: reduce `PeerManager` usage in InstantSend worker functions (Kittywhiskers Van Gogh) 9b2c916 refactor: drop `is_masternode` from `PeerManager` interface functions (Kittywhiskers Van Gogh) Pull request description: ## Additional Information * Depends on #6815 * Depends on #6820 * While this pull request doesn't _entirely_ decouple `PeerManager` from `CInstantSendManager` as the worker thread isn't _reactive_ (i.e. triggered by `ProcessMessage()`), we can reduce its usage by folding all expected network activity into a `MessageProcessingResult` batch that can be consumed by `PostProcessMessage`. To achieve this, `MessageProcessingResult` has been extended to allow * Requesting peers for a transaction (by setting `m_request_tx`) * Relaying inventories to interested peer based on filter match (by setting `m_inv_filter`) This has the additional effect of removing external uses of `RelayInvFiltered()` and `AskPeersForTransaction()`, which can now be safely removed from the `PeerManager` interface as it is now brokered through `MessageProcessingResult`. * Note that while the old `RelayInvFiltered()` allowed specifying _any_ minimum protocol version, `PostProcessMessage()` will assume that `minProtoVersion` is `ISDLOCK_PROTO_VERSION`. This is acceptable as `RelayInvFiltered()` isn't used anywhere else and deterministic InstantSend locks were introduced in v0.18 (see [dash#4381](#4381)). If there is any foreseeable use needing to relay messages to even older versions of Dash Core, `m_inv_filter` can be modified to accommodate that. ## Breaking Changes None expected. ## Checklist - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas **(note: N/A)** - [x] I have added or updated relevant unit/integration/functional/e2e tests **(note: N/A)** - [x] I have made corresponding changes to the documentation **(note: N/A)** - [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_ ACKs for top commit: knst: utACK a02e843 UdjinM6: utACK a02e843 Tree-SHA512: 6a83277781faf996cbb5187d352971c3508191dbf84cd801e062e2cde2db09cf64696bf27b9790f2b278f53adb46c042e04ac5c4dbdebdbc1faba2b262e39930
When receiving an islock, propagate it as islock.
When creating/receiving an isdlock, propagate it as isdlock to peers which support it and as islock to peers which don't.
Functional tests to cover both islock and isdlock scenarios.