Although I support general direction, the devil is in the details. I can't help but worry that OBI might expose the problems we never knew we already had.
For example in current code witness can only change his vote once per schedule (he can produce block B that has no his previously produced block A in the chain, because he switched forks in the meantime), it can happen only in very specific situation and it still depends on other witnesses if they will accept that change of heart (they can still be on a fork that includes A but does not have B). With OBI the same witness can potentially change his vote couple of times per block, so if there is any problem that would be exposed during changed vote, OBI will make it that more likely to actually happen.
Then there is also a problem of witness signature. Witness can change signature. With current code such change will matter during next scheduled block for that witness. What about OBI? Note that changed signature can still be a pending change (but already in the state)... hmm... I actually wonder if it isn't a problem today (witness changing signature and producing block signed with new one being accepted even though the transaction that did the change was not yet included in any block, possibly never becoming part of one due to expiration for example). I did not check if we could potentially have such problem, I'm just thinking aloud, maybe we actually have something that prevents such situations.
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. With OBI the same node can legitimately vote for some block but revoke that vote immediately after receiving new block on different fork. Depending on network propagation some nodes might think the vote is still valid and act on it - they won't be able to switch forks even though they might find themselves in minority.
You are viewing a single comment's thread from:
This is irrelevant for OBI. Doesn't matter whether BP votes with old signature and vote gets accepted or votes with new signature and gets accepted. BP still only gets one vote and that's all that matters. And all such votes aren't even retained, so no issue for replay either. Further, note that it is not a big deal if a BP's vote doesn't get counted because some node might not have applied the pending signature change, it's just one less vote towards irreversibility.
As to votes cast "by block linkage", all pending transactions are rolled back before applying a block, so no pending signature change will allow a BP to sign with the pending signature. So if BP changes their signature just before they produce a block and then use that signature (not sure they would and would need to check code to see if they do), then their upcoming block would just be rejected.
Yeah, I shouldn't have been writing so late at night it seems. I realized the pending being undone when I woke up, but you already pointed that out :o)
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
While the above statement is literally true, it's too vague to address unless you have some more specific potential problem. For example, I could make the same statement that if there's any problem in generating transactions, allowing more transactions in a block increases the chance for a problem. It's true, but without pointing to a concrete problem that is exacerbated, there's nothing to really discuss.
I don't have specific problem yet, I'm just worried about potential of having one.
When it comes to transactions, allowing bigger blocks means allowing bigger transactions (I don't know why it is so, but transactions are limited by block, not by their dedicated constant, possibly to potentially allow bigger custom operations). If there was an operation that slows drastically with size (f.e. some linear search in handling code, or a bug in JSON parser, etc.) then as long as blocks and therefore transactions are small, we won't see the problem. Once we allow big ones, the problem we already had, but hidden, suddenly appears, potentially endangering the network. I see similar potential with OBI, especially that at least for the moment it seems to me like it will make irreversibility a forking choice. Currently when new block is accepted, the block 15 signatures below becomes irreversible. Since it already had 14 signatures, it is highly unlikely it will not be irreversible in other forks, even if recently accepted block will end up being dropped. With OBI two different head blocks can become irreversible (I hope not, but I'm not yet convinced they can't) because they might receive enough votes each in different parts of the network, just some of those votes were revoked in the meantime.
If witnesses are changing their votes then yes you can get two different irreversible head blocks. I would suggest that witnesses not ever change their votes. Of course, you can't literally prevent it, but if it is discouraged, you can probably rely on "enough" witnesses not changing their votes to prevent the problem.
I'm not sure this is actually sufficient when there are forks.
Yes, he's talking about the case of a fork switch. And originally I was also thinking that we had implemented it so that a block producer would cast a new vote for a block during a fork switch (which I think would be ok).
But I was wrong, instead each node keeps track of the last block number it voted for, so it won't cast another vote at the same or earlier block height. While this latter optimization isn't IMO necessary to prevent an irreversible fork, it does reduce the number of votes that get generated during a fork.
I'm not sure it would be okay if multiple votes were cast. You can't be sure that every producer sees every vote. So half may see one vote as part of a 3/4 majority (therefore declaring one fork as immutable) and another half may see the other vote as part of a different 3/4 majority (declaring the other fork as such). This will never resolve because each half will be permanently stuck on their own "immutable" fork.
Yes, its true that it makes it "worse" if multiple votes are cast and that was one of the considerations for avoiding it. But it would still take 50% of them doing so to get a 3/4ths majority on both sides.
In the general case of intentionally bad nodes, they can always cast different votes to different nodes and 50% bad nodes can cause an irreversible fork (that's the term I'm using for what you're calling an immutable one, figured it's best if we stick to just one term for it).
But avoiding two votes by good nodes prevents them from ever inadvertently behaving like a bad node, so practically speaking it is much better if they don't.
Intentionally bad I'm not concerned about here. I'm thinking of a "good" node that changes its votes but then the votes propagate differently. But if good nodes don't change their votes this can't happen.
I'm still not 100% sure about different situations with fork resolution. I'd feel better if there were a more detailed mathematical analysis, or clear reduction to a well-known consensus algorithm, but even without it may work "well enough".
When we did the initial napkin design, we wanted a protocol that would allow for anything less than 1/2 of the witness to be behaving badly. So, the obvious worst case here would be 1/2 bad witnesses voting on two sides of a fork. In such a case, both forks would have 1/4 good witnesses + 1/2 bad witnesses and a 3/4ths majority would be achieved on both sides of the fork.
I wasn't necessarily viewing it as "bad" unless it is defined that way, which wasn't clear to me. The comment about changing votes many times suggested it might be considered as legitimate behavior, but if not then it seems fine that "some" threshold of bad witnesses can break it. That's essentially unavoidable.