Thanks ZmnSCPxj. Yes, I agree there are many ways to embed arbitrary data in the blockchain and it's not feasible to block all of them. That is why it's important to, at the same time as limiting the OP_RETURN to one per block, also propose and implement a layer 2 solution for timestamping so people have a clear and simple upgrade path. That is what I will be discussing in one of the BIPs I intend to release early next week.
Good morning Christopher,
> >> But more importantly, adding limitations on OP_RETURN transactions is not helpful. Users who want to embed arbitrary data in their transactions can always do so by encoding their data inside the values of legacy multi-signature scriptpubkeys (pubkeys can be generated without knowing the private key in order to encode non-key related data). Not only can users do this, users have done this in the past. However, this behaviour is problematic because such multi-signature "data" scriptpubkeys are indistinguishable from "real" multisignature scriptpubkeys, and thus must be kept in the UTXO set. This differs from outputs using OP_RETURN which are provably unspendable, and therefore can be safely omitted from the UTXO set.
>
> This sounds like a good justification to remove the legacy multi-signature capabilities as well.
The same technique can be used on P2PKH as well --- the "pubkey hash" need not be a hash of a public key, it can be a 20-byte commitment, or even an ASCII message like "ZmnSCPxj is the best" (20 characters, I counted).
There is nothing that *can* check if the hash of a public key is indeed the hash of a public key unless you actually reveal the public key.
If you need a 32-byte commitment, a P2WSH would work --- again the "script hash" need not be a hash of a script, it can be any 32-byte commitment.
In all these cases you have to waste 547 satoshi, but that tends to be small compared to tx fees currently.
Regards,
ZmnSCPxj