From: Pieter Wuille <pieter.wuille@gmail•com>
To: Alan Reiner <etotheipi@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
Date: Mon, 17 Nov 2014 11:35:24 +0100 [thread overview]
Message-ID: <CAPg+sBgM4ja0Y96KekJUN7Qg=o0xa1B0VUiiPuFQTYfrupoERg@mail.gmail.com> (raw)
In-Reply-To: <5469692F.9030702@gmail.com>
On Mon, Nov 17, 2014 at 4:19 AM, Alan Reiner <etotheipi@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
next prev parent reply other threads:[~2014-11-17 10:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-16 16:21 Flavien Charlon
2014-11-16 17:24 ` Luke Dashjr
2014-11-16 18:44 ` Jorge Timón
2014-11-16 19:04 ` Jorge Timón
2014-11-17 3:19 ` Alan Reiner
2014-11-17 10:35 ` Pieter Wuille [this message]
2014-11-17 11:20 ` Adam Back
2014-11-17 12:31 ` Chris Pacia
2014-11-17 12:39 ` Pieter Wuille
2014-11-18 22:33 ` Chris Pacia
2014-11-17 11:43 ` Flavien Charlon
2014-11-17 12:00 ` Pieter Wuille
2014-11-17 12:22 ` Jorge Timón
2014-11-18 17:47 ` Btc Drak
2014-11-19 0:46 ` Flavien Charlon
2014-11-17 10:30 ` Wladimir
2014-11-20 23:39 ` Jean-Pierre Rupp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPg+sBgM4ja0Y96KekJUN7Qg=o0xa1B0VUiiPuFQTYfrupoERg@mail.gmail.com' \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=etotheipi@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox