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; 
MIME-Version: 1.0
From: Flavien Charlon <flavien.charlon@coinprism.com>
Date: Sun, 16 Nov 2014 16:21:27 +0000
Message-ID: <CABbpET9eTgk1GyxYbcG++O_rqsnfB7w5_Xp4XgE6qwkmGsm1eg@mail.gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11c350866756690507fc43b5
Subject: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
Precedence: list

--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
   <https://github.com/bitcoin/bitcoin/pull/5075>)
   2. Increase the default maximum payload size from 40 bytes to 80 bytes (
   PR <https://github.com/bitcoin/bitcoin/pull/5286>)
   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

<div dir=3D"ltr"><div>Hi,</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></di=
v><div>There are a number of proposals:</div><ol><li>Allow=C2=A0two OP_RETU=
RN outputs per transaction (<a href=3D"https://github.com/bitcoin/bitcoin/p=
ull/5075">PR</a>)</li><li>Increase the default maximum payload size from 40=
 bytes=C2=A0to 80 bytes=C2=A0(<a href=3D"https://github.com/bitcoin/bitcoin=
/pull/5286">PR</a>)<br>Note that the maximum can be configured already thro=
ugh the &#39;datacarriersize&#39; option - this is just changing the defaul=
t.</li><li>Make the maximum OP_RETURN payload size proportional to the numb=
er of outputs of the transaction</li><li>A combination of the above</li></o=
l><div>3=C2=A0sounds the most interesting, and=C2=A02 would be the second b=
est.</div><div><br></div><div>1 is also good to have as long as the &quot;s=
pace budget&quot; is shared between the two outputs.</div><div><br></div><d=
iv>Can we discuss this and=C2=A0agree on a plan?</div><div><br></div><div>T=
hanks,</div><div>Flavien</div></div>

--001a11c350866756690507fc43b5--