wrong summary link, this is the right one: https://github.com/bitcoin/bitcoin/pull/19109/commits/c4626bcd211af08c85b6567ef07eeae333edba47

built and tested locally ok

I think the deleted blank line is a result of linting. If I try to restore it, it tells me it's a code style violation

In D9430#214040, @deadalnix wrote:

This is breaking the test suite, back to your queue. Please make sure you run it, this is happening way too often.

This is breaking the test suite, back to your queue. Please make sure you run it, this is happening way too often.

I note that you often submit patches that break everything. You should make sure that you compile/run what you submit.

fix the renaming issues.

Implementing isValidStoredWallet in useWallet.js

In D9424#213950, @Fabien wrote:

So the previous content of the if statement was not a bool ?

address review:

So the previous content of the if statement was not a bool ?

This is pretty much good to go. Make sure isProofStateDustThreshold has a descriptive name.

This will allow for initializing the PeerData from the ArgsManager and make it independent from the Processor.

This kinda have the right idea, but the execution is a problem. For as long as you do these in the various constructors, you must have objects at the end, and therefore you end up constructing possibly invalid objects, which is just bad design.

The rationale of this patch doesn't rally make sense. If data aren't optional, then don't put them in the PeerData. If the name turn out to b confusing then rename.

Modified isValidStoredWallet to return bool (required some changes, is now a more specific validation function)

Make the size threshold a number of stakes, not a number of proofs.

Responding to code review feedback

I still want to change the threshold to be a maximum number of stakes, not a number of proofs. That way, it will actually represent a maximum memory footprint and a maximum number of signatures to verify.

Use a multi-index container to avoid using multiple data structures to remember insertion order.
Contributed by @fabcien

rephrase the misleading comment.

rename recentProofRejects -> rejectedProofs.
I used the recent word to mean that the filter has a limited size and will drop the oldest entries when full. But that is an implementation detail. A proof that enters this pool will be bad forever, there is no reset of the filter done on tip updates, like there is for transactions.

What makes them recent and why are they different from other rejected proofs ?

rebase onto master

rebase onto master (this diff has no dependency)