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
|
Return-Path: <bitcoin@upalc.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D47587AA
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Aug 2015 12:13:49 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com
[209.85.213.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3621819A
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Aug 2015 12:13:49 +0000 (UTC)
Received: by igui7 with SMTP id i7so77976116igu.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Aug 2015 05:13:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:date:message-id:subject:from:to
:content-type;
bh=q8vHawa9zkylTkYO17U8B9vdf4nB4dZF0vG4OeZAhEY=;
b=N2A4id6dxnxO0Y83zMOCnphlYoPLQMDZxAXDHByc9l++c+YWwv32CnLWIFUjHOWL+Z
uVL38NSTFf2x8ieT4J6/TgFA0qViByn8gZ68/iF10OBt2z1/jFuLOJSMukovFFQU7SFV
4RSdbTg4gT6HhzWj7gWt0MeH2g2ft8igGDfueYQ5agAqwfBLx/mtY0YuIEfoEiDalV7m
e6GN0VlBxtjswKknOIFlnEK5ezLBP/QcAcIxyLvpQUomf7ACNjXAT01Hg04QnVPPIF9P
/oOoVQ5KDCn8s/L7W78Zi3ZMnrSzIiFRbU4LlhV9LrpcAcxdzp/pX0nw7boV2djp0nQU
v8aA==
X-Gm-Message-State: ALoCoQkCL4QHv/7WAOmlH2NQezI7Q8ohmBHSD/GpxEaOnQA1/mxAsupGkBYMOqkbIVAbDFkVwDyL
MIME-Version: 1.0
X-Received: by 10.50.79.202 with SMTP id l10mr20670247igx.7.1439900028572;
Tue, 18 Aug 2015 05:13:48 -0700 (PDT)
Received: by 10.107.18.155 with HTTP; Tue, 18 Aug 2015 05:13:48 -0700 (PDT)
X-Originating-IP: [203.171.245.240]
Date: Tue, 18 Aug 2015 17:43:48 +0530
Message-ID: <CAED3CWgTOMFgaM6bBfU0Dn-R0NrdrhGAQo34wHEneYkTtB4Opg@mail.gmail.com>
From: Upal Chakraborty <bitcoin@upalc.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=089e0122aaeeb73789051d94d92d
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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: [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 12:13:49 -0000
--089e0122aaeeb73789051d94d92d
Content-Type: text/plain; charset=UTF-8
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.
--089e0122aaeeb73789051d94d92d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Regarding:=C2=A0<a href=3D"http://lists.linuxfoundation.or=
g/pipermail/bitcoin-dev/2015-August/010295.html">http://lists.linuxfoundati=
on.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"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty=
le: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% has=
h power by mining empty blocks, he has to sacrifice Tx fees, which is not e=
conomical. 11% hash power will most likely be a pool and pool miners will f=
ind out soon that they are losing Tx fees because of pool owner's inten=
tion. 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>Ne=
xt, 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>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
Double MaxBlockSize</div><div><div>Else if more than 90% of block's siz=
e, found in the first 2000 of the last difficulty period, 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 s=
ame MaxBlockSize</div><div><br></div><div>This is how, those who want to st=
op 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 als=
o 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, ta=
king first 2000 of the last 2016 blocks is important to avoid data discrepa=
ncy 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><di=
v><br></div></div>
--089e0122aaeeb73789051d94d92d--
|
