This is neat idea, T.C. May. Here are some things that popped into my head thinking of it. I think the idea of multiple encryption of the time-delay message would be extremely useful here. Imagine this. You encrypt a message with as many layers as there are intermediate escrows. In other words, a message is encrypted with layer1 pw, then reencrypted with layer2 pw, then layer3, etc. In the decryption message (separate) there is a long sequence of keys. The lower-level keys closer to the actual message are also encrypted by the higher-level keys. Now, suppose that the way the message is held is this: after 1 level of protection has elapsed, the password message and the encryption message are recombined to a single escrow agent. That agent uses the top-level information (one key is plaintext (maybe not), or encrypted with that agent's public key, or whatever) to decode the top-level of encryption. Then, he again redistributes the next-lower-level of encryption password message and actual message to unique escrow agents. The beauty of this is that a given escrow agent, even once he gets a password, can only strip off "his" topmost level of encryption (at least, that's the intent). He is powerless to decrypt all the lower levels and hence the message itself. Therefore to actually decrypt a message ahead of time would require the collusion of many operators. The message should have some kind of indications at each level when it is to be "reconstituted" (just add water), and escrow agents of course should hold or reject messages that are sent to them for premature decryption. There is also the distinction of "joiners" and "storers" although the two could be combined in some way (both are "forwarders"). The final destination should be the destination the original owner intended, so that there is no final escrow agent that can decrypt the message. He only has an encoded message he can pass along, and another agent only has a meaningless key and the final address as well. When the final destination is reached, the last layer of decryption can be removed by the intended recipient (the money is in -X- account, password -Y- or whatever). I.e., the recipient is the final "joiner". The idea of separating keys and the encoded messages is really ingenious, and I'd guess this "disassociation" has other uses as well. An encrypted message with a password *existing* but *inaccessable* is just as secure as a message using conventional encryption. In fact, there is probably an added dimension of security---in most systems *somebody* knows the key, but here, if it is generated automatically, even the *key* is unknown for awhile! Another possibility is to have some kind of standard protocol for time encrypted messages (this is interesting and seems feasible). Let's say I want a message [x] to be unencrypted on date [y]. I call a "time encryption server" and ask for the secret key associated with my message and date [y]. I encrypt the message and publicize that version. The time server is constantly spewing out the daily code for messages that expire on that date. Anybody just listens to the broadcast and decrypts the messages in their possession using the key. Note however that it is crucial that somehow the key depend on the message itself (via the hashing approaches), otherwise everybody knows everybody else's keys ahead of time just by submitting messages to the server for the particular date. I suppose public-key encryption could be used here but I'm hazy on the details. P.S. this is a really tricky situation compared to above, but it might be possible to make messages with "insecure" passwords that can be broken in a few lifetimes from searches. Of course, this depends very crucially on the pace of technology and the resources devoted to the cracking, two highly variable factors. Also, keep in mind that every message in existence relying on complexity of algorithms is encrypted based on the time-delayed release of revolutionary and unforeseen computer techniques in cracking... or, more specifically, the gamble that they will not occur...