The behavior of addProof changed, yet no test changed. This is suspicious.

Upon looking at what comes next, this is obviously not good to go.

Why does this come AFTER the patch where sqllite DB are created by default?

So the goal here is to create wallet, using sqllite, with zero test by default?

And test plans still test nothing at all.

So at this stage, this whole thing is still untested, yet reachable by users.

You test plan really tests nothing at all.

Is it something we want at all now that we don't want to store the orphan in the proof pool? Also, it seems like you are slowly recreating fetchOrCreatePeer with extra steps.

This is strictly more code and complexity to do the same thing, slower. I don't see what this brings to the table. The diffs description says what the cod does, which i already knew looking at the code, but in the absenc of a justification for this, I see no reason to even consider moving in that direction. This is strictly worse on all fronts.

I don't think this makes any sense. If there is a concurrency problem, then the right way to solve it is to use locks. Right now, we don't do concurency within the peer manager, so no lock needed.

Please send a link to the PR itself so we can see the discussion and associated code.

I think this is probably worth splitting in two, that would make review significantly easier.

Overall, lgtm. This is indeed much better.

I'm sorry none of this makes sense.

Rebase