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.

Why not just check for IBD status in runEventLoop ? What benefit does all this complication achieves?

Some open question, but this is better.

What problem removing the distinction between master key and session key solves? It seems to me like it's making security of the whole thing worse for no good reason.

The use case does not make sense. You don't want to have a long delegation chain for all the node one after the other anyways, you want to have a master key and delegate to each node. There is no point delegating to begin with if the master also have all the private key to which it is delegating. If you want to do that, you might as well distribute the master key instead of devising a complicated scheme that isn't any more secure.

You want to fix the proof size handling before moving on there, or you'll just multiply the point where this needs fixing.

What problem is this solving?

rebase from hell

Make it a config to begin with.

Back to your queue due to test failures.

The config is needed down the road is just saying nothing at all.

You say that it differs from the original by passing a config, but provide no reason as to why. It doesn't looks like to me that this difference is justified.

In D8899#204315, @PiRK wrote:

I added a few tests, but now I 'm no longer sure that all situations described in the PR are possible. I don't know how to reasonably generate a CTransaction whose outputs would add up to an int64 overflow without any single one of the outputs being larger than MAX_MONEY.
It would require 439208192231 outputs.

I know there isn't int he original code, but there should really be tests cases for this.

Address comments

rebase

The requested change differ from the existing code style for a benefit that is at best elusive.

Remove debug logs