Shared information at each endpoint can be used to communicate efficiently but it doesn't qualify as "data compression" as that is currently defined. For exampl

Shared information at each endpoint can be used to communicate efficiently but it doesn't qualify as "data compression" as that is currently defined. For example, if you have a library of books on your end then I can send you a few byte number (the ISBN) to identify a specific book instead of sending a normally compressed copy of the whole book. If you compare the few byte ISBN to the byte size of the book, of course the compression rate is phenomenal but this normally isn't considered data compression but it is related. A real life example is Binary Delta Compression that Microsoft uses in their Windows Update protocol. If you make minor changes to a file in going from version 1.0 to 1.1 say, then instead of transmitting the whole file WU just sends a file identifier + the bits that need to be modified. This is a trade off between sending data and computation at the sending and receiving end. Every so often I read about someone who has the idea to generalize this. The idea is to use/index the standard Windows installation (or something common on most computers) as a "library" to reference. Then to "compress" a file you send a sequence of pointers to the library necessary to recreate the file you want to send at the other end. The problem with this is twofold. First, it takes a lot of computer power to analyze a file and break it down into library references. Second, you are on the wrong side of 2^n and as the file size increases the probability that it or large pieces of it are contained in the library quickly goes to zero. The only way that Sloot's idea would work is if he found a way to generalize this for random (i.e. already compressed or high entropy) data and a method to define an easily created library on the endpoints that is comprehensive and independent (i.e. a basis) for random data. That is a tall order.