neutrino: Added unban peer feature #270
Closed
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
Chinwendu20
changed the title
7 tasks
Chinwendu20
changed the title
Roasbeef
requested changes
Apr 26, 2023
|
Has a linter error failure: |
|
Hello @Roasbeef I have fixed that |
positiveblue
suggested changes
May 18, 2023
Chinwendu20
force-pushed
the
unbanPeer
branch
2 times, most recently
from
d3d5a15 to
4f0b541
Compare
Roasbeef
requested changes
Jun 14, 2023
| @@ -66,6 +66,9 @@ type Store interface { | |||
|
|
|||
| // Status returns the ban status for a given IP network. | |||
| Status(*net.IPNet) (Status, error) | |||
|
|
|||
There was a problem hiding this comment.
In commmit message: banmen -> banman
There was a problem hiding this comment.
Oh okay thanks.
|
Okay I would write the test. |
|
@positiveblue: review reminder |
We can't re-create the pkScript from a keyspend p2tr witness, as we're missing the public key. So this warning will trigger for each block that contains a p2tr key spend, which isn't really useful and confuses users. So we're downgrading the error to a debug message.
The rebroadcaster has now the ability to be supplied with a custom error mapping function which should map different backend errors to the neutrino internal broadcast error.
In this commit, the worker manager is adjusted to only retry a request a certain maximum number of times. This is done so that a smooth transition can be made from call sights currently using the neutrino.queryChainServicePeers method to using the query.WorkManager instead so that the same default behaviour can be expected. In order to also cater for call sights currently using the query.WorkManager, a NoRetryMax optional paramater is added that can used to disable the retry maximum.
Introduce a `WorkManager` interface that encapsulates the Dispatcher interface along with `Start` and `Stop` methods. The previous `WorkManager` struct is converted to `workManager` which is an implementation of the new `WorkManager` interface. The `ChainService` struct is then adapted to hold the new interface instead of the struct. This will make testing easier in future.
Use the work dipatcher interface from the query package to make getdata requests instead of using the old queryPeers function.
Rename the `query` variable in `GetCFilter` so that the `query` package can be imported and used cleanly.
Use the work dispatcher query interface instead of the old queryPeers method for making getcfilter requests. This ensures that the queries are made to the most responsive peers.
Since both GetBlock and GetCFilter now make use of the work dispatcher instead of the `queryPeers` function, we can now remove the `queryPeers` and `queryChainServicePeers` functions.
Lint the files and update the tests to use the `require` package.
Add a new FilterData type that encapsulates the filter, blockhash and type associated with a filter. This is done in order to prepare for a commit that will enable batch writes of these filters.
Introduce a new `rescanState` struct which holds the variables required for a rescan. We then also conver the existing `rescan` function into a method of `rescanState`. This refactor will assist in making future clean up of the `rescan` method easier.
Add a new `waitForBlocks` helper method to rescanState that will wait on block notifications until a given predicate returns true. Currently this method is only called with one predicate but an upcoming commit will make use of it using a differnet predicate.
This is required for the follow up commit where access to the IsCurrent method is required in the rescanState.rescan method which only has access to the ChainSource interface.
Let the rescan function wait until the filter headers have either caught up to the back end chain or until they have caught up to the specified rescan end block. This lets the rescan operation take advantage of doing batch filter fetching during rescan making the operation a lot faster since filters can be fetched in batches of 1000 instead of one at a time.
This check was performed for both the reorg and non-reorg cases, but in the reorg case the headers would count for PoW before validating that the headers connected to one another.
This uses btcd's HeaderCtx and ChainCtx interfaces to be able to validate headers, both contextually and context-free. This allows neutrino to call blockchain.CheckBlockHeaderContext and blockchain.CheckBlockHeaderSanity.
Signed-off-by: Ononiwu Maureen <[email protected]>
Signed-off-by: Ononiwu Maureen <[email protected]>
Signed-off-by: Maureen Ononiwu <[email protected]>
|
Hello, the commit issues here, I do not know how to fix them, so I would be creating a new PR for this. |
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.
Changes:
Associated PR in LND: lightningnetwork/lnd#7606 (With detailed explanation on how to test with LND)
Fixes issue: #253