summaryrefslogtreecommitdiff
path: root/8a/a50a486c02bcfeeeab9ac45a01da84680db244
blob: 751b1c7dc34a20c9f6a2e8e792580ba0995d5069 (plain)
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
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <andyparkins@gmail.com>) id 1RTElo-0008WI-OL
	for bitcoin-development@lists.sourceforge.net;
	Wed, 23 Nov 2011 15:29:56 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.160.175 as permitted sender)
	client-ip=209.85.160.175; envelope-from=andyparkins@gmail.com;
	helo=mail-gy0-f175.google.com; 
Received: from mail-gy0-f175.google.com ([209.85.160.175])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1RTElo-0002MR-3i
	for bitcoin-development@lists.sourceforge.net;
	Wed, 23 Nov 2011 15:29:56 +0000
Received: by ghy10 with SMTP id 10so1953339ghy.34
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 23 Nov 2011 07:29:50 -0800 (PST)
Received: by 10.152.135.179 with SMTP id pt19mr14700895lab.47.1322062190419;
	Wed, 23 Nov 2011 07:29:50 -0800 (PST)
Received: from dvr.localnet (mail.360visiontechnology.com. [92.42.121.178])
	by mx.google.com with ESMTPS id jb5sm16215035lab.15.2011.11.23.07.29.48
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 23 Nov 2011 07:29:48 -0800 (PST)
From: Andy Parkins <andyparkins@gmail.com>
To: Jorge =?iso-8859-1?q?Tim=F3n?= <timon.elviejo@gmail.com>
Date: Wed, 23 Nov 2011 15:29:45 +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>
	<201111231254.41426.andyparkins@gmail.com>
	<CAGQP0AEQukQYB5Bmn-XfK3G0hm0q9r2YDL5W=zy+eBY7Vufb8g@mail.gmail.com>
In-Reply-To: <CAGQP0AEQukQYB5Bmn-XfK3G0hm0q9r2YDL5W=zy+eBY7Vufb8g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2567792.LKsXHrLWy7";
	protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201111231529.46154.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: 1RTElo-0002MR-3i
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:29:56 -0000

--nextPart2567792.LKsXHrLWy7
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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=20
minutes after the stated time, then everyone _can_ wait until the end of th=
at=20
window.  However, they risk their block being rejected by their peers, and=
=20
their efforts are wasted.  In fact, it can be guaranteed by making the acce=
pt=20
window zero.  There is then no reason to carry on computing after the rewar=
d=20
window closes, since you know your peers will reject it.

> > (2) For the network clock; see util.cpp:GetAdjustedTime().
>=20
> 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 averag=
e=20
time.  The node can use any clock it wants, as long as the block time is=20
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=20
whether to accept or reject a block based on the timestamp it claims, and t=
he=20
current time as the miner sees it.  For the sake of compatibility, the clie=
nts=20
currently choose to use a community clock as "current", as established from=
=20
the time they receive from peers in the "version" message (it actually hold=
s=20
offsets between them, which is pretty bad, as a long-connected client will=
=20
drift).  They don't have to, but if miners aren't using time that approxima=
tes=20
what their peers are using, under my system, their blocks would be rejected=
:=20
so an incentive to use that "community clock" exists.



Andy

=2D-=20
Dr Andy Parkins
andyparkins@gmail.com

--nextPart2567792.LKsXHrLWy7
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)

iEYEABECAAYFAk7NEWoACgkQwQJ9gE9xL20jwQCeKy6bb0lumBtQMtcngh8Jp72q
nMYAnAuiWBaGAMVhZYwrOlkmgpOmiD3Q
=HnOD
-----END PGP SIGNATURE-----

--nextPart2567792.LKsXHrLWy7--