Recently it occurred to me that one could potentially design an interactive "compression" scheme which seems to allow for arbitrarily high compression ratios, at the sole expense of time. This already sounds pretty cranky, I realize that, but here is a formal description of the protocol which I hope makes sense:
Define a data store as a tuple $(\mathcal{O}, n, \delta)$ with $\mathcal{O} : \mathbb{N} \to \{ 0, 1\}^n$ a random oracle. We say that the data store "contains" the value $x$ at a (real) time $t \geq 0$ if $\mathcal{O}(\lfloor t \delta^{-1} \rfloor) = x$, such that the contents of the data store randomly change every $\delta$ units of time. A data store could be realized in software using the current time in some agreed-upon representation and any cryptographic hash function.
Alice wants to sends a message to Bob encoded as a bit string as part of an interactive protocol (Alice and Bob are both present and active during the transmission). First they both agree on a suitable $\delta$ such that they can both resolve the current time to within $\delta$ units of time. Then, Alice chooses an integer $n \geq 2$, instantiates a data store $(\mathcal{O}, n, \delta)$, and sends these parameters to Bob, and then breaks up the message into $n$-bit blocks. For each block, Alice then monitors the data store until its contents equal the block, at which point Alice sends a single bit "1" to Bob. When Bob receives this signal, he looks up the contents of the data store and retrieves the corresponding $n$-bit block (possibly rewinding as needed to account for any transmission delay, this is feasible as long as the transmission delay is fairly constant and known to within $\delta$ units of time). When the last block is sent, Alice sends the bit "0", Bob computes a checksum of the message and sends it to Alice for verification.
If the message contained $m$ $n$-bit blocks, the total amount of data actually sent (outside of protocol overhead) was $m$ bits, achieving a compression ratio of $1 - 1/n$, and it would take an expected $m \delta 2^{n}$ time to successfully send it (that is, $\delta 2^{n} / n$ time per bit). Also note that since this scheme doesn't actually use any structure in the message, it can be given already compressed data to compound any already attained compression ratios: the two are not mutually exclusive.
Clearly this doesn't allow for amazingly high transmission rates in general. A realistic usecase could be communication with a space probe, where the light-time transmission delay may be accurately computed allowing for a very low $\delta$, say, $\delta = 10 ~ \text{ns}$. Then we can achieve decent compression ratio/transmission rate tradeoffs, e.g. 94% at 3 KB/s ($n = 16$) or 90% at 122 KB/s ($n = 10$).
It gets exponentially more time-consuming to send data as $n$ increases, so 95% compression ratio is probably about the best one can practically achieve in reasonable time in the general case.
Obviously this only works as an interactive protocol, not as an offline protocol. Also, it doesn't really work "as-is" in real life because you can't just send 1 bit on most channels, as each communication entails a nontrivial amount of overhead (TCP/IP packet, etc..) but in principle I don't see why it couldn't work.
So, does anyone know if this kind of "temporal communication" has been studied before, and can point out any fundamental or practical problems or errors I overlooked that might explain why it isn't used?
