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
159
160
161
162
163
164
|
Return-Path: <s7r@sky-ip.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 194D05A7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 11 Dec 2016 17:11:52 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from ob3-6.mailhostbox.com (ob3-6.mailhostbox.com [162.222.225.28])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0201723B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 11 Dec 2016 17:11:42 +0000 (UTC)
Received: from [0.0.0.0] (unknown [188.214.129.85])
(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
(Authenticated sender: s7r@sky-ip.org)
by outbound.mailhostbox.com (Postfix) with ESMTPSA id 45BB73604A9;
Sun, 11 Dec 2016 17:11:38 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sky-ip.org;
s=20110108; t=1481476300;
bh=4YOhrX3soz0GIczaAX5aFQrDdbqH+/y8Dc3PFPS8GRs=;
h=Reply-To:Subject:References:To:From:Date:In-Reply-To;
b=iyjxU10qX1J8p4ueghfeVpOR/yvm3zZ7p1LVJ9LqrBx/fdlhojPFH+ZTYJRwt8uGm
XhdiDXWFVBoLFjf2jgeoj7BbetRws9dBG5D0Xdavfa/SaMGcEz8MdUf0f4KoqV6yBX
l02TMaMoOcybwiMjzp6L7tc1Xtp/8eiEW+lqr1DY=
Reply-To: s7r@sky-ip.org
References: <CAGCNRJqdu7DMC+AMR4mYKRAYStRMKVGqbnjtEfmzcoeMij5u=A@mail.gmail.com>
<c318f76d-0904-2e1b-453b-60179f8209bb@sky-ip.org>
<CAGCNRJrLM2ZR9qCvuNfyr2mUk50szzHnG-crmpv_3cH=xGxYOg@mail.gmail.com>
To: "t. khan" <teekhan42@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: s7r <s7r@sky-ip.org>
Message-ID: <d691b6f8-0c15-d293-0027-dcce145fbe8e@sky-ip.org>
Date: Sun, 11 Dec 2016 19:11:10 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <CAGCNRJrLM2ZR9qCvuNfyr2mUk50szzHnG-crmpv_3cH=xGxYOg@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature";
boundary="ov6uSsME7bK2q9w5Wv6lEcX2hhT3sg0c7"
X-CMAE-Score: 0
X-CMAE-Analysis: v=2.1 cv=X4TyUDne c=1 sm=1 tr=0
a=dfow1bEn5MXyeC3yr4e2EQ==:117 a=dfow1bEn5MXyeC3yr4e2EQ==:17
a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10
a=13zjGPudsaEWiJwPRgMA:9 a=WbPmnYzAfxEA:10 a=5TDocmF06BmBDxw5PtEA:9
a=QEXdDO2ut3YA:10 a=XWp6eR1vF2W28LyIkrcA:9
X-Scanned-By: MIMEDefang 2.72 on 172.18.214.93
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,URIBL_BLACK 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: Sun, 11 Dec 2016 17:11:52 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--ov6uSsME7bK2q9w5Wv6lEcX2hhT3sg0c7
Content-Type: multipart/mixed; boundary="fT9s2cAmDuw6tH44n1A79Tbh86PgECAGJ";
protected-headers="v1"
From: s7r <s7r@sky-ip.org>
Reply-To: s7r@sky-ip.org
To: "t. khan" <teekhan42@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <d691b6f8-0c15-d293-0027-dcce145fbe8e@sky-ip.org>
Subject: Re: [bitcoin-dev] Managing block size the same way we do difficulty
(aka Block75)
References: <CAGCNRJqdu7DMC+AMR4mYKRAYStRMKVGqbnjtEfmzcoeMij5u=A@mail.gmail.com>
<c318f76d-0904-2e1b-453b-60179f8209bb@sky-ip.org>
<CAGCNRJrLM2ZR9qCvuNfyr2mUk50szzHnG-crmpv_3cH=xGxYOg@mail.gmail.com>
In-Reply-To: <CAGCNRJrLM2ZR9qCvuNfyr2mUk50szzHnG-crmpv_3cH=xGxYOg@mail.gmail.com>
--fT9s2cAmDuw6tH44n1A79Tbh86PgECAGJ
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
t. khan wrote:
> Miners 'gaming' the Block75 system -=20
> There is no financial incentive for miners to attempt to game the
> Block75 system. Even if it were attempted and assuming the goal was to
> create bigger blocks, the maximum possible increase would be 25% over
> the previous block size. And, that size would only last for two weeks
> before readjusting down. It would cost them more in transaction fees to=
> stuff the network than they could ever make up. To game the system,
> they'd have to game it forever with no possibility of profit.
>=20
This is an incentive, if few miners agree to create a large conglomerate
that will ultimately control the network.
You miss something obvious that makes this attack actually free of cost.
Nothing will "cost them more in transaction fees". A miner can create
thousands of transactions paying to himself, and not broadcast them to
the network, but hold them and include them in the blocks he mines. The
fees are collected by him because transactions are included in a block
that he mined and the left amount is in another wallet of the same
person. Repeat this continuously to fill blocks.
> Blocks would get too big -=20
> Eventually, blocks would get too big, but only if bandwidth stopped
> increasing and the cost of disk space stopped decreasing. Otherwise, th=
e
> incremental adjustments made by Block75 (especially in combination with=
> SegWit) wouldn't break anyone's connection or result in significantly
> more orphaned blocks.
>=20
Topology and bandwidth speed / hash rate of the network cannot be
controlled - if we make assumptions about these it might have terrible
consequences.
Even if we take in consideration that bandwidth will only grow and disk
space will only cost less (which is not something we can safely assume,
by the way) the hard limit max. block size cannot grow to unlimited
value (even if the growth happens over time). There is also a validation
cost in time for each block, for the health of the network any node
should be able to download _and_ validate a block, before next block
gets mined.
You said in another post that a permanent solution is preferred, rather
than kicking the can down the road. I fully agree, as well as many
others reading this list, but the permanent solution doesn't necessarily
have to be increasing the max block size dynamically.
If you think about it the other way around, dynamically growing the max
block size is also kicking the can down the road ... just without having
to touch it and get dust on the boot ;)
--fT9s2cAmDuw6tH44n1A79Tbh86PgECAGJ--
--ov6uSsME7bK2q9w5Wv6lEcX2hhT3sg0c7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBCAAGBQJYTYi7AAoJEIN/pSyBJlsRgd8H/jSULp50dLHHXxUJ0TAp9Gvw
HXzuz40cvf8bvP0/slKdQwNCqMmsUHOWHLB8EIvBVtKlCXUXytvC8uQ1ge97ASeU
PJTim2KUOnfh1YWe6ADtdLE4h1coyaPXBey06IrfHQBwKMjUWQn3NUPpAKgUR2ft
/Kw33q/7kZuA6Tno0W4DGhm8j5oBA1LHM5VbA2lOGK7IKSPs7be3dZKaJjnOS0LB
XUXBG5oRTrigWrdlJp/GkwC4PyyBRqzCdtflshZHQLXvG4lin/ZIQ9Xxdlyt2/Fu
dtOqZTafVvOSnQzhcGyR5gh2oybl9ekzp1bM+DltYoj8czFf+DD2jaPlUjg82HA=
=l4f1
-----END PGP SIGNATURE-----
--ov6uSsME7bK2q9w5Wv6lEcX2hhT3sg0c7--
|
