Crypto Compression Concept Worth Big Money - I Did It!

[murraypaul]

I changed my program to use a precalculated file of Pi to 1000000 digits, rather than compute the digits on the fly.

When I apply it to the same 1000000 digits file, it runs out of Pi digits at only 12500 bytes of the input file (out of 1000000 bytes total).

'Compression' stats at that point:
After byte 12505, pi position is 999428
After byte 12506, pi position is 999525
After byte 12507, pi position is 999561
After byte 12508, pi position is 999628
After byte 12509, pi position is 999729
After byte 12510, pi position is 999795
After byte 12511, pi position is 999856
After byte 12512, pi position is 999950

[Jace]

The OP is side stepping the information part though, he's using a huge number that theoretically contains all possible data combinations and indexing it that instead of attempting to compress the raw data. Possibly with other numbers with pi's quality (illogical number or something, nothing recursive in it) the indexing needed will be reduced.

Makes no difference. There is no way to 'cheat' the problem at hand. On average, the index will be at least as large as the actual data itself, and very likely (in 99.999999% cases) even larger.

Personally I can't see how the indexing would be any different that the formula or fractional method I'd posted, for ideal numbers the data could be represented with a very short formula/fraction etc. but the majority of possible data wouldn't have a good solution so would have little or no compression, not worked it out for successive approximation indexing yet though

Besides some exceptional (very rare) 'lucky' numbers, the vast majority will require more data to store the index.

Consider this: even if it would be possible to compress (or 'encode' or 'represent' or 'index') just a tiny bit off any file, you could repeat the same process over and over, and eventually reducing every file to a few or even one bit. I think you'll intuitively feel that's not gonna work.

EDIT: Irrational Number, http://www.mathopenref.com/irrational-number.html

Pi is even a transcendental number (as opposed to e.g. √2 which is also irrational, but algebraic).

[BurtW]

B(asic)Miner questions and specific answers for you:

For every 1 byte of data, I need to index 100 - 150 indexes into Pi.

Where did you get this 100-150 number?  

II am simply moving forward according to some rules I figured out for creating a unique pathway through Pi.  

We would need to see all the rules in order to help you figure out if this idea is theoretically sound.

So I would need (100*50,000) or 500,000 indexes into Pi at least.  Let's say that the last bit of data I find is at index location 501,500 into Pi.  

As pointed out previously a 50 megabyte file contains 50*1024*1024 = 52,428,800 bytes.  So using your number of 100 digits /byte you would need at least 5,242,880,000 digits of pi.

Well, here is my crypto key:

Please stop using this term.  It has a meaning and this is not it.  Use "here is my metadata"

For 0s, we hop from the first 4 in Pi to every other 4 in Pi only.  But if we encounter a 1 in our binary data, then the Hunt Value increments +1, so now we are only hopping on every 5 in Pi.  This is what keeps the record of our original bits.  All the other numbers in Pi are useless as we are encoding.  Here is an example:   001      We would be looking for the first 4 in Pi then the 2nd 4 in Pi and now we must increment +1 and hop to the next 5 in Pi.  We keep hopping on 5s as long as our data is 0s, but if we encounter another 1, we increment and begin hopping along 6s.

Is this the full description?

In this way, our pathway is totally unique

I don't think this is true.

to the data we are feeding into it, and thus our arrival point (end point) can let us figure out the path taken to reach itself by knowing how many 1s were used and then attempting to solve backwards to the decimal point using the precise number of steps it took to encode it, the original file size recorded in bits.

Even if the path was unique, which I don't think it is, this process sounds very very hard, possibly impossibly hard.

Also, I'm not sure I should be saying 8 bits per byte, but my friend taught me 7 bits per byte when working with Ascii Binary, was I misinformed on that?

A byte is always 8 bits by definition.  How that byte and those 8 bits are used to encode data varies.  (Simple) ASCII maps all the various printed symbols into these 8 bits.  8 bits per character.

Remember, the theory works by looking at the data in a file as characters in a book, in Ascii format, and thus will need to encode precisely the same number of bits for every character.  But if you look at a hex and decimal and binary converter online, if you type in just one letter, you only get 3 bits or 4 bits or 2 bits ... some erratic bit size.  Every character must have the same bit size, so I want to translate the data into Ascii Binary.

Don't worry too much about these details.  Just describe the idea itself as well as you can and let the geeks and engineers worry about the details - like whether it is possible or not.

[BurtW]

On average, the index will be at least as large as the actual data itself, and very likely (in 99.999999% cases) even larger.

Not true at all.  If the idea worked, and it does not, but if it did the idea would produce just three small numbers, something like this:

Code:

File size:                52,428,800 bytes
Number of ones found:    209,715,200
Ending location in pi: 5,242,878,123

This is far less than the input of 50 megabytes.

[Professor James Moriarty]

 I am still waiting for 1mb file mail Send it to me , I will try to compress it , what can I lose but time

[balanghai]

On average, the index will be at least as large as the actual data itself, and very likely (in 99.999999% cases) even larger.

Not true at all.  If the idea worked, and it does not, but if it did the idea would produce just three small numbers, something like this:

Code:

File size:                52,428,800 bytes
Number of ones found:    209,715,200
Ending location in pi: 5,242,878,123

This is far less than the input of 50 megabytes.

Now the next question is if this is possible, can a consumer computer do a compression within few seconds if not minutes for average file sizes?

[OnkelPaul]

The biggest question is not whether a computer can do the "compression" but whether it is possible to reconstruct the file.

Here are the chains of digit positions for just 4 bits:

Pi:    314159265358979323846264338327950288419716939937510
0000     4                4   4            4
0001     4                4   4       5
0010     4                4           5                5
0011     4                4           5         6
0100     4 5   5 5
0101     4 5   5           6
0110     4 5  6            6
0111     4 5  6     7
1000       5   5 5                    5
1001       5   5 5         6
1010       5   5           6 6
1011       5   5           6        7
1100       5  6            6 6
1101       5  6            6        7
1110       5  6     7               7
1111       5  6     7    8

As you can see, the bit combinations 0101, 0110 and 1001 all lead to the same ending digit position. The same is true for 0001/1000, 1010/1100 and 1011/1101/1110. This means that the algorithm's output of a file starting with one of the bit patterns in such a group is indistinguishable from the output if the file had started with one of the other bit patterns in the group.

It follows that it is impossible to uniquely decompress the output.

Don't take it personally, but your scheme is not usable.

Onkel Paul

[BurtW]

I am not trying to get the system, as described, to "work" but out of mathematical curiosity I wonder if there is a starting search digit that would create unique ending positions for all 16 of the 4 bit combinations.  We would have to try starting at 0, then 1, then 2, ... up to 9.

If there is one of more starting locations that do in fact lead to unique ending locations for all 16 of the four bit combinations then we could see if any of those could be extended to 8 bits.

If there is even one starting digit that creates a unique map of the 4 bit values or the 8 bit values then it could be used as an esoteric code mapping.

This could also be tried on all 16 starting locations of a hexidecimal representation of pi.

Pretty simple program.  If I get time I might try it for fun.

[murraypaul]

If anyone else is still reading at this point, and wants to check my working, I think I've demonstrated clearly that this is not a reversible compression scheme.

The two letter word "Pi" gives an index of 148.
The following 156 two letter words also give the same index:
(This is restricted to just printable characters, there could be far more matches using the full 256 combinations for each byte)

String: 0i (0011000001101001) Index: 148
String: 0j (0011000001101010) Index: 148
String: 0l (0011000001101100) Index: 148
String: 1I (0011000101001001) Index: 148
String: 1J (0011000101001010) Index: 148
String: 1L (0011000101001100) Index: 148
String: 8I (0011100001001001) Index: 148
String: 8J (0011100001001010) Index: 148
String: 8L (0011100001001100) Index: 148
String: 9A (0011100101000001) Index: 148
String: 9B (0011100101000010) Index: 148
String: 9D (0011100101000100) Index: 148
String: :A (0011101001000001) Index: 148
String: :B (0011101001000010) Index: 148
String: (0011101001000100) Index: 148
String: <A (0011110001000001) Index: 148
String: <B (0011110001000010) Index: 148
String: <D (0011110001000100) Index: 148
String: @; (0100000000111011) Index: 148
String: @= (0100000000111101) Index: 148
String: @> (0100000000111110) Index: 148
String: @[ (0100000001011011) Index: 148
String: @] (0100000001011101) Index: 148
String: @^ (0100000001011110) Index: 148
String: @k (0100000001101011) Index: 148
String: @m (0100000001101101) Index: 148
String: @n (0100000001101110) Index: 148
String: @y (0100000001111001) Index: 148
String: A9 (0100000100111001) Index: 148
String: A: (0100000100111010) Index: 148
String: A< (0100000100111100) Index: 148
String: AK (0100000101001011) Index: 148
String: AM (0100000101001101) Index: 148
String: AN (0100000101001110) Index: 148
String: AY (0100000101011001) Index: 148
String: AZ (0100000101011010) Index: 148
String: A\ (0100000101011100) Index: 148
String: Ai (0100000101101001) Index: 148
String: Aj (0100000101101010) Index: 148
String: Al (0100000101101100) Index: 148
String: B9 (0100001000111001) Index: 148
String: B: (0100001000111010) Index: 148
String: B< (0100001000111100) Index: 148
String: BK (0100001001001011) Index: 148
String: BM (0100001001001101) Index: 148
String: BN (0100001001001110) Index: 148
String: BY (0100001001011001) Index: 148
String: BZ (0100001001011010) Index: 148
String: B\ (0100001001011100) Index: 148
String: Bi (0100001001101001) Index: 148
String: Bj (0100001001101010) Index: 148
String: Bl (0100001001101100) Index: 148
String: CI (0100001101001001) Index: 148
String: CJ (0100001101001010) Index: 148
String: CL (0100001101001100) Index: 148
String: D9 (0100010000111001) Index: 148
String: D: (0100010000111010) Index: 148
String: D< (0100010000111100) Index: 148
String: DK (0100010001001011) Index: 148
String: DM (0100010001001101) Index: 148
String: DN (0100010001001110) Index: 148
String: DY (0100010001011001) Index: 148
String: DZ (0100010001011010) Index: 148
String: D\ (0100010001011100) Index: 148
String: Di (0100010001101001) Index: 148
String: Dj (0100010001101010) Index: 148
String: Dl (0100010001101100) Index: 148
String: EI (0100010101001001) Index: 148
String: EJ (0100010101001010) Index: 148
String: EL (0100010101001100) Index: 148
String: GA (0100011101000001) Index: 148
String: GB (0100011101000010) Index: 148
String: GD (0100011101000100) Index: 148
String: H9 (0100100000111001) Index: 148
String: H: (0100100000111010) Index: 148
String: H< (0100100000111100) Index: 148
String: HK (0100100001001011) Index: 148
String: HM (0100100001001101) Index: 148
String: HN (0100100001001110) Index: 148
String: HY (0100100001011001) Index: 148
String: HZ (0100100001011010) Index: 148
String: H\ (0100100001011100) Index: 148
String: Hi (0100100001101001) Index: 148
String: Hj (0100100001101010) Index: 148
String: Hl (0100100001101100) Index: 148
String: MA (0100110101000001) Index: 148
String: MB (0100110101000010) Index: 148
String: MD (0100110101000100) Index: 148
String: P9 (0101000000111001) Index: 148
String: P: (0101000000111010) Index: 148
String: P< (0101000000111100) Index: 148
String: PK (0101000001001011) Index: 148
String: PM (0101000001001101) Index: 148
String: PN (0101000001001110) Index: 148
String: PY (0101000001011001) Index: 148
String: PZ (0101000001011010) Index: 148
String: P\ (0101000001011100) Index: 148
String: Pi (0101000001101001) Index: 148
String: Pj (0101000001101010) Index: 148
String: Pl (0101000001101100) Index: 148
String: QI (0101000101001001) Index: 148
String: QJ (0101000101001010) Index: 148
String: QL (0101000101001100) Index: 148
String: SA (0101001101000001) Index: 148
String: SB (0101001101000010) Index: 148
String: SD (0101001101000100) Index: 148
String: UA (0101010101000001) Index: 148
String: UB (0101010101000010) Index: 148
String: UD (0101010101000100) Index: 148
String: YA (0101100101000001) Index: 148
String: YB (0101100101000010) Index: 148
String: YD (0101100101000100) Index: 148
String: ZA (0101101001000001) Index: 148
String: ZB (0101101001000010) Index: 148
String: ZD (0101101001000100) Index: 148
String: \A (0101110001000001) Index: 148
String: \B (0101110001000010) Index: 148
String: \D (0101110001000100) Index: 148
String: `9 (0110000000111001) Index: 148
String: `: (0110000000111010) Index: 148
String: `< (0110000000111100) Index: 148
String: `K (0110000001001011) Index: 148
String: `M (0110000001001101) Index: 148
String: `N (0110000001001110) Index: 148
String: `Y (0110000001011001) Index: 148
String: `Z (0110000001011010) Index: 148
String: `\ (0110000001011100) Index: 148
String: `i (0110000001101001) Index: 148
String: `j (0110000001101010) Index: 148
String: `l (0110000001101100) Index: 148
String: aI (0110000101001001) Index: 148
String: aJ (0110000101001010) Index: 148
String: aL (0110000101001100) Index: 148
String: cA (0110001101000001) Index: 148
String: cB (0110001101000010) Index: 148
String: cD (0110001101000100) Index: 148
String: eA (0110010101000001) Index: 148
String: eB (0110010101000010) Index: 148
String: eD (0110010101000100) Index: 148
String: iA (0110100101000001) Index: 148
String: iB (0110100101000010) Index: 148
String: iD (0110100101000100) Index: 148
String: jA (0110101001000001) Index: 148
String: jB (0110101001000010) Index: 148
String: jD (0110101001000100) Index: 148
String: lA (0110110001000001) Index: 148
String: lB (0110110001000010) Index: 148
String: lD (0110110001000100) Index: 148
String: qA (0111000101000001) Index: 148
String: qB (0111000101000010) Index: 148
String: qD (0111000101000100) Index: 148
String: rA (0111001001000001) Index: 148
String: rB (0111001001000010) Index: 148
String: rD (0111001001000100) Index: 148
String: tA (0111010001000001) Index: 148
String: tB (0111010001000010) Index: 148
String: tD (0111010001000100) Index: 148

In fact, even with the single character 'P', there are three other printable characters with the same index:
String: B (01000010) Index: 74
String: D (01000100) Index: 74
String: P (01010000) Index: 74
String: ` (01100000) Index: 74

[rigel]

I just invented a beautiful  compression software: it's called md5

It can compress files of any size to just 128 bit

Still  developing decompression tool...

[bit-joker]

OP is simply delusional and people keep feeding the troll. He keeps saying his yada yada yadas with no useful information. Reminds me of Herbalife; "you can be RICH like the actor in this video. You just have to buy a ton of our expensive overpriced inventory...". The focus is on how rich you can be instead of the product you'll try to sell.

Even if OP could break mathematical laws, he should look for angel investors, showing them his "discovery". Google how to patent an idea instead of wasting people's time. See how long this thread is? OP is just looking for attention or trying to scam somebody without knowledge about compression.

[2112]

OP is simply delusional and people keep feeding the troll. He keeps saying his yada yada yadas with no useful information. Reminds me of Herbalife; "you can be RICH like the actor in this video. You just have to buy a ton of our expensive overpriced inventory...". The focus is on how rich you can be instead of the product you'll try to sell.

Even if OP could break mathematical laws, he should look for angel investors, showing them his "discovery". Google how to patent an idea instead of wasting people's time. See how long this thread is? OP is just looking for attention or trying to scam somebody without knowledge about compression.

C'mon, don't get paranoid. This isn't any sort of scam, it is just a harmless crackpottery. Nobody's going to lose any money or health or life or anything really valuable after reading this thread. Remember that Bitcoin a currency backed by gold, commedy gold.

[Kazimir]

Here is a zip containing 3 test files of exactly 1MB (1048576 bytes) each:

http://www.mediafire.com/download/z2sniezt41c8hi0 or mega mirror

Just to be sure you're getting the correct data, the MD5 checksums of the 3 included files are:

statistics-2b.ocx = d027872ea8e2b5b7db33cf6c2da23080
example.mp5 = e4d85efed99135c8d55ff23dc5b10c34
delta.iff = cb44279ee8c9e7a6859498f5ebd8427e

I'm curious to see if B(asic)Miner or anyone else can successfully compress any of these files to 950K or smaller. What the heck, even 990K (1013760 bytes) would already be very impressive.

[Kazimir]

I do not understand your propositions , both of them . Am I allow to try to .rar whatever you send me?

Sure, go ahead. I haven't tried it but I'm pretty sure Rar won't reduce them to 950K or less (in fact, I think Rar won't even reduce 1 bit off them).

See link above for 1MB test files

[murraypaul]

For the 5 letter input file "Hello", I cancelled the program early on in the search for duplicate encodings, but it had already found almost 2 million five letter words which gave the same Pi index (305). There are 227k words starting with 0 which do.
Hopefully it is clear that this process does not work, as it assigns the same output value to multiple different input files, and therefore there is no way of reconstructing the original input file from just the output index.

[Professor James Moriarty]

I do not understand your propositions , both of them . Am I allow to try to .rar whatever you send me?

Sure, go ahead. I haven't tried it but I'm pretty sure Rar won't reduce them to 950K or less (in fact, I think Rar won't even reduce 1 bit off them).

See link above for 1MB test files

 I am at work now , I will try and respond in about 5 hours (more or less).

 I will simply .rar these and check if that worked , if it doesnt I just lost

 So you can basically .rar these if you want and dont wait me for 5 hours , if it doesnt compress them the answer will be on your hands without waiting for me for 5 hours

[B(asic)Miner]

But this was only an example of how the encoder works, not its compression value.  I told you before, this is for larger than 500k files.  You don't seem to understand, now matter how many times I say the same thing different ways, that this one code represents whatever size file you are working with.  If the file is 1024K or 1024 MB, it's still the same one crypto key.  Whether it's 1 MB or 100MB or 1000MB, it's just one 4k file.  You aren't listening.  Your only job appears to be to find ways to break my theory using small data sets of 3 bytes, when I clearly said many times this won't be used for data that small.  

You don't seem to understand when I try to explain very clearly why your process will not work.
You've even seen a joke page created by someone else with broadly the same process, and another page explaining why it will not work.

Let's say I encode Apple's iCloud Installer, which is just under 50 MB in size (according to Google).  For every 1 byte of data, I need to index 100 - 150 indexes into Pi.  I am not converting anything or recording anything to do this movement.  I am simply moving forward according to some rules I figured out for creating a unique pathway through Pi.  So I would need (100*50,000) or 500,000 indexes into Pi at least.  Let's say that the last bit of data I find is at index location 501,500 into Pi.  Well, here is my crypto key:

[0.501500.8.5250]  I didn't have to record any other data that than.  Now that's placed into the 4K file that is used to tell the software how to reconstitute the data.

A):  50,000 is 50KB, not 50 bytes. 50MB is 50*1024*1024, not 50*1000.

B): And what if you don't find the last bit of data until index location 501,500,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000...(repeat up until 50MB)?

You entire process only works if you assume you can find all possible index locations in less space that the original file took.
You cannot do this.

C):
And what people keep telling you, but you refuse to accept, is that on average, the index required to store the final position will be as large as the file you are trying to store.

ANSWERS:

A) Thanks.
B) You have just revealed that you still don't understand what I am doing, this is not meant to criticize, that is why I am here afterall, for you--or someone--to finally understand how this works.  I am not looking through Pi for data that matches what's in Pi.  The numbers in Pi are irrelevant.  My formula uses Pi or any irrational number we want to lay a path like Hansel and Gretel through the forest to the Witches House.  The bread trail is merely dropped down when we encounter something important.  All other numbers are irrelevant. Imagine Hansel looks for trees with mold growing on them (0s) to drop his bread crumb.  And Gretel is looking for magic mushrooms (1s) to drop her mushrooms.  We begin our journey into the forest, with every tree in the forest one of the numbers in Pi after the decimal point.  As we travel along, pass every tree one by one, looking for mold or mushrooms.  When we find a moldy tree (the 0 we are looking for in our current byte to be encoded (say 00100001) we consider that first 0 encoded right there.  Now our second bit in our string is a 0 too.  So we progress to the next moldy tree.  We skip everything else along the way.  We hit our next moldy tree, and have now considered our second bit encoded.  Now we are looking for a 1 bit, so the thing we are hunting (currently 4s in Pi) are changed by +1 to 5s.  5s are now magic mushrooms.  Since bits 4,5,6,7 in the example above are all 5s, we keep hunting magic mushrooms for 4 hops (hopping on the 5s now) and on our last bit (another +1) we are hunting for 6s, clearings.  Oh, now we've completed our hunt, we have arrived at the witches house in the clearing by the end.  So our Crypto Key is now  [1.0.174.6.0]. 

If you sent that Crypto Key to me as I have just displayed it there, I could go into my Pi index I've built (it's very small, but helpful for under 5 bytes or so), and count backwards from there until I found the starting point and from there, I would know all the data going forward merely by reading the changes.  In the Crypto Key above, here is the breakdown of how a Crypto Key works backwards to decipher the Timeline.   (timeline means from decimal point forward thru Pi to Ending Index #.)   [1  (the first number) is the Mega Chunk number    0  (our second number) is what the starting Bit was (0 or 1) so we can be sure of where we initially began looking.  If it was a 0, we start with 4s but if it was a 1, we start looking for 5s right from the start.   174 (the third number) is our Ending Index Value of Pi.   6 (our fourth number) is the End Hunt Value, which tells us for sure that we were hunting for 6s when we stopped encoding.  and the final 0 (our fifth number in the crypto key) is our Flip Count. This tell us how many times we cycled from from our initial hunt value (4 or 5) back to that same number. 

Our Flip Count works from our first Hunt Value back to itself.  5 to 5 ....  so in 2 bytes of data, if there were eleven 1's, our ending Hunt Value would be 6 and our Flip Count would be 1.  It would look like this    [1.1.?.6.1]   Meaning First Chunk, starting bit = 1, (? = ? because I'm not looking it up now), Ending Hunt Value=6, and Flip Count = 1 (it flipped once when we passed 5 the 2nd time in our example 2 bytes of data containing eleven 1s).

C) The index isn't included in the file we save, that would be stupid, since it would do just as you say, include a lot of data we don't need to even include.  The index is Pi, a known number anyone who programs can program in moments to auto generate, in less than 51 bytes I'm told.  So our co/deco would include it built in to generate our index is RAM.  The part you're not getting (and again, I don't blame you, I WANT you to understand because that would be awesome!) is that we don't include any index in our output file, THAT'S WHY IT CAN BE 4K.   The fact that we used an index in Pi that was 16 million indexes long has nothing to do with our final file size, because we are just writing down the Index point itself. 

C part 2)  In addition, our Index is also more complex in that we are not going to run one program all the way through Pi to obtain the Crypto Key unless it's under a certain size (to be determined later, with research) and we will not allow this program to encode anything under 500KB in size also.  When running 8 GB through our program, we will use the same 2GB of RAM (with Pi written into memory there while the program is running to encode or decode, but dumped thereafter) and run that program in equal pieces.  Our 4k program will also tell the last piece (if it is not equal) exactly how many bytes and bits down to the bit it needs to add (which will later be removed) in order to keep all 4 pieces exactly equal.  That equal size is also written into the 4k file, so the program knows exactly how much data it's working it.  Thus, an 8 Gig file could look like this:

[OPENFILE]
[FileSplitSize=2GB]
[filesize=8000000000_&_Name="8GBofStuffForWhomever.zip"_&_LastChunkDataSize=956,524]
[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]

[B(asic)Miner]

B(asic)Miner, how about this: wanna bet? Walk your talk? Put your money where your mouth is? After all, money talks and bullshit walks

I give you a few 1 MB files (1048576 bytes). If you can compress them to 950 KB (972800 bytes) or less, I pay you 100 BTC. If you are unable to pull this off within a reasonable time limit, let's say one or two months from now, you pay 1 BTC to any charity of your choice (must post tx here )

Deal?

 I thought this was possible? Aren't we able to rip games and all? I dont get it why cant he compress 1mb into 950kb ?

 This is not 'of course it can be done' message , it is more like 'I really dont know if we are able to do this or not , I tought we were able to do it but I might be wrong' type of message

Oh, he'll probably be able to compress some 1MB files to 950KB. But not the ones I'm supplying

See, compression is all about information density. Quite some everyday files of 1MB contain much less than 1MB of actual information. A text file, for example, or an image with lots of 'empty' spaces, will not have a very high information density. Meaning they use 1MB of disk space to store a lower amount of actual data.

But if an 1MB file actually holds (close to) 1MB of information, there's no way to represent that same information in significantly less disk space. Brilliant compression algorithm or crypto key magic or not. And to get the proper persective: the vast majority (like 99.9999%) of all 1MB files actually do hold pretty close to 1MB of information.

Either way, I have enough faith in these principles to set a 100 BTC bounty to be proven otherwise. Hope to hear from B(asic)Miner soon.

I would LOVE to take your bet, I really would, but I am not a programmer, nor do I have elite math.  I have no hope of programming this thing myself.  All I did was invent the process that needs to be taken and implemented. If anyone on this forum wants to program my idea for me, then I'll give you anything you want (within fairness, as long as I get some money when we strike it rich, and as long as you keep my name as a co-inventor.  I say co-inventor (not full inventor) because that programmer is going to need to be able to figure out how to read from my index point backward and solve my timeline to decode the bits out of Pi again.  If they can't do that, its all for naught, and I'm sure its going to take some hard math and genius of his own to accomplish that.  I may not be useful for that portion.   

Then we (those of us working on the software) will take your bet, and we will also take the Hutter award too, because when we encrypt that 100 MB wikipedia document down to 4k, they are going to owe us the full 50,000 Euros, too. 

[B(asic)Miner]

That is why I called it a "very large out of band reproducible random data set (like pi)"

That is why it is an encoding/decoding system, not a compression system.

Very large amounts of information can be encoded in very small metadata:  ISBN numbers, URLs, etc.

He is not talking about data compression at all.  He just does/did not know the proper terminology is all.

Yes!

And Yes!!

And YEEESS!

AND YEEEESSSS!

God, I love you BurtW!  Thank God for you.  You get it.  You know I am not joking around here and you see it more and more clearly every day.

[B(asic)Miner]

Oh God, please just give OP a bitch-slap!

I NEED a good bitch slap to calm down after arguing with you all for so long!  Hahaha ....