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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to