Double producing. Whether it is intentional or a problem of misconfigured backup node, using the same or different witness signatures, now it can only happen once per schedule.
One block producer double voting isn't going to make anything irreversible, because a 3/4ths majority is needed. The problem case here would be if a LOT of witnesses were double producing. This is part of the reason we don't just use something like a simple majority for irreversibility.
There is one scenario where that could happen: if a lot of witnesses configured a backup producer to "fail-over" produce if the backup loses contact with their primary producer node. Of course, such a node configuration has always been a bad idea and could always result in irreversible forks along the split line if it managed to split backup nodes on one side and primary nodes on the other> But the proper setup for a backup node is to have it ready to run, but require manual intervention to enable block production, so that a network split doesn't result in two irreversible forks.
I always thought it works the following way: when backup node detects that main node lost block and there is no contact with it, it creates a transaction to change key to its own (signed with witness key of the main) and starts producing. This way if the main node really died, backup starts to produce blocks next schedule, if main is ok and backup just lost contact with network, backup will temporarily be on a fork. In worst case backup and main will just swap roles. On top of it, if changing key was becoming effective for the network only if block containing such change became irreversible, in normal cases swapping producing node would still be possible, but in case of massive network split, the network as a whole would rather stop entirely (having not enough valid producers on either side of split) then to make the split irreversible.
But ok, if manual intervention on backup is required each time, that works too.
Block producer? Boy you talkin like this is EOSIO wheres @dan larimer and elon musk to get you hired at twitter lol
I think block producer is a better name than witness, so when discussing the concept in a generic sense (as opposed to one where the duties are specific to block producers on Hive, such as voting for HBD interest rates, block size, etc) I prefer it over witness. Of course, DanL is the guy who came up with the term "witness" to start with, so I don't think use of either term is "sucking up" exactly.
If I had to make a guess, block producer at EOS was probably coined by someone who felt that the previous term "witness" was obscure and vaguely threatening, same as me.
imagine when we have a blocktrades eosio main net chain just for handling transactions for blocktrades.us and you have people setup their own blocktrades block producers and use alcor.exchange style dex and yeah have a dex with some system with tokenized stake in communities set up to hold bitcoin and litecoin and ethereum etc