Topic: Crypto Compression Concept Worth Big Money - I Did It! - page 13. (Read 13895 times)

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.

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.

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.

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.

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.

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' ?

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?

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

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.

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.

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

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?

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

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.

Everybody will laugh at him :-)

@Basic miner

Consider putting your idea also on Encode.ru the biggest data compression forum.The winners of hutter prize are its members and regularly post there.

Generally if you understand how computers work... and what exactly "32-bits" represents - aka 4billion possible combos.  You start to get a very VERY crystal clear picture of how hard compression is.

To be honest, most compression now adays is for very very specific types of data (mp4/mp3/jpg - and "lossy").  General multipurpose true (as in what you compress you get _exactly_ back when you de-compress) - compression - IE zip/rar/etc aren't very powerful on the grand scale of things.  They just remove "wasted" space.

FIFY

Release it on an open source license then.

No, I'm afraid you'll be just another internet kook noone had ever heard of.