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
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
|
Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 97BE0596
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 20:45:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f41.google.com (mail-la0-f41.google.com
[209.85.215.41])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DE00E1BE
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 20:45:40 +0000 (UTC)
Received: by labiq1 with SMTP id iq1so16592161lab.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 13:45:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=kWFvXFg5t2U8D2NgSCogNFDV9a+hKHi7WjePTK+jPXw=;
b=owa0f6OXuRFzTLdSEZ2WG+nSjY6zDRtRh6kXwy2cnqXE8o55lHgBq43kgwvZy8n2Jk
GLe+un/4wcf/QE8EXdZ4M4qa+DhIIhc2z4DNdlhu0C6hfWsd4UeU+cu9jYvt6EWLzMDp
lIG16/z1gw3tWxK4FQB4/bubPAze8P/I2DTgn81lkOlQsZ7pn4uOduq3/scjcnDZcSUh
xzz8XkqhViXn7SSKzeofv/pTCuKngrrUpKWJTE58YwB41LyU+P79aWcl7QlJx+yJ/uLe
M+CnTAWF4O32yb7J7CoVPswMwMu03txiwwJcuu2uZcapeMs6kVnS/VrNO9/6VwCDmJkL
lrBg==
MIME-Version: 1.0
X-Received: by 10.152.5.65 with SMTP id q1mr5252571laq.110.1438375538974; Fri,
31 Jul 2015 13:45:38 -0700 (PDT)
Received: by 10.112.53.5 with HTTP; Fri, 31 Jul 2015 13:45:38 -0700 (PDT)
Received: by 10.112.53.5 with HTTP; Fri, 31 Jul 2015 13:45:38 -0700 (PDT)
In-Reply-To: <4608887.aSM42bDkNk@coldstorage>
References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com>
<F7601CF2-2B89-4D11-8B56-8FFF63A4063C@gmail.com>
<25FD9AAD-99F5-4322-AF34-243F75AE82C4@gmail.com>
<4608887.aSM42bDkNk@coldstorage>
Date: Fri, 31 Jul 2015 13:45:38 -0700
Message-ID: <CABr1YTc46x3RoKKF=cckcmVRWCaAQc0KOTrGRX+A-h5V=xYB9A@mail.gmail.com>
From: Eric Lombrozo <elombrozo@gmail.com>
To: Thomas Zander <thomas@thomaszander.se>
Content-Type: multipart/alternative; boundary=089e013d17540de984051c31e798
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't
temporary
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jul 2015 20:45:42 -0000
--089e013d17540de984051c31e798
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I would love to be able to increase block size. But I have serious doubts
about being able to do this safely at this time given what we presently
know about the Bitcoin network. And I'm pretty sure I'm not alone in this
sentiment.
Had we been working on fixing the known issues that most complicate bigger
blocks in the last six years, or even in the last three years after many
issues had already been well-identified, perhaps we'd be ready to increase
the limit. But other things have seemed more important, like specifying the
use of X.509 overlay protocols or adding complex filtering mechanisms to
the p2p protocol to make it practical to use tx merkle trees...and as a
result we're not ready for safely allowing larger blocks.
- Eric
On Jul 30, 2015 11:43 PM, "Thomas Zander via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Thursday 30. July 2015 16.33.16 Eric Lombrozo via bitcoin-dev wrote:
> > I don=E2=80=99t think it=E2=80=99s really a matter of whether we agree=
on whether it=E2=80=99s
> good
> > to raise the block size limit, Gavin. I think it=E2=80=99s a matter of =
a
> difference
> > in priorities.
>
> Having different priorities is fine, using your time to block peoples
> attempts
> to increase block size is not showing different priorities, it shows
> conflicting
> priorities.
> Different priorities means you can trust someone else to do things they
> care
> about while you do things you care about.
> --
> Thomas Zander
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--089e013d17540de984051c31e798
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">I would love to be able to increase block size. But I have s=
erious doubts about being able to do this safely at this time given what we=
presently know about the Bitcoin network. And I'm pretty sure I'm =
not alone in this sentiment.</p>
<p dir=3D"ltr">Had we been working on fixing the known issues that most com=
plicate bigger blocks in the last six years, or even in the last three year=
s after many issues had already been well-identified, perhaps we'd be r=
eady to increase the limit. But other things have seemed more important, li=
ke specifying the use of X.509 overlay protocols or adding complex filterin=
g mechanisms to the p2p protocol to make it practical to use tx merkle tree=
s...and as a result we're not ready for safely allowing larger blocks.<=
/p>
<p dir=3D"ltr">- Eric</p>
<div class=3D"gmail_quote">On Jul 30, 2015 11:43 PM, "Thomas Zander vi=
a bitcoin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br type=3D"attri=
bution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">On Thursday 30. July <a href=3D"tel:=
2015%2016.33.16" value=3D"+12015163316">2015 16.33.16</a> Eric Lombrozo via=
bitcoin-dev wrote:<br>
>=C2=A0 I don=E2=80=99t think it=E2=80=99s really a matter of whether we=
agree on whether it=E2=80=99s good<br>
> to raise the block size limit, Gavin. I think it=E2=80=99s a matter of=
a difference<br>
> in priorities.<br>
<br>
Having different priorities is fine, using your time to block peoples attem=
pts<br>
to increase block size is not showing different priorities, it shows confli=
cting<br>
priorities.<br>
Different priorities means you can trust someone else to do things they car=
e<br>
about while you do things you care about.<br>
--<br>
Thomas Zander<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--089e013d17540de984051c31e798--
|
