summaryrefslogtreecommitdiff
path: root/73/da17e7038fec0e5894579b6f939cd38c695460
blob: 14b57cb0f197f143cedad145acfd36ab7ce81ade (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
Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 75E2F847
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 16 Aug 2015 16:52:54 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com
	[209.85.213.175])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CD37FEE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 16 Aug 2015 16:52:52 +0000 (UTC)
Received: by igfj19 with SMTP id j19so42234930igf.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 16 Aug 2015 09:52:52 -0700 (PDT)
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:from:date
	:message-id:subject:to:cc:content-type;
	bh=eVFlx748zMZvg4qKzKGUuauV5CN6joUVVRtZEK+5TvA=;
	b=gM1rTtGm3Yu2amfEwWpNjj/Zc8JAOBOAm76kkVAAjbYQ0axWTIsexUI2XhunFKRQhw
	FGv+nTPFLAGA1EQEkXbghGdkoscY8WRomCyV1x1WFlEzDgWDG8ZDOjb6f71/2Ubo9TEj
	cazgj+tTHcTNsLAeIv3KyDR/k4L7rNTsJxUJoMHtPkmVD34Otz893LHzNKHb5bCEaYDO
	lbnOY22x0/3Byn0kv9sJwahnIFWMVmACXdNEnwjITVKBocx2aC0VMJIKl0KD9GRJPJ0o
	ZptkmYKGM76kMQICblPvJs4JKtTb/u+Kne/Q0TF3sK4JQLw2Fn52o0GEOF8T00Grk40p
	NjJg==
X-Gm-Message-State: ALoCoQn9aLKQaKo5BFQNynKLQfXMukTur4Vum/35n1m9lp6RDZ6wZjczl69WdvNm4DJRFLQTKQnA
X-Received: by 10.50.88.8 with SMTP id bc8mr13542545igb.46.1439743972236; Sun,
	16 Aug 2015 09:52:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.138.14 with HTTP; Sun, 16 Aug 2015 09:52:32 -0700 (PDT)
X-Originating-IP: [172.56.40.188]
In-Reply-To: <CAG86ZOzEnjMw4xam5oUuuvyfoAps=47j418cZcw9BLs-yUCB2g@mail.gmail.com>
References: <CAG86ZOzEnjMw4xam5oUuuvyfoAps=47j418cZcw9BLs-yUCB2g@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Sun, 16 Aug 2015 09:52:32 -0700
Message-ID: <CAOG=w-sEqBpNK3ncJhKVp7h3+HckeFF0WhdDtjh=t6NH+Ok8Nw@mail.gmail.com>
To: Levin Keller <post@levinkeller.de>
Content-Type: multipart/alternative; boundary=089e0111bea208a3bc051d708446
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Minimum Block Size
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: Sun, 16 Aug 2015 16:52:54 -0000

--089e0111bea208a3bc051d708446
Content-Type: text/plain; charset=UTF-8

Levin, it is a complicated issue for which there isn't an easy answer. Part
of the issue is that "block size" doesn't actually measure resource usage
very reliably. It is possible to support a much higher volume of typical
usage transactions than transactions specifically constructed to cause DoS
issues. But if "block size" is the knob being tweaked, then you must design
for the DoS worst case, not the average/expected use case.

Additionally, there is an issue of time horizons and what presumed
improvements are made to the client. Bitcoin Core today can barely handle
1MB blocks, but that's an engineering limitation. So are we assuming fixes
that aren't actually deployed yet? Should we raise the block size before
that work is tested and its performance characteristics validated?

It's a complicated issue without easy answers, and that's why you're not
seeing straightforward statements of "2MB", "8MB", or "20MB" from most of
the developers.

But that's not to say that people aren't doing anything. There is a
workshop being organized for September 12-13th that will cover much of
these "it's complicated" issues. There will be a follow-on workshop in the
Nov/Dec timeframe in which specific proposals will be discussed. I
encourage you to participate:

http://scalingbitcoin.org/

On Sun, Aug 16, 2015 at 9:41 AM, Levin Keller via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hey everyone,
>
> as with the current "max block size" debate I was wondering: Is anyone
> here in favor of a minimum block size (say 2 MB or so)? If so I would be
> interested in an exchange (maybe off-list) of ideas. I am in favor of a
> lower limit and am giving it quite a bit of thought at the moment.
>
> Cheers
>
> Levin
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr"><div><div><div><div>Levin, it is a complicated issue for w=
hich there isn&#39;t an easy answer. Part of the issue is that &quot;block =
size&quot; doesn&#39;t actually measure resource usage very reliably. It is=
 possible to support a much higher volume of typical usage transactions tha=
n transactions specifically constructed to cause DoS issues. But if &quot;b=
lock size&quot; is the knob being tweaked, then you must design for the DoS=
 worst case, not the average/expected use case.<br><br></div>Additionally, =
there is an issue of time horizons and what presumed improvements are made =
to the client. Bitcoin Core today can barely handle 1MB blocks, but that&#3=
9;s an engineering limitation. So are we assuming fixes that aren&#39;t act=
ually deployed yet? Should we raise the block size before that work is test=
ed and its performance characteristics validated?<br><br></div>It&#39;s a c=
omplicated issue without easy answers, and that&#39;s why you&#39;re not se=
eing straightforward statements of &quot;2MB&quot;, &quot;8MB&quot;, or &qu=
ot;20MB&quot; from most of the developers.<br><br></div>But that&#39;s not =
to say that people aren&#39;t doing anything. There is a workshop being org=
anized for September 12-13th that will cover much of these &quot;it&#39;s c=
omplicated&quot; issues. There will be a follow-on workshop in the Nov/Dec =
timeframe in which specific proposals will be discussed. I encourage you to=
 participate:<br><br></div><a href=3D"http://scalingbitcoin.org/">http://sc=
alingbitcoin.org/</a><br></div><div class=3D"gmail_extra"><br><div class=3D=
"gmail_quote">On Sun, Aug 16, 2015 at 9:41 AM, Levin Keller via bitcoin-dev=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.=
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;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hey everyone,<di=
v><br></div><div>as with the current &quot;max block size&quot; debate I wa=
s wondering: Is anyone here in favor of a minimum block size (say 2 MB or s=
o)? If so I would be interested in an exchange (maybe off-list) of ideas. I=
 am in favor of a lower limit and am giving it quite a bit of thought at th=
e moment.</div><div><br></div><div>Cheers</div><span class=3D"HOEnZb"><font=
 color=3D"#888888"><div><br></div><div>Levin</div></font></span></div>
<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>
<br></blockquote></div><br></div>

--089e0111bea208a3bc051d708446--