Heh, well, I had an interesting discussion about this stuff with one of the core devs, and there's actually kind of a nice advantage to Counterparty and similar moving to a system where careful steganography and similar measures are being taken to keep the system unblocked: if someone does do the "fill the chain with child porn" legal attack on Bitcoin the community can argue that they certainly didn't support it in any way. It also goes back to things like trying to ban or discourage address reuse: if your protocol can be censored, changing it to be harder to censor tends to be actually good for the ecosystem as a whole.

An interesting thing to do might be to change Bitcoin to validate that 33 byte PUSHDATA's are valid pubkeys in the IsStandard() rules. The easiest way to co-erce arbitrary data to look like a pubkey is via something like Mastercoin's encoding scheme, and that has the nice property of being easiest to implement with steganography that hides the data and gives everyone in the ecosystem good plausible deniability.

Anyway, I'm gonna write more about this in the coming weeks as a semi-formal paper, as well as talk about when you can get away with the lesser security of hash-linked side-chain schemes. Some best practices libraries implementing both would be useful for everyone in this ecosystem.


Also, congrats on BitcoinTangibleTrust for doing something with this tech.