summaryrefslogtreecommitdiff
path: root/94/5c84e2d2246dcb452f9f4a0c343441215f51e1
blob: 7a69039aabe7633ff6239d3763a616703f0878c1 (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
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 535B1514
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 11 Dec 2016 21:40:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com
	[209.85.213.44])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4B6431EF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 11 Dec 2016 21:40:23 +0000 (UTC)
Received: by mail-vk0-f44.google.com with SMTP id p9so32478030vkd.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 11 Dec 2016 13:40:23 -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=NemXYpi44/6JJlVCcAROZpqVbxf7JrQk7HJr9BCuc7Y=;
	b=imdpNFZO0WBbDPnYg+j+Q3t/7SAyGYLXHgDL9aXck9E6RCzBX0/xjU3gt6tEDjfjKr
	pmabLJ5DU9m3K25Edz+r0Xtk0A5IyfzOg6cQSzESQ2G8HYar1o2j8zf1fPy4leUT5XB3
	W7CJzI0nKc/0jB7DAfDdym3Q2FcpJo99zLInjK0GUZLgwYmzDzn5tqOilNCX+vAvgatD
	YFb3poRQQsL1SsRd4P4R+FDnl582q9jRa3MNqT5blBZptWpguVNgCqie4ZIv0IH3v+tQ
	QRMTA9zT62QNGQYvOgPIuzFuXGiUDjVov2I1WRRHH9Q62M45tsACHuQCfYDE7omvrNfh
	9X/Q==
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=NemXYpi44/6JJlVCcAROZpqVbxf7JrQk7HJr9BCuc7Y=;
	b=Q0BPVDms0TJ6aOLfOfXxeGDlGPyrOs75ujOMP/b4FUu0bJUNoO6is4V584espg3D57
	To7vnobGXg6ajUE8aSNQYTqvqpX2SYrODiMLuN92H8PRkarnSfaK/bZDPdNd1QRZXsYe
	OFTxd6E7etw40ngdtsV2Yfu8zQTH+KZbkYLe4k4EI/id7ftEmzCD+Nl4V0VvNxaB+Zj3
	4Wg7o4ScyG/NazUknToT7mtLV4V0Nvjy5BK/m/P1GnY+xFvjQRfsct5BfH9rBz7ezmOX
	N8vTwNR7Z4nfwx4aEdYNMjTwkCR9Ba3LzX1otYivsOsBkT95CWI/wQJSpnT2HLlqR/AV
	jB3A==
X-Gm-Message-State: AKaTC00EwnJwKN5kI7DDMFBrLr3k6f3okXqLk60AdJQB2QTXyO6fAR3l70dVq1ZPRKhG6SDvwjB6vkNBLiRAjw==
X-Received: by 10.31.14.206 with SMTP id 197mr34297633vko.38.1481492422422;
	Sun, 11 Dec 2016 13:40:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.49.144 with HTTP; Sun, 11 Dec 2016 13:40:21 -0800 (PST)
In-Reply-To: <CADvTj4rC6OyCFCwpExRdRF_ZVU_ONjtb3PycR3T_fkm6d=b_Wg@mail.gmail.com>
References: <CAGCNRJqdu7DMC+AMR4mYKRAYStRMKVGqbnjtEfmzcoeMij5u=A@mail.gmail.com>
	<c318f76d-0904-2e1b-453b-60179f8209bb@sky-ip.org>
	<CAGCNRJrLM2ZR9qCvuNfyr2mUk50szzHnG-crmpv_3cH=xGxYOg@mail.gmail.com>
	<d691b6f8-0c15-d293-0027-dcce145fbe8e@sky-ip.org>
	<CAGCNRJo_VE9nBhP=oY7hV0UJ-OSuTBxu+Tf28_utJW8qi7rzxg@mail.gmail.com>
	<CADvTj4rC6OyCFCwpExRdRF_ZVU_ONjtb3PycR3T_fkm6d=b_Wg@mail.gmail.com>
From: "t. khan" <teekhan42@gmail.com>
Date: Sun, 11 Dec 2016 16:40:21 -0500
Message-ID: <CAGCNRJqEVo6cMOLeENNue3=2mAHnWL2ViUKXVXAke_W0CXKKEg@mail.gmail.com>
To: James Hilliard <james.hilliard1@gmail.com>
Content-Type: multipart/alternative; boundary=001a11457f28937647054368d54c
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
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 21:40:24 -0000

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

On Sun, Dec 11, 2016 at 3:31 PM, James Hilliard <james.hilliard1@gmail.com>
wrote:

> What's most likely to happen is miners will max out the blocks they
> mine simply to try and get as many transaction fees as possible like
> they are doing right now(there will be a backlog of transactions at
> any block size). Having the block size double every year would likely
> cause major problems and this proposal allows over a 7x increase it
> seems.


Block75 is not exponential scaling. It's true the max theoretical increase
in the first year would be 7x, but the next year would be a max of 2x, and
the next could only increase by 50% and so on.

However, to reach the max in the first year: 1) ALL blocks would have to be
100% full and 2) transactions would have to increase at the same rate. We'd
have to be doing 2.1 million transactions a day within a year to make that
happen, and would therefore need blocks to be that big.

Realistically, max block size will grow (and shrink) at a much slower rate
... even more so with SegWit.


>  The main problem with this proposal I think is that users effectively

have no way to stop the miners from increasing block size
> continuously.


Yes they could, simply by not sending transactions. Users don't care at all
about block size. They just want their transactions to be fast and
relatively cheap.

-t.k.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra">On Sun, Dec 11, 2016 at 3:3=
1 PM, James Hilliard <span dir=3D"ltr">&lt;<a href=3D"mailto:james.hilliard=
1@gmail.com" target=3D"_blank">james.hilliard1@gmail.com</a>&gt;</span> wro=
te:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What&#39=
;s most likely to happen is miners will max out the blocks they<br>
mine simply to try and get as many transaction fees as possible like<br>
they are doing right now(there will be a backlog of transactions at<br>
any block size). Having the block size double every year would likely<br>
cause major problems and this proposal allows over a 7x increase it<br>
seems.</blockquote><div><br></div><div>Block75 is not exponential scaling. =
It&#39;s true the max theoretical increase in the first year would be 7x, b=
ut the next year would be a max of 2x, and the next could only increase by =
50% and so on.</div><div><br></div><div>However, to reach the max in the fi=
rst year: 1) ALL blocks would have to be 100% full and 2) transactions woul=
d have to increase at the same rate. We&#39;d have to be doing 2.1 million =
transactions a day within a year to make that happen, and would therefore n=
eed blocks to be that big.</div><div><br></div><div>Realistically, max bloc=
k size will grow (and shrink) at a much slower rate ... even more so with S=
egWit.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=C2=A0The main =
problem with this proposal I think is that users effectively</blockquote><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">
have no way to stop the miners from increasing block size<br>
continuously.</blockquote><div><br></div><div>Yes they could, simply by not=
 sending transactions. Users don&#39;t care at all about block size. They j=
ust want their transactions to be fast and relatively cheap.</div><div><br>=
</div><div>-t.k.</div></div></div></div>

--001a11457f28937647054368d54c--