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
|
Return-Path: <bram@bittorrent.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3AE8B40D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 10 Dec 2016 23:12:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f175.google.com (mail-io0-f175.google.com
[209.85.223.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C8C0513B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 10 Dec 2016 23:12:26 +0000 (UTC)
Received: by mail-io0-f175.google.com with SMTP id p42so120563241ioo.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 10 Dec 2016 15:12:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bittorrent-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=r2ZeL3VC3MwHwVD8mSSx59FWGmF+GZo6BO8GG9xJAu8=;
b=nQcN925AxZVlEJaaa+7juKSz/tu/0ZlCEhN65HDi4hWSonXo1X3ZA8PF14cAx6qfEq
Mvi9hgGnLwflK7kxzWVf/nZwNlzqy2j0umhtwVuC5tb7II91MJSU/61L3QdqVptyQpPH
ZpFGWIv/jtq814FqnsUYPA5GzEyU5d2UarhpIsaChPYv9ndAnI+MPGpgmHdNciMA9Yl8
htvBrLJUChrczUR/VXHoe5gSvVnbNPXJ9SQQt9cGQcswGZITwdQLma5sGqIgaYcgerrA
rS41mp2/fg+BwXpwEnSUdWOo2cGvUAqD1ciq6A1RGL+G+NJ+9Au6F2l0QLX1WWC4pmi3
stXw==
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;
bh=r2ZeL3VC3MwHwVD8mSSx59FWGmF+GZo6BO8GG9xJAu8=;
b=XQX3BRWRt4xNgh2wJ6JIlByuWsYoeRR3brBWEeImGLouqiFyh+lOENy/RUXyaEXjDb
sVe/h+Ct86I+dVbO4MOLiUkNXNfVSLXMwkw0X7Us1oXvo2epjFoIagek3vhI7eKFJRnB
bXLMnl2U8sCsXjGTScvMkVDykRtFQA5oeluu6ZN8AYJj15tyLeMVJkucANbleDFJLK9w
4g3A+Wb8LavZvyNJYzVhTHrwozxrJ7aAoTHCAarslUbhSA/XuxJ4vtB7xdfN26lSP005
WjdxGzZvJ3LV8ZnEl7MEv1Cpniu/wTRLS97vS6L+w09Y2B793zgdPKfekqOjTjmy6yMB
0D6g==
X-Gm-Message-State: AKaTC03ABA4I0npM8gijP2QHWNV5CtGh0INxtPvvNtneuveYNzKoLMe0yd74xl8K21aEumjmpjTGoj4GYeprlLjt
X-Received: by 10.107.136.164 with SMTP id s36mr76471882ioi.214.1481411546227;
Sat, 10 Dec 2016 15:12:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.36.224.199 with HTTP; Sat, 10 Dec 2016 15:12:25 -0800 (PST)
In-Reply-To: <CAGCNRJqdu7DMC+AMR4mYKRAYStRMKVGqbnjtEfmzcoeMij5u=A@mail.gmail.com>
References: <CAGCNRJqdu7DMC+AMR4mYKRAYStRMKVGqbnjtEfmzcoeMij5u=A@mail.gmail.com>
From: Bram Cohen <bram@bittorrent.com>
Date: Sat, 10 Dec 2016 15:12:25 -0800
Message-ID: <CA+KqGkq6soxt-SK4Liby5NE=QSt4-OTZ-FfsEd6qDGwvZpnpKQ@mail.gmail.com>
To: "t. khan" <teekhan42@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113eb2c2fabbcc054356004a
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Managing block size the same way we do difficulty
(aka Block75)
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: Sat, 10 Dec 2016 23:12:27 -0000
--001a113eb2c2fabbcc054356004a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Mon, Dec 5, 2016 at 7:27 AM, t. khan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Put another way: let=E2=80=99s stop thinking about what the max block siz=
e should
> be and start thinking about how full we want the average block to be
> regardless of size. Over the last year, we=E2=80=99ve had averages of 75%=
or
> higher, so aiming for 75% full seems reasonable, hence naming this concep=
t
> =E2=80=98Block75=E2=80=99.
>
That's effectively making the blocksize limit completely uncapped and only
preventing spikes, and even in the case of spikes it doesn't differentiate
between 'real' traffic and low value spam attacks. It suffers from the same
fundamental problems as bitcoin unlimited: There are in the end no
transaction fees, and inevitably some miners will want to impose some cap
on block size for practical purposes, resulting in a fork.
Difficulty adjustment works because there's a clear goal of having a
certain rate of making new blocks. Without a target to attempt automatic
adjustment makes no sense.
--001a113eb2c2fabbcc054356004a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Dec 5, 2016 at 7:27 AM, t. khan via bitcoin-dev <span dir=3D"ltr"><<=
a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b=
itcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div><div><br><div>Put another way: let=
=E2=80=99s stop thinking about what the max block size should be and start =
thinking about how full we want the average block to be regardless of size.=
Over the last year, we=E2=80=99ve had averages of 75% or higher, so aiming=
for 75% full seems reasonable, hence naming this concept =E2=80=98Block75=
=E2=80=99.<br></div></div></div></div></blockquote><div><br></div><div>That=
's effectively making the blocksize limit completely uncapped and only =
preventing spikes, and even in the case of spikes it doesn't differenti=
ate between 'real' traffic and low value spam attacks. It suffers f=
rom the same fundamental problems as bitcoin unlimited: There are in the en=
d no transaction fees, and inevitably some miners will want to impose some =
cap on block size for practical purposes, resulting in a fork.</div><div><b=
r></div><div>Difficulty adjustment works because there's a clear goal o=
f having a certain rate of making new blocks. Without a target to attempt a=
utomatic adjustment makes no sense.</div></div></div></div>
--001a113eb2c2fabbcc054356004a--
|
