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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <andyparkins@gmail.com>) id 1RTABM-0004W1-NZ
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Nov 2011 10:36:00 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.53 as permitted sender)
client-ip=74.125.82.53; envelope-from=andyparkins@gmail.com;
helo=mail-ww0-f53.google.com;
Received: from mail-ww0-f53.google.com ([74.125.82.53])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RTABL-00056V-Tb
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Nov 2011 10:36:00 +0000
Received: by wwf27 with SMTP id 27so1860064wwf.10
for <bitcoin-development@lists.sourceforge.net>;
Wed, 23 Nov 2011 02:35:51 -0800 (PST)
Received: by 10.216.134.209 with SMTP id s59mr4028130wei.62.1322044551526;
Wed, 23 Nov 2011 02:35:51 -0800 (PST)
Received: from dvr.localnet (mail.360visiontechnology.com. [92.42.121.178])
by mx.google.com with ESMTPS id co5sm8014859wib.8.2011.11.23.02.35.49
(version=TLSv1/SSLv3 cipher=OTHER);
Wed, 23 Nov 2011 02:35:50 -0800 (PST)
From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Date: Wed, 23 Nov 2011 10:35:42 +0000
User-Agent: KMail/1.13.6 (Linux/3.0.0-1-686-pae; KDE/4.6.3; i686; ; )
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1819154.H5s9Egm0ks";
protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201111231035.48690.andyparkins@gmail.com>
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(andyparkins[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1RTABL-00056V-Tb
Subject: [Bitcoin-development] Addressing rapid changes in mining power
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 23 Nov 2011 10:36:00 -0000
--nextPart1819154.H5s9Egm0ks
Content-Type: Text/Plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hello,
One problem with Bitcoin is that if large numbers of miners suddenly switch=
=20
off, the network takes a long time to adapt (since the adaption time is a=20
function of blocks generated, and the block generation rate has changed). =
The=20
same problem exists in the other direction, but an increased generation rat=
e=20
for a little while doesn't really do any harm.
I had this idea as a way of completely normalising the block generation rat=
e,=20
regardless of network power. I hesitate to offer it, as I get shouted down=
a=20
lot, but what the hell...
Let's imagine that the whole network shares a clock (which it does already)=
=2E =20
Let's abandon the idea of a target difficulty. Instead, every node just=20
generates the most difficulty block it can. Simultaneously, every node is=
=20
listening for "the most difficult block generated before time T"; with T be=
ing=20
picked to be the block generation rate (10 minutes).
Every node is therefore generating blocks and comparing not against some=20
moving average determined target, but rather against the most difficult=20
recently received block. If the generated block is harder than the receive=
d=20
block, then it gets broadcast.
Clearly, early on in the block, the traffic would be high, but that could b=
e=20
limited with a bit of intelligence -- there's no point broadcasting your be=
st=20
blocks in minute 0 of the current block... you know everyone will beat it, =
as=20
it was so easy. So the rule would be broadcasts only start at T/2 plus a=20
little randomisation. There wouldn't be that many because someone will hav=
e=20
generated a pretty good block by chance in the first half, and that will=20
quickly stop anybody else from bothering to broadcast their easier block. =
=20
There is no advantage to broadcasting a lesser block, so there is no incent=
ive=20
to cheat.
As always: the most difficult chain wins; and blocks with out-of-bounds tim=
es=20
are rejected regardless of difficulty. Everyone therefore has an incentive=
to=20
base their next block on the block with highest difficulty from the previou=
s=20
period.
The block period is now guaranteed to be 10 minutes (or in fact, whatever=20
period you like, there is no danger at all in changing it to 2 minutes); an=
d=20
there is no change of block generation rate with network power. Changes in=
=20
network power merely adjust the average difficulty of the best block per=20
period. The cost is higher network traffic, because there are block=20
broadcasts that don't necessarily make it to the end. However, there's no=
=20
need to broadcast the full block, only the header. If that block turns out=
to=20
be the winner, then the other nodes will request the full block at the end =
of=20
the period, and will check it's valid. If it's not then the next highest o=
n=20
the list will be requested. So again,=20
I recognise that this is a pretty large change to make; and so don't really=
=20
expect it to happen. Perhaps one day though... when all the wishlist items=
go=20
into one huge protocol overhaul.
Andy
=2D-=20
Dr Andy Parkins
andyparkins@gmail.com
--nextPart1819154.H5s9Egm0ks
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEABECAAYFAk7MzH8ACgkQwQJ9gE9xL234zgCg2Ccrm8EjKqKZ2awfa0p8SZ0x
vrEAni5jRq1RMnu1VT8E77gTd9ZBK62C
=w6Wf
-----END PGP SIGNATURE-----
--nextPart1819154.H5s9Egm0ks--
|
