it's not even just the power rangers (to the extent anyone cares to distinguish, as if a spamming attack on bitcoin codebase maintenance is somehow totally different from a denial of service attack on same)

It's not even just the power rangers who deny the possibility of deep reorgs / fork unwindings, since there's the once supposed alternative playing the part of controlled opposition by doing the exact same thing. So no, I don't call TRB/TBF people and Stan in particular the code spammers, but I do call them the DoSers, sitting all those years in the seat of power, privilege and publicity granted by MP's say-so and doing jack shit with it: not just by the broader goal of community development and outreach but even by their own narrower self-professed goal of codebase cleanup. Or telling whoever came by with difficulties building or running the code that it was their own problem until proved otherwise by extensive effort (and not just regarding Bitcoin or with newbies). Or as already linked (nao with moar context), misrepresenting a vulnerability as having been closed.

But I can quite forgive the reader for confusing who I was putting in which category of attack, that being the larger point after all - who cares, they're not worth distinguishing outside of entomological interest.

So no, I have no further use for Stan's opinion on anything; or how did it go? "I do not bite my thumb at you, Sir. But I do bite my thumb, Sir."

where you could bring argument to Stan personally

To quote the prior exchange Jacob mentions :

2020-05-20 12:06
asciilifeform: if he has q's re trb at any pt (or for that matter re fg, or any other piece of asciilifeform's tech that he's tryin' to get rich off) they will have to be answered by someone other than asciilifeform .
...
2020-05-20 15:22
jfw: So if I take others' warnings it's biorobots, fatwas and strafbaten, while if I try to figure things out myself it's wankage. I suppose now if I use alf-techs it'll be "monkeys with no hands living in temple they could never have built", while if I replace them it'll be "aryan physics and hostile forks".
jfw: Curious game, only way to win is...

I supposed it's not a surprise, but par for the course he incorrectly inferred personal attack where there wasn't one. I read Jacob to be saying prb is doing the spamming on the codebase, which pretty much all would agree with. If you take the time to actually read the link on denial of service attack and the article it's from in comment #2, you may learn for the first time your nodes remain vulnerable to the DOS attack you think was patched years ago, a patch which was never included in the official 'tbf' tree anyways.

Perhaps a better use of ya'll's time than assuming we're scared of talking and ought "nut up" would be to get off your high horse and start looking into the documented vulns your nodes run limp with and/or lower hanging fruit like fixing all those oh so many broken links on your "how to build".

P.S. What's one reason Jacob or anyone else should go to Stan wrt Bitcoin maintenance when there's a direct quote from #therealbitcoin above wrt his expressed and later signed move to "cement" betrayal of the Bitcoin protocol in his tree and ignore any chain that comes along with a deeper fork than the magic number he coads or allows users to configure ? How is that betrayal of the protocol substantially different than USGavin's ?

Because he's your supposed friend whereas Gavin's your enemy ?

Each of us decided years ago not to work with the other, and for significant reasons it would appear. I have no desire nor need to "reprogram his head" nor convince him of anything and so I leave him alone.

To the extent I quote him now, it is for my own needs to speak my truth, to clarify and differentiate my approach where past association could otherwise be misconstrued.

Is addressing issues as they occur really the right way to go about understanding/maintaining the bitcoind codebase?

Good question, being more proactive with the work and bringing on more people to help with it is a priority. First step is I need to publish the higher level road map with concrete steps to get there. Being more deliberate with the work can also raise the odds of improving the cashflow to support the work.

As far as the fabled trbi, perhaps that's the holy grail, but how does one get there ? From our perspective, the manageable way to go about it is to clean up the Satoshi codebase as much as possible such that the protocol can be understood well enough to be specified.

I don't see a connection here to the goose chase / rat race of enumerating badness. The amount of badness in the code, while perhaps large, is bounded (and note that I've already cut out large swaths in single strokes such as boost libraries).

As far as a rewrite from scratch, it's a seductive idea but uhm... have you ever tried reimplementing a complex protocol with no spec, a messy reference and an absolute requirement for full compatibility ? I think you overestimate how green is the grass on that side. From my own experience, I couldn't even get a rewrite of my own Scheme interpreter to full compatibility much less acceptable performance after about a month of luxurious undistracted hacking. The core tends to be fun and easy but the periphery is large (the long tail of the details).

Most of the problems Satoshi had to work through were of his own creation. The sadness is that it's an ugly, kludgey prototype for a jumble of half-baked ideas that got stuck promoted to the role of production implementation of the one great idea. But that's the reality we have to work with.

I must say though that this whole ordeal made me think of points two and three from the six worst ideas in computer security.

Is addressing issues as they occur really the right way to go about understanding/maintaining the bitcoind codebase? It seems that this article is a (successful!) swing of the hammer in a game of whack-a-mole.

I remember a while ago there was discussion about writing 'trbi'. This was to be a version of bitcoind done the right way, although iirc it also included changes to the protocol. Maybe writing a bitcoind that is compatible with the current chain in order to more intimately understand all the problems satoshi had to work through and then afterwards mapping/annotating all of his code is a better way to get bitcoind closer to the ideal than addressing problems as they occur.