summaryrefslogtreecommitdiff
path: root/29/e53a6eb629468044967982485865f3dc45b098
blob: d9449e27ee1f932c61795700b7a7945f35253155 (plain)
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: <gsanders87@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 79EFCB61
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 27 Jan 2017 20:47:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f176.google.com (mail-qt0-f176.google.com
	[209.85.216.176])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CDBAF187
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 27 Jan 2017 20:47:41 +0000 (UTC)
Received: by mail-qt0-f176.google.com with SMTP id k15so155949709qtg.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 27 Jan 2017 12:47:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=K4pLevkX3W0zXJUEpH0el63v2XButpWbYyllXW7q9Zw=;
	b=tnQP/D9UalcCemYS5Im3i26pBlzOjgRNRBSL3C13d1RSlT4OsP2rv2F6kpnJYk5lb4
	0G2Ays5SLlqY1/LqLj+w/2s/WZy6xgD5k0df1Mm9LGDlIYYDCQGGdn7bPpH1w97dngcd
	qHFXPR77dl+cgM6GZfcvGOkZ2rIMaL7z38OTR0DB3pSd6n8kR87VUguLsKaomAmKwPUa
	QQnnHbnneuE63hh8EyErHJVv/9fkWK2RsIC2FGdnJEwQoci01gV/YRfqrGp88LBgBx98
	dt2mbHEs9MKB+n+PvqdO4TDlW46HHfi9VxWQdh5Rqsm+W+oCYXKDF9GHiSth1NgcmQ22
	4hTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=K4pLevkX3W0zXJUEpH0el63v2XButpWbYyllXW7q9Zw=;
	b=l2e/2Q7w1f7theZiHrH0Q9NLVi3yCKrop7Y9dm5/dpJxxxgyRsaJ6TAPmGE7tfcBa0
	ilJppQzFaxfAPJypFzB9WhwJfcvbuhDQsvzesmVVuC9yALntBWmDTIk0Ou2zMLXOq0EU
	KhaJjDo3D/p4oGeQJse3BthDuo/N3M5622bEhAsZWl4gdVfYqpGP64j2NsdL1BimyZSf
	XTndlHUH6CjiK6znBBYsxE+GZg1nNyJKhQQwJGwRSGf6yO4R+1ZSOFM12jFA9LTEX2DB
	3EvV8o+0/xyYVrP5h1kZ3NkNOKq0KEwdW3kr8Iz9TlXvsaHGOoxod19mwYynrkUQTlDB
	tu2w==
X-Gm-Message-State: AIkVDXJZ609rTOA4gbvyNKg79rABOe0a22S0pQQCHH19htUXCE/T9OBgf0YsK4JU75jBNdyJNfh/H/OOojq7rw==
X-Received: by 10.200.49.106 with SMTP id h39mr10531799qtb.257.1485550061013; 
	Fri, 27 Jan 2017 12:47:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.137.230 with HTTP; Fri, 27 Jan 2017 12:47:20 -0800 (PST)
In-Reply-To: <CAMZUoKmUH7ah7pnUgLHFtwYacw2=v3rJ0-csJ8thRy=REM92iw@mail.gmail.com>
References: <201701270107.01092.luke@dashjr.org>
	<CAAy62_+1OjF3V5g4wpOyW0KtNGodddJu_cxOfG-f+8LB7D=rPA@mail.gmail.com>
	<CAAy62_JuWMQ=HMmcw8GsQSDM8S+4LJeG1GHw1OdT+mQC3H-DOA@mail.gmail.com>
	<201701270414.18553.luke@dashjr.org>
	<CAAy62_LHtrx7k73kznMpPvheA--0T9YiHkjHArf2KK0Qt+ViUg@mail.gmail.com>
	<CAAy62_LeNi1djDmArX0RWW=rD0GJU9eSqCy0o4G9eg3Y7O+0Wg@mail.gmail.com>
	<CAMZUoKnxqxvPQehdWo1ZaHB-1-od4cHvJRDTmF5x7ty1CdLbUQ@mail.gmail.com>
	<CAMZUoK=eb3jgA7Rwt38tvZt0tYk7gRVPc_2=HUWg1L_vaD93uw@mail.gmail.com>
	<CAMZUoKmUH7ah7pnUgLHFtwYacw2=v3rJ0-csJ8thRy=REM92iw@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Fri, 27 Jan 2017 15:47:20 -0500
Message-ID: <CAB3F3DviHkQo9ndYphOgUvgSum9TTzX=AA_Acdf-9sZJ7TuHuQ@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.io>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1142d35caed873054719930c
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	HTML_MESSAGE, RCVD_IN_DNSWL_LOW,
	RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Three hardfork-related BIPs
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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, 27 Jan 2017 20:47:42 -0000

--001a1142d35caed873054719930c
Content-Type: text/plain; charset=UTF-8

Note that the 4MB number comes from a single network metric.

Quotes directly from the paper in question:
http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf

>Our results hinge on the key metric of effective throughput in the overlay
network, which we define here as which blocks propagate within an average
block interval period the percentage of nodes to.
...
>Note that as we consider only a subset of possible metrics (due to
difficulty in accurately measuring others), our results on
reparametrization may be viewed as upper bounds: additional metrics could
reveal even stricter limits.

It says nothing about any mining centralization pressure, DoS attacks, etc.
A single metric among many we have to contend with.






On Fri, Jan 27, 2017 at 3:34 PM, Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> On Jan 27, 2017 03:03, "Andrew Johnson via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Other researchers have come to the conservative conclusion that we could
> handle 4MB blocks today.
>
>
> I believe this is a mischaracterization of the research conclusions.  The
> actual conclusion was that the maximum value for the blocksize that the
> network can safely handle (at that time) is some value that is
> (conservatively) no more than 4MB.  This is because the research only
> studies one aspect of the effect of blocksize on the network at a time and
> the true safe value is the minimum of all aspects.  For example, the 4MB
> doesn't cover the aspect of quadratic hashing for large transactions in
> large blocks.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--001a1142d35caed873054719930c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Note that the 4MB number comes from a single network metri=
c.<div><br></div><div>Quotes directly from the paper in question:=C2=A0<a h=
ref=3D"http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf">http://fc16.ifca.ai/b=
itcoin/papers/CDE+16.pdf</a></div><div><br><div>&gt;Our results hinge on th=
e key metric of effective throughput in the overlay
network, which we define here as which blocks propagate within an average
block interval period the percentage of nodes to.</div></div><div>...</div>=
<div>&gt;Note that as we consider only a subset of possible metrics (due to=
 difficulty in accurately measuring others), our results on reparametrizati=
on may be viewed as upper bounds: additional metrics could reveal even stri=
cter limits.<br></div><div><br></div><div>It says nothing about any mining =
centralization pressure, DoS attacks, etc. A single metric among many we ha=
ve to contend with.</div><div><br></div><div><br></div><div><br></div><div>=
<br></div><div><br></div></div><div class=3D"gmail_extra"><br><div class=3D=
"gmail_quote">On Fri, Jan 27, 2017 at 3:34 PM, Russell O&#39;Connor via bit=
coin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfou=
ndation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><span c=
lass=3D""><br><div class=3D"gmail_extra" dir=3D"auto"><br><div class=3D"gma=
il_quote">On Jan 27, 2017 03:03, &quot;Andrew Johnson via bitcoin-dev&quot;=
 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wrote:</div><div cl=
ass=3D"gmail_quote" dir=3D"auto"><br><blockquote class=3D"m_456496729940206=
7845m_9040702076880917011quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto">Other rese=
archers have come to the conservative conclusion that we could handle 4MB b=
locks today.</div></div></blockquote></div></div><div dir=3D"auto"><br></di=
v></span><div dir=3D"auto">I believe this is a mischaracterization of the r=
esearch conclusions.=C2=A0 The actual conclusion was that the maximum value=
 for the blocksize that the network can safely handle (at that time) is som=
e value that is (conservatively) no more than 4MB.=C2=A0 This is because th=
e research only studies one aspect of the effect of blocksize on the networ=
k at a time and the true safe value is the minimum of all aspects.=C2=A0 Fo=
r example, the 4MB doesn&#39;t cover the aspect of quadratic hashing for la=
rge transactions in large blocks.</div></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--001a1142d35caed873054719930c--