📅 Original date posted:2016-01-26
📝 Original message: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.
I give one example use case in the BIP. I agree that special wallet support
would make the feature even better, but if someone tried to use Core the
transaction would at least not be rejected.
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.
On Mon, Jan 25, 2016 at 7:23 PM, Luke Dashjr <luke at dashjr.org> wrote:
> On Tuesday, January 26, 2016 3:17:12 AM Toby Padilla wrote:
> > I don't think every application of OP_RETURN could be classified as
> "spam".
>
> Perhaps not, but in this context I cannot think of any non-spam use cases.
> Use cases should come before changes to support them.
>
> > I also don't think burning the value is going to dissuade anyone from
> going
> > down that route. I don't think lost value is better for anyone.
>
> Lost value is better because it has a cost to the spammer, and deflates the
> rest of the bitcoins.
>
> Luke
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160125/a1a5ce6c/attachment.html>;
Toby Padilla [ARCHIVE] /
npub1m9…huekt
2023-06-07 17:48:10
in reply to nevent1q…ssxn
Author Public Key
npub1m99yqj0pat7mwzsdczyn28z84ce47adngzqp9kzft4gc3xke52fqqhuektPublished at
2023-06-07 17:48:10Event JSON
{
"id": "5bbb26830a764f04e626346f4082cd353f1438018a13393430c256e8eefda01d",
"pubkey": "d94a4049e1eafdb70a0dc089351c47ae335f75b3408012d8495d51889ad9a292",
"created_at": 1686160090,
"kind": 1,
"tags": [
[
"e",
"368032d333e01794ac3e7b97c278de084cce6e6228857d943836fb1a934a5739",
"",
"root"
],
[
"e",
"4446383fa1ec97c708b7b4602a98be2563bdba9ab1164db43101f6d80441ca64",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2016-01-26\n📝 Original message:There are already valid use cases for OP_RETURN, it only makes sense to\nfully support the feature. The only reason it's not supported now is\nbecause the Payments protocol came before OP_RETURN.\n\nI give one example use case in the BIP. I agree that special wallet support\nwould make the feature even better, but if someone tried to use Core the\ntransaction would at least not be rejected.\n\nI've also been exploring this area with key.run (\nhttps://git.playgrub.com/toby/keyrun) and want the functionality for voting\nbased on aggregate OP_RETURN value. *Not* to store data on the blockchain,\nbut to associate content pointers with transactions.\n\nI think that since OP_RETURN has already been approved and supported it\ndoesn't make much sense for me to have to re-defend it from scratch here.\n\nOn Mon, Jan 25, 2016 at 7:23 PM, Luke Dashjr \u003cluke at dashjr.org\u003e wrote:\n\n\u003e On Tuesday, January 26, 2016 3:17:12 AM Toby Padilla wrote:\n\u003e \u003e I don't think every application of OP_RETURN could be classified as\n\u003e \"spam\".\n\u003e\n\u003e Perhaps not, but in this context I cannot think of any non-spam use cases.\n\u003e Use cases should come before changes to support them.\n\u003e\n\u003e \u003e I also don't think burning the value is going to dissuade anyone from\n\u003e going\n\u003e \u003e down that route. I don't think lost value is better for anyone.\n\u003e\n\u003e Lost value is better because it has a cost to the spammer, and deflates the\n\u003e rest of the bitcoins.\n\u003e\n\u003e Luke\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160125/a1a5ce6c/attachment.html\u003e",
"sig": "c927417faaa38db1584c450cb9be2bf0a0d6efb6743fe8c1cb01153655020a962781fbd2f1ac7608b608ffc3501b978d7e5b10d540652aa8d36091c191e4c40c"
}