Quote from: jl777 on March 19, 2014, 11:48:26 PM

Quote from: dexX7 on March 19, 2014, 11:38:38 PM

80 bytes would be better than 40 bytes, but is this amount sufficient to support all XCP transaction types?

Could the info needed be compressed to fit into 40 bytes?
What sort of entropy does the typical XCP OP_RETURN data have?

Depending on the data, it might be possible to create a small customized compress/decompress function

If someone can post an example it would help me analyze this a bit more

Edit: due to the importance of this I think it would even make sense to create a custom "dictionary" of common bit patterns (hopefully there are some) in the desired OP_RETURN data. This would have to be put into the counterpartyd, but doing stuff like this might be what is needed to get 2:1 compression, then again maybe standard compression will just work, but I think some sort of custom code would have a good chance. It all depends on the type of data.

James

It would take some serious shoe-horning to fit all of the data we need into 40 bytes reliably, and in three months they could lower it to 35 bytes (again, for no reason) and then we'd be screwed.

On the plus side, we can fit a lot more than 80 bytes into 256 one-of-three multi-sig outputs, and now we have no incentive to use less than that except lower fees.