Protecting My Code

Community Forums/General Help/Protecting My Code

Shortwind(Posted 2010) [#1]
Scenerio:

1. I created a new compression technique that compresses all 255 byte chunks into 3 byte chunks.

2. I want to sell this technique to the video companies, computer companies, hard drive companies, Internet companies.

3. I want this to stay out of the media.

4. Problem: They want/need (for obivious reasons), for me to come to their offices and allow them to test the executable on their own systems with their own data. How do I protect my program? Once they copy the executable to their systems, they could be loading it into a emulator, a debugger, etc, and then just disassemble my code, stealing my work.

5. How do I demostrate to them, beyond shadow of a doubt, without giving away the compression technique, that this is real, and not a farse?

6. What companies should I even goto first? This technique would change everything we now know about video disks, computer storage, band-width issues on the internet, communications over cell phones, etc...

In search of a little advice. Is there professional lawyers that specialize in these sorts of transactions?


N(Posted 2010) [#2]
Do you consider this a realistic scenario?


plash(Posted 2010) [#3]
1. I created a new compression technique that compresses all 255 byte chunks into 3 byte chunks.
Let me just halt you right there for a moment and let out a hearty laugh: Hahahahaha.

2. I want to sell this technique to the video companies, computer companies, hard drive companies, Internet companies.
Only natural.

3. I want this to stay out of the media.
For what reasons?

4. Problem: They want/need (for obivious reasons), for me to come to their offices and allow them to test the executable on their own systems with their own data. How do I protect my program? Once they copy the executable to their systems, they could be loading it into a emulator, a debugger, etc, and then just disassemble my code, stealing my work.
There's no real answer to this, as everything is re-engineerable.

5. How do I demostrate to them, beyond shadow of a doubt, without giving away the compression technique, that this is real, and not a farse?
Show them the code and extensive examples of the compression at work, or at least how the algorithm works.

6. What companies should I even goto first? This technique would change everything we now know about video disks, computer storage, band-width issues on the internet, communications over cell phones, etc...
Dunno.

In search of a little advice. Is there professional lawyers that specialize in these sorts of transactions?
Probably not.

Since you've listed this as "scenario", I can only assume you've not created a magical 255 -> 3 byte compression algorithm.


GfK(Posted 2010) [#4]
If you're serious (and I'm taking the 255-3 byte thing with a huge handful of salt, tbh), patent the algorithm before doing anything. That in itself is a minefield and I'd recommend a good lawyer that specialises in patents.


Shortwind(Posted 2010) [#5]
LOL, don't start. I've been researching this for over 12 years.

It has led me to understand, and learn more about advanced factoring, data compression in general (and it's limitations), and to no surprise to the wise - never listen to someone that tells you "It can't be done." Because if you know your history, even a tiny bit, you'll realize that many men and women, greater that I'll ever be, have went against that old adage and just "did it" despite the nay sayers.

The point, I suppose, is to find out how do you in the industry protect your code from being stolen by less than scruplous companies when it's code that you know they will do anything to get, have basically unlimited budgets, and can destroy your world if you, the tiny insignificant pimple, even attempt to accuse them of anything... (Apple, Microsoft, etc...)

It's the same with crypto techniques, although you then have govenments coming after you, and death is the consequence.

LOL, I don't want to get into a debate about compression techniques. That, again, wasn't my point. :) Sorry if I missled in my original post.


big10p(Posted 2010) [#6]
1. If this was possible, it would have been done years ago.

Therefore, 2, 3, 4, 5 and 6 require no answers.


Shortwind(Posted 2010) [#7]
The only way I've come up with to protect my code (given the original scenario)

1. Take two computers with me to the meeting. One for the compression, the other for the decompression.

2. They give me a USB thumb-drive, or DVD with a bunch of files to compress. Compress the files and write the compressed version to a a different USB Thumb-drive or DVD.

3. Take that to the uncompress computer. uncompress the files, copy those to another disk.

4. Let them then test those files on their own computers for errors.

Seem like a plausible plan?

Or I could just release the code to Public Domain and let them fight over it themselves, leaving myself to remain anonymous. And sit back and laugh at all the persuing lawsuits between these huge companies. Drink a little more beer, and die poor, but happy. LOL


BlitzSupport(Posted 2010) [#8]
As much as I'd like it to be true, you can't just overcome basic mathematics "despite the naysayers" -- unlike other inventions.

If you really believe (as have many before) that you've created a breakthrough in compression, then you can either follow Gfk's advice (for $$$) or release for peer review (for the advancement of science). At some point you simply have to show somebody if you want to be believed.

Expect many people to be taking hefty pinches of salt along the way!


DavidDC(Posted 2010) [#9]
Seem like a plausible plan?

I guess... You'd have to prove the computers were totally isolated - ie no bluetooth or whatnot.


Matty(Posted 2010) [#10]
So how does your algorithm work?


Oiduts Studios(Posted 2010) [#11]
Isn't this physically and technically impossible? So you can take a string and compress it 85 times smaller and still keep the same information? Well if this is true then make sure to tell the media about Blitz and how awesome it is.


Floyd(Posted 2010) [#12]
This will be a tough sell. Right now you sound like one of those "free energy" companies that pop up occasionally. They never demonstrate a working device, ostensibly because they fear revealing their super duper top secret technology. But they will gladly accept development funds.


xlsior(Posted 2010) [#13]
I created a new compression technique that compresses all 255 byte chunks into 3 byte chunks.


I'd think that is mathematically impossible. I'm sure that you can compress SOME homogenous data that well, but there is absolutely no way that you'll be able to compress essentially random binary information that small.

If it sounds too good to be true, it generally is.


Gabriel(Posted 2010) [#14]
Sorry to spoil your fun, but I've already duplicated your results. The first byte is the number of bytes in the decompressed chunk. The second byte is the content of each byte* in the decompressed chunk. The third byte is for decoration.


* All bytes in a chunk have to be the same. It's a slight inconvenience, but a small price to pay for such an awesome compression algorithm.


Serpent(Posted 2010) [#15]
The keyword in Shortwind's question is scenario. This is physically impossible in the first place, and therefore I don't think Shortwind has done it.

@Shortwind: If you have done this and you can prove me wrong (despite the whole concept being mathematically impossible) I will be awed (but I won't be awed because it is mathematically impossible).

In terms of protecting your code - if this ever did happen for some impossible reason - you would need a patent and a very good lawyer.

Now on the offtopic issue of whether this is possible.
Have you heard of the pigeon-hole principle?
Principle: If there are 6 pigeons that need to fit in 5 pigeon holes, there will be 2 pigeons in at least 1 of the holes.
How does this apply to data compression? You cannot express 6 possibilities with 5 states - there will be a double up.

Think about files - what are they? Why do we need them? They essentially store arrangements. A text file needs enough bytes to store every character. Say there is one byte per character. You cannot store 100 characters in 99 bytes because there are not enough COMBINATIONS of bytes to express the possible combinations of letters.
Hopefully you're understanding my bad explanation.

Anyway, you seem to believe that it may possible to store 255 bytes in 3 bytes. Behold the inherent problem in this:
In 255 bytes, there are 256^255 different combinations possible. You are suggesting that EVERY ONE of those combinations can be represented in 3 bytes. You are suggesting that 256^255 different combinations can be represented by 256^3 combinations.
3 bytes worth of data CANNOT represent 255 bytes worth of data. 3 bytes CANNOT represent the same number of combinations as 255 bytes.


The counter argument to this would be "Well why is data compression possible then? If we cannot represent the same number of combinations in less bytes than how is data compression possible?"

Data compression involves reducing redundacy in data. When a file has unnecessary data or unnecessary repetition of data, it is compressable. For example, text files unnecessarily represent each word over and over again. This is a reason why they are so compressible - some of the data, the repetition of words, is redundant and can be removed. In this case, a compression algorithm might replace all words in a text file with a two-byte long index - each index's corresponding word might be stored at the start of the file.

Infinite data compression is IMPOSSIBLE. You need to get over that. It is very possible to create compression techniques that reduce redundancy in files, but you cannot represent the same numbers of combinations in fewer numbers of bytes.


Floyd(Posted 2010) [#16]
There's always the possibility a dramatically improved compression routine. This is especially true for something like video where a certain amount of lossiness may be acceptible.

The description at the top of this thread sounds like a "one size fits all" sort of compression, suitable for video, hard drives etc, with 255 to 3 compression. That is clearly impossible.


_PJ_(Posted 2010) [#17]
4. Problem: They want/need (for obivious reasons), for me to come to their offices and allow them to test the executable on their own systems with their own data. How do I protect my program? Once they copy the executable to their systems, they could be loading it into a emulator, a debugger, etc, and then just disassemble my code, stealing my work.

5. How do I demostrate to them, beyond shadow of a doubt, without giving away the compression technique, that this is real, and not a farse?

6. What companies should I even goto first? This technique would change everything we now know about video disks, computer storage, band-width issues on the internet, communications over cell phones, etc...



How do you arrive at q4. before answering q6?

The answer to q4. is to apply for a patent.
The answer to q5. is to trial your idea on any piece of code. They should only be able to decompress it if they KNOW your compression algorithm.
The answer to q6. I would approach some company such as Sony or who deal with this kinda stuff.


_Skully(Posted 2010) [#18]
Try compressing a binary 255 to 3..

ROTFLOL.. this is a total sham

So thats 255/3... lol... 85 to 1

Compress: 123456789023456789013456789012456789012356789012346789012345123456789023456789 to 1 byte... go ahead


Shortwind(Posted 2010) [#19]
Serpent (and others) have hit it clearly on the head. As I said, I was only hoping to get information and advice on code protection.

Ok, so maybe I should have came up with a more believable scenario, sorry.


Serpent(Posted 2010) [#20]
Okay thought so - sorry for the hammering on infinite compression. Either way, if you did come up with something that good you would need serious legal help.


xlsior(Posted 2010) [#21]
If it really is something valueable that you're trying to protect, patenting it would be the way to go.

As far as showing information to interested companies: signed non-disclosure forms, at a minumum.


-=Darkheart=-(Posted 2010) [#22]
In the scenario you outline, assuming your technique actually works:

a) Apply for a patent (even though software patents are evil), you must of course fully disclose your method as part of the application.

b) Publish your techniques features and that you have a patent applied for.

c) Set up a limited liability company which you own, (a simple process), manage everything through this (this is so you don't become personally liabile if it all goes wrong).

d) Contact existing compression companies (PKWare, Rarsoft etc) and arrange a demo. You will need to be pretty open with them if you want to have any credibility. As long as the meeting is well documented and your patent application is already in you should be fine.

I have to say, I'd be very surprised if your claims hold up, I think they must only work with specific data or very specific data types. It is for example, possible to achieve 98% + compression with just ZIP, as long as you are compressing bitmap files or some other easily compressible data. I assume you've tried some of the standard data sets used by other compression technologies? Also you don't mention if your technique is lossy or lossless (everyone seems to be assuming it is lossless).

The other thing you might want to do is talk to other people on the compression scene like Igor Pavlov (who developed 7zip), they can probably give you some good advice.

Darkheart


ShadowTurtle(Posted 2010) [#23]

Try compressing a binary 255 to 3..

ROTFLOL.. this is a total sham

So thats 255/3... lol... 85 to 1

Compress: 123456789023456789013456789012456789012356789012346789012345123456789023456789 to 1 byte... go ahead


This is possible since ~1990 (QuickBasic, RAW File format etc.)

Fast sample:
Drawing a 900 pixel line does only need this piece of code "L900". The bitmap file format needs more than ~1000 Bytes for this. You see: 1000 Bytes vs 4 Bytes. This is a better compression than 255/3.

At moment i do create a Handy-Mobile-Fantasy-Roleplaying-Game-Creator application wich does export a binary file. This file is optimized for Handhelds and so on. The original game file is about 2 Megabyte. The optimized binary has only 11 kb.

Into the runtime player i do program a music-tracker-player like the one in "Mario Paint" (it is a Super Nintendo game for kids). The sound/music files will be only 2kb big. You can see here a few unofficial examples (only on youtube):

World Revolution - Chrono Trigger, Mario Paint
Chrono Trigger 600 AD on Mario Paint
Robo's Theme from Chrono Trigger on Mario Paint

I think this sounds better than most musics from commercial mobile games. At moment there are ~30 minuts playtime stored in 30kb.

There are so many compression posibilitys... you must only do hard-coding and think about that what you do!!!

Ok.. this was a little bit offtopic. Sorry ^^


Otus(Posted 2010) [#24]
:)

If someone indeed figured out a new much superior compression algorithm and wanted to make money with it, I suppose applying for a patent would be step 1.* Personally, I would then use it to claim the Hutter price. That and a few press releases should give it enough publicity (without needing to disclose any code) that companies get interested.

Now, realistically, anyone can figure out a compression algorithm that works in a specific case, but general purpose compression is *very* difficult.

* Personally I very much discourage this. Patenting math is not cool.


GfK(Posted 2010) [#25]
Drawing a 900 pixel line does only need this piece of code "L900". The bitmap file format needs more than ~1000 Bytes for this. You see: 1000 Bytes vs 4 Bytes. This is a better compression than 255/3.
That's only true in very specific circumstances, and completely useless for generic compression.


Oiduts Studios(Posted 2010) [#26]
And like GFK said the line thing only specifies the length of a line, not accounting what direction, RGB values, and maybe even width.


puki(Posted 2010) [#27]
There is a fair chance that it is already patented, but not in active use.

There are tons and tons of compression patents - for example:
http://www.uspto.gov/web/patents/patog/week42/OG/html/1347-3/US07606954-20091020.html

http://www.uspto.gov/web/patents/patog/week32/OG/html/1345-2/US07574719-20090811.html


Start reading your way through this list:
http://search.usa.gov/search?affiliate=web-sdmg-uspto.gov&v%3Aproject=firstgov&query="data+compression"

Bare in mind that the above is 'data compression', but a patent for data compression does not have to be under 'data compression'.


ShadowTurtle(Posted 2010) [#28]
That's only true in very specific circumstances, and completely useless for generic compression.

This is so true.. i think every encoder must be optimized for "area of use". JPG is great for images. MP3 is good for music. ZIP is good for custom files on wich you can not realy code a decoder (lack of time/experience and so on).

And like GFK said the line thing only specifies the length of a line, not accounting what direction, RGB values, and maybe even width.

This work must do the encoder. Ok this is not realistic for me (lack of time and so on). I use this way only to encode 8-bit images. It is the best way. At end the compressed zip file was higher sized than the original file:

1. use half-bytes (4bit) to store information chunks (like x, y coordinates)
2. encode colorized rectangles from left to right and up to down. Save only size and color information.
3. save a little bit about the width & height of the image. Oh.. this is not needed. I use standard 16x16 Pixels.

The following tile graphic needs only 30 bytes into the file. It is saved with 90° angle (do not forget the 8 pixel rectangle limit) because this compress even better.



calculate it a little up and it is a good compression (16 tiles per tileset. 30 tilesets are available and so on...).

Saved the single entity as file and compressed with zip, the file is bigger. ~7 Months ago i compressed 4000 tile-images into a archive (zip). The archive was bigger than the files on my hard drive. This must mean i do use already good compression (data limited compression).

There are so many compression posibilitys... you must only do hard-coding and think about that what the code should save!!!