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
|
Return-Path: <maveric.all@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 512988DD
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Aug 2015 23:52:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com
[209.85.220.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B3661173
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Aug 2015 23:52:42 +0000 (UTC)
Received: by qkdv3 with SMTP id v3so32153358qkd.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 06 Aug 2015 16:52:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:from:date:message-id:subject:to:content-type;
bh=/i3OvpZvLKKKGPZaVbLEnxjrJ3eRTeQqJ+Re/7AqxEU=;
b=MqPZ/gOmGu13ahpCI/Rnd6EVqmZcsU6MN0ZDdi+iCIicK7j9IFpbtBViiFuoAYXde4
XsWL6DB1xEW1pkWu7MdKpLn0OyxiZnUJ4k36X3XFABooB6qiawyEqfZtsknbDlydhTgJ
cHzJrOm4mG6Vj4Y2cEV8pzXBrSduJINrd53//+a+Mo+zt8m+URcmUEj1HYHqb/k2yDln
1LOCz3y+/NEXam7x/y0SCEn3+7Vq+3Xafc2vNx/2l13jSEMCwGieS4JHupk2JMz8VnS5
+SMgc28+fZS6+s97/0jXGMknMpQN6zlupHWI6s0jVczDLyYtxmAOV5MAIT5MgAW0tiEM
utlg==
X-Received: by 10.55.17.168 with SMTP id 40mr7620273qkr.83.1438905161794; Thu,
06 Aug 2015 16:52:41 -0700 (PDT)
MIME-Version: 1.0
From: Wes Green <maveric100@gmail.com>
Date: Thu, 06 Aug 2015 23:52:32 +0000
Message-ID: <CAOvA3_hhzWqX0k7xbua=qFptb90fkbCU-WDMih4=mX+kRrWG1g@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a1136ea6608c971051cad373f
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_20,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: [bitcoin-dev] Block size implementation using Game Theory
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: Thu, 06 Aug 2015 23:52:43 -0000
--001a1136ea6608c971051cad373f
Content-Type: text/plain; charset=UTF-8
Bitcoin is built on game theory. Somehow we seem to have forgotten that and
are trying to fix our "block size issue" with magic numbers, projected
percentage growth of bandwidth speeds, time limits, etc... There are
instances where these types of solutions make sense, but this doesn't
appear to be one of them. Lets return to game theory.
Proposal: Allow any miner to, up to, double the block size at any given
time - but penalize them. Using the normal block reward, whatever
percentage increase the miner makes over the previous limit is taken from
both the normal reward and fees. The left over is rewarded to the next
miner that finds a block.
If blocks stay smaller for an extended period of time, it goes back down to
the previous limit/ x amount decrease/% decrease (up for debate)
Why would this work?: Miners only have incentive to do raise the limit when
they feel there is organic growth in the network. Spam attacks, block bloat
etc would have to be dealt with as it is currently. There is no incentive
to raise the size for spam because it will subside and the penalty will
have been for nothing when the attack ends and block size goes back down.
I believe it would have the nice side effect of forcing miners to hold the
whole block chain. I believe SPV does not allow you to see all the
transactions in a block and be able to calculate if you should be adding
more to your reward transaction if the last miner made the blocks bigger.
Because of this, the miners would also have an eye on blockchain size and
wont want it getting huge too fast (outsize of Moore's law of Nielsen's
Law). Adding to the gamification.
This system would encourage block size growth due to organic growth and the
penalty would encourage it to be slow as to still keep reward high and
preserve ROE.
What this would look like: The miners start seeing what looks like natural
network growth, and make the decision (or program an algorithm, the beauty
is it leaves the "how" up to the miners) to increase the blocksize. They
think that, in the long run, having larger blocks will increase their
revenue and its worth taking the hit now for more fees later. They increase
the size to 1.25 MB. As a result, they reward would be 18.75 (75%). The
miner fees were .5BTC. The miner fees are also reduced to .375BTC. Everyone
who receives that block can easily calculate 1) if the previous miner gave
themselves the proper reward 2) what the next reward should be if they win
it. Miners now start building blocks with a 31.25 reward transaction and
miner fee + .125.
--001a1136ea6608c971051cad373f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><p style=3D"margin:0px 0px 0.357142857142857em;padding:1px=
0px;font-size:14px;line-height:1.3em;font-family:Verdana,arial,sans-serif;=
color:rgb(34,34,34)">Bitcoin is built on game theory. Somehow we seem to ha=
ve forgotten that and are trying to fix our "block size issue" wi=
th magic numbers, projected percentage growth of bandwidth speeds, time lim=
its, etc... There are instances where these types of solutions make sense, =
but this doesn't appear to be one of them. Lets return to game theory.<=
/p><p style=3D"margin:0.357142857142857em 0px;padding:1px 0px;font-size:14p=
x;line-height:1.3em;font-family:Verdana,arial,sans-serif;color:rgb(34,34,34=
)">Proposal: Allow any miner to, up to, double the block size at any given =
time - but penalize them. Using the normal block reward, whatever percentag=
e increase the miner makes over the previous limit is taken from both the n=
ormal reward and fees. The left over is rewarded to the next miner that fin=
ds a block.</p><p style=3D"margin:0.357142857142857em 0px;padding:1px 0px;f=
ont-size:14px;line-height:1.3em;font-family:Verdana,arial,sans-serif;color:=
rgb(34,34,34)">If blocks stay smaller for an extended period of time, it go=
es back down to the previous limit/ x amount decrease/% decrease =C2=A0(up =
for debate)</p><p style=3D"margin:0.357142857142857em 0px;padding:1px 0px;f=
ont-size:14px;line-height:1.3em;font-family:Verdana,arial,sans-serif;color:=
rgb(34,34,34)">Why would this work?: Miners only have incentive to do raise=
the limit when they feel there is organic growth in the network. Spam atta=
cks, block bloat etc would have to be dealt with as it is currently. There =
is no incentive to raise the size for spam because it will subside and the =
penalty will have been for nothing when the attack ends and block size goes=
back down.=C2=A0</p><p style=3D"margin:0.357142857142857em 0px;padding:1px=
0px;font-size:14px;line-height:1.3em;font-family:Verdana,arial,sans-serif;=
color:rgb(34,34,34)">I believe it would have the nice side effect of forcin=
g miners to hold the whole block chain. I believe SPV does not allow you to=
see all the transactions in a block and be able to calculate if you should=
be adding more to your reward transaction if the last miner made the block=
s bigger. Because of this, the miners would also have an eye on blockchain =
size and wont want it getting huge too fast (outsize of Moore's law of =
Nielsen's Law). Adding to the gamification.</p><p style=3D"margin:0.357=
142857142857em 0px;padding:1px 0px;font-size:14px;line-height:1.3em;font-fa=
mily:Verdana,arial,sans-serif;color:rgb(34,34,34)">This system would encour=
age block size growth due to organic growth and the penalty would encourage=
it to be slow as to still keep reward high and preserve ROE.</p><p style=
=3D"margin:0.357142857142857em 0px;padding:1px 0px;font-size:14px;line-heig=
ht:1.3em;font-family:Verdana,arial,sans-serif;color:rgb(34,34,34)">What thi=
s would look like: The miners start seeing what looks like natural network =
growth, and make the decision (or program an algorithm, the beauty is it le=
aves the "how" up to the miners) to increase the blocksize. They =
think that, in the long run, having larger blocks will increase their reven=
ue and its worth taking the hit now for more fees later. They increase the =
size to 1.25 MB. As a result, they reward would be 18.75 (75%). The miner f=
ees were .5BTC. The miner fees are also reduced to .375BTC. Everyone who re=
ceives that block can easily calculate 1) if the previous miner gave themse=
lves the proper reward 2) what the next reward should be if they win it. Mi=
ners now start building blocks with a 31.25 reward transaction and miner fe=
e + .125.</p><p style=3D"margin:0.357142857142857em 0px;padding:1px 0px;fon=
t-size:14px;line-height:1.3em;font-family:Verdana,arial,sans-serif;color:rg=
b(34,34,34)"><br></p></div>
--001a1136ea6608c971051cad373f--
|
