Rebase

Use using instead of typedef and use the proper naming convention for types.

I don't think this really make sense. What happens to the previous proof?

I don't think this depends on D10222 anymore.

You should remove the whole peerid business, it doesn't seem relevant to the first iteration.

Remove the whole proof handler thing. Test from addProofToReconciledirectly.

Ok I think I'm getting a sense of where this is going. This patch definitely suffers from doing too many things. The whole ConflictingProofHandlerbusiness could be extracted from this and put in another patch.

I'd like an explanation of what's going on here. If this is presumably something, then there is a way to test if it is that thing.

The PR clearly doesn't match.

You very often have these build failures. Are you running your test plan?

Ok, nevermind, the assumptions are there, but we have a file for that. This avoids baking in contradictory assumptions.

I don't think it makes sense to have many different way to serialize the exact same thing, or to back the addresses in the consensus layer. None of this seems to me to be a good idea.

I don't understand what that does, considering the address is a representation of a script to begin with.

It seems that this comes after core added some tooling related to determinism in tests. Why is that out of order? Is there a plan to get that as well?

There are obvious problems with this. For instance, one can completely disable avalanche by flooding the system with proofs. While it is not expected that all problems are solved right out of the bat, this is somewhat surprising that none of the limitations have been thought through and do not inspire confidence that this is moving in the right direction at all. Documenting known problems in the code, in addition of having the benefice that problems are documented in the code, is the only way a reviewer can asses if the person writing the code is actually moving somewhere sensible with it.

Test suite is broken.

This is probably a good idea to add a linter to auto fix this, just like it is done for uint8_t .

It would be preferable to change these names for something that follow the proper convention, rather than changing them from one name that doesn't follow the convention to another.

This is not very good because you are removing the function call, with an explicit name.

I don't really like the design of this.

Can we change the default and remove the option in two separate steps?

I still don't see what problem it solves. This whole thing's purpose is *to protect good nodes from eviction* . From that perspective, nodes for which we don't know and nodes which have a bad track record don't really differ: if they aren't good node, there is no point protecting them.

I don't understand what problem this is solving. The description isn't describing a problem that this solves. I'm no convinced this is needed at all.

The approach looks reasonable overall, but I don't think the avalanche book is very necessary.

I don't think this approach makes sense. Peer score is used to chose the poling frequency, so this metric should show in the node's avalanche score. I think you are trying to optimize something that shouldn't exist here.

I haven't reviewed everything, but it is clear that this is mixing refactoring with actual functionality. Please extract the refactoring in their own diff.