š
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
ZmnSCPxj [ARCHIVE] /
npub1g5ā¦3ms3l
2023-06-07 22:51:43
in reply to nevent1qā¦g45y
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-07 22:51:43Event JSON
{
"id": "f81d813f1440173fbbe8d0a3ff6613d6ecc0fbfc23be3ca85106a81dcff059f1",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686178303,
"kind": 1,
"tags": [
[
"e",
"603f39678bcc9e8e30f94bfe6386763f2e249a0ec7bc1f247dad6d882215065d",
"",
"root"
],
[
"e",
"2dc586184d02b3ce8f38430a4e11dd71d1b73581d5c931c30be0df700f9b9785",
"",
"reply"
],
[
"p",
"ee55eb03423bd4db01d5c92ad434d52c602d9da1de37ed37cc5bf7d2a13a4cab"
]
],
"content": "š
Original date posted:2021-04-16\nš Original message:Good morning Christopher,\n\n\u003e \u003e\u003e 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.\n\u003e\n\u003e This sounds like a good justification to remove the legacy multi-signature capabilities as well.\n\nThe 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).\nThere 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.\n\nIf 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.\n\nIn all these cases you have to waste 547 satoshi, but that tends to be small compared to tx fees currently.\n\nRegards,\nZmnSCPxj",
"sig": "6b4e4cac5c34299d1e9c4cbd1ebb4507d205356b9c9793abdb39da4221397b1e3825d2b7433b7e84b2708f42113bca95f75d2ab3369236983131cd52d0e64028"
}