From mboxrd@z Thu Jan 1 00:00:00 1970 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 1Xq33b-0002Dm-3g for bitcoin-development@lists.sourceforge.net; Sun, 16 Nov 2014 16:52:11 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of pixodegames.com designates 209.85.217.172 as permitted sender) client-ip=209.85.217.172; envelope-from=flavien.charlon@pixodegames.com; helo=mail-lb0-f172.google.com; Received: from mail-lb0-f172.google.com ([209.85.217.172]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Xq33Y-00086d-PW for bitcoin-development@lists.sourceforge.net; Sun, 16 Nov 2014 16:52:10 +0000 Received: by mail-lb0-f172.google.com with SMTP id u10so7418319lbd.31 for ; Sun, 16 Nov 2014 08:52:02 -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:from:date:message-id:subject:to :content-type; bh=OMM/6wPcjjvpkdKO6LwhmCpS21OVvId7ti8BmhFSROg=; b=UXuJoEWFrl9k5LX/hebnoZt2jUKN150oDZ8+VXN5s4i7Re5xiQPBOiSrp+aPv1BEf4 9jNwt+LyuuoDOW2ADcE3jmfUi73KUeyt5h1XDxosf8uHZxEPF5PvT80PQVllZ98TCsht hqgDc+nsfVmmeFK6+j/juZ87cxaHnwl4jnr3WYafPBr6aDEnuNvClp5RiJHE6ZOpKkaI aGxuhZdMMJJH9sDJrIZV7EfPIqJdPJgm0End95OARqjzkxKyVs44bOEk20CGFKpJ9QWi rwvRvsuD9Ib7Cnfkucv5lJ35nDCHLNuIWwYriwRGJ4rJqvH5ZpTD1ErnaK8cBJHzzE4J pWUQ== X-Gm-Message-State: ALoCoQkd6nO73upPNiZGJ/5Xxy6lvhoX/m0sZRX96hUzfdsf9BMFQK3lbYvsYc3nGnRuVQWHFL31 X-Received: by 10.113.5.7 with SMTP id ci7mr21596201lbd.9.1416154928123; Sun, 16 Nov 2014 08:22:08 -0800 (PST) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com. [209.85.217.174]) by mx.google.com with ESMTPSA id s5sm6487364laa.9.2014.11.16.08.22.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Nov 2014 08:22:07 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id w7so6311424lbi.33 for ; Sun, 16 Nov 2014 08:22:07 -0800 (PST) X-Received: by 10.152.42.172 with SMTP id p12mr21185882lal.11.1416154927544; Sun, 16 Nov 2014 08:22:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.23.227 with HTTP; Sun, 16 Nov 2014 08:21:27 -0800 (PST) X-Originating-IP: [89.100.161.202] From: Flavien Charlon Date: Sun, 16 Nov 2014 16:21:27 +0000 Message-ID: To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a11c350866756690507fc43b5 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: 1Xq33Y-00086d-PW Subject: [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: Sun, 16 Nov 2014 16:52:11 -0000 --001a11c350866756690507fc43b5 Content-Type: text/plain; charset=UTF-8 Hi, The data that can be embedded as part of an OP_RETURN output is currently limited to 40 bytes. It was initially supposed to be 80 bytes, but got reduced to 40 before the 0.9 release to err on the side of caution. After 9 months, it seems OP_RETURN did not lead to a blockchain catastrophe, so I think it might be time to discuss increasing the limit. There are a number of proposals: 1. Allow two OP_RETURN outputs per transaction (PR ) 2. Increase the default maximum payload size from 40 bytes to 80 bytes ( PR ) Note that the maximum can be configured already through the 'datacarriersize' option - this is just changing the default. 3. Make the maximum OP_RETURN payload size proportional to the number of outputs of the transaction 4. A combination of the above 3 sounds the most interesting, and 2 would be the second best. 1 is also good to have as long as the "space budget" is shared between the two outputs. Can we discuss this and agree on a plan? Thanks, Flavien --001a11c350866756690507fc43b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The data that can be emb= edded as part of an OP_RETURN output is=C2=A0currently limited to 40 bytes.= It was initially supposed to be 80 bytes, but got reduced to 40 before the= 0.9 release to err on the side of caution.

After = 9 months, it seems OP_RETURN did not lead to a blockchain catastrophe, so I= think it might be time to discuss increasing the limit.

There are a number of proposals:
  1. Allow=C2=A0two OP_RETU= RN outputs per transaction (PR)
  2. Increase the default maximum payload size from 40= bytes=C2=A0to 80 bytes=C2=A0(PR)
    Note that the maximum can be configured already thro= ugh the 'datacarriersize' option - this is just changing the defaul= t.
  3. Make the maximum OP_RETURN payload size proportional to the numb= er of outputs of the transaction
  4. A combination of the above
    5. 3=C2=A0sounds the most interesting, and=C2=A02 would be the second b= est.

    1 is also good to have as long as the "s= pace budget" is shared between the two outputs.

    Can we discuss this and=C2=A0agree on a plan?

T= hanks,
Flavien
--001a11c350866756690507fc43b5--