On Sat, Nov 30, 2013 at 5:57 PM, Ximin Luo <[email protected]> wrote: > > (Maria, [1] is the OldBlue paper?) > > I just read that myself, and can now see that the DAG model it proposes is the > same as the one I mentioned in that other thread I started. Sorry for not > reading through everything. I was also thrown off by the description of the > "consensus check" which seems a separate thing from OldBlue, which requires > hashes of all previous messages. > > I don't think this is necessary though - when you send a message with its > parent(s), this commitment is treated transitively, so you don't need to > explicitly publish that you've seen the non-direct ancestors. What does "all > previous messages" (explicit transitivity) gain us, Trevor?
I was assuming the message stream from any user to another is ordered and reliable, so committing to all predecessors is fairly easy, you just commit to the most recent message from each user. But I agree that committing to DAG predecessors would result in smaller messages, so could be advantageous. OTOH, piggybacking all predecessors means the recipient learns all predecessors for a message upon receipt of that message. That has advantages too: * In an OldBlue-type protocol, the recipient could issue LostMsg requests for all missing predecessors right away, instead of needing multiple rounds of waiting for lost messages to arrive before discovering more predecessors. * In a simpler "consensus-check" protocol, if the "timeliness" check fails on a message's predecessor, the recipient has fuller information on the security fault. For example: Suppose that we're only piggybacking DAG predecessors, and A receives a message from B whose DAG predecessor is a message from C. If the C message doesn't arrive within a time threshold, A's client could display: "ERROR: messages from C are not arriving in time". But the C message might have other predecessors that may (or may not) have arrived. Yet A doesn't know about them! If all predecessors were piggybacked, A could display a more accurate message, e.g.: "ERROR: messages from C and D are not arriving in time". So this seems like a trade-off, one approach or the other may make sense in different situations. Anyways, you wrote a lot else!, I'll try to look at some of it later... Trevor _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
