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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <andyparkins@gmail.com>) id 1RTCdn-0001ti-OG
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Nov 2011 13:13:31 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.47 as permitted sender)
client-ip=209.85.214.47; envelope-from=andyparkins@gmail.com;
helo=mail-bw0-f47.google.com;
Received: from mail-bw0-f47.google.com ([209.85.214.47])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RTCdk-0003X7-0F
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Nov 2011 13:13:31 +0000
Received: by bkbzs2 with SMTP id zs2so1582875bkb.34
for <bitcoin-development@lists.sourceforge.net>;
Wed, 23 Nov 2011 05:13:21 -0800 (PST)
Received: by 10.204.154.1 with SMTP id m1mr24009362bkw.107.1322054001645;
Wed, 23 Nov 2011 05:13:21 -0800 (PST)
Received: from dvr.localnet (mail.360visiontechnology.com. [92.42.121.178])
by mx.google.com with ESMTPS id f14sm12840279bkv.3.2011.11.23.05.13.13
(version=TLSv1/SSLv3 cipher=OTHER);
Wed, 23 Nov 2011 05:13:17 -0800 (PST)
From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Date: Wed, 23 Nov 2011 13:13:12 +0000
User-Agent: KMail/1.13.6 (Linux/3.0.0-1-686-pae; KDE/4.6.3; i686; ; )
References: <201111231035.48690.andyparkins@gmail.com>
<CAGQP0AEZ9CUNd9ERyMsx741bqjLptY4pPRU6EmxQcD7kR8bdbw@mail.gmail.com>
<CALxbBHVEvCqun0aX_9awGhW39h5cx0jLPx2ptoesBcmKGO-_Dw@mail.gmail.com>
In-Reply-To: <CALxbBHVEvCqun0aX_9awGhW39h5cx0jLPx2ptoesBcmKGO-_Dw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1771003.jepphUgMgD";
protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201111231313.12534.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
0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RTCdk-0003X7-0F
Subject: Re: [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 13:13:31 -0000
--nextPart1771003.jepphUgMgD
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
On 2011 November 23 Wednesday, Christian Decker wrote:
> The current block generation with a fixed difficulty was chosen because it
> it clear when to adjust and to what target difficulty it has to be
> adjusted. If we were to use synchronized time windows and select the
> hardest block it gets incredibly complicated as synchronization is not
> possible in distributed systems. Even the smallest drift would allow for
> forks in the chain all over the place. Furthermore the delay in propagati=
on
> will also cause forks.
>=20
> If 1/2 of the network see one block as the hardest, and for the rest of t=
he
> network it came too late then we'll have a fork that stays with us quite a
> while.
>=20
> The block chain is described as a timestamp server in the paper, but it is
> more of a proof-of-existence before, as the contained timestamp cannot be
> trusted anyway.
These are reasonable objections. My counter is this:
Let's view block difficulty as a measure of time, not time itself. The=20
timestamp is merely a convenience for the block. You cannot fake the=20
computing power needed for a particular difficulty; so the hardest chain=20
always wins (note: hardest chain).
If I am a miner, I have two choices:
(a) try to replace the top block on the current hardest chain
(b) try to append to the current hardest chain
Either of these is acceptable; but in case (a) I have to generate a more=20
difficult block to replace it; in case (b), at the start of the window, any=
=20
difficulty is acceptable (however, I'm competing with other miners, so _any=
_=20
difficulty won't beat them).
The rule then is that you're trying to win the one block reward that is=20
available every 10 minutes; and your peers will be rejecting blocks with=20
timestamps that are lies.
Perhaps an example...
- I (a node), download the blockchain
- The blockchain has N potential heads. Each of those heads has a time, t
and a sum_of_difficulty.
- The next block reward is going to go to the highest difficulty with
t < timestamp < (t + T) _and_ verified timestamp (i.e. not received more
than, say 5 minutes, from its claimed timestamp).
- I can choose any head to start generating from, but given that it's the
highest difficulty chain that's going to win the next reward (not the=20
highest difficulty block), I will surely pick the most difficult?
- A rogue miner then issues a block with a fake timestamp; it actually
generated at (t + T + 5) but claims (t + 5). Should I start using
that block as my new head? Obviously not, because my peers might decide
that it is a lie and reject it because it was received too late, making =
my
work useless. It is in my interest to pick a head that is honest.
Resolving forks is easy:
- 50 coins every ten minutes only
- most difficult chain wins
I'm certainly not saying it's a simple change. There are certainly areas I=
=20
haven't thought about, and could be game-overs; but I do like the idea of=20
there being no target difficulty, and instead the blocks are issued at a fi=
xed=20
ten minute rate (or rather the rewards are).
Andy
=2D-=20
Dr Andy Parkins
andyparkins@gmail.com
--nextPart1771003.jepphUgMgD
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)
iEYEABECAAYFAk7M8WgACgkQwQJ9gE9xL23jUwCeMGn+f43h9T9S9D8eWD1GpgUL
WacAniocPuMKKHd/dH3stLrPyQK5Sc41
=Th78
-----END PGP SIGNATURE-----
--nextPart1771003.jepphUgMgD--
|
