📅 Original date posted:2014-11-17
📝 Original message:On Mon, Nov 17, 2014 at 4:19 AM, Alan Reiner <etotheipi at gmail.com> wrote:
>
> On 11/16/2014 02:04 PM, Jorge Timón wrote:
>> I remember people asking in #bitcoin-dev "Does anyone know any use
>> case for greater sizes OP_RETURNs?" and me answering "I do not know of
>> any use cases that require bigger sizes".
>
> For reference, there was a brief time where I was irritated that the
> size had been reduced to 40 bytes, because I had an application where I
> wanted to put ECDSA in signatures in the OP_RETURN, and you're going to
> need at least 64 bytes for that. Unfortunately I can't remember now
> what that application was, so it's difficult for me to argue for it.
> But I don't think that's an unreasonable use case: sending a payment
> with a signature, essentially all timestamped in the blockchain.
You can still send the signature out of band (for example using the
payment protocol), and just have the transaction commit to a hash of
that signature (or message in general), either using an OP_RETURN
output to store the hash, or using the pay-to-contract scheme that
Jorge mentioned above. That has exactly the same timestamping
properties.
My main concern with OP_RETURN is that it seems to encourage people to
use the blockchain as a convenient transport channel, rather than just
for data that the world needs to see to validate it. I'd rather
encourage solutions that don't require additional data there, which in
many cases (but not all) is perfectly possible.
--
Pieter
Pieter Wuille [ARCHIVE] /
npub1tj…jtl6r
2023-06-07 15:27:29
in reply to nevent1q…wjyf
Author Public Key
npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rPublished at
2023-06-07 15:27:29Event JSON
{
"id": "8fe6152e7aa7c09bc2d35a42eb2bcc07fc1013175b066bf3785eca5d8e9d928e",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686151649,
"kind": 1,
"tags": [
[
"e",
"9ea4322dc19e55ba7a16fb4778826be5d9520c59d79239c258ee43cc77449b49",
"",
"root"
],
[
"e",
"1706e7f4cfdb9bc4c6a1abb1e3835844fa6d09ed8819f1e59bdd7eec64a58922",
"",
"reply"
],
[
"p",
"86f42bcb76a431c128b596c36714ae73a42cae48706a9e5513d716043447f5ec"
]
],
"content": "📅 Original date posted:2014-11-17\n📝 Original message:On Mon, Nov 17, 2014 at 4:19 AM, Alan Reiner \u003cetotheipi at gmail.com\u003e wrote:\n\u003e\n\u003e On 11/16/2014 02:04 PM, Jorge Timón wrote:\n\u003e\u003e I remember people asking in #bitcoin-dev \"Does anyone know any use\n\u003e\u003e case for greater sizes OP_RETURNs?\" and me answering \"I do not know of\n\u003e\u003e any use cases that require bigger sizes\".\n\u003e\n\u003e For reference, there was a brief time where I was irritated that the\n\u003e size had been reduced to 40 bytes, because I had an application where I\n\u003e wanted to put ECDSA in signatures in the OP_RETURN, and you're going to\n\u003e need at least 64 bytes for that. Unfortunately I can't remember now\n\u003e what that application was, so it's difficult for me to argue for it.\n\u003e But I don't think that's an unreasonable use case: sending a payment\n\u003e with a signature, essentially all timestamped in the blockchain.\n\nYou can still send the signature out of band (for example using the\npayment protocol), and just have the transaction commit to a hash of\nthat signature (or message in general), either using an OP_RETURN\noutput to store the hash, or using the pay-to-contract scheme that\nJorge mentioned above. That has exactly the same timestamping\nproperties.\n\nMy main concern with OP_RETURN is that it seems to encourage people to\nuse the blockchain as a convenient transport channel, rather than just\nfor data that the world needs to see to validate it. I'd rather\nencourage solutions that don't require additional data there, which in\nmany cases (but not all) is perfectly possible.\n\n-- \nPieter",
"sig": "84968916116aafc564fa8b1d0af368d2b93f48185aa0693734c7b20438f7dc080f55fa3415d1786d54905a08876d18bc31913be35d58cc709ffe04c510abcf31"
}