From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XqJec-0007cR-Nh for bitcoin-development@lists.sourceforge.net; Mon, 17 Nov 2014 10:35:30 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.180 as permitted sender) client-ip=209.85.213.180; envelope-from=pieter.wuille@gmail.com; helo=mail-ig0-f180.google.com; Received: from mail-ig0-f180.google.com ([209.85.213.180]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XqJeb-0006jy-SE for bitcoin-development@lists.sourceforge.net; Mon, 17 Nov 2014 10:35:30 +0000 Received: by mail-ig0-f180.google.com with SMTP id h15so4912605igd.1 for ; Mon, 17 Nov 2014 02:35:24 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.137.84 with SMTP id l81mr1583390iod.61.1416220524552; Mon, 17 Nov 2014 02:35:24 -0800 (PST) Received: by 10.50.248.5 with HTTP; Mon, 17 Nov 2014 02:35:24 -0800 (PST) In-Reply-To: <5469692F.9030702@gmail.com> References: <201411161724.19573.luke@dashjr.org> <5469692F.9030702@gmail.com> Date: Mon, 17 Nov 2014 11:35:24 +0100 Message-ID: From: Pieter Wuille To: Alan Reiner Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1XqJeb-0006jy-SE Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 10:35:30 -0000 On Mon, Nov 17, 2014 at 4:19 AM, Alan Reiner wrote: > > On 11/16/2014 02:04 PM, Jorge Tim=F3n 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. --=20 Pieter