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
|
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 D8C8F6C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 2 Jan 2017 19:32:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f179.google.com (mail-ua0-f179.google.com
[209.85.217.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 29D11192
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 2 Jan 2017 19:32:26 +0000 (UTC)
Received: by mail-ua0-f179.google.com with SMTP id 34so267653978uac.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 02 Jan 2017 11:32:26 -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=ani6j/nDXFwO+cTjEk6nDIdW2dusNrOqJlKsx2R8FVA=;
b=bgYiKPfIFrw96zz8OQ4SdKNiMqmuwAnyWSuiGy3cR3cDptfJSBWC6zdZVncuO11tHV
doM0WYPQh4tChbbYIw0mLUFyXxmBqNnX3Qs73PiwmhdtelFjuU6ZGK//PHW9/QGQGfzz
aJ48elKUTyb5sM39GKSSgxFQ83f8WWt080Xz5/kxkXhoPEdPEqRAn7NapVSohcSmp0cj
Antw70Grgj267QAo/PlB8WCCtL/6SftDWOZZCIdWHxn7Thl+MgW5ZaB1mLiH9shsWW6B
s1GUHKowu36nxXgOm8uJjgA+AtgdWNPbme02IC/+pF177fYuWEyYi+iS7m5PQWYrD5lw
aQhw==
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=ani6j/nDXFwO+cTjEk6nDIdW2dusNrOqJlKsx2R8FVA=;
b=XsVZBQgm3ANBlG7x5VjiE4aP1E7D1jGy7pEzklhuLGLrjDQYlduzHm2h5CD1hl5Tpm
DSPuKpIZNWq+ZtsxbgDiqD9w6dTrzvqPTAXJae5XasEJUk02brmDb5UoZIKcQ7lcyeVK
1oj39fUI9hY1VXv5PReqdEAtvwVhN5BHevIOhhGbq1MXpntB+mCR+3F2VHtpZMAq7Cvt
jGtO4UpU6izdPPOUEKiSmgO1+D5ObXubZLrrL6HsYpuCyHK73xErxFBlFnpEQVXAXqB2
JviKp2S0UrEN/G+cMvYY4nW71spJkABvCR+PZLodh576iZljM63wliPhtu4nychGwGJ7
yZHg==
X-Gm-Message-State: AIkVDXKAzhgp5kkrbhj0Td+WK7YT3sUBa4lcT+IXPJLkIZ+4M7lryiXLKihiaJKHc6XL9iuDPYaUXNvThvWm7w==
X-Received: by 10.176.7.215 with SMTP id d23mr45634948uaf.112.1483385545365;
Mon, 02 Jan 2017 11:32:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.49.144 with HTTP; Mon, 2 Jan 2017 11:32:24 -0800 (PST)
In-Reply-To: <2273244.fZU5ULDz4l@cherry>
References: <CAGCNRJoN7u3yvzitH2KSmVty-p0tX9jxWLHPb8uO5CPZmxmoRg@mail.gmail.com>
<2273244.fZU5ULDz4l@cherry>
From: "t. khan" <teekhan42@gmail.com>
Date: Mon, 2 Jan 2017 14:32:24 -0500
Message-ID: <CAGCNRJp71NCxQ3jk4hu-kXF94RiqfeD=AVnxR37TrJ7bDG310w@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=f403045f8ab47f1d270545219c4b
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
Subject: Re: [bitcoin-dev] BIP - 'Block75' - New algorithm
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: Mon, 02 Jan 2017 19:32:27 -0000
--f403045f8ab47f1d270545219c4b
Content-Type: text/plain; charset=UTF-8
Math should decide the max block size, not humans (miners in this
case). The goal of Block75 is to manage the max block size without any
human intervention.
Under Block75, miners don't have any direct control but could still choose
to mine smaller blocks (same as now), though doing so would cost them the
fees from transactions they didn't include in their blocks.
A maximum block size is necessary to prevent a single nefarious miner from
creating a ridiculously large block which would break the network.
- t.k.
On Mon, Jan 2, 2017 at 2:01 PM, Tom Zander <tomz@freedommail.ch> wrote:
> On Monday, 2 January 2017 13:04:37 CET t. khan via bitcoin-dev wrote:
> > Thoughts?
>
> This proposal doesn't change the block size, it only changes the maximum
> block size. Which is expected, nothing bad there.
>
> The direct consequence of this, though is that the miners set the maximum
> block size. Because they decide on the actual created block size.
>
> This leads me to the simple question why we can't just give the miners full
> control of the maximum block size directly?
>
> The fact of the matter is that miners have for the full history of Bitcoin
> been able to set the block size, until they hit the 1MB limit.
> And your proposal keeps that property, but why have a maximum in the
> protocol?
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
>
--f403045f8ab47f1d270545219c4b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Math should decide the max block size, not humans (miners =
in this case).=C2=A0The goal of Block75 is to manage the max block size wit=
hout any human intervention.<div><br></div><div>Under Block75, miners don&#=
39;t have any direct control but could still choose to mine smaller blocks =
(same as now), though doing so would cost them the fees from transactions t=
hey didn't include in their blocks.</div><div><div><br></div><div>A max=
imum block size is necessary to prevent a single nefarious miner from creat=
ing a ridiculously large block which would break the network.</div><div><br=
></div><div>- t.k.<br><div><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On Mon, Jan 2, 2017 at 2:01 PM, Tom Zander <span dir=3D"ltr"><=
<a href=3D"mailto:tomz@freedommail.ch" target=3D"_blank">tomz@freedommail.c=
h</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204=
);border-left-style:solid;padding-left:1ex">On Monday, 2 January 2017 13:04=
:37 CET t. khan via bitcoin-dev wrote:<br>
> Thoughts?<br>
<br>
This proposal doesn't change the block size, it only changes the maximu=
m<br>
block size. Which is expected, nothing bad there.<br>
<br>
The direct consequence of this, though is that the miners set the maximum<b=
r>
block size. Because they decide on the actual created block size.<br>
<br>
This leads me to the simple question why we can't just give the miners =
full<br>
control of the maximum block size directly?<br>
<br>
The fact of the matter is that miners have for the full history of Bitcoin<=
br>
been able to set the block size, until they hit the 1MB limit.<br>
And your proposal keeps that property, but why have a maximum in the<br>
protocol?<br>
<span class=3D"gmail-HOEnZb"><font color=3D"#888888">--<br>
Tom Zander<br>
Blog: <a href=3D"https://zander.github.io" rel=3D"noreferrer" target=3D"_bl=
ank">https://zander.github.io</a><br>
Vlog: <a href=3D"https://vimeo.com/channels/tomscryptochannel" rel=3D"noref=
errer" target=3D"_blank">https://vimeo.com/channels/<wbr>tomscryptochannel<=
/a><br>
</font></span></blockquote></div><br></div></div></div></div></div>
--f403045f8ab47f1d270545219c4b--
|
