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
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <decker.christian@gmail.com>) id 1RTBfz-00007b-NH
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Nov 2011 12:11:43 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.161.47 as permitted sender)
client-ip=209.85.161.47;
envelope-from=decker.christian@gmail.com;
helo=mail-fx0-f47.google.com;
Received: from mail-fx0-f47.google.com ([209.85.161.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RTBfy-0000eW-DW
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Nov 2011 12:11:43 +0000
Received: by faat2 with SMTP id t2so2315950faa.34
for <bitcoin-development@lists.sourceforge.net>;
Wed, 23 Nov 2011 04:11:36 -0800 (PST)
Received: by 10.181.12.111 with SMTP id ep15mr10333202wid.10.1322050296111;
Wed, 23 Nov 2011 04:11:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.227.197.141 with HTTP; Wed, 23 Nov 2011 04:10:55 -0800 (PST)
In-Reply-To: <CAGQP0AEZ9CUNd9ERyMsx741bqjLptY4pPRU6EmxQcD7kR8bdbw@mail.gmail.com>
References: <201111231035.48690.andyparkins@gmail.com>
<CAGQP0AEXrp3=j8WkQkUzJRhZYF6VxCsFz_ADXE8uz+d2YLfNcw@mail.gmail.com>
<201111231130.58785.andyparkins@gmail.com>
<CAGQP0AEZ9CUNd9ERyMsx741bqjLptY4pPRU6EmxQcD7kR8bdbw@mail.gmail.com>
From: Christian Decker <decker.christian@gmail.com>
Date: Wed, 23 Nov 2011 13:10:55 +0100
Message-ID: <CALxbBHVEvCqun0aX_9awGhW39h5cx0jLPx2ptoesBcmKGO-_Dw@mail.gmail.com>
To: =?ISO-8859-1?Q?Jorge_Tim=F3n?= <timon.elviejo@gmail.com>
Content-Type: multipart/alternative; boundary=f46d0435bffc46640704b265d297
X-Spam-Score: 0.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
(decker.christian[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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
2.5 FREEMAIL_REPLY From and body contain different freemails
-1.2 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RTBfy-0000eW-DW
Cc: bitcoin-development@lists.sourceforge.net
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 12:11:43 -0000
--f46d0435bffc46640704b265d297
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
First of all I do agree that a method for adjusting the difficulty in a
huge power drop is needed (I don't see it so much in power rises).
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 propagation
will also cause forks.
If 1/2 of the network see one block as the hardest, and for the rest of the
network it came too late then we'll have a fork that stays with us quite a
while.
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.
Regards,
Chris
2011/11/23 Jorge Tim=F3n <timon.elviejo@gmail.com>
> With the current system, the timestamp can also be cheated, but miners
> have no direct incentive to do it. With your system, they increase
> their probability of mining a block by putting a false timestamp.
> Also, where's the network clock you're talking about? Isn't it the
> timestamps in the blockchain?
>
>
>
> 2011/11/23, Andy Parkins <andyparkins@gmail.com>:
> > On 2011 November 23 Wednesday, Jorge Tim=F3n wrote:
> >> 2011/11/23, Andy Parkins <andyparkins@gmail.com>:
> >> > Let's abandon the idea of a target difficulty. Instead, every node
> just
> >> >
> >> > generates the most difficulty block it can. Simultaneously, every
> node
> >> > is listening for "the most difficult block generated before time T"=
;
> >> > with T being
> >> > picked to be the block generation rate (10 minutes).
> >>
> >> A miner could try to obtain more difficulty out of time and cheat its
> >> reported datetime (T).
> >
> > Just as with the current system.
> >
> > The defence is that on receipt of a block, its timestamp is checked
> against
> > the node's own clock and averaged network clock. Blocks out of that ba=
nd
> > are
> > rejected.
> >
> >
> > Andy
> > --
> > Dr Andy Parkins
> > andyparkins@gmail.com
> >
>
>
> --
> Jorge Tim=F3n
>
>
> -------------------------------------------------------------------------=
-----
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--f46d0435bffc46640704b265d297
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
First of all I do agree that a method for adjusting the difficulty in a hug=
e power drop is needed (I don't see it so much in power rises).<br><br>=
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 distri=
buted systems. Even the smallest drift would allow for forks in the chain a=
ll over the place. Furthermore the delay in propagation will also cause for=
ks.<br>
<br>If 1/2 of the network see one block as the hardest, and for the rest of=
the network it came too late then we'll have a fork that stays with us=
quite a while.<br><br>The block chain is described as a timestamp server i=
n the paper, but it is more of a proof-of-existence before, as the containe=
d timestamp cannot be trusted anyway.<br>
<br>Regards,<br>Chris<br><br><div class=3D"gmail_quote">2011/11/23 Jorge Ti=
m=F3n <span dir=3D"ltr"><<a href=3D"mailto:timon.elviejo@gmail.com">timo=
n.elviejo@gmail.com</a>></span><br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
With the current system, the timestamp can also be cheated, but miners<br>
have no direct incentive to do it. With your system, they increase<br>
their probability of mining a block by putting a false timestamp.<br>
Also, where's the network clock you're talking about? Isn't it =
the<br>
timestamps in the blockchain?<br>
<br>
<br>
<br>
2011/11/23, Andy Parkins <<a href=3D"mailto:andyparkins@gmail.com">andyp=
arkins@gmail.com</a>>:<br>
<div><div class=3D"h5">> On 2011 November 23 Wednesday, Jorge Tim=F3n wr=
ote:<br>
>> 2011/11/23, Andy Parkins <<a href=3D"mailto:andyparkins@gmail.c=
om">andyparkins@gmail.com</a>>:<br>
>> > Let's abandon the idea of a target difficulty. =A0Instead=
, every node just<br>
>> ><br>
>> =A0> generates the most difficulty block it can. =A0Simultaneou=
sly, every node<br>
>> =A0> is listening for "the most difficult block generated =
before time T";<br>
>> =A0> with T being<br>
>> =A0> picked to be the block generation rate (10 minutes).<br>
>><br>
>> A miner could try to obtain more difficulty out of time and cheat =
its<br>
>> reported datetime (T).<br>
><br>
> Just as with the current system.<br>
><br>
> The defence is that on receipt of a block, its timestamp is checked ag=
ainst<br>
> the node's own clock and averaged network clock. =A0Blocks out of =
that band<br>
> are<br>
> rejected.<br>
><br>
><br>
> Andy<br>
> --<br>
> Dr Andy Parkins<br>
> <a href=3D"mailto:andyparkins@gmail.com">andyparkins@gmail.com</a><br>
><br>
<br>
<br>
</div></div>--<br>
<div class=3D"HOEnZb"><div class=3D"h5">Jorge Tim=F3n<br>
<br>
---------------------------------------------------------------------------=
---<br>
All the data continuously generated in your IT infrastructure<br>
contains a definitive record of customers, application performance,<br>
security threats, fraudulent activity, and more. Splunk takes this<br>
data and makes sense of it. IT sense. And common sense.<br>
<a href=3D"http://p.sf.net/sfu/splunk-novd2d" target=3D"_blank">http://p.sf=
.net/sfu/splunk-novd2d</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br>
--f46d0435bffc46640704b265d297--
|
