📅 Original date posted:2016-01-26
📝 Original message:On 26/01/16 03:30, Toby Padilla via bitcoin-dev wrote:
> There are already valid use cases for OP_RETURN, it only makes sense
> to fully support the feature. The only reason it's not supported now
> is because the Payments protocol came before OP_RETURN.
>
You keep saying OP_RETURN is new, but it has been there from day one.
It's purpose is causing script execution to end if encountered.
Since then, we have tolerated putting pushdata's after it, and even
raised the limit for the size of this data. It still doesn't mean every
proposal has to be rewritten to cater for a new allowance we give
OP_RETURN.
> I've also been exploring this area with key.run
> (https://git.playgrub.com/toby/keyrun) and want the functionality for
> voting based on aggregate OP_RETURN value. *Not* to store data on the
> blockchain, but to associate content pointers with transactions.
>
> I think that since OP_RETURN has already been approved and supported
> it doesn't make much sense for me to have to re-defend it from scratch
> here.
I'd generally agree with Luke. Removing the cost of this hurts bitcoin,
and ironically, your application to a certain degree. Just because you
can do a thing one way, it doesn't mean you should. Especially if your
applications success depends on people spamming OP_RETURN hashes of
every torrent they like.
Thomas Kerin [ARCHIVE] /
npub1e4…nt5am
2023-06-07 17:48:10
in reply to nevent1q…xre8
Author Public Key
npub1e4azew50kk9xzvfpqxzlyftkjt6kken0kf9lnncpdj524f9y4cqsfnt5amPublished at
2023-06-07 17:48:10Event JSON
{
"id": "3a5e12eca658da7bd2349471674f83f65adf2c296b1f103ddf473cdb7e271cf1",
"pubkey": "cd7a2cba8fb58a6131210185f2257692f56b666fb24bf9cf016ca8aaa4a4ae01",
"created_at": 1686160090,
"kind": 1,
"tags": [
[
"e",
"368032d333e01794ac3e7b97c278de084cce6e6228857d943836fb1a934a5739",
"",
"root"
],
[
"e",
"5bbb26830a764f04e626346f4082cd353f1438018a13393430c256e8eefda01d",
"",
"reply"
],
[
"p",
"d94a4049e1eafdb70a0dc089351c47ae335f75b3408012d8495d51889ad9a292"
]
],
"content": "📅 Original date posted:2016-01-26\n📝 Original message:On 26/01/16 03:30, Toby Padilla via bitcoin-dev wrote:\n\u003e There are already valid use cases for OP_RETURN, it only makes sense\n\u003e to fully support the feature. The only reason it's not supported now\n\u003e is because the Payments protocol came before OP_RETURN.\n\u003e\nYou keep saying OP_RETURN is new, but it has been there from day one.\nIt's purpose is causing script execution to end if encountered.\n\nSince then, we have tolerated putting pushdata's after it, and even\nraised the limit for the size of this data. It still doesn't mean every\nproposal has to be rewritten to cater for a new allowance we give\nOP_RETURN.\n\n\n\u003e I've also been exploring this area with key.run\n\u003e (https://git.playgrub.com/toby/keyrun) and want the functionality for\n\u003e voting based on aggregate OP_RETURN value. *Not* to store data on the\n\u003e blockchain, but to associate content pointers with transactions.\n\u003e\n\u003e I think that since OP_RETURN has already been approved and supported\n\u003e it doesn't make much sense for me to have to re-defend it from scratch\n\u003e here.\n\nI'd generally agree with Luke. Removing the cost of this hurts bitcoin,\nand ironically, your application to a certain degree. Just because you\ncan do a thing one way, it doesn't mean you should. Especially if your\napplications success depends on people spamming OP_RETURN hashes of\nevery torrent they like.",
"sig": "85560fd97075c532aac8b0c3aa91bf4f5058a5977cfea99aad59539c03abc761d9bed43a5cdafdb1dd1f68c17a0a00eef5bd928f89c2186bec28cbe024d87bc7"
}