I'm not sure I understand you. If by such “Progressive” attack vectors you are referring to the way switching forks work (just above my "hey, isn't it an attack vector?"), then to use that for an attack you don't even need to have an account, let alone be a witness. You just send completely invalid (but properly formed) blocks in out of order fashion, then send a block that would connect previously sent blocks to form longer fork and that forces the node to unwind many blocks from main fork only to notice the very first block from new fork is actually bad, so the node wastes time for unwinding and reapplication of the blocks on main fork (and you can repeat that many times between blocks).
Such attack wouldn't work on Hive simply because, due to OBI, fork databases of Hive nodes consist most of the time of just one block - LIB - so there is nothing to unwind (therefore no time wasted) during such attack. And even in rare cases when Hive might actually have substantial amount of reversible blocks on main branch, two other factors make the attack unlikely successful and even then weak. First, as mentioned in article, Hive p2p now uses block id as p2p block message id, and that means p2p can actually see what block it is asking for when it talks to its peers - that is not possible for legacy chain nodes that use old message hash. It means it is much harder to trick Hive p2p into getting and pushing blocks out of order during live sync (when node is time constrained and when the successful attack would be most impactful). Second factor is the speed of block processing, which is much higher in Hive than in legacy chain, so even if the attack was somehow successful, it would still not do anything.
Even for legacy chain such attack is just a single node harassment, it won't collapse the network. Moreover you'd first need to make a tool that can talk with a node as if it was a legitimate peer - it needs to make proper handshake, produce valid "blockchain synopsys", then follow proper p2p protocol for showing inventory and sending messages. We actually "have" such tool, but at the moment it is just in a form of necessity (to enable emulating whole network of peers on a single computer for stress testing) and a concept. People I know that are capable of implementing it are busy with more urgent work. It has a working name though - mock-peer - so half done, right? 😄
Or simply a completely randomized order that shuffles continuously (maybe that’s the way it currently is?)
The witnesses are shuffled when schedule is formed and it is done in pseudo-random way, however, since initial order depends on factors that can be influenced with witness voting, it is most likely possible to manipulate that order - hats off for the person who can pull that continuously.
Ah, yes. Perhaps I misinterpreted your explanation of Progressive vs. Conservative nodes. I interpreted that as a potential attack vector, wherein Progressives (running new code) might try to inject blocks into the chain that would not otherwise be allowed (by the old code).
It is actually the other way around - Progressives want stricter rules (more regulation 😀 ). The article talks about what would happen if Progressives tried to introduce such change with a "soft fork" (as described in Investopedia definition linked at the beginning) without official hardfork. And the punch line is that such definition does not fit Hive.
Thanks for the clarification.