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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <luke@dashjr.org>) id 1Xq3Yp-0004M2-HZ
for bitcoin-development@lists.sourceforge.net;
Sun, 16 Nov 2014 17:24:27 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of dashjr.org
designates 192.3.11.21 as permitted sender)
client-ip=192.3.11.21; envelope-from=luke@dashjr.org;
helo=zinan.dashjr.org;
Received: from zinan.dashjr.org ([192.3.11.21])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Xq3Yo-00010U-EG for bitcoin-development@lists.sourceforge.net;
Sun, 16 Nov 2014 17:24:27 +0000
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:61b6:56a6:b03d:28d6])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id DF20D1080004;
Sun, 16 Nov 2014 17:24:20 +0000 (UTC)
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Sun, 16 Nov 2014 17:24:18 +0000
User-Agent: KMail/1.13.7 (Linux/3.17.3-gentoo; KDE/4.12.5; x86_64; ; )
References: <CABbpET9eTgk1GyxYbcG++O_rqsnfB7w5_Xp4XgE6qwkmGsm1eg@mail.gmail.com>
In-Reply-To: <CABbpET9eTgk1GyxYbcG++O_rqsnfB7w5_Xp4XgE6qwkmGsm1eg@mail.gmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201411161724.19573.luke@dashjr.org>
X-Spam-Score: -1.5 (-)
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 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1Xq3Yo-00010U-EG
Cc: Flavien Charlon <flavien.charlon@coinprism.com>
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: <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 17:24:27 -0000
On Sunday, November 16, 2014 4:21:27 PM Flavien Charlon wrote:
> 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.
Mining policies such as this is always up to miners.
It's not a development topic.
> There are a number of proposals:
>
> 1. Allow two OP_RETURN outputs per transaction (PR
> <https://github.com/bitcoin/bitcoin/pull/5075>)
This one seems uselessly inefficient. Protocols needing OP_RETURN could just
as easily look for an independent push opcode in a single OP_RETURN output.
> 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.
I don't care strongly, but IMO this kind of focus on defaults is part of the
problem. I'd prefer to have the default be randomised to incentivise miners to
make the decision they're supposed to be making, rather than pushing the
responsibility onto developers to set defaults.
> 3. Make the maximum OP_RETURN payload size proportional to the number of
> outputs of the transaction
Right now, this policy requires code hacks. Of the three ideas, this one looks
the most ripe for code changes (particularly one that makes it possible to
configure this policy, not hardcoding it).
Luke
|
