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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@jtimon.cc>) id 1Xq583-0001Vk-Md
for bitcoin-development@lists.sourceforge.net;
Sun, 16 Nov 2014 19:04:55 +0000
Received: from mail-wg0-f51.google.com ([74.125.82.51])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Xq582-0004XY-9p
for bitcoin-development@lists.sourceforge.net;
Sun, 16 Nov 2014 19:04:55 +0000
Received: by mail-wg0-f51.google.com with SMTP id k14so3898178wgh.38
for <bitcoin-development@lists.sourceforge.net>;
Sun, 16 Nov 2014 11:04:48 -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:date
:message-id:subject:from:to:cc:content-type
:content-transfer-encoding;
bh=+TyQAx5fkmqoKiz96PgLCcwgxawFe1gVG/2xqQsIPdA=;
b=NuZSKicLSumk1D7IPcvzS+M4EuVhkuxaFE+RjXrHruPAjEm8hYlw9hcVr3sSI7lWZo
cNvEaMWNTocwmd1k9DnyjNcQSqgDfe5XFgiQ7rY6IWtnThCzxeBnU2FPgvwk1V9NdeTL
Ym1pmpq4gePgntjcnfkavuO3Was85+FDd8n1roilaBsTfNXOgubPiG5uCbVdcjn54r05
Z34tEJ27CFMIgC3LO6/YQCSdT05cIixkIRa1QrWp94FIPrkm0+qEEZ6EL1JJoCp1YGkB
eCD8Tik856EKgFZZRXX3sNvl6+7rTJCiXo37j6rWE7SGxqvBrJhabs+Ckj5LqOItC2FU
p+5w==
X-Gm-Message-State: ALoCoQlWljVuMCqNmU4uSsajhwb2NvYweZ1lS4gOy5ozOq7Z5tXvZBTHl0JUPV/wokqR/yS1gjed
MIME-Version: 1.0
X-Received: by 10.194.192.2 with SMTP id hc2mr31497716wjc.75.1416164688255;
Sun, 16 Nov 2014 11:04:48 -0800 (PST)
Received: by 10.194.19.38 with HTTP; Sun, 16 Nov 2014 11:04:48 -0800 (PST)
X-Originating-IP: [92.251.101.114]
In-Reply-To: <CABm2gDpBOtZB01Qj3Dc3dWSpG2zLr+VPYbnwrq8YVh8qfxMW5Q@mail.gmail.com>
References: <CABbpET9eTgk1GyxYbcG++O_rqsnfB7w5_Xp4XgE6qwkmGsm1eg@mail.gmail.com>
<201411161724.19573.luke@dashjr.org>
<CABm2gDpBOtZB01Qj3Dc3dWSpG2zLr+VPYbnwrq8YVh8qfxMW5Q@mail.gmail.com>
Date: Sun, 16 Nov 2014 20:04:48 +0100
Message-ID: <CABm2gDoi1593ssoGN69E42c-N3s02yYKAqDEDA2m-e+6LqjpTQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1Xq582-0004XY-9p
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
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 19:04:55 -0000
As an aside, the decision to make it 40 bytes made sense because it is
enough for timestamping. In fact, you can do cheaper and even secret
(and thus impossible to censor by miners) timestamping using
pay-to-contract [1], which uses exactly 0 extra bytes in your
transaction and the blockchain.
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".
I'm aware that so called "proof of publication" is not equivalent to
timestamping, but I wasn't aware at the moment (and I don't think it's
very interesting but that's obviously only my opinion, "embedded
systems" developers will disagree).
[1] Here's a video explaining pay-to-contract in the context of
invoicing as a use case: https://www.youtube.com/watch?v=3DqwyALGlG33Q
Here's a generic working implementation:
https://github.com/Blockstream/contracthashtool
On Sun, Nov 16, 2014 at 7:44 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
> I agree with Luke, we can endlessly discuss the "best defaults" like
> the default size allowed for OP_RETURN, minimum fees, anti-dust
> policies, first-seen vs replace-by-fee, etc; but the fact is that
> policies depend on miners. Unfortunately most miners and pools are
> quite apathetic when it comes to configure their own policy.
> In my opinion the best we can do is to make it easier for miners to
> implement their own policies by abstracting out those parts of the
> code. Pull requests like #5071 and #5114 are steps in that direction.
> So if you're interested in having more miners accepting 80 bytes
> OP_RETURN transactions, I suggest you invest some time reviewing and
> testing those PRs.
> Although this wasn't its main purpose, separating script/standard was
> also a little step in the same direction.
|
