Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XqKpX-0001yR-Gu for bitcoin-development@lists.sourceforge.net; Mon, 17 Nov 2014 11:50:51 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of pixodegames.com designates 209.85.217.182 as permitted sender) client-ip=209.85.217.182; envelope-from=flavien.charlon@pixodegames.com; helo=mail-lb0-f182.google.com; Received: from mail-lb0-f182.google.com ([209.85.217.182]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XqKpV-0002Lv-Fk for bitcoin-development@lists.sourceforge.net; Mon, 17 Nov 2014 11:50:51 +0000 Received: by mail-lb0-f182.google.com with SMTP id f15so17469465lbj.13 for ; Mon, 17 Nov 2014 03:50:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=v5x3qwtzzzSut4U3ACujo2D4fJ3FY9u6KSuXxOU2uA8=; b=FG+DqAkY4y3qxVOiXE8d0QaYYK2jLrnRwXelkOkMqJlbNLp0AMpDvepgtm4jMRv/Wm dp/AusIO5V6+Owene+cKGrQaZ2VKuWfJ47IuD7dzT9CE5eRuE1zTLqL/iuEL5txZski8 K+TeKJajDiD4zmW1HlVVuDLpqN5JcyLx0FUBwm0nv5ns6eVeJq4Z6bN9SvIltzbl+YWC GyniQdqfqsSDD0Z/1OhQGI51GzQbNf5QiCG69XM/QgLrg5Nz3IYLek3RVpM9N9bHCic/ HjWx+I+VfYAoEUed7MP/jMu03ntF8xvHHLMrhv4QmXlp5ciyoDZSTLUjlh7DPyd9sUNp 2FJA== X-Gm-Message-State: ALoCoQnoCgzaUwIGbMXG+INVHgISqUIsai8DT45iEEkRNjAd90qVRd4vTlaQ+Y8RLwXvOc6UkGWj X-Received: by 10.152.7.193 with SMTP id l1mr26568749laa.57.1416224658994; Mon, 17 Nov 2014 03:44:18 -0800 (PST) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com. [209.85.217.171]) by mx.google.com with ESMTPSA id e10sm9026776lbq.1.2014.11.17.03.44.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Nov 2014 03:44:18 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id b6so15888366lbj.30 for ; Mon, 17 Nov 2014 03:44:18 -0800 (PST) X-Received: by 10.152.204.9 with SMTP id ku9mr12427123lac.55.1416224658258; Mon, 17 Nov 2014 03:44:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.23.227 with HTTP; Mon, 17 Nov 2014 03:43:38 -0800 (PST) X-Originating-IP: [89.100.161.202] In-Reply-To: References: <201411161724.19573.luke@dashjr.org> <5469692F.9030702@gmail.com> From: Flavien Charlon Date: Mon, 17 Nov 2014 11:43:38 +0000 Message-ID: To: Pieter Wuille Content-Type: multipart/alternative; boundary=001a1134386ead97bc05080c7f4e X-Spam-Score: -0.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 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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: 1XqKpV-0002Lv-Fk 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 11:50:51 -0000 --001a1134386ead97bc05080c7f4e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > My main concern with OP_RETURN is that it seems to encourage people to use the blockchain as a convenient transport channel The number one user of the blockchain as a storage and transport mechanism is Counterparty, and limiting OP_RETURN to 40 bytes didn't prevent them from doing so. In fact they use multi-sig outputs which is worse than OP_RETURN since it's not always prunable, and yet let them store much more than 40 bytes. For Open Assets , we need to store a URL in the OP_RETURN output (with optionally a hash) plus some bytes of overhead. 40 bytes comes really short for that. The benefit of having a URL in there is that any storage mechanism can be used (Web, FTP, BitTorrent, MaidSafe...), whereas with only a hash, you have to hardcode the storing mechanism in the protocol (and even then, a hash is not enough to address a HTTP or FTP resource). Storing only a hash is fine for the most basic timestamping application, but it's hardly enough to build something interesting. I've counted the number of OP_RETURN outputs in the blockchain for the month of October 2014. There were 1,674 OP_RETURNs for a span of 4,659 blocks. Assuming they were all 40 bytes (the average is probably less than half of that), that means an increase of 14.37 bytes per block. Considering a 1 MB block, that's about 0.0013% of the block used up by OP_RETURN data in average. Increasing to 80 bytes will have a negligible impact on bandwidth and storage requirements, while being extremely useful for many use cases where a hash only is not enough. Flavien On Mon, Nov 17, 2014 at 10:35 AM, Pieter Wuille wrote: > On Mon, Nov 17, 2014 at 4:19 AM, Alan Reiner wrote: > > > > On 11/16/2014 02:04 PM, Jorge Tim=C3=B3n 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 > > > -------------------------------------------------------------------------= ----- > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > > http://pubads.g.doubleclick.net/gampad/clk?id=3D157005751&iu=3D/4140/ostg= .clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --001a1134386ead97bc05080c7f4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> My main concern with OP_RETURN is that it seems = to encourage people to use the blockchain as a convenient transport channel=

The number one user of the blockchain as a storag= e and transport mechanism is Counterparty, and limiting OP_RETURN to 40 byt= es didn't prevent them from doing so. In fact they use multi-sig output= s which is worse than OP_RETURN since it's not always prunable, and yet= let them store much more than 40 bytes.

For Open Assets, = we need to store a URL in the OP_RETURN output (with optionally a hash) plu= s some bytes of overhead. 40 bytes comes really short for that. The benefit= of having a URL in there is that any storage mechanism can be used (Web, F= TP, BitTorrent, MaidSafe...), whereas with only a hash, you have to hardcod= e the storing mechanism in the protocol (and even then, a hash is not enoug= h to address a HTTP or FTP resource). Storing only a hash is fine for the m= ost basic timestamping application, but it's hardly enough to build som= ething interesting.

I've counted the number of= OP_RETURN outputs in the blockchain for the month of October 2014. There w= ere 1,674 OP_RETURNs for a span of 4,659 blocks.=C2=A0Assuming they were al= l 40 bytes (the average is probably less than half of that), that means an = increase of 14.37 bytes per block. Considering a 1 MB block, that's abo= ut 0.0013% of the block used up by OP_RETURN data in aver= age.

Increasing to 80 by= tes will have a negligible impact on bandwidth and storage requirements, wh= ile being extremely useful for many use cases where a hash only is not enou= gh.

Flavien
=

On Mon, Nov= 17, 2014 at 10:35 AM, Pieter Wuille <pieter.wuille@gmail.com>= ; wrote:
On Mon, Nov 17, 201= 4 at 4:19 AM, Alan Reiner <etothe= ipi@gmail.com> wrote:
>
> On 11/16/2014 02:04 PM, Jorge Tim=C3=B3n wrote:
>> I remember people asking in #bitcoin-dev "Does anyone know an= y 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 goi= ng to
> need at least 64 bytes for that.=C2=A0 =C2=A0Unfortunately I can't= remember now
> what that application was, so it's difficult for me to argue for i= t.
> But I don't think that's an unreasonable use case:=C2=A0 sendi= ng a payment
> with a signature, essentially all timestamped in the blockchain.

You can still send the signature out of band (for example using the<= br> 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<= br> many cases (but not all) is perfectly possible.

--
Pieter

---------------------------------------------------------------------------= ---
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & mo= re
Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gam= pad/clk?id=3D157005751&iu=3D/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--001a1134386ead97bc05080c7f4e--