[I hope that I'm not simply demonstrating my abject ignorance in the following paragraphs.] I recall from my graduate school days that many communicating process mathematical proofs (virtually) passed the entire (linear) communications history back and forth; but this was several years prior to serious public research into crypto protocols. It occurred to me that using modern crypto primitives -- e.g., crypto quality hash functions -- one needn't pass the history itself, but merely the *hash* of the communications history, so the history need no longer be a merely "virtual" history, but a real parameter made of solid bits. Since a crypto quality hash can't be faked, and since we do have industrial-grade crypto, the *only* way to extend the communication history is by allowing parties A & B to *alternately* extend this communications history. Thus, we have a simplified version of a *blockchain* problem, where A & B *must* alternate, and *only* A can extend a history most recently produced by B, and *only* B can extend a history most recently produced by A. In essence, we're simultaneously building *two* blockchains: A's blockchain, which can fully "see" the items added by A but only dimly see (observe only hashed bits) those added by B, and B's blockchain, which can fully "see" the items added by B but only dimly see those added by A. [I have thought a lot about exactly what goes into the "state" of A and the "state" of B, as well as what should be included in the parameter packets added by A and B, but I thought I would start with the bare blockchain history idea.]