Free Energy | searching for free energy and discussing free energy

Solid States Devices => solid state devices => Topic started by: nix85 on July 16, 2020, 06:57:03 PM

Title: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 16, 2020, 06:57:03 PM
i know this is not overunity, but it kinda is..

it has already been discussed here https://overunity.com/7456/another-strange-story/

in case you didn't hear about it, jan slooth was TV tehnician from netherlands who after 20 years of research in 1995 created a data sharing technique which could allegedly store a complete movie in 8 kilobytes. 1 day before he would hand over the code an would be a multimillionaire he died of a "heartattack"

he allegedly played 16 movies simultaneously from a 64kb phone card

he said it was "so simple a simple tehnician could figure it in a second if shown the source code"

he was EXTREMELY paranoid and secretive about it

>> https://www.youtube.com/watch?v=jLp5gS9h9UI

data to be sent was 2 million times smaller than the original.

if taken literally, this would be like to squeeze lets say 1999999 various numbers into 1 digit. impossible like that of course, information entropy..

...but is it?

 i'll first quote a guy that left a comment here http://jansloot.telcomsoft.nl/Sources-1/More/CaptainCosmos/Not_Compression.htm#.Xdyn0PlKiCq

Quote
You're allmost there. Sloot just used an analog converter. The analog signal was created by a device that was parametrized by the data on the chipcard. The precise digital measuring of the output of the analog signal then generates the digital sequence. Digital compressors are extremely limited because computers use integer or real data to work with. Analog systems can contain millions (some unlimited) of times the quantity of information that digital systems contain.

Sloot was a tv-technician in the transition period from high-quality analog technology to the digitalisation. He made the link between the two. His technique would or will ruin a whole industry, making ''our'' hich-tech IT based on digital processing completely obsolete.

For the one who does not understand the upper part: Consider a circle. The relation between diameter and circumference is the nubmer PI. Thats, 3.1415... and an inifinite numer of digits never recurring. Thats quite an amount of information in a simple analog thing.

There are other simple analog things that contain lots of information, even if you stay in the ''rational number'' range. Every movie, ever made on DVD and goïng to be made on DVD or every file on a computer in the world can be drawn by a single line on one sheet of paper: the slope (Y/X) as a finite row of digits can be the result of a digital measurement. Replace the sheet with a (virtual) tv-screen, and you have the SLOOT-compression, or something like. It's a digital to analog- and reverse thing. No more no less.

Sloot himself spoke about the ''end of the digital era''.

but does it really have to be analog?

sloot was generating these tiny keys by comparing source file to a database, 70mb for each type of data, videos, sound, text, pictures, and reverse was done one the other end.

Roel Pieper, former CTO and board member of Philips, is quoted as saying (translated from Dutch):

Quote
It is not about compression. Everyone is mistaken about that. The principle can be compared with a concept as Adobe-postscript, where sender and receiver know what kind of data recipes can be transferred, without the data itself actually being sent.

indeed, there is no compression here.

remember that since data is so extremelly "reduced", same 8kb key must be able to represent many different sets of data, different movies. but how.

WITH DYNAMIC COMPONENTS ON BOTH ENCODING AND DECODING SIDE, PARAMETRIZED BY SIMPLE SET OF VARIABLES ON THE BEGINNING OF THE KEY.

this is the only way this could have worked, even theoretically

to put it most plainly, we can represent any file of any kind as simply a sequence of numbers, so goal is to reduce 1 page full of random numbers to let's say 3/4 or 2/3 or even 1/2 of the page without data lost, with multiple iterations near infinite "compression" results. but how.

like i said, if we have a certain mechanism generating random data, let's say 10 generators of random numbers on encoder and decoder side.

lets say when movie is about to be turned into a 8kb key, those random generators are parametrized by exact time and date number, so its always unique.

totally unique and random datastream will be produced by the oscillators, THE SAME datastream on both sides.

we also have the same algorithm and same 70mb (can be more) library on both sides.

70mb library was probably an index of random numbers and algorithm had to first recognize which chunks of generated random numbers correspond to the source file..

maybe then it just sent the number of the table in which the big number was to be found and in combination with the timestamp software on the other side could look into that table, compare it with its own datastream at that timestamp moment and extract the usable data.

this is just a crude idea, probably not the best one, but i believe it was somewhere along these lines.

i also stumbled upon this old video, is it fake i dont know, claiming to reduce any file to 256 bytes

https://www.youtube.com/watch?v=kQsWP6n03EU

as sloot himself said it was extremely simple
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 17, 2020, 01:52:57 AM
...
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 17, 2020, 03:15:02 AM
Probably will not be right, but can try.

Letters are 32 bit numbers each, 1 integer.


We have sequence ABCD, which are 4 * 32 bit number (integers),

but it has only 256 iterations, which we can write in 1 integer or less

For combination AAAA, we write number 0, and max is 255 (DDDD).


Can we apply this further?



Because there are 26 letters, number of iterations (combinations) for ABCD will be 456976 for all possible letters in that 4 symbol block,

26 * 26 * 26 * 26 = 456976

and 456976 we can also write inside 1 integer instead of 4 integers.

AAAA = 0

ZZZZ = 456975


So, we write number of sequence (iterations) of blocks of 4 or more symbols, rather than integer symbols.

And if we have in small database all iterations, we can simply reverse number to given block of 4 letters.



I said I will try only, not claiming it will work.

It will work only for limited number of symbols.


Same principle goes for number of colors of 1 pixel.

Digital to analog, or maybe vice versa?
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 17, 2020, 05:49:34 AM
that was one of first things i thought of, how many bits per letter depends on the encoding system

Quote
An ASCII character in 8-bit ASCII encoding is 8 bits (1 byte), though it can fit in 7 bits.

An ISO-8895-1 character in ISO-8859-1 encoding is 8 bits (1 byte).

A Unicode character in UTF-8 encoding is between 8 bits (1 byte) and 32 bits (4 bytes).

A Unicode character in UTF-16 encoding is between 16 (2 bytes) and 32 bits (4 bytes), though most of the common characters take 16 bits. This is the encoding used by Windows internally.

A Unicode character in UTF-32 encoding is always 32 bits (4 bytes).

An ASCII character in UTF-8 is 8 bits (1 byte), and in UTF-16 - 16 bits.

The additional (non-ASCII) characters in ISO-8895-1 (0xA0-0xFF) would take 16 bits in UTF-8 and UTF-16.

i gave a lot of thought to extended ascii II table, each of the 8 bit characters may represent a number from 0-255, or 255-510, or 510-765, or 765-1020, or a certain function or coordinate of a cube encoding large number of variables.

https://theasciicode.com.ar/

for example 255x255x255 cube contains 16,581,375 cells and any of those cells can be addressed with just 24 bits (or even 21).

of course there is no reason to limit this to 3d cube, we could give it 30 dimensions instead so string of 30 ascii characters would be enough to address any of this many variables

1,571,105,731,713,312,715,511,913,444,948,824,285,516,982,702,388,429,082,930,088,043,212,890,625

but that approach has great limitation that it does not allow for further compression, unlike if we got a string of numbers that could be further reduced.

this is one of brute force approaches, not a solution by itself. solution might be combination of this with some complex logic and random data stream. receiver knows "what can and cannot be sent".

Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 17, 2020, 06:21:20 AM
Yes,

You saw it well, it can not be compressed further.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 17, 2020, 07:15:37 AM
if we meditated on this for some time, im sure we would crack it, but i guess no one really cares that much. i think such revelations come by merit, soot got it after 20 years of search, how impatient would it be to expect to get it in few days or weeks invested in this. but implications are too big to be forgotten, hundreds of ultraHD movies on a floppy disk, maybe world isnt ready for it.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 17, 2020, 07:49:16 AM
You got me thinking, and the aplications of such invention are huge.
You can have Wikipedia on your phone without net.
Movies, books, everything.

Tons of data, almost unlimited.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: ramset on July 17, 2020, 01:30:29 PM
Being autonomous of the net and having worlds knowledge available in such small package [pure unaltered by ??]  would truly be a gift towards independence and for humanity .
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 17, 2020, 05:57:39 PM
something i thought of yesterday, not a solution, just a thought.

something like criss cross

Suppose for example that you have a table of 1 digit numbers 10 x 10. Once the random generator fills the table with first set of 100 numbers, you can now create 40 unique 10 digit sequences from these 100 just by reading first line from left to right then right to left, same for other 9 lines, then same vertically for all 10 columns, then you can add at least 30 diagonal lines containing ~10 digits on average

so we have aproximatelly 700 digit unique sequence and any sequence longer than 4 digits that cooresponds to source file within those 10 digit chunks can be addressed with just 4 digit coordinates, start and stop cell.

for example coordinates 5055 can address a 5 or 6 digit sequence

with multiple iterations sequence of coordinates would be generated that should be shorter than source string.

but it probably would not be, what are the chances 5 or more digit sequences from the source string would appear among 70 ~10 digit random numbers strings

also, problem with this is you must place a non-numerical separator so algorithm knows when set of random numbers changes, so output would not be pure shorter numbers, but would have these separators among them for each iteration but maybe it could memorize their location and remove them so pure number string can be further reduced

just an idea. not such a good idea

he used a 70Mb library for each type of data. We do not know if that library contained just index of random numbers, or complex logic or both.

Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 17, 2020, 07:31:05 PM
...
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 17, 2020, 11:07:01 PM
something i thought of yesterday, not a solution, just a thought.

something like criss cross

Suppose for example that you have a table of 1 digit numbers 10 x 10. Once the random generator fills the table with first set of 100 numbers, you can now create 40 unique 10 digit sequences from these 100 just by reading first line from left to right then right to left, same for other 9 lines, then same vertically for all 10 columns, then you can add at least 30 diagonal lines containing ~10 digits on average

so we have aproximatelly 700 digit unique sequence and any sequence longer than 4 digits that cooresponds to source file within those 10 digit chunks can be addressed with just 4 digit coordinates, start and stop cell.

for example coordinates 5055 can address a 5 or 6 digit sequence

with multiple iterations sequence of coordinates would be generated that should be shorter than source string.

but it probably would not be, what are the chances 5 or more digit sequences from the source string would appear among 70 ~10 digit random numbers strings

also, problem with this is you must place a non-numerical separator so algorithm knows when set of random numbers changes, so output would not be pure shorter numbers, but would have these separators among them for each iteration but maybe it could memorize their location and remove them so pure number string can be further reduced

just an idea. not such a good idea

he used a 70Mb library for each type of data. We do not know if that library contained just index of random numbers, or complex logic or both.


It is good idea actually.

If the table is big enough to cover most of possible number combinations, could work.

This way you can write even big numbers with just coordinates.


You are not far away from his idea.


In his 70Mb he probably had some kind of similar table for creating strings or sequences of numbers,

which are larger than pointers, vectors itself (coordinates in your case).


Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 17, 2020, 11:13:30 PM
something i thought of yesterday, not a solution, just a thought.

something like criss cross

Suppose for example that you have a table of 1 digit numbers 10 x 10. Once the random generator fills the table with first set of 100 numbers, you can now create 40 unique 10 digit sequences from these 100 just by reading first line from left to right then right to left, same for other 9 lines, then same vertically for all 10 columns, then you can add at least 30 diagonal lines containing ~10 digits on average

so we have aproximatelly 700 digit unique sequence and any sequence longer than 4 digits that cooresponds to source file within those 10 digit chunks can be addressed with just 4 digit coordinates, start and stop cell.

for example coordinates 5055 can address a 5 or 6 digit sequence

with multiple iterations sequence of coordinates would be generated that should be shorter than source string.

but it probably would not be, what are the chances 5 or more digit sequences from the source string would appear among 70 ~10 digit random numbers strings

also, problem with this is you must place a non-numerical separator so algorithm knows when set of random numbers changes, so output would not be pure shorter numbers, but would have these separators among them for each iteration but maybe it could memorize their location and remove them so pure number string can be further reduced

just an idea. not such a good idea

he used a 70Mb library for each type of data. We do not know if that library contained just index of random numbers, or complex logic or both.


And one more thing.


I know you showed example.

But in example are decimal numbers, so we need 10 symbols to cover.

What about same table with just binary 0 or 1. Lots of sequences.

Will that be simpler or more complicated?
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 17, 2020, 11:50:09 PM

It is good idea actually.

If the table is big enough to cover most of possible number combinations, could work.

This way you can write even big numbers with just coordinates.


You are not far away from his idea.


In his 70Mb he probably had some kind of similar table for creating strings or sequences of numbers,

which are larger than pointers, vectors itself (coordinates in your case).

i was just trying to be humble :) its a good idea, but i dont think it would work like that.

i was thinking also about big table and other data than single digit numbers, including ascii, just alphabet and the binary you mention. with binary i think it would be less efficient.

for example whole source file could be one gigantic table, and at each set of random numbers, algorithm would find all the sequences in the source table that match those in the random table and replace them with coordinates, but then u must place a spacer before and after coordinates and what is the gain then, u now got spacers in the output which cannot be removed unless u also memorized coordinates for them which cost a lot.

there is more to this, i think he used complex logic so reciever knows "what can and cannot be sent"...

or maybe library was really just index of random numbers and he found some clever way to address them apparently breaking the information entropy. but he clearly did not break it, he found a workaround.



Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 17, 2020, 11:59:09 PM

also, problem with this is you must place a non-numerical separator so algorithm knows when set of random numbers changes, so output would not be pure shorter numbers, but would have these separators among them for each iteration but maybe it could memorize their location and remove them so pure number string can be further reduced



If you don't stop, separator, delimiter is not needed.

First coordinate, begin

Second coordinate, end sequence (2345)

Third coordinate, begin second sequence,

Fourth coordinate, end second sequence (12345),

But, actually you read it from memory as 234512345, as one sequence without delimiter,

just search in table for pieces which are longest to fill sequence.


You read it as continuous number, just as it is in memory.



You read memory from beginning till  the end as series of numbers merged together.

We know how long byte or integer is.


For example we have bytes

104

and

055

merge it, we know that byte is 3 places,

104055 and then search for best suited sequence to fill it from table,

I merged 2 bytes, but you can merge 100 bytes as continuous sequence and then look into table.


The whole movie is one big continuous number, sequence.

When you look memory with hex editor, there is number after number. You can look at it as one long number.


Then you don't need delimiter.

Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 18, 2020, 12:27:59 AM

If you don't stop, separator, delimiter is not needed.

First coordinate, begin

Second coordinate, end sequence (2345)

Third coordinate, begin second sequence,

Fourth coordinate, end second sequence (12345),

But, actually you read it from memory as 234512345, as one sequence without delimiter,

just search in table for pieces which are longest to fill sequence.


You read it as continuous number, just as it is in memory.



You read memory from beginning till  the end as series of numbers merged together.

We know how long byte or integer is.


For example we have bytes

104

and

255

merge it, we know that byte is 3 places,

104255 and then search for best suited sequence to fill it from table,

I merged 2 bytes, but you can merge 100 bytes as continuous sequence and then look into table.


Then you don't need delimiter.

if you encode the source linearly, from beginning onward, you need a spacer, not all iterations of the 100 random numbers will yield same number of matches, some iterations will yield 10 pairs of coordinates, some none, and you must know when random numbers change.

in a case if you go about it non-linearly, turning the whole source file into a table, and for each set of 100 random numbers finding the matches across the whole source file and replacing them with coordinates ..you again need spacers (or something to replace them).


lets say after 10,000 iterations you have turned a whole source file into coordinates...

encoding algorithm could of course know which sequences have been replaced with coordinates at which iteration, but how would algorithm on decoding side know.

no way for it to know, it must know exactly at which iteration those coordinates where placed there.

Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 18, 2020, 12:37:58 AM


Movie or file is series of numbers merged

123456789123456789123456789

Now you look into table and write coordinates

5
55
2
78
34
26

We know that first number is begin,
second number is end,
so you read coordinates in pairs of 2.

5, 55 = 12345
2, 78 = 678912345
34, 26 = 6789123456789

and merge sequence together again

123456789123456789123456789

and write it back into memory as it was at first place, in sequence.


So, number of coordinates are telling us how much sequence is long.

When there are no coordinates we are done, and vice versa.


No delimiter.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 18, 2020, 12:38:28 AM
another detail worth mentionig is encoding side could do a lot of computation to find input variables that yield most matches for a particular file, so random is not really random but customized random.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 18, 2020, 12:44:13 AM

Movie or file is series of numbers merged

123456789123456789123456789

Now you look into table and write coordinates

5
55
2
78
34
26

We know that first number is begin,
second number is end,
so you read coordinates in pairs of 2.

5, 55 = 12345
2, 78 = 678912345
34, 26 = 6789123456789

and merge sequence together again

123456789123456789123456789

and write it back into memory as it was at first place, in sequence.


So, number of coordinates are telling us how much sequence is long.

When there are no coordinates we are done, and vice versa.


No delimiter.

and how did you imagine using 1 digit coordinate, it cannot be 555, only 0555, otherwise coordinates would get mixed up.

as for spacer, again, coordinates are produced in different iterations, from different sets of random numbers, algorithm MUST know which iteration produced which coordinates, so spacer is needed
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 18, 2020, 12:46:51 AM
The problem is because we think in decimal which is not suited for binary and numbers dont match.

We can write byte 255, but can not 999, because byte can not hold it.

Lets say that coordinates are max 2 numbers, 00 - 99 and you write it that way.

You have table 100 * 100,

6 coordinates are 12 numbers.

If we can write with 12 numbers 25 numbers, then the thing will work,

otherwise, hmm?

Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 18, 2020, 12:52:15 AM
Yes, it must be 05, 55 and not 5, 55.

And we spend more memory, but delimiter is not needed.

Delimiter will be very hard to implement, if we dont know exact length of sequence.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 18, 2020, 12:55:55 AM
u dont gain anything from going from 100 number table to 10,000 number table. everything just gets proportionally bigger, that is why i kept it at 100.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 18, 2020, 12:57:06 AM
Yes, it must be 05, 55 and not 5, 55.

And we spend more memory, but delimiter is not needed.

Delimiter will be very hard to implement, if we dont know exact length of sequence.

how do you imagine decoder would know from which iteration to take which coordinates, if its not given that instruction. it needs a spacer
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 18, 2020, 01:00:02 AM
I must say, you really got me into this problem!

But, it is good to talk and exercise our brains,

even if we dont find anything.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 18, 2020, 01:07:18 AM
how do you imagine decoder would know from which iteration to take which coordinates, if its not given that instruction. it needs a spacer


My thought was,



once we convert sequence into pairs of coordinates,

we read coordinates as number again and second iteration goes.

We write number of iterations into one long integer.



Can you try to explain how would you do it, just to see where I could be wrong?


Lets presume that we can write more numbers with coordinates than the number sequence really is.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 18, 2020, 01:17:43 AM
this is my second time i am at it, like 10 months ago i was totally into it for few weeks, i started with idea of reducing big numbers to simpler formulas

for example 205891132095673 is equal to 2^10+3^30.

but this is a blind alley, no further reduction is possible. then i realized it can only be done with dynamic component on both sides parametrized the same way.

but this is nothing new, this april fool's joke video is about that https://www.youtube.com/watch?v=KOvoD1upTxM

not worthy going nuts over it, remember sloot was seeking for 20 years before he got it.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 18, 2020, 01:21:15 AM


You are very right,


this is not easy task, and it involves lots of brainstorming, for sure.

But is very interesting.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 18, 2020, 01:22:43 AM

My thought was,



once we convert sequence into pairs of coordinates,

we read coordinates as number again and second iteration goes.

We write number of iterations into one long integer.



Can you try to explain how would you do it, just to see where I could be wrong?


Lets presume that we can write more numbers with coordinates than the number sequence really is.

its not about writing the number of iterations...like i said, look for decoder side, how will decoder know at which iteration to pick coordinates.

there is no way to avoid the spacer and this is where this idea dies.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 18, 2020, 01:31:43 AM
Damn,


It was starting to get fun!
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 18, 2020, 01:41:42 AM


Anyway, good topic Nix,



Regards.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 18, 2020, 01:46:21 AM
yea, sooner or later someone will crack it. hopefully they'll share it, if not no prob, we got quite bandwidth these days
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 21, 2020, 03:15:36 AM
just to add, answer might be in SUPERPOSITION.

EDIT: i removed the idea of projecting multiple films one over another, that was just a side idea which would clearly not work, but i feel he used superposition in some way.

for example how much data can fit in 1 second of digital sound, 44,100 samples per second, 16 bits per sample...no matter how complex the sound is size of the file will be the same.

even with limited sound bandwidth of 50Hz-20KHz, layers of data can fit into many subbands, clearly, higher we go toward top frequency, more data per second.

if more data can be crammed this way than it takes to produce the sound, then further compression is possible.

of course sound is just an example, it would be far more efficient to use higher frequencies.

he said age of digital is over
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 21, 2020, 06:06:36 AM
i created in audacity what was supposed to be 22khz and 18khz squarewave and mixed them.

but uncompressed wav file like this would be huge and once you pack it up with so much signals you could hardly compress it further, data would become nonreadable.

not a solution, just an idea.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 22, 2020, 08:26:37 PM
Hi Nix,

didnt forget, just reading about losseless compression methods to maybe
see what is missing.

Yes, the analog can store more, but then we must store analog somehow again.

I been on trail on maze algorithm.
The theory is simple.
You have 10*10 grid.
You start from lets say 5, 0. Bottom of grid.
Then you move up choosing right and left, and up for every step.
Every intersection on grid has rules, it writes numbers which will tell you did you turn right or left, 0 or 1.
When you reach top, lets say 7. 10, you just start from 7, 0.
It is eternal grid. No ending.
Flags, numbers on intersections are remembering from where you came.

It means that if you go backward following the same rules you will end up where you begin.

In maze you write your start position, number of steps, and end position,
and you record grid intersection numbers, flags.

So, end file length is always the same length, different number of steps and different end position.

In between there are trillions of possible combinations. Left and right, and up for every step.

It is not new idea. But what to write on interswctions to remember the way you come from?
There are few people which are working on this problem,
you will be amazed how far they come.

Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 23, 2020, 12:26:40 AM
in fact, what you call endless maze is where the idea on the 1. page came from, it's one and the same thing.

i thought of all possible variations, 1 column and set of random data flowing through it left to right and a pointer jumping up and down according to instructions.

or static random data table and pointer moving by given angle, even in 3d cube like structure.

the problem is that instructions that can cover any random data are in the end longer than the data.

we need to think in simpler terms
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 23, 2020, 05:31:51 AM
the idea i liked the most from the start is that he a used complex logic pyramid

maybe he took 3 symbols on the top and using complex logic, parametrized by random data, expanded them into longer strings of symbols over and over again

what i mean is that $%) on top can expand into many different strings depending on the random input at each step and if same random input is used same long string will be generated always

and then reversed the process, using complex logic and same random numbers that are not being sent but will be generated at the other side, he compressed those long strings into shorter and shorter ones

maybe those 70mb contained not only logic but many possible patterns and random set combinations that would speed up the compression.

this, ofc, could be all digital. i dont see the need for literally analog since all is essentially analog. analog seems like blind alley cause you need huge amount of data to create complex waveforms, but logic and same random data does not.


                              $%)
                            $&$/(%/
                         $%&%$/&%//
                    $%/&()/%&=)/&)=/)/
                )/(=)#?$)=(#?)=("=($)"#(
         (/Z/&#)=(/?()"?)=UIFO#")=U(F?)="
    $%&%/(&=)/&=)(/=)(/&(/&)(/&)(/&()/&()
/&#ZUIFR()F)==F)=#/(/&Q"#)=#=)")=#$/(&/(
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 23, 2020, 07:02:52 AM
Yes, I am trying to see.that analog connection Sloot talked about.

Because all this things we talked can be done in digital form without use of analog.

Maybe he found the way to read correctly very dense analog data.

In that time analog to digital conversion was not so advanced like today.

We have to consider that it was long time ago.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 23, 2020, 07:21:24 AM
but what would reading it correctly give him, nothing really

that analog signal must in some way contain a whole movie or whatever

and how are you gonna create a signal that contains a whole movie with 4 or 8kb code

lossless 1min of sound requires like few megbytes, not to mention a whole movie

i believe it can be done in digital and i dont see how he did it, if he did, in analog


Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 23, 2020, 07:29:59 AM
That analog part is really unclear.

Connection?
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 23, 2020, 08:03:04 AM
there is this information entropy wall, there must be a way around it
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 23, 2020, 08:44:55 AM
...
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: lancaIV on July 23, 2020, 11:56:56 AM
(S)cryptology
Icon/-ography

Codex
Key: en-/de-coder

Information
Writer
Reader
Storage
You are thinking in quantum computering ,similar our cerebral neuronal programing,in best/perfect case ! 8)

Patrick Flanagan " neurophone" !
Prof.Naoki Ikeda RFe204 grains : 1000x times faster than silicium transistors ,Tbit velocity

To holographic "Tesa-film/foil" like storage ,medium : "gel,glue-like"(haemoglobin)

Phillip Morris Prize :  compression system
Ex-G.D.R. : invention MP3 logic  structure

Opto-electric
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 23, 2020, 12:06:23 PM
more like quantum healing :)
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: lancaIV on July 23, 2020, 12:11:12 PM
For this I think for Bernhard Shaw a right quantum good old translucent  " glass h/w- uiskey" was enough to become healed ! ::)
One problem : "artificial information" can become "awaked" and get an "Eigen-life/demand"

                           Learning and growing (child to adult) "KIND" :artificial life

How much decision freedom and self-command degree the quantum operator get ?

What for me seems logical not for you/other has to be ,at first without basic knowledge and experience,logical !
What for you/other seems logical for me ,without your/others their  knowledge,experience and reazons ,has to be logical !
 
            No! Means No! ,The Quantum program demands : member from the anti-cybersex-#metoo-coalition  ;D
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: triangle on July 23, 2020, 01:09:32 PM
Jan Sloot was a intelligent man that wanted not more then leave there family a good inheritance, he succeeded as his materials are bought with the help of Abn Amro bank after he past away.

This all concept came in the 90ties after the memory card was introduced by Toshiba in the late 80ties.

That time we didnt knew better then that pc,s had big harddisks, but we didnt taught of the possibilities with the memory cards where you could actually save a movie from a low quality on.

In my opinion he copied the links to the saved files on his floppy disk with a command that directly loaded the movie, and hiding the memory card under the mainboard  when he demostrated and opened the computer indeed nobody could see or detect a big harddisk ( know that computers was quit new that time and we didnt know all the possibilities)

If you copy a hyperlink from a movie that is saved on your D: harddrive and you copy the link on your desktops C: to start the movie in D: drive you see that it contains several kb,s same as demonstrated by Jan Sloot.

I think he was smart enough to connect and replace the big hard drive for a memory card that could be hide anywhere between the boards, and therefor there is no algorithm to crop files in de way he demonstrated.

Just my opinion,!

Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: lancaIV on July 23, 2020, 01:33:45 PM
https://translate.google.com/translate?hl=de&sl=de&tl=en&u=https%3A%2F%2Fkompendium.infotip.de%2Fmpeg_videokompression.html (https://translate.google.com/translate?hl=de&sl=de&tl=en&u=https%3A%2F%2Fkompendium.infotip.de%2Fmpeg_videokompression.html)


One of the Philip Morris Award winner https://de.wikipedia.org/wiki/Philip_Morris_Forschungspreis (https://de.wikipedia.org/wiki/Philip_Morris_Forschungspreis)


( often later also A.Nobel Prize winner)






https://de.wikipedia.org/wiki/Peter_Fromherz (https://de.wikipedia.org/wiki/Peter_Fromherz)


https://translate.google.com/translate?hl=de&sl=de&tl=en&u=https%3A%2F%2Fde.wikipedia.org%2Fwiki%2FPeter_Fromherz (https://translate.google.com/translate?hl=de&sl=de&tl=en&u=https%3A%2F%2Fde.wikipedia.org%2Fwiki%2FPeter_Fromherz)


https://en.wikipedia.org/wiki/Neurochip (https://en.wikipedia.org/wiki/Neurochip)


Theodor Haensch 2 times winner and later A.Nobel


Immanuel Bloch 2 times winner and  ::)
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 23, 2020, 02:10:25 PM
i dont think he was such an idiot, to try to fool CEOs of multi billion companies with a shortcut, lol.

his facial expression to me confirms he had a great discovery.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 23, 2020, 02:12:14 PM
Too much money was at stake, so faking is less probable.

Nix,

Random numbers are random and we can not predict sequence.

But dividing numbers will give sequences which we can predict,
because the result is always the same.

There is simple way to solve entropy.

2 small numbers divided can give up to 10 numbers before they start to repeat.

22/7 = 3.142857  with 2 small numbers which can be packed into 1 byte,
we wrote 7 numbers.

Which gives me idea.
Irrational numbers.

Pi is holding all combinations in universe never repeating.
Question is how to implement pointer to known sequence inside it?
I mean, for decoding, we dont remember sequences, but initial conditions to calculate pi from
given decimal point for the given length.

For coding we have to have pi calculated for maybe trillion decimals,
and write in table conditions from where cpu will start calculating,
but for decoding cpu just calculates pi from conditions.

So we remember conditions for calculating pi from given decimal point,
for the given length. Resulting in calculating needed sequence of x numbers.

We calculate. We dont remember sequences.

Another example is square root from 2,
same thing.
It holds all possible short and long sequences needed.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: triangle on July 23, 2020, 02:19:17 PM
i dont think he was such an idiot, to try to fool CEOs of multi billion companies with a shortcut, lol.

his facial expression to me confirms he had a great discovery.

Well, it depends how you seeing it, maybe he was a genius in fooling CEO,s

Anyways, it was my opinion, you might be right.

I wish everyone good luck to create or find the algorithm.

All his documentation is buyed, so they should have found something, however his computer box is dissapeared, i think destroyed after the family and his partner found out the reason behind.

No oil gigants could be involved, so no reason to hide if it was real.

Goid luck .
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 23, 2020, 02:24:46 PM
Calculating holds the key.

By calculating we can create more numbers than is needed,
by writing initial conditions for calculation only.

And irrational numbers are huge containers which already holds all
possible sequences we can imagine.

Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 23, 2020, 02:25:04 PM
Too much money was at stake, so faking is less probable.

Nix,

Random numbers are random and we can not predict sequence.

But dividing numbers will give sequences which we can predict,
because the result is always the same.

There is simple way to solve entropy.

2 small numbers divided can give up to 10 numbers before they start to repeat.

22/7 = 3.142857  with 2 small numbers which can be packed into 1 byte,
we wrote 7 numbers.

Which gives me idea.
Irrational numbers.

Pi is holding all combinations in universe never repeating.
Question is how to implement pointer to known sequence inside it?
I mean, for decoding, we dont remember sequences, but initial conditions to calculate pi from
given decimal point for the given length.

For coding we have to have pi calculated for maybe trillion decimals,
and write in table conditions from where cpu will start calculating,
but for decoding cpu just calculates pi from conditions.

So we remember conditions for calculating pi from given decimal point,
for the given length. Resulting in calculating needed sequence of x numbers.

We calculate. We dont remember sequences.

Another example is square root from 2,
same thing.
It holds all possible short and long sequences needed.

eh, irrational numbers, i gave them as much thought since day 1 as i did anything so far mentioned, including making a table of calculations for all the numbers with sets of "random" numbers, and then using a certain decimal value as pointer.

but you are stuck with same issue as before, trying to fit 100 numbers in 1 digit.

this is brute force approach and not good as such

i'd say goal is not to break entropy but expand the system on both sides, find common wider reference

one of ideas i had was criss crossing or navigating pi, but that approach is so flawed i don't even need to mention

3 . 1 4 1 5 9 2 6 5 3 5 8 9 7 9 3 2 3 8 4 6 2 6 4 3 3 8 3 2 7 9 5 0 2 8 8 4 1 9 7 1 6 9 3 9 9 3 7 5 1 0 5 8 2 0 9 7 4 9 4 4 5 9 2 3 0 7 8 1 6 4 0 6 2 8 6 2 0 8 9 9 8 6 2 8 0 3 4 8 2 5 3 4 2 1 1 7 0 6 7 9 8 2 1 4 8 0 8 6 5 1 3 2 8 2 3 0 6 6 4 7 0 9 3 8 4 4 6 0 9 5 5 0 5 8 2 2 3 1 7 2 5 3 5 9 4 0 8 1 2 8 4 8 1 1 1 7 4 5 0 2 8 4 1 0 2 7 0 1 9 3 8 5 2 1 1 0 5 5 5 9 6 4 4 6 2 2 9 4 8 9 5 4 9 3 0 3 8 1 9 6 4 4 2 8 8 1 0 9 7 5 6 6 5 9 3 3 4 4 6 1 2 8 4 7 5 6 4 8 2 3 3 7 8 6 7 8 3 1 6 5 2 7 1 2 0 1 9 0 9 1 4 5 6 4 8 5 6 6 9 2 3 4 6 0 3 4 8 6 1 0 4 5 4 3 2 6 6 4 8 2 1 3 3 9 3 6 0 7 2 6 0 2 4 9 1 4 1 2 7 3 7 2 4 5 8 7 0 0 6 6 0 6 3 1 5 5 8 8 1 7 4 8 8 1 5 2 0 9 2 0 9 6 2 8 2 9 2 5 4 0 9 1 7 1 5 3 6 4 3 6 7 8 9 2 5 9 0 3 6 0 0 1 1 3 3 0 5 3 0 5 4 8 8 2 0 4 6 6 5 2 1 3 8 4 1 4 6 9 5 1 9 4 1 5 1 1 6 0 9 4 3 3 0 5 7 2 7 0 3 6 5 7 5 9 5 9 1 9 5 3 0 9 2 1 8 6 1 1 7 3 8 1 9 3 2 6 1 1 7 9 3 1 0 5 1 1 8 5 4 8 0 7 4 4 6 2 3 7 9 9 6 2 7 4 9 5 6 7 3 5 1 8 8 5 7 5 2 7 2 4 8 9 1 2 2 7 9 3 8 1 8 3 0 1 1 9 4 9 1 2 9 8 3 3 6 7 3 3 6 2 4 4 0 6 5 6 6 4 3 0 8 6 0 2 1 3 9 4 9 4 6 3 9 5 2 2 4 7 3 7 1 9 0 7 0 2 1 7 9 8 6 0 9 4 3 7 0 2 7 7 0 5 3 9 2 1 7 1 7 6 2 9 3 1 7 6 7 5 2 3 8 4 6 7 4 8 1 8 4 6 7 6 6 9 4 0 5 1 3 2 0 0 0 5 6 8 1 2 7 1 4 5 2 6 3 5 6 0 8 2 7 7 8 5 7 7 1 3 4 2 7 5 7 7 8 9 6 0 9 1 7 3 6 3 7 1 7 8 7 2 1 4 6 8 4 4 0 9 0 1 2 2 4 9 5 3 4 3 0 1 4 6 5 4 9 5 8 5 3 7 1 0 5 0 7 9 2 2 7 9 6 8 9 2 5 8 9 2 3 5 4 2 0 1 9 9 5 6 1 1 2 1 2 9 0 2 1 9 6 0 8 6 4 0 3 4 4 1 8 1 5 9 8 1 3 6 2 9 7 7 4 7 7 1 3 0 9 9 6 0 5 1 8 7 0 7 2 1 1 3 4 9 9 9 9 9 9 8 3 7 2 9 7 8 0 4 9 9 5 1 0 5 9 7 3 1 7 3 2 8 1 6 0 9 6 3 1 8 5 9 5 0 2 4 4 5 9 4 5 5 3 4 6 9 0 8 3 0 2 6 4 2 5 2 2 3 0 8 2 5 3 3 4 4 6 8 5 0 3 5 2 6 1 9 3 1 1 8 8 1 7 1 0 1 0 0 0 3 1 3 7 8 3 8 7 5 2 8 8 6 5 8 7 5 3 3 2 0 8 3 8 1 4 2 0 6 1 7 1 7 7 6 6 9 1 4 7 3 0 3 5 9 8 2 5 3 4 9 0 4 2 8 7 5 5 4 6 8 7 3 1 1 5 9 5 6 2 8 6 3 8 8 2 3 5 3 7 8 7 5 9 3 7 5 1 9 5 7 7 8 1 8 5 7 7 8 0 5 3 2 1 7 1 2 2 6 8 0 6 6 1 3 0 0 1 9 2 7 8 7 6 6 1 1 1 9 5 9 0 9 2 1 6 4 2 0 1 9 8 9
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: lancaIV on July 23, 2020, 02:32:16 PM
The best heads works for solution  8)  : https://en.wikipedia.org/wiki/Beale_ciphers (https://en.wikipedia.org/wiki/Beale_ciphers)


https://en.wikipedia.org/wiki/The_Code_Book (https://en.wikipedia.org/wiki/The_Code_Book)


https://en.wikipedia.org/wiki/Quantum_cryptography (https://en.wikipedia.org/wiki/Quantum_cryptography)




https://www.degruyter.com/view/journals/nanoph/ahead-of-print/article-10.1515-nanoph-2020-0110/article-10.1515-nanoph-2020-0110.xml?language=en (https://www.degruyter.com/view/journals/nanoph/ahead-of-print/article-10.1515-nanoph-2020-0110/article-10.1515-nanoph-2020-0110.xml?language=en)


https://en.wikipedia.org/wiki/Quantum_superposition (https://en.wikipedia.org/wiki/Quantum_superposition)  Experiments and applications


The code-key has ever to be "perfect identical" = finite stage  ! Decoding input = Encoding output


Pi and https://www.youtube.com/watch?v=io11cbrTTNg (https://www.youtube.com/watch?v=io11cbrTTNg) are "endless" numbers, infinite !


1      = I  Unum                 /1                          /= per or pro = in-version
10    = X/D ecem              / 10
100  = C    entum             / 100
1000=M     ile                  /  1000
........


0 = nullus or zero
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 23, 2020, 02:39:38 PM
i used to think calculating is the key too, that was my first idea, to represent big numbers as short formulas, of course that's a bad idea

its not a problem to generate long strings of numbers, so many ways to do that. to do it in a predictable way for arbitrary values is different story
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 23, 2020, 02:56:37 PM
when i first got into it i also gave a lot of thought to prime numbers, like indexing first say 1000 primes and breaking down superlong numbers using these and similar. blind alley.

there must be a simple workaround that allows a repatable compression, that is the only way that makes sense how he achieved 1:2 million ratio


                              4
                             34
                            234
                           1234
                          01234
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 23, 2020, 10:21:15 PM
http://endlesscompression.com

You probably saw this page...
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 23, 2020, 11:35:10 PM
http://endlesscompression.com

You probably saw this page...

yes, he talks a lot but does not have a solution.

to elaborate more on one of first ideas i had, how to turn 2 digit number into 1

let's say you want to compress 45

random numbers are also 2 digit and at that moment number is 56

each random number could have it's own complex mathematical formula

but let's keep it simple and say we just divide, we calculate

56/45=1.24444444444

let's say we are writing down 3rd digit after decimal point so 4

we could as well calculate 56-45=11 and write down numerical value 2 or something else, and infinity of other formulas

so on decoder side, it sees answer is 4, random number 56, it knows which operation has been performed for that random number...

so it calculates or looks in the table of precalculated values

if 45 is the only of 100 numbers that has 4 at that decimal point for that operation, then we got a score

what are the chances

let's see


56/99=0.56565656565
56/98=0.57142857142
56/97=0.57731958762
56/96=0.58333333333
56/95=0.58947368421
56/94=0.59574468085
56/93=0.60215053763
56/92=0.60869565217
56/91=0.61538461538
56/90=0.62222222222
56/89=0.62921348314
56/88=0.63636363636
56/87=0.64367816092
56/86=0.65116279069
56/85=0.65882352941
56/84=0.66666666666
56/83=0.67469879518 and ups another one, so no good
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 24, 2020, 07:40:20 PM
I been reading a lot about endless compression. EC.

You got me hooked.

I did not realize how much money it worth and EC
has its own casualties, just as FE.
Lots of people been involved over the years,
but nobody found solution.

Pointers of any kind wont do much good.
Because there must be number of pointers same as number of data chunks
they are pointing, so compression is limited or small.

Same goes for any type of hash or rainbow tables.

Another type of writing is needed,
which does not involve pointers or similar, or equations.

Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 24, 2020, 10:36:56 PM
like that guy in the video said they expected 100 billion dollars turnover within 4 years.
but screw the money, greedy mindset is not worthy of it, the biggest reward is appreciation of a principle. i wouldnt compare it to fe, fe is solved in million ways, i don't know if anyone solved this after sloot

that's what i'm saying, pointers are no good, at least not pointers alone

1:2,000,000 compression must be some kind of multistage compression

how to send data without sending it, "receiver knows what can and cannot be sent"

maybe if we stare into his eyes long enough it will come to us :)
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 24, 2020, 11:47:08 PM
It will come.

No secret is forewer.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 24, 2020, 11:51:16 PM
If you think about it.

It is not compression at all.

Another way for data to write itself.

Pi is holding so much data. Counter is pointing to every and each sequence.

So, it is not sequence, it is counter.

Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 25, 2020, 12:01:21 AM
sure it will. sooner or later.

not compression indeed, that's why i put it in quotes

there is infinity of data all around us, not only in pi

of course, how to index it in efficient way is the missing key
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 25, 2020, 12:11:59 AM
Index is wrong way.

Do not index anything.
It is just a way that data is written.
It overwrites itself and still holding the data.

Counting.

Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 25, 2020, 12:21:07 AM
please don't talk as if you know, you don't

he probably used indexing in some way
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 25, 2020, 12:30:11 AM
I cracked Sloot algorithm in 3 days.

For 2 days I was reading only about endless compression.

I cracked Tito mystery in 5 days and gave you solution.

Tesla coil, secondary bifilar, bifilar connected on opposite sides,

not on same side like cap.

You can try it first with directional pulses to see effect.

It must be step up, for effect to emerge, then you have to step down,
to gain amps again. You have to switch it. Spark gap is cheapiest switch.

Secondary bifilar will give you voltage as mono winding secondary will.

But it wont affect primary, because it has no field. Static only.

Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 25, 2020, 12:34:28 AM
what did you crack again please

so we're telling jokes now
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 25, 2020, 12:41:34 AM
No jokes.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 25, 2020, 12:47:02 AM
What counter does?

It holds maximum value over all data.

Can you use it?

Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 25, 2020, 12:48:02 AM
take some rest, you are starting to halucinate
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 25, 2020, 12:54:34 AM
OK
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 25, 2020, 02:01:37 AM
this guy also claimed 1:2 million compression, all digital, ended up in court investors asking back the money he already wasted

this website claims he used math formulas, my first approach http://web.archive.org/web/20110903072425/http://www.adamsplatform.com.au/

https://www.smh.com.au/business/compressed-into-nothingness-20100808-11qdh.html
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 25, 2020, 02:21:03 AM
It can be any compression you want.

All lengths are written, not compressed, to same size.

It grows only for 1 integer when old counter pass its max value.

Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 25, 2020, 02:27:21 AM
Yesterday, it seems imposible to me. No way.

Think about it as new data overwrite old data but still holds old values.

No matter how many times you overwrite same data.

And it is only counter and simple math.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 25, 2020, 02:33:29 AM
didn't i tell you to rest until halucinations pass
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 25, 2020, 02:34:54 AM
It can not be clearer than I just wrote.

This is OU forum, and is open for FE. Which I did.

Endless compression is not FE.

Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 25, 2020, 02:38:39 AM
OK for second time.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 25, 2020, 03:50:27 AM
sloot's patent

https://patents.google.com/patent/NL1009908C2/en
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 25, 2020, 04:02:30 AM
Sloot patent is all about compression.

I read it yesterday.

But if you read it carefully, it needs previous data to calculate new,
and overwrite previous.
Very simple.

Third time. No more questions.

Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 25, 2020, 04:07:10 AM
Sloot patent is all about compression.

I read it yesterday.

But if you read it carefully, it needs previous data to calculate new,
and overwrite previous.
Very simple.

Third time. No more questions.

Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 25, 2020, 04:12:16 AM
i read it last year (the summary at http://endlesscompression.com/), it's not disclosing the key details

sloot was extremely paranoid about it, all he disclosed is some general stuff and possibly even that is misleading

you are trying to sound as if you know how he did it but you don't, so curb it




Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 25, 2020, 04:21:18 AM
I am not 15, but 50.

I dont seek attention.

Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 25, 2020, 04:30:49 AM
then act your age

im just saying you don't know the principle so don't claim that you do

yea, i know all he said in the patent, but wall of information entropy stands as tall as always

how he turned a string of 2 million random numbers/symbols into 1 remains unknown

Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 25, 2020, 06:05:56 AM
 all numbers with numerical value nine can be divided by nine
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: triangle on July 25, 2020, 01:05:10 PM
But if you read it carefully, it needs previous data to calculate new,
and overwrite previous.
Very simple..

Great news , if it is simple then replicate it, share it, its open source right? If you not want to share this then sell the technology, buy lots of solar panels to help the world! Good journey!!
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: lancaIV on July 25, 2020, 02:36:39 PM
We shall not read what we want to read !
We shall read what is written :  1 to 1Enter in search machine/-s : Sloot compression

and read the information !
When not the compreesion is the solution then it is the emittent and recheiver de-/en-coder matrix/schablone/klischee/scheme !
And where is written 2000000:1 data compression when it is to read movi dat 10000/ up to 1750000/1 !
It is ny software possible to compress  in very high density but then the record is anymore the same and with each new compression much data gets mixed and  far away from the original !
High compression means also high comparison time need for the hardware ,especially for the optical reader,scanner like !


A fake ? Why was/react  the Phillips representant at first deerved and in the same month becomed project company CEO ?
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: triangle on July 25, 2020, 02:54:34 PM
A fake ? Why was/react  the Phillips representant at first deerved and in the same month becomed project company CEO ?

Everyone can be a CEO of a company, doesnt say anything, same situation with him when he left philips, he became CEO of nothing at the end!

Just my view.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: lancaIV on July 25, 2020, 03:05:47 PM
https://jansloot.telcomsoft.nl/Sources-1/More/CaptainCosmos/Not_Compression.htm#.XxwyY55KjWU (https://jansloot.telcomsoft.nl/Sources-1/More/CaptainCosmos/Not_Compression.htm#.XxwyY55KjWU)

When somebody reaches an high stage in a multi-national trust like Phillipps he will think twice to leave this save position and to risc his name and reputation !
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: triangle on July 25, 2020, 03:10:14 PM
Http://jansloot.telcomsoft.nl

When somebody reaches an high stage in a multi-national trust like Phillipps he will think twice to leave this save position and to risc his name and reputation !

I agree with you, however everyone can make mistakes! He didnt had any profile on computer science, he just was impressed with what he seen.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: purelyconstructive on July 26, 2020, 12:08:20 AM
What a fascinating topic! I had never heard of Sloot's work previously, but some of the things that have been pointed out to me about Marko Rodin's Vortex-Based Mathematics covers similar ground, especially a few of the ideas written about within this thread. Here is an article that introduces some basic concepts as they relate to the research being done here; please feel free to skip over it if it does not interest you...

A Simple Mathematical Approach To File "Compression" (and The Physics Behind It)

• A file of any type is merely a binary number. The size of the file determines the length of the binary number used to represent it.

When represented in a higher base, that binary number takes on a smaller form. For example, the same binary number represented within decimal is going to be much shorter (i.e.: it will have fewer digits).

Main Point #1: The number itself has not changed, just the way in which it is represented. Therefore, size is not necessarily determined by the amount of data involved, but by how we choose to symbolize it. No data is being added or removed.

The real question is: Is there a fast and reliable way to convert a number from one base into another (such as from binary to decimal)?

Indeed, there is! [see "Residue Number Systems"]

• A thing does not always have to be physically present if we are given the instructions necessary to make it from scratch.

Main Point #2: If we can provide an algorithm that generates a given number, then we do not need to "store" the information itself. We can recreate it "on the fly" just by following the steps of the algorithm!

Further, if the algorithm is simple and recursive, then we only need to specify a small number of steps and how many times to repeat them.

The next best question is: What kind of algorithm do we need to do this?

We can start with simple processes that we might already know!

For example, we can take a decimal number of any size and add together its digits until we get a single digit. This is equivalent to "compressing" that number. In other words, we can represent a very large number (with many digits) as a single number (with only one digit).

Then, to "decompress" it, we merely specify how many times we need to multiply that single number by 9 in order to give us our starting number again.

The adding and multiplying procedures described above can both be done very quickly, and in turn, can be used to scale the size of a number up and down very easily. Again, a handful of small numbers can represent an incredibly large number (i.e.: one with many digits).

• We often distinguish between "analog" and "digital" signals (or to put it another way, between things which are "continuous" and "discrete"). An "analog" signal is one that can take on an "infinite" range of measured values (such as temperature, pressure, and so on). A "digital" signal is one that can be represented by a "finite" (or limited) number of states. This set of states is referred to as its "quantinization".

Computers utilize two distinct states, "off" and "on", represented by the 0's and 1's of binary. Therefore, computers are considered "digital", even though the electrical waves that run through their circuitry are technically considered "analog".

We can convert one signal type into the other through a process called "sampling". Many devices do this all the time (with "Analog-to-Digital Converters", or "ADCs", and "Digital-to-Analog Converters", or "DACs"). This is done with varying amounts of fidelity or "resolution". However, there is thought to be a minimum amount of information that must be present in order for one to effectively move between the two types of signals [see "Nyquist-Shannon sampling theorem"].

Therefore, the final "million dollar" question is: Is it possible to create a sampling process where there is a 1-to-1 correspondence between an analog and digital signal? Where no information is "lost" and what is necessary can be retrieved?

As strange as it may sound, logic would dictate that this may actually be possible (and without introducing concepts outside of "standard" science). For example, we interpret all energy as both "quantized" and "conserved". In other words, it comes in distinct packets (like "photons" of light) and it never disappears completely, only changes form!

To put it more plainly, there is no such thing as an "analog" signal per se, only systems that seem so complex that we try to approximate them with numbers, rather than represent them directly as numbers. At a high enough resolution, all signals are "digital".

---------

For those of you who are interested in Vortex-Based Mathematics, here is a series of articles that builds it all "from the ground up":

• The Universe: A Play In Four Acts (https://letslearntogether.neocities.org/scispirit/VBM/universe.html)
Description: A condensed introduction to some fundamental patterns within Vortex-Based Mathematics

• It's Vortices! Vortices All The Way Down! (https://letslearntogether.neocities.org/scispirit/VBM/vortices.html)
Description: Developing the fundamental patterns with an eye for their application within science

• The Flux Thruster (https://letslearntogether.neocities.org/scispirit/VBM/fluxthruster.html)
Description: Exploring the "proof of concept" for creating technologies based on Vortex-Based Mathematics

• The Machine Becomes A Ghost (https://letslearntogether.neocities.org/scispirit/VBM/machineghost.html)
Description: Laying a foundation for "artificial intelligence" by mimicking Nature within the basics of computer hardware and software

They are written with the intention of being understandable to anyone with very little background, but also give ideas that would be valuable to someone with a deeper understanding of the subjects involved (such as an engineer, mathematician, physicist, etc.).

Personally, I won't claim to know much about anything, but I am absolutely certain that we can all work together to use this type of information to benefit all of humanity in incredible ways.

Thank you for reading. Happy Studies! ♥
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 26, 2020, 03:19:06 AM
interview with sloot's son, ofc, he knows nothing

he has good suspicion that big companies are already using this in secret

https://factsaboutdirk.wordpress.com/2018/09/13/interview-with-ben-sloot-son-of-inventor-jan-sloot/

some good ideas here. i like the MIDI music analogy, short keys instruct the cpu to generate music which has much more information in it than the keys do


https://ask.slashdot.org/story/17/06/09/0025250/ask-slashdot-what-is-your-view-on-sloot-compression
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 26, 2020, 07:18:09 AM
this guy makes a good point that if it worked as sloot claimed it would be possible to encode dozens of movies in ending credits of first movie and so on, or why not use each frame to encode set of keys for a movie, so 1 "movie" could contain hundreds of thousands of movies and each of those movies also, and so on to infinity

really sounds fishy

"however sloot claimed his video encoding to be so good that you could have on a floppy all the movies in the world- because recursion, if his scheme worked you could encode the next movie in the images in the credits scene of the previous movie - THIS SHOULD clue people in that it was just all bullshit, but for some reason doesn't? how hard is it for people to grasp this recursion problem of arbitrary information? it has nothing to do with if the compression scheme is procedural or not, it's just about if you can point to so much arbitrary data with so little data."
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: triangle on July 26, 2020, 04:17:03 PM
Sloot patent is all about compression.

I read it yesterday.

But if you read it carefully, it needs previous data to calculate new,
and overwrite previous.
Very simple.

Third time. No more questions.

We still waiting for you to replicate this as you stated its simple! When will you tell the forum members you cracked the Sloot Algorithm?
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 26, 2020, 07:27:57 PM
When you share your device,
you are not sharing, but demanding and trolling members.

I tried method on paper on a few random sequnces with high entropy,
and it worked.

It is long way from real product and coding software.
Maybe it wont work on a huge amount of data, maybe.

And this is FE forum, and I shared related to FE.

What about you?

You wanna just others to do work for you?

Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 26, 2020, 07:29:57 PM
Do you know Chris outside this forum, triangle?
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: triangle on July 26, 2020, 08:06:46 PM
Sloot patent is all about compression.

I read it yesterday.

But if you read it carefully, it needs previous data to calculate new,
and overwrite previous.
Very simple.

Third time. No more questions.

Dont change the subject, you said its very simple, if it is simple help the forum to crack it, or are those just empty words?

Think then twice before stating something as empty words doesnt help anyone!

Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 26, 2020, 11:38:19 PM
When you share your device,
you are not sharing, but demanding and trolling members.

I tried method on paper on a few random sequnces with high entropy,
and it worked.

It is long way from real product and coding software.
Maybe it wont work on a huge amount of data, maybe.

And this is FE forum, and I shared related to FE.

What about you?

You wanna just others to do work for you?

ur full of bs, if not let's see it

Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 26, 2020, 11:42:14 PM
And you want it for what exactly?

Just to know?
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: triangle on July 26, 2020, 11:48:24 PM
And you want it for what exactly?

Just to know?

You are just a insecure child with a very ignorant attitude.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 26, 2020, 11:49:33 PM
ur acting like a child who wants to be seen as a big man, but just looks silly






Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 26, 2020, 11:50:03 PM
If it works, it will come to you and everyone else.

The only reason you want to know now,

is to be in front of everyone, develop it and sell it first.

I know you for few days, why should I work with you instead with someone
I know lot longer and I can trust.

The goal is same. To go public.

Why are you person I should reveal all?

I will tell to persons I choose and have trust in them.

I dont know who you are, I know only nickname.

Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 26, 2020, 11:52:06 PM
Tell me,


If you crack it, will you ever come on this forum and share?

Be honest.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 26, 2020, 11:53:12 PM
spare us the bs
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: triangle on July 26, 2020, 11:53:16 PM
ur acting like a child who wants to be seen as a big man, but just looks silly

Let him please, he is just a insecure child, he dont know how to react, let him be!
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 27, 2020, 12:06:37 AM
No,

I dont wanna be rude to Nix.

I worked on endless compression for 3 years around 2003.
I failed. Tried many things.

That is why this topic was interesting to me.
I suppose I just needed a time to forget about it.
By reading about it again, I just saw where I was wrong before.

On paper it works, best with high entropy data.
It does not mean that it will work with large amount of data.
And to work on this and try it, I will work with my friends,
which I can trust.

Nobody is holding you.
I did it with paper and pencil, I am not at home on my PC.
And will be on road for a week more.


Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 27, 2020, 12:13:54 AM
those are empty words without substance



Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: triangle on July 27, 2020, 12:19:04 AM
No,

I dont wanna be rude to Nix.

I worked on endless compression for 3 years around 2003.
I failed. Tried many things.

That is why this topic was interesting to me.
I suppose I just needed a time to forget about it.
By reading about it again, I just saw where I was wrong before.

On paper it works, best with high entropy data.
It does not mean that it will work with large amount of data.
And to work on this and try it, I will work with my friends,
which I can trust.

Nobody is holding you.
I did it with paper and pencil, I am not at home on my PC.
And will be on road for a week more.

Well you are rude, 1 thing i do not understand, you worked 3 years in 2003 on this algorithm on paper? But how come? If you are 15 years young you was born in 2005.

Can you please explain? I completely lost here!
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 27, 2020, 12:24:54 AM
OK,

I have a home
I have my PC
I worked for 3 years on paper, my PC...

For last week I am on the road.
I dont have my PC in my car
I did not carry laptop this time.

For a week more until I get back home,
I have phone, paper and pencil.

Are you still lost.
Maybe you just have to switch to another account and feel better, triangle.

Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: triangle on July 27, 2020, 12:35:38 AM
OK,

I have a home
I have my PC
I worked for 3 years on paper, my PC...

For last week I am on the road.
I dont have my PC in my car
I did not carry laptop this time.

For a week more until I get back home,
I have phone, paper and pencil.

Are you still lost.
Maybe you just have to switch to another account and feel better, triangle.

With all respect, thank you for explaining, 1 thing you didnt explained thats your age, if you are 15 you then born in 2005, how it is possible to work on the algorithm in 2003?

I didnt asked if you have a car, house or pc, you get sloppy, small mistakes!
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 27, 2020, 12:41:33 AM
I have more than 15.

I wrote that already in this topic.

Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: triangle on July 27, 2020, 12:51:03 AM
I have more than 15.
I wrote that already in this topic.

Sorry I didnt read that you was 16, my sincer apology.

If you cracked the code then I believe you had read about Han van Meegeren, same thing just other product, probably that inspired you and learned from it in how you could decode Jan Sloot algorithm!

Once again apology for saying you was 15, indeed you need to be 16 to use a car. My bad.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 27, 2020, 12:59:32 AM
No problem at all.

And thanks for wishing me 16 again.
Very nice from you.

Yea, I probably stole it from someone else.
I did not worked for it at all in that 3 years, and over the years.
You think that things are comming just like that,
by itself?

I am not clear what you want, you already have your FE device.
You want more?
How much more?


Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 27, 2020, 01:02:27 AM
And you have few accounts here.

What more do you want?
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: triangle on July 27, 2020, 01:10:14 AM
No problem at all.

And thanks for wishing me 16 again.
Very nice from you.

Yea, I probably stole it from someone else.
I did not worked for it at all in that 3 years, and over the years.
You think that things are comming just like that,
by itself?

I am not clear what you want, you already have your FE device.
You want more?
How much more?

Nope, im not interested in this as it doesnt exist and cant be achieved.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: triangle on July 27, 2020, 01:10:43 AM
And you have few accounts here.

What more do you want?

This is all you got? Cant do better?
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 27, 2020, 01:13:13 AM
let's play along

you don't have to reveal your big "secret"

let's see input and output string

let's have some fun
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 27, 2020, 01:22:19 AM
I was wrong.

It does not work.

It is impossible to do such a thing.

WhatIsIt

Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 27, 2020, 01:31:40 AM
from simple to impossible in few posts, eh

it indeed is impossible in a way sloot and adams claimed, cause if it were true you should be able to encode next movie(s) in ending credits of the first and so on recursively to infinity
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: WhatIsIt on July 27, 2020, 01:36:38 AM
I was wrong,

I see my mistake now.
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on July 27, 2020, 01:59:48 AM
dutch comment from the long version of tv report on sloot

https://www.youtube.com/watch?v=4V-qrQd87xY

i google translated it, guy claims he used to tell people to buy a new tv and then repair and sell their old tv, well, kinda common practice, that alone doesn't dismiss him as much as recursion argument

not sure what he means by death ad, is this a translation error or he implies sloot faked his death

"funny. Jan Sloot was known early on that if you offered a TV for repair, he would tell you to buy a new one because repair was too expensive. Then you bought a new TV and Jantje repaired your old TV and sold it for a lot of money. My brother-in-law was working for him at the time and I can still remember Jan Sloot calling my brother-in-law when that death ad was in the newspaper. I think Jan Sloot could think outside the box and was perfectly able to make you believe that something was possible."
Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: nix85 on February 14, 2022, 06:39:31 PM
Today i somehow got reminded of Sloot and been thinking about it again. I regurgitated many of the old ideas and had some new ones.

As for my idea from the first page, i knew from the moment i came up with it it is a good idea potentially great, but i instantly saw it has serious drawbacks and it turned out it has serious drawbacks as already noted back there, first drawback is it needs a spacer so decoder can tell between different iterations but that is just one ASCII symbol 8 bits worth, for example █, that is not such a big issue altho it complicates things for multistage compression a bit. Second drawback is simply the small likelihood of sequences longer than 4 digits corresponding to sequences to be encoded appearing among the random sequences. That's a bigger issue which means many iterations would have to be done to encode even just first 100 numbers which means not so efficient in the end.

It comes down to how to make the coordinates shorter than the data efficiently and that it allows for multistage compression. I already mentioned this back then, with enough computing power random stream could be found which most matches the original stream.

But i don't think this is how Sloot did it (if he did it), he stressed the term analog and said age of digital is over.


Title: Re: Let's crack Sloot algorithm - infinite "compression"
Post by: ne0 on September 28, 2022, 07:47:21 PM
Possible breakthrough happened during my conversation with some denier on youtube, IDEA came to me.

Quoting myself....

So if we have the same unique random number stream "playing" simultaneously with numbers to be sent, say software generates ones when random number matches the data number and zeros when it does not.

So we get 1110001100101100000101000010001000010000100010000100001001001000000100000

Notice the possible advantage here of representing a 4 bit number with a single bit, of course there would be many mismatchess too but gain is possible.

Before this is done, software should look into the database of random number streams and pick those with highest number of matches. Etc.

Since we end up with a nice pure stream of zeros and ones, of course generated streams should be converted into numbers 0-9 and further compressed in same manner which is a BIG advantage. Possibility of multiple iterations is essential to 'infinite' compression.

It's all about smartly picking data from the "random" stream and doing it many times.

Etc.... use your INTELLIGENCE. We are not trying to break the information entropy, we are finding an elegant way to work with it in a wider context.

...end of quote.

Essential part is obviously having a large enough pool of random streams to find streams with high match %.

I encourage everyone to take the idea and develop it further. I am asking for no credit or royalties. I am too focused on other things and got no time for it. This goes especially to all you young ones reading who have a spark for this.

"The numbers from 0 to 10 are thus in binary 0, 1, 10, 11, 100, 101, 110, 111, 1000, 1001, and 1010"