double dPriority = -(*mapPriority.begin()).first;

This would have been easily caught except that it gets buried under the mountain of other unresolved compiler warnings. Doesn't seem worth the bother to regrind just for this; there's various other unused bits lying around that could be garbage-collected in one go at a later point.

There's still time until 2028 and surely even after that, what's the hurry?!

And that's just the one we *know* about from MP's grep-driven survey. But no worries, somebody will have fixed boost by then!

At any rate, the "inconsistency" of having something clean while there still is otherwise around a lot of dirty stuff is simply the first step of any cleaning process in practice

Indeed, it's more akin to mopping half of a long-neglected floor than to mowing half of a lawn. "But it makes the other half look worse by comparison" - good!

how do you jump to the conclusion that it's this a significant factor that slows down the initial sync process?

To be clear, I don't put it as firmly as a conclusion at this stage; but the question stands as to why I even suspected it, "wovon man nicht sprechen kann, darueber muss man schweigen" and all. I dug into my logs and found there was more history to it than I first recalled here:

1. In July-August 2019, I was dependent on a PRB (0.11) node on my main, Gentoo machine which I had allowed to run critically low on disk space. Rather than mess with HDD upgrades I was trying to solve both problems at once by getting TRB running on a Gales machine with new SSD. In order to get it synced as fast as possible I wanted to feed it by local connection to the existing node, meaning it would need to not ban said node.

2. At the same time, Robinson already had his coin on a TRB node and was trying to fund a deedbot wallet for Pizarro hosting. He consulted some websites to pick an economical transaction fee and sent, but it got stuck. He guessed that maybe his TRB-only peers had a higher minimum relay threshold set (though now we know this wasn't how it worked as there was no threshold setting per se). One thing we tried was rebuilding without the ban-hammer to get it relayed to prb-net, as an easier first step before implementing the missing "getrawtransaction" so as to try pushing directly to block explorers.

3. In September 2019 my new TRB node finished syncing; just after it reached the tip it stopped getting anything but bastard/orphan blocks. I tried lifting the ban-hammer, I suppose because it was in my toolbox and fresh in mind, and it synced up straightaway. I also noticed I seemed to be feeding a number of other nodes, in that I'd log 2-5 "received getdata for: block ..." after each incoming block; this despite not having any unusually wide or fast connectivity otherwise. A few weeks later I restarted the node for unrelated reasons, going back to a fully-strict build, which over the next days would again get hung up receiving no usable blocks. Again I restarted with the relaxed version and again it got synced.

4. In February 2020, mod6 reported a number of nodes stuck at block 618406. I tried restarting with the relaxed version, which again worked, and shared my notes; also noted in #o. Since apparently lobbes didn't manage to crank the link archiver I've now fished out the paste ref (and begin to wonder why I even used pastes instead of just putting text files in my own web space in the first place).

5. In February 2021 I noted my node was persistently lagging again, though at least getting blocks in small bursts, hourly or so. Again I tried relaxing it, with a proper vpatch this time (though just removing the ban, not adding an option as seen here); at first it didn't help, but my "addnodes" list had enough TRB peers to fill up its 8 connection slots. Upon pruning this list it again got moving, and appeared to be feeding 4 other nodes. In May 2021 Robinson reported running for months without a hitch using the same patch.

As far as contrary evidence, I do seem to recall intervals of block starvation even with a relaxed node, but haven't found mention of it on this dig.

I can even agree that such a comment would certainly be a useful addition to the patch itself but I'm not all that convinced that it really is much of a solution to what seems to me a deeper problem.

That's a fair point about moar comments. Not sure it's quite worth the bother to regrind at this point just for this; perhaps if any other issues come up with the patch. Otherwise I can bear it in mind for next time.

But it's at best a closer-to-the-code variant of commenting on it here; in any case it requires the author to notice and call it out, which does nothing for the patch reader whose proper aim I'd say is to mentally reconstruct the meaning of the change without taking anyone's word for it. I haven't managed to conceive of any way around "bringing from home all the context" though. You could perhaps - at review time if not at signing time - drop the magic number of three lines and have diff show the whole changed file as context.

Some MP refs that came to mind on the question - just to capture them, with no particular conclusion - were on the fundamental function of talmudic commentary in maintaining this kind of codebase and his search for a universal comment format.

As far as I can tell, this establishes JWRD Computing as not just the most active but the sole current maintainer of the rough yet uncorrupted codebase inherited from Satoshi Nakamoto.

There's still time until 2028 and surely even after that, what's the hurry?!

Actually this is a recurring theme when I work in this codebase: in order to get anything done I either need to do it in the same stupid way as the existing examples, or else do it the simple and obvious way but create inconsistency, or else get sucked into fixing ALL of it.

Fwiw, in my experience this is a recurring theme whenever working with legacy/unmaintained or even simply large-and-old-enough codebases, really. At any rate, the "inconsistency" of having something clean while there still is otherwise around a lot of dirty stuff is simply the first step of any cleaning process in practice (as opposed to in theory where everything is always fully consistent and all cleaning of everything can be and is also best done fully in one single step and so on and so forth).

and that ignoring this situation only serves to isolate one's node, contributing to a sometimes unbearably slow initial sync process.

Not that I see any problem at all with actually letting the user decide (oh, how unclean of the user to want to ever run some code that might talk to "heathens" at all, I know) but how do you jump to the conclusion that it's this a significant factor that slows down the initial sync process?

It further turns out that of that dozen, only four are actually used by bitcoind! (Plus possibly one indirectly: at least part of boost_system is pulled in by boost_filesystem.) And yes, bjam readily provides a way to specify which parts to build. Who knew?

Ha, well done!

These are details that I suspect would be entirely missed when reading just the patch on its own, a point perhaps worth some deeper pondering.

This is an important point I would say and it actually does feed into one of the reasons why I'm still pondering the next step with VaMP - I start suspecting that the whole bare-bones approach of "here, read this diff and bring from home ALL its context" is not such a literate approach to coding as it might like to brand itself (even if it arguably was, back in the 1980's, perhaps). Sure, it can be argued along the lines of "there should have been then a comment in the code pointing out this sort of context-based detail." I can even agree that such a comment would certainly be a useful addition to the patch itself but I'm not all that convinced that it really is much of a solution to what seems to me a deeper problem.