ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2021-04-16 📝 Original message:Good morning Christopher, ...
📅 Original date posted:2021-04-16
📝 Original message: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
📝 Original message: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