Slashdot Mirror
Ask Slashdot: What Is Your View On Sloot Compression? (youtube.com)
An anonymous reader writes: A Dutch electronics engineer named Jan Sloot spent 20 years of his life trying to compress broadcast quality video down to kilobytes -- not megabytes or gigabytes (the link in this story contains an 11 minute mini-documentary on Sloot). His CODEC, finalized in the late 1990s, consisted of a massive 370Mb decoder engine that likely contained some kind of clever system for procedurally generating just about any video frame or audio sample desired -- fractals or other generative approaches may have been used by Sloot. The "instruction files" that told this decoder what kind of video frames, video motion and audio samples to generate were supposedly only kilobytes in size -- kind of like small MIDI files being able to generate hugely complex orchestral scores when they instruct a DAW software what to play. Jan Sloot died of a heart attack two days before he was due to sign a technology licensing deal with a major electronics company. The Sloot Video Compression system source code went missing after his death and was never recovered, prompting some to speculate that Jan Sloot was killed because his ultra-efficient video compression and transmission scheme threatened everyone profiting from storing, distributing and transmitting large amounts of digital video data. I found out about Sloot Compression only after watching some internet videos on "invention suppression." So the question is: is it technically possible that Sloot Compression, with its huge decoder file and tiny instruction files, actually worked? According to Reddit user PinGUY, the Sloot Digital Coding System may have been the inspiration for Pied Piper, a fictional data compression algorithm from HBO's Silicon Valley. Here's some more information about the Sloot Digital Coding System for those who are interested.
If you read the original stories in Dutch, the whole story becomes a lot clearer.
The system he had was enclosed in a box and you could initially see his "demo" of 4 movies in low quality. There were various claims on Sloot's part that it was only x size but nobody was allowed to look into or program the system. He was going around investors fishing for money to make it work at bigger resolutions for his lossless compression algorithm. When he croaked nobody found anything in regards source code or design documents.
It's also mathematically impossible to get the file compressions he got. At best it was a reference to a pre-programmed movie.
Custom electronics and digital signage for your business: www.evcircuits.com
The conspiracy theory ignores Jevon's Paradox. As computing efficiency goes up, people buy more computing/storage/bandwidth since the increased demand driven by new applications swamps the decreased demand from greater efficiency. So Sloot's compression algorithm (if it really worked) would have likely driven demand up, and killing him would have made no sense.
Disclaimer: I didn't kill him, and this post is not an effort to cover up the conspiracy.
No, they can't. They could do double-spending attacks, but with fairly low probability and not without people noticing. They couldn't add arbitrary transactions, because transactions need to be signed by private keys that miners don't have access to. They can't commit invalid blocks because all other full nodes (crucially including the ones run by payment providers and exchanges) check the validity of blocks. They could fork and make their own chain, but anybody can do that and the fork wouldn't be very interesting if nobody was using it.
They can't do "anything they want".
It doesn't work. I've written some papers on this.
Basically, every set of easily-compressible numbers has the property that the next one gets farther and farther away at exactly the rate needed to ensure that the offsets from one to any other natural number require (in total) exactly the same number of bits as you'd need to just write those numbers out yourself.
Proof:
1) Suppose you could represent any natural n in [0,max] as c(n).
2) Then you obviously need to be able to decompress any c(n) to the corresponding n. Hence, c is bijective.
3) By (2) c(n) is just a permutation of [0,max].
5) As is obvious since (3) is a permutation, the total compressed size of the output range is equal to the total compressed size of the input range: Information content is conserved by permutations (Pigeonhole principle)
Now, your particular method sets c(n) = (k,o), where k is the nearest compressible number, and o is the offset, perhaps also compressed. It doesn't actually matter what compressor functions you use, the result is general:
The proportion of strings in your domain which compress down to less than m bits remains unchanged. In other words, there are 2^m strings in m bits, and the proportion in [0,max] is just (2^m)/max.
Set max = 2^(1000000000000), or the number of terabyte-sized files. Now just evaluate (2^m)/(2^1000000000000) and you'll quickly see why your compression algorithm doesn't work. It'll work for a vanishingly small number of bitstrings, just like how we can represent 10^23 using only 5 symbols, but as you go further and further out from those easily-compressible numbers, the offsets themselves become uncompressible large numbers!
--
- Oskar Lidelson