You'd want to count the size of the decoder, like http://en.wikipedia.org/wiki/Hutter_Prize

Yeah. You really need this caveat to avoid the loophole where you can compress anything to zero bytes by making the desired output a literal in your decompressor (which just ignores its input and prints the hard-coded literal).

This could be considered a real-world application of "hello world" programs: Winning compression prize contests by blatantly abusing the rules.

Well, yes. Except the source text is tiny, so unfortunately all the software is pretty big in comparison.

I love the Hutter Prize, and the various compression benchmark sites.

It's just pretty unconstrained without that kind of rule. And a decompressor that doesn't have to be fast can be tiny.

Now there's a code golf challenge I can work with. Mind posting some of your techniques?

Oh! At the moment I'm just using existing software (PAQ8 variants, and WinRK).

WinRK is best so far. It's not free. It has a 30 day trial. (http://winrk.com/)

General-purpose compressors for comparison:

   gzip      : 66513
   gzip  -c9 : 66099
   bzip2 -c9 : 53619
   xz    -c9 : 59572

Interestingly, bzip2 is the best. Often xz is better, but apparently not for this data.