I have to say I find the Genesis transaction mechanism quite awkward. Why not put the color definition (the URL encoded string) as a message in the transaction?
What do you mean a "message in the transaction"? Right now there is no standard way to encode data in a transaction aside from OP_RETURNs, which we specifically listed as an option. If you're thinking about those messages that blockchain.info shows, they're a proprietary overlay backed by BCI's database, not anything in the Bitcoin network.
Also, the fact that you have to send coins to the COLGEN address is a no-no to me. This is an unnecessary dependency.
If you want adoption, colored coins need to be completely decentralized, as is Bitcoin. The "standard" shouldn't rely on a central address like COLGEN.
We got a lot of similar feedback, and we decided we'll listen. We got rid of the COLGEN address part, and replaced it with an output to the 1111111111111111111114oLvT2 address (which is cryptographically unspendable by anyone and so neutral). I still like the "marker address" idea because it lets light clients easily search for geneses on BCI by going to
http://blockchain.info/address/1111111111111111111114oLvT2, but I think doing it this way removes the centralization. We do want to make a premium color system, but we will set that up as a BitcoinX project independent of the underlying colored coins framework.
Also, I simplified the paper somewhat over the last few days, including making the tagging-based coloring algorithms simpler. The property that colorvalue = value - padding or zero is now true for all colors, for example.
