CRDT semantics for the authentication transactions #41
Description
Currently, authentication transactions are ordered, which means the desired state depends on the order of the tx processing. This is a very serious issue due to the racy nature of the gossiping.
What we effectively want to have is either:
a) proper implementation of the ordered transitions - this means generating proper requires and provides tags for the transcation pool, or
b) make the transactions semantics unordered - which would eliminate the need for ordering in the first place.
To implement (a), we already have a nonce provided by the robonode, however if the robonode issues the nonce, and it's then lost (i.e. the tx with it is never submitted to the network) - then the successive transactions won't be able to form the chain (due to a missing link) and we the bioauth process will be stuck. There are workaround that we could implement there, like having the network generate the nonce first to reserve the place in the queue, and then authorizing at the robonode with the nonce provided - but it's complicated, and will require way more complexity than going with (b) (as in we'll need epoch- or block-height- based timeouts, etc).
As for (b) - it is way more in line with our original design. To achieve it, all we have to do is ban both the incoming and existing keys, rather than only the new key. Currently, we have the semantics of "rejecting" the conflicting auth ticket. If we instead add both the conflicting auth tickets (i.e. both the new one and the one already in chain) to the "ban list" - we'll be good to go.