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: <teekhan42@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7601640D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 11 Dec 2016 00:53:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com
[209.85.213.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C35C814B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 11 Dec 2016 00:52:59 +0000 (UTC)
Received: by mail-vk0-f53.google.com with SMTP id p9so26074311vkd.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 10 Dec 2016 16:52:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=ukPpIi6SxnU6sC36T+VIwjHQhH6odsFNesHU6DBUGeU=;
b=LLMstDGIGL41+M1O7Yoywo0Vduo0ZFJz9c4EZw/Dd/xnv8DpHHD/dGnVvi15tidyhA
0/eogc/dDFbrqKkUaAIiTK2ERsv82pKiB6GH35LZzU761XxmTJnrPv11NmAHbfZy2NoI
kO5N3xMAFERSgHfN/+iGA2sPUKH2x1CsJ1LfVW3fn1KLrHeiPo0c6I+5FPn/zEjLTONb
jFVX0ZNiW4MRH2fem71ZS22sZ4zNrWoZ1geL9tY/bwrgIdRdirKT68RPgOr1TtKExLin
scB8vOdtPQQ47AZkg+XQ7RqLvczXNe01YdUBXvKqfiDtNX3F1uCe1XqDOeubB/yOoGxM
I9hw==
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;
bh=ukPpIi6SxnU6sC36T+VIwjHQhH6odsFNesHU6DBUGeU=;
b=Fb0baVhT9r+8eQog3L8EBXrTvCVu+j2DcSwPkZXYfGhy2E3qhlZnG8lBuol+gW6Ors
fir0TRQJRp5qiWTExHPf47mmTyzoPVtjRCwR5h4pfrReFobcN5xkiUnpg1q9E0jv9Ds3
x/aXt2u1ZctNc5JZuEh271U3Y7KIllp3FI9j3KrJqsiLAovF8XfcXIzP+HUch55kkZkl
btcNKFSALVRs+bMBgcjML96U/ntdeFiqy1zFjWHkr9FIYOuIQ/L4qjaz/vpUF7o/QJGL
UXVqRY73v771D9F6tik+JwSOk5aYSY6dvofWm6NSQOizKGT9zlUN7rtQaTsSUI4vxHJw
dExw==
X-Gm-Message-State: AKaTC033H2ZSmw/fPgb+aPmtKoz6O59zvYSmRJ1Q/cshNqhtb600JsBVchfjpxItqDrTE9NjhMycL5xAJ8zyOQ==
X-Received: by 10.31.65.3 with SMTP id o3mr28021133vka.3.1481417578998; Sat,
10 Dec 2016 16:52:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.49.144 with HTTP; Sat, 10 Dec 2016 16:52:58 -0800 (PST)
In-Reply-To: <CA+KqGkq6soxt-SK4Liby5NE=QSt4-OTZ-FfsEd6qDGwvZpnpKQ@mail.gmail.com>
References: <CAGCNRJqdu7DMC+AMR4mYKRAYStRMKVGqbnjtEfmzcoeMij5u=A@mail.gmail.com>
<CA+KqGkq6soxt-SK4Liby5NE=QSt4-OTZ-FfsEd6qDGwvZpnpKQ@mail.gmail.com>
From: "t. khan" <teekhan42@gmail.com>
Date: Sat, 10 Dec 2016 19:52:58 -0500
Message-ID: <CAGCNRJr+q-G_sA16tL56GHVsHC8M3JDohfRFeB3uxB6ts5n5ng@mail.gmail.com>
To: Bram Cohen <bram@bittorrent.com>
Content-Type: multipart/alternative; boundary=001a114dd3f48f731e0543576803
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 11 Dec 2016 00:53:50 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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: Sun, 11 Dec 2016 00:53:00 -0000
--001a114dd3f48f731e0543576803
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Agreed, the clear goal of 10 minutes per block is why the difficulty
adjustment works well. Blocks averaging 75% full is the clear goal of the
described method. That's the target to attempt.
Under Block75, there will still be full blocks. There will still be
transaction fees and a fee market. The fees will be lower than they are now
of course.
Hardcoding a cap will inevitably become a roadblock (again), and we'll be
back in the same position as we are now. Permanent solutions are preferred.
On Sat, Dec 10, 2016 at 6:12 PM, Bram Cohen <bram@bittorrent.com> wrote:
> 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 si=
ze 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 conce=
pt
>> =E2=80=98Block75=E2=80=99.
>>
>
> That's effectively making the blocksize limit completely uncapped and onl=
y
> preventing spikes, and even in the case of spikes it doesn't differentiat=
e
> between 'real' traffic and low value spam attacks. It suffers from the sa=
me
> 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.
>
--001a114dd3f48f731e0543576803
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Agreed, the clear goal of 10 minutes per block is why the =
difficulty adjustment works well. Blocks averaging 75% full is the clear go=
al of the described method. That's the target to attempt.<div><br></div=
><div>Under Block75, there will still be full blocks.=C2=A0There will still=
be transaction fees and a fee market. The fees will be lower than they are=
now of course.</div><div><br></div><div>Hardcoding a cap will inevitably b=
ecome a roadblock (again), and we'll be back in the same position as we=
are now. Permanent solutions are preferred.<br><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">On Sat, Dec 10, 2016 at 6:12 PM, Bram Cohen =
<span dir=3D"ltr"><<a href=3D"mailto:bram@bittorrent.com" target=3D"_bla=
nk">bram@bittorrent.com</a>></span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span>On Mon=
, 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">bit=
coin-dev@lists.linuxfounda<wbr>tion.org</a>></span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width=
:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div><div><br><div>Put another way: let=E2=80=99s s=
top thinking about what the max block size should be and start thinking abo=
ut how full we want the average block to be regardless of size. Over the la=
st year, we=E2=80=99ve had averages of 75% or higher, so aiming for 75% ful=
l seems reasonable, hence naming this concept =E2=80=98Block75=E2=80=99.<br=
></div></div></div></div></blockquote><div><br></div></span><div>That's=
effectively making the blocksize limit completely uncapped and only preven=
ting spikes, and even in the case of spikes it doesn't differentiate be=
tween 'real' traffic and low value spam attacks. It suffers from th=
e same fundamental problems as bitcoin unlimited: There are in the end no t=
ransaction fees, and inevitably some miners will want to impose some cap on=
block size for practical purposes, resulting in a fork.</div><div><br></di=
v><div>Difficulty adjustment works because there's a clear goal of havi=
ng a certain rate of making new blocks. Without a target to attempt automat=
ic adjustment makes no sense.</div></div></div></div>
</blockquote></div><br></div></div></div>
--001a114dd3f48f731e0543576803--
|
