Crypto Compression Concept Worth Big Money - I Did It!

[Jace]

I just want one of two things:   1) for my quest to be over by being proven it can't work (in a public way, not in some secret board room) ... or 2) finding it can work and getting the reward for not giving up on it.

We have proven it can't work, repeatedly.
You just don't believe us.

This. It seems like you're simply ignoring logical facts. Claiming that people don't understand your idea. Well, we do. Really.

B(asic)Miner, do you even consider at all that it might be possible that your idea is just flawed? As in, plain wrong? Cause if not, no reasoning whatsoever will cure this delusion and we might as well end this discussion, and leave you to your attempts without further hindrance (good luck in that case).

[B(asic)Miner]

OOPS, reading back through the previous posts I see this has already been shown here:

https://bitcointalk.org/index.php?topic=288152.msg3120822#msg3120822

Oh well, might as well post my work here anyway....

-----------------------------------------------------------------

Thanks for writing the program!  Cool, I was just about to do the same.

Here is a quick example showing that the paths are not unique for the idea as described.  We may not have the full description and there may be more to it than we have been told but using the start at 4, jump to next 4 as long as the input is zero and increment when the input is one idea:

The following two sequences must have different paths:

00001000
00010000

Assume what if we are in an area of pi with the following sequence of digits:

   4 ... 4 ... 4 ... 5 ... 4 ... 5 ... 5 ... 5 ... 5  (where ... means digits that do not matter in this example)

If my understanding of the idea is correct both inputs land at the same end location.

These two DO have two different ending points (Index Ending Point)
00001000 would map to 4 4 4 4 5 5 5 5   >>(INDEX 190)   (four 4s within the first 36 Indexes of Pi and four 5s within the 48 to 190 indexes)
00010000 would map to 4 4 4 5 5 5 5 5   >>(INDEX 209)   (three 4s within the first 23 Indexes and five 5s within 48 to 209)

>>For this example you gave, the paths are different.  But we can probably still find a solution where both byte pairs match, you just chose the wrong example.

but with the totally possible distribution given we end up at the same ending location.

Is our understanding of your idea complete and correct or is there more to it than described so far?

[BurtW]

My statement above was more general: "this can happen somewhere therefore you will not get unique results".

However, here is exactly the same issue happening right there in the first few digits of pi.

Maybe by carefully studying this specific example you will discover this is the general problem with the entire idea:

Take this part of pi:

3.141592653589793238462643383279502884197169399375

These two sequences have exactly the same length and both end on the final 5:

00010
00001

This is a very specific example of exactly what I described as a general problem.

[B(asic)Miner]

Okay, thanks for your assessment of my situation, all of you.

I just want to know a few more things from you all.  

Let's say I made a modification to my ruleset (actually, it's not a modification, its the ruleset I started with, but felt it would add too much complexity, but perhaps that's what is needed here anyway) so I am going to give the ruleset here again from my original template.  Please someone, the ones who did the proofs before, do a few proofs again to show me my error, or if it's viable now:

Here goes everything:


1) Open file to processed.  Analyze the data.  Then we open our file and begin to record the following:
   A) Original Filename.  Size of the Original File.  Size of Pi Index Used (how big each chunk is to be split into).  Size of the last Mega Chunk in bits (if applicable).
   B) Basekey (the first 64 bytes of the original file, giving the program enough room to establish a unique path given a number of hops.
  
2) Begin reading the data one character at a time (converting hex to Ascii Binary) all in memory using the loaded Pi Index to the Pi Index Size shown in example A above.  Convert everything (all file contents) to Ascii Binary (so every incoming piece of data is exactly 8 bits).  Begin moving forward through Pi by hopping on a single solitary digit called a "Hunt Value" meaning the number we are to be hopping on in Pi.  Starting from the decimal point, begin encoding by hopping.  Start at the 1st 4 in Pi if our first bit is a 0.  If it's a 1, start at the first 5 in Pi.  Hop along Pi, encoding 0s and 1s using these rules.

>>Here comes the rule change!

0 = no change in Hunt Value. 1s = +1 to Hunt Value.   However, how we search for our Hunt Value changes here:   We have to double confirm every Hunt Value against the Index at that location being even (0) or odd (+1).  We can only accept a Hunt Value which double confirms the bit we are encoding.  For example:   Here is  our data to be encoded:

0010 0001  (space added for readability only)

Our first Hunt Value is 4, but we can't stop on just any 4 now, it must be an EVEN 4!  Here goes:   The first 4 in Pi is at index 2 (if you are counting indexes 1-50 and not 0-49 like coders do, so let's please just use 1-50 to keep this easy to read (no offsetting for now))  That means the first 4 IS a 4 AND it's EVEN.  

Let's continue:  the 2nd 0 in our encoding byte example ....  the next four we find in Pi is at Index 19 (odd) but we are looking for an EVEN 4 because our encoding bit is still 0.   Our third 4 is at Index 23 (no good still) so we keep going ....  ah, at Index 36, we have our 2nd EVEN 4!   So now our 2nd bit is encoded ....   Next we are encoding (our third encoding bit) a 1, so now we need to find the next ODD 5 (it increments+1 and because it's a 1, its ODD too) ...  so our first 5 from that location is at Index 48 (an even, so its no good) ... but at Index 51, we have our first ODD 5, we just encoded that bit.  

This process continues accordingly.  This spreads out the hops a great distance, ensuring the path taken is more unique, but at a cost of having to use way more of the Index for every byte "stored" ...

>SNIP


DECODING CHANGES:
We now have an additional checksum for helping to narrow down the possible paths that could have been taken.  

Please someone (murraypaul that means YOU-wink) run the proofs you ran before using this new method and see if they are not all unique. I beg you.  I am very curious to see what comes from this.

[BurtW]

That does not fix the problem.

[B(asic)Miner]

That does not fix the problem.

Maybe you're right, but I want to wait until Murraypaul redoes his long list of Indexes again showing that they still end at the same place every time.  Maybe the list will shrink considerably to almost nothing, in which case, I only then need to find a few more criteria to increase uniqueness again.  It may still be possible, but I won't know until the proofs are shown here.  Thanks BurtW.

[spndr7]

Generative Art
"Generative Art" is often used to refer to computer generated artwork that is algorithmically determined.

Some examples of generative art (5 examples in 451 KB)
You can see how much data is algorithimically compressed in these demos.

More resources
Scene 
Assembly
Demojs

[bseymour]

This is indeed impossible, and is simply proven. It bothered me for months about a decade ago when I was working on a brainstorm team to do something very similar, where a small amount of mathematical data could be processed into a much larger file. Herein lies the problem:

In any given amount of bytespace, represented by x as the number of total bytes, you have 256^x different possible combinations.

So, for instance, in a 20 KB compressed file, you have 256^20,000 total possibilities. Assuming that is 98% compression, the original file would be 1 MB. Problem is that a 1 MB file would have 256^1,000,000 different possible outcomes.

This kind of compression does not exist because you cannot use mathematics to create an all-inclusive compression method. That is why most compressions are very specific to the type of file you are working with.

[B(asic)Miner]

Generative Art
"Generative Art" is often used to refer to computer generated artwork that is algorithmically determined.

Some examples of generative art (5 examples in 451 KB)
You can see how much data is algorithimically compressed in these demos.

More resources
Scene  
Assembly
Demojs

Oh, I love DemoScene!  I was an an Amiga fan in late 80's and early 90's until long after Windows DOS came on the scene, which was totally bankrupt of efficiency compared to the Amiga.  Long live Amiga, forever.  (Okay, fanboy rant over).

I have all the Demoscene demos and have also made a collection of all their music, too, it's some of my favorite music in the world.  


ANSWER:
Yes, to get on with your input, I was trying to think of a way to store a mathemetical version of my compressed key as a jpeg, where each pixel would be black (on white background) to show the movement thru Pi in a stock-exchange sort of drawn squiggly line representing the path taken from all possible paths.  It would draw from left to right when encoding, going from bottom and rising toward the top right, with every 0 going down and every 1 going up and groups of 0s (but not 1s) going level (left toward right).  Then the image would be analyzed and decoded back out using the black bits to help the program to accurately calculate all the ups and down of the timeline, which would be unique.  Because even if the overall file ended up at the same Index, the internal bits would rise and fall differently, creating a key effect from the actual shape of the path taken.  Then you could do optical image recognition on the image, counting pixels, overlaying the computer's approximation until it finally matches 100%, and then you'd know the actual path taken bit for bit, not just because of the end place thru Pi.  It would become a signature based on unique shape (which WOULD BE UNIQUE).  

But I wonder how much data it would take to create such a drawing even for the smallest of files?  The image would become enormous and would have to be saved in a lossless format otherwise if even one bit got changed, it would be a disaster.  For a 50 MB file, it might take a 50 MB image, defeating the whole purpose.  (Although the image would be only in black and white, not color, so that might help some.)  

Just a thought though.  What do the rest of you think of that?

[bseymour]

I think it's interesting conversation over a bowl, but not feasible. You're almost guaranteed to end up with a larger file size than you started with by using the methods you suggest.

[Kazimir]

Maybe you're right, but I want to wait until

Dude, you remain ignorant of simple logic, and keep on wandering in meaningless details and experiments. I like your creativity, but there is a much more fundamental problem here, that has nothing to do with Pi, hunt values, flipping bits, decimal encoding paths, or ANY other approach you may think of.

It may still be possible, but I won't know until the proofs are shown here.

The proof HAS been shown here (numerous times) that it is simply NOT possible, but you choose to ignore that.


Your idea is essentially the same as this: (just replace "2-bit" with "5MB" and "1-bit" with "4KB")

You: "I made an amazing discovery, an idea to reduce any 2-bit file by 50%! Using quaternion matrix inversion, I can trace a reverse index into Pi's decimal data (which is, after all, infinite) and find a unique cubic prime for every possible path that can be used to re-create the original file. Thus encoding (not compressing, but encoding!) any 2-bit file in a crypto key that is only 1 bit long!"

Critic: "Sounds fancy, but there are four possible 2-bit files (00, 01, 10, and 11), and only two possible 1-bit crypto keys (0 and 1). No matter what crazy method you use to compress or encode a 2-bit file, you will only ever be able to distinguish between two possible outcome files."

You: "Hmm, maybe you're right, but what if I do <...some smart change in the technical part marked above in green...>"

Critic:

See, you're completely ignoring the actual argument, and keep fiddling with details of an interesting yet inherently impossible algorithm.

[Kazimir]

If your idea would work, then how about the following approach:

We compress 1280 different files of 5MB each, into 4KB crypto keys. We concatenate all 1280 4KB crypto keys together into one file, which then becomes 5MB in total. We compress that file as well, in 4KB.

So effectively, we have now compressed each 5MB file into 4KB/1280 = about 3.2 bytes. Really?

And we could actually do the same thing again, and compress 1280 sets of 1280 5MB files, compress each set into 1280 4KB crypto keys, concatenate the set's crypto keys and compress that to a second crypto key (like above), then concatenate all the 2nd crypto keys and compress the resulting 5MB into a third, final 4KB crypto key. We have now compressed each 5MB file into 0.02 bits.

Really??

[BurtW]

^^  pretty darn clear

[Buffer Overflow]

Hey wait, I've got an idea. Let's compress those 0.02 bits again! Genius!

Eventually we might be able to compress it to zero. 

[Kazimir]

Hey wait, I've got an idea. Let's compress those 0.02 bits again! Genius!

Eventually we might be able to compress it to zero. 

We can store the entire internet in 4KB! (that is including my porn collection... and let me assure you that's HUGE!)

[Buffer Overflow]

Hey wait, I've got an idea. Let's compress those 0.02 bits again! Genius!

Eventually we might be able to compress it to zero. 

We can store the entire internet in 4KB! (that is including my porn collection... and let me assure you that's HUGE!)

I don't think your poo fetish porn will compress all that well. 

[kslavik]

Hey wait, I've got an idea. Let's compress those 0.02 bits again! Genius!

Eventually we might be able to compress it to zero. 

We can store the entire internet in 4KB! (that is including my porn collection... and let me assure you that's HUGE!)

Reply by B(asic)Miner:
... but, but, we can just look at all the gazillion possible collisions and pick the one  which contain your porn collection - it will be pretty obvious when you try to look inside it.

[murraypaul]

0 = no change in Hunt Value. 1s = +1 to Hunt Value.   However, how we search for our Hunt Value changes here:   We have to double confirm every Hunt Value against the Index at that location being even (0) or odd (+1).  We can only accept a Hunt Value which double confirms the bit we are encoding.  For example:   Here is  our data to be encoded:

0010 0001  (space added for readability only)

Our first Hunt Value is 4, but we can't stop on just any 4 now, it must be an EVEN 4!  Here goes:   The first 4 in Pi is at index 2 (if you are counting indexes 1-50 and not 0-49 like coders do, so let's please just use 1-50 to keep this easy to read (no offsetting for now))  That means the first 4 IS a 4 AND it's EVEN.  

Let's continue:  the 2nd 0 in our encoding byte example ....  the next four we find in Pi is at Index 19 (odd) but we are looking for an EVEN 4 because our encoding bit is still 0.   Our third 4 is at Index 23 (no good still) so we keep going ....  ah, at Index 36, we have our 2nd EVEN 4!   So now our 2nd bit is encoded ....   Next we are encoding (our third encoding bit) a 1, so now we need to find the next ODD 5 (it increments+1 and because it's a 1, its ODD too) ...  so our first 5 from that location is at Index 48 (an even, so its no good) ... but at Index 51, we have our first ODD 5, we just encoded that bit.  

This process continues accordingly.  This spreads out the hops a great distance, ensuring the path taken is more unique, but at a cost of having to use way more of the Index for every byte "stored" ...

>SNIP


DECODING CHANGES:
We now have an additional checksum for helping to narrow down the possible paths that could have been taken.  

Please someone (murraypaul that means YOU-wink) run the proofs you ran before using this new method and see if they are not all unique. I beg you.  I am very curious to see what comes from this.

The following two letter strings give the same index value as 'Pi', using the new method outlined above:

String: 0M (0011000001001101) Index: 197
String: 0Y (0011000001011001) Index: 197
String: 0e (0011000001100101) Index: 197
String: 0i (0011000001101001) Index: 197
String: 1I (0011000101001001) Index: 197
String: PM (0101000001001101) Index: 197
String: PY (0101000001011001) Index: 197
String: Pe (0101000001100101) Index: 197
String: Pi (0101000001101001) Index: 197
String: QI (0101000101001001) Index: 197
String: rA (0111001001000001) Index: 197

The following single letter strings give the same index as P:
String: 0 (00110000) Index: 110
String: P (01010000) Index: 110

Encoding the same 1.3MB file as before now gives:

After byte 1295988, pi position is 202830581
After byte 1295989, pi position is 202830702
After byte 1295990, pi position is 202830819

So you are now using 157 digits of Pi for each byte encoded, almost exactly the 160 that would be expected.

[murraypaul]

Encoding all possible one to three byte files using only 62 printable characters gives a total of 426 resulting index values, compared to the 242234 that would be required for full uniqueness.
Of those 426 values, only 26 were uniquely mapped to by a single string.
Lowest used index was 76, highest was 790. (These indexes all start with 1 = the 3 of 3.14).
Most popular index was 517, which was mapped to by 18891 different strings.

[B(asic)Miner]

Okay guys, no sense beating my head in again and again with iterations of less and less funny jokes.  It's like you're taking your own jokes and compressing them.  And then taking that compressed joke and compressing it again into a smaller, less funny joke.  Until it's you beating my head in for daring to try to imagine something cool.

You win.  I can see the end of the road for this argument.  But I didn't want to give up that easy, you know?  It wouldn't make sense for me to give up that easy after spending 3 years on it.  So you have to understand me at least, right?  Isn't that enough for a tad bit of sympathy.  At least BurtW gave me some love for making him think and he said he enjoyed my thread at the very least.  And I had fun talking with all of you.  Probably the most fun I've had in years back when I first came to China and had like 12 friends and four girlfriends at the same time.  Life was smoking back then, but tapered off pretty rapidly into tedium and boredom.  There are only a few highlights in one's life when you reach over 40 like me.  But anyway, thanks again for all your hard work, and for taking the time to respond to this fanciful imagination.

I will not add more to this thread but I may be back with another idea, but I won't waste your time with that idea until I see how my experiments go.  At this point, I haven't considered that idea long enough to be able to withstand your criticisms of it until I've gone over it all much more deeply.  I think I have another cool way to do compression that will be awesome, but it won't be as awesome as the philosopher's stone I started with.  I guess it wasn't awesome anyway, since it won't work.

But let me ask you all a serious question, and yes, it's related to this very topic which I am closing in the next few posts after your responses end:

Let's say, just for argument, that a way existed to compress huge movies down to 4k or 64k.  That it could be done.  (I'm just saying WHAT IF here, so follow along with me) ...  your approach, indeed all of the most intelligent amongst you's approaches, have been to consider the mathematical probabilities of that plan working.  And if the math says it can't be done, you don't do it.  So let's say a way did exist, and you (because of your adherance to math statistics telling you what can't be done) you never EVEN TRY.  

In sports they say (to encourage athletes who want to give up) that you can only make a basket if you're willing to make a throw.  Am I wrong to try?  Do you think everyone should always listen to mathematical probabilities and not even try?  Because if that were the case, maybe the Universe itself (which is a kind of universal intelligence we are discovering more and more about every day, that is kind of alive in some way, universally sentient) wouldn't be here?  Because the chances of there being life are so small, nearly impossible, that for it to exist is indeed something to ponder deeply.  I'm just saying.  If we never take a shot, we can't ever make a basket.  Don't let math dictate your life, dictate your own life and screw the math is what I say.

The maths are the laws of the universe, and a universal language, but I seriously believe that in 200 years from now (if WW3 doesn't end us "coming soon to a nation near you!") we will have found all the ways to do these same things I'm proposing, because of someone like me didn't listen to the rules and tried it for goddsake.

Thanks for your time.