Crypto Compression Concept Worth Big Money - I Did It!

[B(asic)Miner]

Basic information theory says it is not possible to produce an algorithm that reduces the size of every possible input sequence. No matter what magical algorithm you are using, I will be able to construct input that, when compressed, take up as much or more space than before.

If you use a magical "dna sequence" (hash value call it what you will) with a length of 128 bytes, that gives you 2^1024 possible ways to represent a file. The problem is that I can construct 2^1024+1 different files, and it has to follow then that two of these files will produce the same hash value. You will have no way of knowing which of these two files was used as the original input for your algorithm.

There is no "loophole" or "alternative dimensions" that will allow you to represent 2^1024+1 unique values with 2^1024 bits.

-Michael

Michael, thanks for your comments, but you don't know what I am doing and I can't tell you everything of course.  But the method I am using to copy the data allows for infinite possibilities, where the file's size actually helps to make it more unique than less unique.  The larger the file, the more impossible another file could have its "hash" as you call it, although I am not using hashes because that implies a mathematical compression algorythm.  And it's not even an algorythm.  It's just three core rules.  It's so easy to do the encoding, it could be done on the fly by even the world's slowest CPU, even for large data sets.  It's the decoding that will take fast GPU or ASIC rendering to solve the block the way Bitcoin does.

PS:  There are containers in nature (into which data can be stuffed if you know how, and I do) and it can be downloaded from that container anywhere in the world by anyone if they knew the crypto code.  What this says is that everything we've ever done is already contained in nature if you know how the bits were arranged, all possible combinations already exist in nature, not only for everything we've already done, but for everything we will ever do in the future, too.  But it takes understanding how my theory works to be able to realize how that.

[sealberrder]

You should waste time writing lengthy posts, and code test implementation of your idea instead to see how it does work 

[BurtW]

And it's not even an algorythm.  It's just three core rules.  It's so easy to do the encoding, it could be done on the fly by even the world's slowest CPU, even for large data sets.  It's the decoding that will take fast GPU or ASIC rendering to solve the block the way Bitcoin does.

You certainly are swimming against the main stream here.  I know you keep saying that you are not describing a compression algorithm but you need to know that all of the current modern video compression standards fully specify the decoder and leave the encoder unspecified.

You are saying that you are going to specify the encoder but leave the decoder unspecified?

Specifying the encoder and not the decoder is kind of like saying the answer to life, the universe and everything is 42 - we just don't know the question yet.

Is there any way you can specify the decoding process?

[mberg2007]

Michael, thanks for your comments, but you don't know what I am doing and I can't tell you everything of course.  But the method I am using to copy the data allows for infinite possibilities, where the file's size actually helps to make it more unique than less unique.  The larger the file, the more impossible another file could have its "hash" as you call it, although I am not using hashes because that implies a mathematical compression algorythm. 

Look, I'm sure you put a lot of thought into this but you are out to do something that just isn't possible. It doesn't matter if its a hash value or if the numbers come from a magic 8 ball or though visions by psychics. The simple fact is that if you have 4 bytes compressed size, then the total number of unique inputs that can be represented by those 32 bits are 2^32 = some 4 billion or so. But I can create a lot more unique files than 4 billion. You have to see that. Decoding the 4 bytes compressed data has multiple solutions (actually an infinite number of solutions) and there is no way to know which one of these solutions was the original input.

You're trying to build a perpetuum mobile and refuse to accept the mathematical and physical facts that tell you that this just isn't possible. Sorry, don't mean to be harsh, but you are wasting time and energy.

-Michael

[DeathAndTaxes]

You're trying to build a perpetuum mobile and refuse to accept the mathematical and physical facts that tell you that this just isn't possible. Sorry, don't mean to be harsh, but you are wasting time and energy.

How is it a waste of time and energy to scam money off of "investors"?  Your only mistaken is in thinking the OP is genuine.

[B(asic)Miner]

BurtW:
The decoding method is Brute Force, sorting descending columns of binary branches looking for the blockchain that solves a timeline.  That's why I need some help programming this, if only to find out how long such a routine will take, because it could be that although my theory will work in theory, in reality, the time needed to decode the block may outweight ever actually using it.   Then the theory is busted anyway, due to that possibility.

 
Michael:
Has Pi ever been solved?  Because I was under the notion that it was an irrational number of non-repeating digits going on endlessly.  My theory requires the use of Pi to at least 1 or 2 GB which are held in memory.  The bits of 0s and 1s create a branching storyline through Pi that, based on my ruleset, can only arrive at one location in Pi for every unique file.  If that is the case, how is it possible that you can say my Crypto Key isn't unlimited, or INFINITE even?  The index location itself that you arrive at in Pi is the key.  You only arrive at the location you arrive at by following a few rules.  There is NO POSSIBLE WAY to arrive at any location with two different files because the bits inside those files will cause the program to take a different turn when encoding it, arriving at a different place in the "timeline" of Pi.  If you took the same jpeg image, loaded it and changed one pixel from white to black, saved it out, so that only 1 pixel was different, then that change would ripple through the timeline, meaning you would stop on a totally different place in Pi.  We can't possible go too far into Pi because we have to be able to sort backwards from the Index we stopped at and find the decimal point in Pi 3.14 etc...  the decimal point is the beginning point.  Our timeline must fit exactly to the last digit, otherwise, the program keeps hunting through the possible combinations.  That's why I say it could end up being that my theory can't work based on the time needed to search billions of combinations, although the actual searching isn't encrypted, it just straight numbers, so it should be pretty fast, I would wager.

Now you've gone and gotten me to give away a large portion of the concept, I hope this doesn't come back to bite me.

[balanghai]

And so is tesla considered to be mad and crazy. But look, his systems do work.

[kslavik]

First, please stop calling it a blockchain - it is not a blockchain or you do not understand what a blockchain is.

Secondy, can you apply your method to a sequence which looks like that xxx.yyyy.zzzz to reduce it even further? As you claim, that you can compress any data, it mean you can further reduce its size, right? So a string in a form of xxx.yyy.zzzz could be reduced to xx.yy.zz, and why stop there, let's run it again and produce an even smaller "crypto-hash" by running it again to look like that: x.y.z. What is stopping us? Do you see what I just did? I just improved you method from 99.8 to 99.99998 compression ratio. Don't you see a contradiction there?

[spndr7]

root 2      1.41421356 23730950 48801688 72420969 80785696 71875376 94807317 66797379 ...
binary         01001110 01110110 00001000 10000101 00101010 11011110 10001111 00111111 ...


Here 8 byte binary data can be represented by modding every digit of root 2 (0 for even and 1 for odd) by 2 till 64 places(size of data).

I don't know whether its possible or not to finding corresponding decimal digit sequences of irrational numbers for arbitrary data set.
Mapping meaningful data to nature's randomness would be too difficult.
It is seems impossible.What do you say 'b ASIC Miner' ?

[B(asic)Miner]

root 2      1.41421356 23730950 48801688 72420969 80785696 71875376 94807317 66797379 ...
bin             01001110 01110110 00001000 10000101 00101010 11011110 10001111 00111111 ...


Here 8 byte binary data can be represented by modding every digit of root 2 (0 for even and 1 for odd) by 2 till 64 places(size of data).

I don't know whether its possible or not to finding corresponding decimal digit sequences of irrational numbers for arbitrary data set.
Mapping meaningful data to nature's randomness would be too difficult.
It is seems impossible.What do you say 'b ASIC Miner' ?

It is not impossible, and it's not even difficult, because I have done it.  At least in theory (which I have proven on paper at least).  I still have to wade through actually implementing it with the right team of people to see if it actually works in reality not just just theory.

Again, there is a trade off for doing this, it means we have to do a huge amount of hunting through huge strings of data over and over again, and I'm not sure it won't take 25 years to solve one file if it's over 1 GB in size.  But I've heard those Quantum 500 mbit computers can do calculations that boggle the mind.  Of course, then only the government could use my theory in that case.  I'm hoping that this theory will work for the average user, or else it isn't something I want to even create.  Just more power to the government, I don't want that.

[B(asic)Miner]

First, please stop calling it a blockchain - it is not a blockchain or you do not understand what a blockchain is.

Secondy, can you apply your method to a sequence which looks like that xxx.yyyy.zzzz to reduce it even further? As you claim, that you can compress any data, it mean you can further reduce its size, right? So a string in a form of xxx.yyy.zzzz could be reduced to xx.yy.zz, and why stop there, let's run it again and produce an even smaller "crypto-hash" by running it again to look like that: x.y.z. What is stopping us? Do you see what I just did? I just improved you method from 99.8 to 99.99998 compression ratio. Don't you see a contradiction there?

The smallest text file size is 4 Kilobytes sitting empty on your desktop.  If you fill it with a block of text and save it, it still read 4 kilobytes.  In that text file would be something that looked like this (I'm not a programmer so this is only an illustration, please no criticism unless its to actually teach me):

[OPENFILE]
[filesize=2400000000_&_Name="video_for_kslavik.avi"]
[MChunks=4_&_REM:  Begin Chunk(s) on Next Line! ]
[1,w, xxxxxx, y, zzzz]
[2,w, xxxxxx, y, zzzz]
[3,w, xxxxxx, y, zzzz]
[4,w, xxxxxx, y, zzzz]
[CLOSEFILE]

If you were to run that through MY theory (which is made for larger files above 1 megabyte) you would still end up with this for the next smaller part:

[OPENFILE]
[Layer=2]
[MChunks=1_&_REM:  Begin Chunk(s) on Next Line! ]
[1,w, xxxxxx, y, zzzz]
[CLOSEFILE]

SO WHAT WOULD BE THE POINT?  I suppose you could do a RAR compression of the text file, but still, what's the point?  It's already small enough.

[murraypaul]

Has Pi ever been solved?  Because I was under the notion that it was an irrational number of non-repeating digits going on endlessly.  My theory requires the use of Pi to at least 1 or 2 GB which are held in memory.  The bits of 0s and 1s create a branching storyline through Pi that, based on my ruleset, can only arrive at one location in Pi for every unique file.  If that is the case, how is it possible that you can say my Crypto Key isn't unlimited, or INFINITE even?  The index location itself that you arrive at in Pi is the key.  You only arrive at the location you arrive at by following a few rules.  There is NO POSSIBLE WAY to arrive at any location with two different files because the bits inside those files will cause the program to take a different turn when encoding it, arriving at a different place in the "timeline" of Pi.

It doesn't matter.
If your index key is only N bits long, you cannot index more than 2^N files. No matter how much more you post, this will continue to be true.

Pi is an irrational number, which means there is no fixed sequence of recurring digits which continues indefinitely.
It does not mean that every sequence of Y digits is guaranteed to be unique.
In fact, even a few moments of thought will tell you that there must be repeating sequences, otherwise Pi would be representable by a finite string of digits, which it isn't.

So there is a possible way to end up with the same index key from two different files, and that is how you end up with only 2^N possible answers.

[murraypaul]

The smallest text file size is 4 Kilobytes sitting empty on your desktop.  If you fill it with a block of text and save it, it still read 4 kilobytes. 

No.
The file will always take up at least one filesystem block, and it may be that for your filesystem each block is 4Kb.
That does not mean that the file contains 4Kb of information.

[B(asic)Miner]

Has Pi ever been solved?  Because I was under the notion that it was an irrational number of non-repeating digits going on endlessly.  My theory requires the use of Pi to at least 1 or 2 GB which are held in memory.  The bits of 0s and 1s create a branching storyline through Pi that, based on my ruleset, can only arrive at one location in Pi for every unique file.  If that is the case, how is it possible that you can say my Crypto Key isn't unlimited, or INFINITE even?  The index location itself that you arrive at in Pi is the key.  You only arrive at the location you arrive at by following a few rules.  There is NO POSSIBLE WAY to arrive at any location with two different files because the bits inside those files will cause the program to take a different turn when encoding it, arriving at a different place in the "timeline" of Pi.

It doesn't matter.
If your index key is only N bits long, you cannot index more than 2^N files. No matter how much more you post, this will continue to be true.

Pi is an irrational number, which means there is no fixed sequence of recurring digits which continues indefinitely.
It does not mean that every sequence of Y digits is guaranteed to be unique.
In fact, even a few moments of thought will tell you that there must be repeating sequences, otherwise Pi would be representable by a finite string of digits, which it isn't.

So there is a possible way to end up with the same index key from two different files, and that is how you end up with only 2^N possible answers.

I appreciate you taking the time to explain matters, but I haven't your background, and I'm not sure what you mean by 2^N, so I can't actually formulate any response to your critique that will make sense to you.

Every unique file is, itself, made up of repeating strings of data, but what makes the data unique from other files is the arrangment of the data, how the 0s and 1s are arranged.  Thats true for almost everything. Some popular music differs from other songs only by a few notes and the main singer, but we view almost all of it as unique, the small differences do a lot, even if its almost the same.

What I've created is a way for every bit (0 or 1) to affect the path taken to reach the index in Pi.  Therefore, its impossible for any index in Pi to hold more than any one outcome.

Take 0000001  and    0001000   and  100000 for example.   The index for each is, respectively:

BYTE EXAMPLE:              0000001:       0001000:        100000:
    Pi Index:                      (57)               (85)             (103)

And that's just with one byte of data.  The larger the file size, the more unique it becomes.   You could have billions of 1 megabyte files, and if even one bit in their internal structure was different, the outcome would be different.  This is truly the butterfly effect at work.

[murraypaul]

It doesn't matter.
If your index key is only N bits long, you cannot index more than 2^N files. No matter how much more you post, this will continue to be true.

Pi is an irrational number, which means there is no fixed sequence of recurring digits which continues indefinitely.
It does not mean that every sequence of Y digits is guaranteed to be unique.
In fact, even a few moments of thought will tell you that there must be repeating sequences, otherwise Pi would be representable by a finite string of digits, which it isn't.

So there is a possible way to end up with the same index key from two different files, and that is how you end up with only 2^N possible answers.

I appreciate you taking the time to explain matters, but I haven't your background, and I'm not sure what you mean by 2^N, so I can't actually formulate any response to your critique that will make sense to you.

Every unique file is, itself, made up of repeating strings of data, but what makes the data unique from other files is the arrangment of the data, how the 0s and 1s are arranged.  Thats true for almost everything. Some popular music differs from other songs only by a few notes and the main singer, but we view almost all of it as unique, the small differences do a lot, even if its almost the same.

What I've created is a way for every bit (0 or 1) to affect the path taken to reach the index in Pi.  Therefore, its impossible for any index in Pi to hold more than any one outcome.

Take 0000001  and    0001000   and  100000 for example.   The index for each is, respectively:

BYTE EXAMPLE:              0000001:       0001000:        100000:
    Pi Index:                      (57)               (85)             (103)

And that's just with one byte of data.  The larger the file size, the more unique it becomes.   You could have billions of 1 megabyte files, and if even one bit in their internal structure was different, the outcome would be different.  This is truly the butterfly effect at work.

Lets go in stages:
a) If you have billions of unique files, they must map to billions of unique Pi indexes, otherwise two files would map to the same index, and you would not be able to to determine which of the two files was the original. Do you agree?
b) If you had hundreds of billions of unique files, they must map to hundreds of millions of unique Pi indexes, otherwise two files... Do you agree?
c) Therefore the number of possible indexes increases as the number of possible input files increases. Do you agree?
d) Therefore the number of possible indexes increases as the size of the input files increase. Do you agree?
e) Therefore there is no fixed length of index string which can possibly represent all of the possible indexes for all possible files. Do you agree?
If you have got all the way through to e) and still agree, then you should see that your scheme as presented, with a fixed index length which represents all possible files, is impossible.

To take a small example, lets look at all files of 32 bits in length.
There are 2^32 of them. (2*2*2*2... 32 with 32 numbers 2s in).
That is 4294967296 in decimal.
So there are 4294967296 possible input files.
They each need to have a unique Pi index.
Therefore there must be 4294967296 Pi indexes for them.
That is 2^32 Pi indexes.
Therefore you need 32 bits to represent the possible Pi indexes.
Therefore, as explained before, the average file size after compression will be the same (or greater, with a poor compression scheme) that the average input file size.

[B(asic)Miner]

It doesn't matter.
If your index key is only N bits long, you cannot index more than 2^N files. No matter how much more you post, this will continue to be true.

Doh!  I finally understood your meaning, sorry.  I do see your point at last.  But that only helps me in the long run, because now I can do something to implement an offset function, meaning we can reset where to start from in Pi if and when we do run into such an error during the research phase of programming this.

I am working with Pi, but I could just as easily work with other irrational numbers, too.  This would serve as a way to encrypt each file by offering hundreds of possible irrational number sets so someone couldn't easily find your file if they somehow got a hold of your Crypto Key.

Isn't it possible we could work with a large enough index key that the N bits you are referring to are larger than the number of files in existence at present or any time in the near future?  How many total files are there in the world at this point?  Does anyone know?

[BurtW]

So if the sequence of bits you are looking for is very long:

   01000010001001000...101001000111

Let's say 1 million bits then are you trying to locate this 1 million bit sequence in pi?

[kslavik]

It doesn't matter.
If your index key is only N bits long, you cannot index more than 2^N files. No matter how much more you post, this will continue to be true.

Doh!  I finally understood your meaning, sorry.  I do see your point at last.  But that only helps me in the long run, because now I can do something to implement an offset function, meaning we can reset where to start from in Pi if and when we do run into such an error during the research phase of programming this.

I am working with Pi, but I could just as easily work with other irrational numbers, too.  This would serve as a way to encrypt each file by offering hundreds of possible irrational number sets so someone couldn't easily find your file if they somehow got a hold of your Crypto Key.

Isn't it possible we could work with a large enough index key that the N bits you are referring to are larger than the number of files in existence at present or any time in the near future?  How many total files are there in the world at this point?  Does anyone know?

You still don't get it, do you:  if you take all 64 bit files in the universe (8 bytes), there are 2^64 possible files which could be build with those 8 bytes (only 8 bytes). How are you going to represent all those 8 Quintillion files with an index which is less than 8 bytes?

[BurtW]

Here is a very simple example.

We know pi out to who know how many digits - for the sake of this example let's call it "enough".

Your phone number is 123-456-7890

You find your phone number and it happens to be at location 987,654 in the number pi.

You can say "My phone number is 123-456-7890".  This takes 10 digits.

OR

You can say my phone number is at the 987,654 digit of pi.  Cool!

BUT

What if you find your phone number at location 987,654,321,987,654,321 in the number pi.

You can say "My phone number is 123-456-7890".  This takes 10 digits.

OR

You can say my phone number is at the 987,654,321,987,654,321 digit of pi - but this actually takes more digits.

Have you solved this problem?

[murraypaul]

Isn't it possible we could work with a large enough index key that the N bits you are referring to are larger than the number of files in existence at present or any time in the near future?  How many total files are there in the world at this point?  Does anyone know?

You could pick some arbitrarily large value of N, sure.
But the second shoe, which hasn't dropped yet, is that your index key will (on average) be the same size as the files you are trying to compress.
So it takes up just as much space (on average) to store the index key as it would to store the file itself.
To compress 1MB files, you need a 1MB index key.
To compress 100GB files, you need a 100GB index key.