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
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
|
Return-Path: <cp@ows.fr>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id EB93F8A6
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Aug 2015 20:27:06 +0000 (UTC)
X-Greylist: delayed 00:42:31 by SQLgrey-1.7.6
Received: from moe.ows.fr (smtp.ows.fr [194.116.202.39])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 10B121C3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Aug 2015 20:27:05 +0000 (UTC)
Received: from 93-103-156-51.dynamic.t-2.net ([93.103.156.51]
helo=[192.168.1.239]) by moe.ows.fr with esmtpa (Exim 4.80)
(envelope-from <cp@ows.fr>) id 1ZRmo9-0000hA-Qc
for bitcoin-dev@lists.linuxfoundation.org;
Tue, 18 Aug 2015 21:44:30 +0200
Message-ID: <55D38B19.2090609@ows.fr>
Date: Tue, 18 Aug 2015 21:44:25 +0200
From: cedric perronnet <cp@ows.fr>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: bitcoin-dev@lists.linuxfoundation.org
References: <CAED3CWgTOMFgaM6bBfU0Dn-R0NrdrhGAQo34wHEneYkTtB4Opg@mail.gmail.com>
In-Reply-To: <CAED3CWgTOMFgaM6bBfU0Dn-R0NrdrhGAQo34wHEneYkTtB4Opg@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------010804030508030306040108"
X-SA-Exim-Connect-IP: 93.103.156.51
X-SA-Exim-Mail-From: cp@ows.fr
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,HTML_MESSAGE,
RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:57:07 +0000)
X-SA-Exim-Scanned: Yes (on moe.ows.fr)
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 20:27:07 -0000
This is a multi-part message in MIME format.
--------------010804030508030306040108
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Sounds like a much better approach than arbitrary deciding what the
block size should be
BR
Le 18/08/2015 14:13, Upal Chakraborty via bitcoin-dev a écrit :
> 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
--------------010804030508030306040108
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Sounds like a much better approach than arbitrary deciding what the
block size should be<br>
BR<br>
<br>
<div class="moz-cite-prefix">Le 18/08/2015 14:13, Upal Chakraborty
via bitcoin-dev a écrit :<br>
</div>
<blockquote
cite="mid:CAED3CWgTOMFgaM6bBfU0Dn-R0NrdrhGAQo34wHEneYkTtB4Opg@mail.gmail.com"
type="cite">
<div dir="ltr">Regarding: <a moz-do-not-send="true"
href="http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html">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="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><i>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.</i></blockquote>
<div><br>
</div>
<div><br>
</div>
<div>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.</div>
</div>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Next, I would like to propose a slightly modified technical
solution to this problem in algorithmic format...</div>
<div><br>
</div>
<div>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> Double MaxBlockSize</div>
<div>
<div>Else if more than 90% of block's size, found in the first
2000 of the last difficulty period, is less than 50%
MaxBlockSize</div>
<div> Half MaxBlockSize</div>
</div>
<div>Else</div>
<div> Keep the same MaxBlockSize</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Looking for comments.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------010804030508030306040108--
|
