No need for it to be compatible.

Either delegation must have at least one level or they don't. It doesn't make sense to insist on avahello having some special type of delegation.

That is a significant step backward. The contention on cs_main is obviously far greater than the one on the peer manager. What alternative have you considered? Why do they fail?

This is doing several thing at once. What about starting with a validateproof RPC?

You'll note that there is a set of message to exchange mempool content, there is no reason to not do the same for proofs, because this is introducing quadratic behavior.

Just check the signature as soon as the messages arrives. There is no point making this dependent on the network layer.

Please address previous feedback.

Ok, so the problem that you want to solve is knowing if the proof is rejected or just orphaned. The solution can come in many forms. For instance:
1/ Separate validation that doesn't depend from the state (and is therefore def invalid) and validation that is state dependent, put the stateless check outside the peer manager and handle the result there. This doesn't require any changes here.
2/ Do the check here and add a way to export the result, which this patch really doesn't achieve.

Why couldn't fetchOrCreatePeer put the proof in the orphan set based on validation? Why is a new API needed? I strongly suspect that as you actually solve problems that you haven you'll discover that this is not needed.

I completely fail to see what this patch achieve. The added code seems to be at best redundant with existing code, at worse introduce bugs (if not today, then later as redundancy gets out of sync).

This change does not looks like it make sense to me, because you don't know if it is actually taking ownership or not.

I conclude from the lack of answer that there is actually no reason to initialize the struct where it is.

I don't see any reason this patch should exists, and the description provides none.

Can you use the common denomination for backports, so that this can be grepped for? I just realized that I greened several of these, I shouldn't have. This is making keeping track of things in git pretty much impossible.

I'm going to green this for the sake of progress and this is fairly contained, but I think there are still problems in the API.

The approach looks sensible, but there are no test for anything. It seems like this does too little to constitute a unit.

The test are not passing.

Why does this depends on D9365 . It seems to me that verifying that the delegation is correct isn't really something that depends on being able to supply it. If anything, it should be done no matter what.

Please edit the diff's title and description, right now they are not even proper sentences.

You shouldn't put all the method in the header file. No need to recompile them in every module where they are included, unless they are trivial and you want the optimizer to see that.

I have nothing against generating proofs this way, but the abstraction provided is clearly not good.

In D9345#214194, @PiRK wrote:

What about bool hasDustStake(Proof p);?

Why are the changes to P2PTxInvStore ignored?

Ok, now this is looking more like something that make sense. There is this encoding/decoding of the session key that needs to be addressed, but beside that, it's all good.

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.

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.

On a side, note, if we commit to the proof score being the amount in satoshi, how do we handle overflows?

Wouldn't moving away imply to not do the translation in more and more places over time?

This is doing to many things at once. You should break this up, and, as you do so, you'll discover that there are various holes in some parts. This is just going to take forever to get all the parts right if they all prevent each other from moving.

You'll keep shuffling things around until you ask yourself the questions "What does the initialization?" "What does fetch the config?" "What does verify the validity of the different parameters?" and so on. Once you got the answers to these question, you need to apply them consistently.

You need to find what the right API for initialization is. Fixing the current API is mostly motion not progress. If you initialized where thing should be initialized, you wouldn't need to access the proof here now (maybe later, but later is later) and therefore, you wouldn't need to figure out what is the right API to access the proof.

The PR in the description is not correct

You need to read your code, it is telling you things and you are ignoring these things.