Hi everyone, I have a question considering the topic of this converstion.
If we have a situation like this: >> At some point t_0, it so happens that A and B each send a message (m_a >> and m_b) to all other participants at approximately the same time [0]. >> At t_0, the internal transcript state of A, B and C is the same. >> >> When C receives m_a, the consensus check matches and C updates her >> internal transcript state to include m_a. >> Now, when C receives m_b, the consensus check won't match since the >> internal transcript state of C includes m_a, while the consensus check >> of m_b doesn't (B was not aware of m_a when m_b was sent and hence it >> was not included in its consensus check). >> > That's OK. m_b's consensus check doesn't have to include every > message in C's transcript, it just has to be consistent with C's > transcript. Which it is! how exactly C checks the consistency of m_b's consensus check? I didn't get this explanation by Trevor: > On Thu, Nov 21, 2013 at 3:47 PM, George Kadianakis <[email protected]> wrote: >> Trevor Perrin <[email protected]> writes: >> >> Because your "consensus check" format contains the number of messages >> contributed by each participant, a receiver knows when the "consensus >> check" of a message is incomplete and can instead calculate the digest >> for that specific subset of messages. >> > I was thinking of something a bit different: if a message X is > received before its "causal predecessor" messages, the recipient would > set a timer and expect the predecessors to arrive before the timer > expires; once the predecessors arrive, X's consensus hash is verified. Maria 2013/11/26 Trevor Perrin <[email protected]> > On Thu, Nov 21, 2013 at 3:47 PM, George Kadianakis <[email protected]> > wrote: > > Trevor Perrin <[email protected]> writes: > > > > Because your "consensus check" format contains the number of messages > > contributed by each participant, a receiver knows when the "consensus > > check" of a message is incomplete and can instead calculate the digest > > for that specific subset of messages. > > I was thinking of something a bit different: if a message X is > received before its "causal predecessor" messages, the recipient would > set a timer and expect the predecessors to arrive before the timer > expires; once the predecessors arrive, X's consensus hash is verified. > > Not sure whether X should be displayed right away, or only after its > predecessors arrive (like Old Blue)? I guess that's more of a UI > question. > > > > This seems like it might work. But we should still consider some > > scenarios: > > > > - What happens if an evil participant selectively sends a message to > > n-1 participants? That is, all participants but one. > > > > If this happens, the n-1 participants will start including that > > extra message in their consesus check, but the single participant > > who was left out will not be able to calculate a proper digest. > > > > But I guess that's why you included the timestamp in the consesus > > check [0]: So that after a while (when the missing message can't be > > attributed to network latency) the client of the left out > > participant will be like "hm, something weird is happening with your > > transcript!". > > I think a timestamp isn't required for that, only local timers. Once > the victim recipient learns of the existence of an "extra message" > from any other participant, the victim will set a timer, and expect > the extra message to arrive before it expires. > > The timestamp would help a silent (non-broadcasting) victim realize > that everything she's seeing is causally consistent but, say, delayed > 1 week. > > But if the victim were to broadcast periodic, empty ACK messages with > consensus checks, you could maybe achieve that without timestamps. > The other participants would immediately realize the victim was > (unacceptably) far behind by looking at her consensus check, *or* - if > the victim's ACK was dropped - the victim would observe the other > participants fail to include her ACK within an acceptable time. > > > > - What happens if the consensus check fails? You said "then this is a > > security error, and the chat is shut down." but shutting down the > > chat so easily might enable DoS attacks that can be triggered by a > > single evil client who sends corrupted consensus digests > > Hmm, I *think* it wouldn't be that hard to report that "User A is > reporting a different view of the chat from B,C,D,E". You could > restart the chat, but if that happens repeatedly, you exclude User A? > > Another problem is that I'm assuming message streams are ordered *and* > reliable. I believe OTR traditionally has assumed ordered but not > reliable streams. Do typical OTR-supporting chat protocols drop > messages often? > > If you have to deal with unreliable message delivery, I think you > either need some sort of ack / retransmit layer, or some more > complicated consensus algorithm... > > > Trevor > _______________________________________________ > OTR-dev mailing list > [email protected] > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev >
_______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
