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
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
|
Return-Path: <wardell.c@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5829A89D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Aug 2015 17:26:47 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yk0-f175.google.com (mail-yk0-f175.google.com
[209.85.160.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9B79515D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Aug 2015 17:26:46 +0000 (UTC)
Received: by ykfw73 with SMTP id w73so111922647ykf.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Aug 2015 10:26:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type; bh=7UOABCS7Alw+a/Z5rLbot+V06+kJJ4SqeChfscQv0XI=;
b=usXXQn/RqXnzSzl/ILSLElors6c0gq22Zy0p+puJoCMqs/B6eJ9rkSPr0+GzVuIuVn
bUzALrCL1wHf1CNxvCllQEXW4MBLEQyuOmrMG4moLzh4wAZCZEaVyjA8Jxfkl3+1AUZo
SB/wc/kr9S7Ei+Wg4l9MJhF8NvVzyHYeT2FvLzORlgC2hzv1nvo8DcJ9lTYvXAhUmNa4
rw6sc+HF3vVdSJE8QwuzSDuVoT2Ia4Pe2EYud8Eecy3Md6VgC19SPLrdW9z7ab/JcZlH
ENjUcB3S1fTsolyhgbe2C/xcPAp7zIf8i5yXNhMAtwzO5R0ruZWDqGnIyvF7jCObChSK
wtyg==
MIME-Version: 1.0
X-Received: by 10.129.81.194 with SMTP id f185mr8566209ywb.41.1439918805914;
Tue, 18 Aug 2015 10:26:45 -0700 (PDT)
Received: by 10.37.2.69 with HTTP; Tue, 18 Aug 2015 10:26:45 -0700 (PDT)
In-Reply-To: <CAED3CWgTOMFgaM6bBfU0Dn-R0NrdrhGAQo34wHEneYkTtB4Opg@mail.gmail.com>
References: <CAED3CWgTOMFgaM6bBfU0Dn-R0NrdrhGAQo34wHEneYkTtB4Opg@mail.gmail.com>
Date: Tue, 18 Aug 2015 13:26:45 -0400
Message-ID: <CAEieSeSw04FYCCa-Df+V6BgJo1RHqPvJWt9t=c-JCC=dnhraWA@mail.gmail.com>
From: Chris Wardell <wardell.c@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a11456cbcee9a35051d9938e6
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Tue, 18 Aug 2015 17:26:47 -0000
--001a11456cbcee9a35051d9938e6
Content-Type: text/plain; charset=UTF-8
I'm no authority on the subject, but I don't understand why there is a max
block-size, other than anti-spam measures.
The only other reason I have heard for a max-block-size is to force people
into paying higher fees.
This seems like the wrong way to force fees. If you want to force fees,
then do exactly that - make fees required, and set a minimum... don't force
people to pay fees by limiting transactions per second. That's like
shooting yourself in the foot to get free surgery....
On Tue, Aug 18, 2015 at 8:13 AM, Upal Chakraborty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Regarding:
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html
>
>
> I am arguing with the following statement here...
>
> *I see problems to this approach. The biggest one I see is that a miner
>> with 11% of hash power could sabotage block size increases by only ever
>> mining empty blocks.*
>
>
>
> First, I would like to argue from economics' point of view. If someone
> wants to hold back the block size increase with 11% hash power by mining
> empty blocks, he has to sacrifice Tx fees, which is not economical. 11%
> hash power will most likely be a pool and pool miners will find out soon
> that they are losing Tx fees because of pool owner's intention. Hence,
> they'll switch pool and pool owner will lose out. This is the same reason
> why 51% attack will never happen, even if a pool gets more than 51% hash
> power.
>
>
> Next, I would like to propose a slightly modified technical solution to
> this problem in algorithmic format...
>
> If more than 50% of block's size, found in the first 2000 of the last
> difficulty period, is more than 90% MaxBlockSize
> Double MaxBlockSize
> Else if more than 90% of block's size, found in the first 2000 of the last
> difficulty period, is less than 50% MaxBlockSize
> Half MaxBlockSize
> Else
> Keep the same MaxBlockSize
>
> This is how, those who want to stop increase, need to have more than 50%
> hash power. Those who want to stop decrease, need to have more than 10%
> hash power, but must mine more than 50% of MaxBlockSize in all blocks. In
> this approach, not only miners, but also the end user have their say.
> Because, end users will fill up the mempool, from where miners will take Tx
> to fill up the blocks. Please note that, taking first 2000 of the last 2016
> blocks is important to avoid data discrepancy among different nodes due to
> orphan blocks. It is assumed that a chain can not be orphaned after having
> 16 confirmation.
>
> Looking for comments.
>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a11456cbcee9a35051d9938e6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I'm no authority on the subject, but I don't =
understand why there is a max block-size, other than anti-spam measures.<br=
><br></div><div>The only other reason I have heard for a max-block-size is =
to force people into paying higher fees.<br><br>This seems like the wrong w=
ay to force fees.=C2=A0 If you want to force fees, then do exactly that - m=
ake fees required, and set a minimum... don't force people to pay fees =
by limiting transactions per second.=C2=A0 That's like shooting yoursel=
f in the foot to get free surgery....<br><br><br></div></div><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote">On Tue, Aug 18, 2015 at 8:13 AM=
, Upal Chakraborty via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:=
bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.=
linuxfoundation.org</a>></span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">Regarding:=C2=A0<a href=3D"http://lists.linuxfoundation.o=
rg/pipermail/bitcoin-dev/2015-August/010295.html" target=3D"_blank">http://=
lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html</a>=
<div><br><div><br></div><div>I am arguing with the following statement here=
...</div><div><br></div><div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2=
04);border-left-style:solid;padding-left:1ex"><i>I see problems to this app=
roach. The biggest one I see is that a miner with 11% of hash power could s=
abotage block size increases by only ever mining empty blocks.</i></blockqu=
ote><div><br></div><div><br></div><div>First, I would like to argue from ec=
onomics' point of view. If someone wants to hold back the block size in=
crease with 11% hash power by mining empty blocks, he has to sacrifice Tx f=
ees, which is not economical. 11% hash power will most likely be a pool and=
pool miners will find out soon that they are losing Tx fees because of poo=
l owner's intention. Hence, they'll switch pool and pool owner will=
lose out. This is the same reason why 51% attack will never happen, even i=
f a pool gets more than 51% hash power.</div></div></div><div><br></div><di=
v><br></div><div>Next, I would like to propose a slightly modified technica=
l solution to this problem in algorithmic format...</div><div><br></div><di=
v>If more than 50% of block's size, found in the first 2000 of the last=
difficulty period, is more than 90% MaxBlockSize</div><div>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0Double MaxBlockSize</div><div><div>Else if more than 90=
% of block's size, found in the first 2000 of the last difficulty perio=
d, is less than 50% MaxBlockSize</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Half MaxBlockSize</div></div><div>Else</div><div>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0Keep the same MaxBlockSize</div><div><br></div><div>This is ho=
w, those who want to stop increase, need to have more than 50% hash power. =
Those who want to stop decrease, need to have more than 10% hash power, but=
must mine more than 50% of MaxBlockSize in all blocks. In this approach, n=
ot only miners, but also the end user have their say. Because, end users wi=
ll fill up the mempool, from where miners will take Tx to fill up the block=
s. Please note that, taking first 2000 of the last 2016 blocks is important=
to avoid data discrepancy among different nodes due to orphan blocks. It i=
s assumed that a chain can not be orphaned after having 16 confirmation.</d=
iv><div><br></div><div>Looking for comments.</div><div><br></div><div><br><=
/div><div><br></div><div><br></div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>
--001a11456cbcee9a35051d9938e6--
|
