1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
|
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 <flavien.charlon@pixodegames.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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 <bitcoin-development@lists.sourceforge.net>
(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 <bitcoin-development@lists.sourceforge.net>;
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 <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
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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
<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 'datacarriersize' 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 "s=
pace budget" 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--
|
