Bug in ABA protocol's use of Common Coin

[amiller]

Bug in ABA protocol's use of Common Coin

[afck]

As an optimization, after we've received N - f CONF messages, we should probably use the minimal value set as vals of which we know that at least one honest node put it into a CONF, to make termination as likely as possible?

I.e. if we sent CONF({v}) ourselves or we received f + 1 CONF({v}), we set vals = {v}. Otherwise vals = {v, w}. Then if the coin is also v, we can terminate. (Even if originally we had arrived at {v, w}, and sent CONF({v, w}).)

I wonder if it would be safe to use vals = {v} even if neither of those are true, but if in the meantime we have collected N - f AUX(v) messages (so now we wouldn't need the other AUX(!v) messages anymore, and realize we could have sent CONF({v})) — or would that reopen the doors to something like the original attack again?

Edit: …or would that actually make termination less likely, because we would be less likely to switch to the coin value, like possibly all the other good nodes?
If we can justify both {v} and {v, w} with the above arguments, should we use {v} only if the coin is v, and otherwise use {v, w} (i.e. switch)?
Probably there is no right answer, and the best strategy depends on the number of faulty nodes, and the current distribution of estimates. Something like: If the coin is not v, use whatever the majority of the CONF messages says? (Never counting invalid CONFs, of course, with values not in our own bin_values.)

Edit 2: And would it be worth doing the CONF round even in epochs with a fixed coin, just because it makes it more likely that we can terminate? It would increase the number of message rounds in the most optimistic case, but since ACS has to wait for all ABA instances, it is as slow as the slowest out of N ABAs.

If we go with the first rule — always use {v} if you can —, then if we received N - f CONF({v}) messages, we know that at least f + 1 correct nodes sent CONF({v}) and therefore will use vals = {v} and not switch to !v, even if the coin is !v. We therefore know that v will end up in bin_values in the next epoch eventually, and could send both BVAL(v) and AUX(v) right at the beginning of the next epoch, and put v into bin_values right away. If enough nodes do that, it would effectively remove one message round from the next epoch.

[xygdys]

There is a bug in the CONF Phase implement
https://github.com/initc3/HoneyBadgerBFT-Python/blob/e8bcbc081dfb5d1e7298039d47bbebf7048b8e62/honeybadgerbft/core/binaryagreement.py#L40

The message broadcast on line 40 should be values, which is the output of AUX Phase, instead of bin_values. Otherwise, the security guarantees of the AUX round would not take effect!