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
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
|
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 585E725A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 20:57:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f46.google.com (mail-la0-f46.google.com
[209.85.215.46])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5BDAC266
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 20:57:16 +0000 (UTC)
Received: by lacct8 with SMTP id ct8so18260726lac.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 13:57:14 -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=LsEvjGzT5zYs6nTzwLArpBjk9ZBqsn4P9RFv29RPfyg=;
b=xugSe1tLyc8MQCJWw3aVzmyL05rkf3Xre97cVEbEPYjx/FaeUnCexQQ6HOkib4oLkL
noxu0fgTOek8V8PsoRWdVHw44VT5dyYtZ52kToA7SbwA4Z7GVure2bcjyrmwz/UiW4u8
X7W0RAGK4G9iGcjkr55Mmk1TGj2LMYRV38+hqfk3/MmzUvlPuxJ5s81fOkhPcMx+7j+7
KI7964HNfv1+FNWdaVFw8HbWfqZGre5Bw+5/+msgcXtvZmplLmwqwBxs+5WaSiWkwpBI
ajNO9UIQa78hFNNbxV35K+ZJqPiBejTBCNhiTLcrIQW43vRloSu+VTSOqF3+3d4PiLZV
zMyg==
MIME-Version: 1.0
X-Received: by 10.152.28.73 with SMTP id z9mr5252948lag.93.1438376234706; Fri,
31 Jul 2015 13:57:14 -0700 (PDT)
Received: by 10.112.53.5 with HTTP; Fri, 31 Jul 2015 13:57:14 -0700 (PDT)
Received: by 10.112.53.5 with HTTP; Fri, 31 Jul 2015 13:57:14 -0700 (PDT)
In-Reply-To: <CABr1YTc46x3RoKKF=cckcmVRWCaAQc0KOTrGRX+A-h5V=xYB9A@mail.gmail.com>
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>
<CABr1YTc46x3RoKKF=cckcmVRWCaAQc0KOTrGRX+A-h5V=xYB9A@mail.gmail.com>
Date: Fri, 31 Jul 2015 13:57:14 -0700
Message-ID: <CABr1YTfsf8Z9tyjMTyQRpo0bDtZAG+m=-0W_vxd5pp5Qs1YnDg@mail.gmail.com>
From: Eric Lombrozo <elombrozo@gmail.com>
To: Thomas Zander <thomas@thomaszander.se>
Content-Type: multipart/alternative; boundary=089e0158c02685ed46051c32101b
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:57:17 -0000
--089e0158c02685ed46051c32101b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Having said that, I must admit that the complex filtering mechanisms are
pretty clever...they almost make it practical to use SPV...now if only we
were committint to structures that can prove the validity of returned
datasets and miners actually validated stuff, it might also offer some
level of security.
On Jul 31, 2015 1:45 PM, "Eric Lombrozo" <elombrozo@gmail.com> wrote:
> 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 bigge=
r
> 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 increas=
e
> the limit. But other things have seemed more important, like specifying t=
he
> 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 agre=
e 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
>>
>
--089e0158c02685ed46051c32101b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Having said that, I must admit that the complex filtering me=
chanisms are pretty clever...they almost make it practical to use SPV...now=
if only we were committint to structures that can prove the validity of re=
turned datasets and miners actually validated stuff, it might also offer so=
me level of security.</p>
<div class=3D"gmail_quote">On Jul 31, 2015 1:45 PM, "Eric Lombrozo&quo=
t; <<a href=3D"mailto:elombrozo@gmail.com">elombrozo@gmail.com</a>> w=
rote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr"=
>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 kno=
w about the Bitcoin network. And I'm pretty sure I'm not alone in t=
his 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" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote=
:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thursday 30. Ju=
ly <a href=3D"tel:2015%2016.33.16" value=3D"+12015163316" target=3D"_blank"=
>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" target=3D"_blank">=
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>
</blockquote></div>
--089e0158c02685ed46051c32101b--
|
