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
|
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 <timon.elviejo@gmail.com>) id 1RTEuE-0001XK-NW
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Nov 2011 15:38:38 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.47 as permitted sender)
client-ip=209.85.214.47; envelope-from=timon.elviejo@gmail.com;
helo=mail-bw0-f47.google.com;
Received: from mail-bw0-f47.google.com ([209.85.214.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RTEuD-0007ct-RX
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Nov 2011 15:38:38 +0000
Received: by bkbzs2 with SMTP id zs2so1832112bkb.34
for <bitcoin-development@lists.sourceforge.net>;
Wed, 23 Nov 2011 07:38:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.152.87 with SMTP id f23mr24892814bkw.18.1322062711467;
Wed, 23 Nov 2011 07:38:31 -0800 (PST)
Received: by 10.223.132.194 with HTTP; Wed, 23 Nov 2011 07:38:30 -0800 (PST)
In-Reply-To: <201111231529.46154.andyparkins@gmail.com>
References: <201111231035.48690.andyparkins@gmail.com>
<201111231254.41426.andyparkins@gmail.com>
<CAGQP0AEQukQYB5Bmn-XfK3G0hm0q9r2YDL5W=zy+eBY7Vufb8g@mail.gmail.com>
<201111231529.46154.andyparkins@gmail.com>
Date: Wed, 23 Nov 2011 16:38:30 +0100
Message-ID: <CAGQP0AGWTa-iRsryMZnFxnMEPRdy_hm+P+FUN9jBVK0F+AgVDA@mail.gmail.com>
From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= <timon.elviejo@gmail.com>
To: Andy Parkins <andyparkins@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.1 (/)
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
(timon.elviejo[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
2.5 FREEMAIL_REPLY From and body contain different freemails
-0.8 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RTEuD-0007ct-RX
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 15:38:38 -0000
But the protocol must have a deterministic way to determine if a block
must be accepted or rejected.
I don't know what NTP is, but if you can have a perfect distributed
clock your proposal may work.
2011/11/23, Andy Parkins <andyparkins@gmail.com>:
> On 2011 November 23 Wednesday, Jorge Tim=F3n wrote:
>
>> Well, I meant "the probability of your block being the hardest".
>> What a miner can do is hash the block (cheating the timestamp) for 2
>> more minutes than the rest of the people and then send it to the other
>> nodes. Nodes cannot possibly know when did you hashed the block only
>> by looking at their clock when they receive it, because there's also
>> network latency.
>
> True enough; but then the same is true for everyone else. If the window =
is
> 2
> minutes after the stated time, then everyone _can_ wait until the end of
> that
> window. However, they risk their block being rejected by their peers, an=
d
> their efforts are wasted. In fact, it can be guaranteed by making the
> accept
> window zero. There is then no reason to carry on computing after the rew=
ard
> window closes, since you know your peers will reject it.
>
>> > (2) For the network clock; see util.cpp:GetAdjustedTime().
>>
>> 1) This is part of the satoshi client but not the protocol. A miner
>> can rewrite this part of the code and there won't be anything in the
>> chain that contradicts the protocol.
>
> Well yes. What does that matter? It's only a way of calculating an aver=
age
> time. The node can use any clock it wants, as long as the block time is
> verified by the peers.
>
>> 2) I haven't read the code but I'm pretty sure that's not a perfect
>> decentralized clock.
>
> It definitely isn't. NTP is mentioned in the source as an alternative.
>
>> I will be more specific. Where's the network clock in the chain (in
>> the protocol)?
>
> It's nothing to do with the protocol; it's an individual miner choosing
> whether to accept or reject a block based on the timestamp it claims, and
> the
> current time as the miner sees it. For the sake of compatibility, the
> clients
> currently choose to use a community clock as "current", as established fr=
om
> the time they receive from peers in the "version" message (it actually ho=
lds
> offsets between them, which is pretty bad, as a long-connected client wil=
l
> drift). They don't have to, but if miners aren't using time that
> approximates
> what their peers are using, under my system, their blocks would be reject=
ed:
> so an incentive to use that "community clock" exists.
>
>
>
> Andy
>
> --
> Dr Andy Parkins
> andyparkins@gmail.com
>
--=20
Jorge Tim=F3n
|
