📅 Original date posted:2021-04-17
📝 Original message: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.
On Fri, Apr 16, 2021 at 11:52 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210417/3299b183/attachment-0001.html>;
Christopher Gilliard [ARCHIVE] /
npub1qm…0hwnt
2023-06-07 22:51:43
in reply to nevent1q…t05z
Author Public Key
npub1qmsejphez6np2my9fu40kj9en68d5fa3s7ap4ul7eh9aeuljusgs50hwntPublished at
2023-06-07 22:51:43Event JSON
{
"id": "0b409b913e5a5d5c924d25413a77368056cfcde0bb1a6cdef6459087e115b785",
"pubkey": "06e19906f916a6156c854f2afb48b99e8eda27b187ba1af3fecdcbdcf3f2e411",
"created_at": 1686178303,
"kind": 1,
"tags": [
[
"e",
"603f39678bcc9e8e30f94bfe6386763f2e249a0ec7bc1f247dad6d882215065d",
"",
"root"
],
[
"e",
"f81d813f1440173fbbe8d0a3ff6613d6ecc0fbfc23be3ca85106a81dcff059f1",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2021-04-17\n📝 Original message:Thanks ZmnSCPxj. Yes, I agree there are many ways to embed arbitrary data\nin the blockchain and it's not feasible to block all of them. That is why\nit's important to, at the same time as limiting the OP_RETURN to one per\nblock, also propose and implement a layer 2 solution for timestamping\nso people have a clear and simple upgrade path. That is what I will be\ndiscussing in one of the BIPs I intend to release early next week.\n\nOn Fri, Apr 16, 2021 at 11:52 PM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\n\u003e Good morning Christopher,\n\u003e\n\u003e \u003e \u003e\u003e But more importantly, adding limitations on OP_RETURN transactions is\n\u003e not helpful. Users who want to embed arbitrary data in their transactions\n\u003e can always do so by encoding their data inside the values of legacy\n\u003e multi-signature scriptpubkeys (pubkeys can be generated without knowing the\n\u003e private key in order to encode non-key related data). Not only can users\n\u003e do this, users have done this in the past. However, this behaviour is\n\u003e problematic because such multi-signature \"data\" scriptpubkeys are\n\u003e indistinguishable from \"real\" multisignature scriptpubkeys, and thus must\n\u003e be kept in the UTXO set. This differs from outputs using OP_RETURN which\n\u003e are provably unspendable, and therefore can be safely omitted from the UTXO\n\u003e set.\n\u003e \u003e\n\u003e \u003e This sounds like a good justification to remove the legacy\n\u003e multi-signature capabilities as well.\n\u003e\n\u003e The same technique can be used on P2PKH as well --- the \"pubkey hash\" need\n\u003e not be a hash of a public key, it can be a 20-byte commitment, or even an\n\u003e ASCII message like \"ZmnSCPxj is the best\" (20 characters, I counted).\n\u003e There is nothing that *can* check if the hash of a public key is indeed\n\u003e the hash of a public key unless you actually reveal the public key.\n\u003e\n\u003e If you need a 32-byte commitment, a P2WSH would work --- again the \"script\n\u003e hash\" need not be a hash of a script, it can be any 32-byte commitment.\n\u003e\n\u003e In all these cases you have to waste 547 satoshi, but that tends to be\n\u003e small compared to tx fees currently.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210417/3299b183/attachment-0001.html\u003e",
"sig": "80a51e8f44c73f13aaf7d56e1fe0e6767dff837e1bfc87d19f3fac4d291e0be37ac57833a726b616dd4d519d8dce3f18b4fdf5c35b0addc3c76f1745ae86c982"
}