This type of analysis is crucial. We need more of it, so that those of us unfamiliar with core dev stuff can better understand the inner workings.
Thanks!
Based on your above description, it seems to me that a simple strategy to hinder such “Progressive” attack vectors would be to alternate the order of block producers based on their witness ranking as follows (or something similar): 1, 11, 2, 12, 3, 13, …, 9, 19, 10, 20, 1, 11. With the random “21st” witness randomly inserted somewhere in the middle of that list. Or simply a completely randomized order that shuffles continuously (maybe that’s the way it currently is?).
Maybe this, or some similar approach, is already implemented?
The point I’m making here is that 1, 2, 3, …, 18, 19, 20, “21”, 1, 2, 3, would allow Progressives a chance to stack blocks by inserting themselves into the lower tier of the witness list all at once, then produce multiple successive “would-be-invalid” blocks.
I'm not sure I understand you. If by
such “Progressive” attack vectorsyou 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? 😄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.