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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <andyparkins@gmail.com>) id 1RTCLm-0006Pn-OT
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Nov 2011 12:54:54 +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=andyparkins@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 1RTCLm-0002CQ-09
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Nov 2011 12:54:54 +0000
Received: by bkbzs2 with SMTP id zs2so1557221bkb.34
for <bitcoin-development@lists.sourceforge.net>;
Wed, 23 Nov 2011 04:54:47 -0800 (PST)
Received: by 10.204.152.25 with SMTP id e25mr24469280bkw.51.1322052887563;
Wed, 23 Nov 2011 04:54:47 -0800 (PST)
Received: from dvr.localnet (mail.360visiontechnology.com. [92.42.121.178])
by mx.google.com with ESMTPS id x14sm12776819bkf.10.2011.11.23.04.54.42
(version=TLSv1/SSLv3 cipher=OTHER);
Wed, 23 Nov 2011 04:54:43 -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 12:54:41 +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>
<201111231130.58785.andyparkins@gmail.com>
<CAGQP0AEZ9CUNd9ERyMsx741bqjLptY4pPRU6EmxQcD7kR8bdbw@mail.gmail.com>
In-Reply-To: <CAGQP0AEZ9CUNd9ERyMsx741bqjLptY4pPRU6EmxQcD7kR8bdbw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1588240.KrQuzvx5lf";
protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201111231254.41426.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: 1RTCLm-0002CQ-09
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:54:54 -0000
--nextPart1588240.KrQuzvx5lf
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
On 2011 November 23 Wednesday, Jorge Tim=F3n wrote:
> 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?
(1) The "probability of mining a block" is old-think. The probability of=20
mining a block is 100% in my system. Instead, it becomes "the probability =
of=20
your block being the hardest" and that requires actual hashing power=20
regardless of the timestamp you write on the block. I could write that my=
=20
block was generated next year; but I can't fake the hashing power it needs =
to=20
generate one year's worth of hashes.
If chain difficulty were summed correctly (sum(log(difficulty)), I guess),=
=20
then time makes not the slightest difference anyway. You can issue blocks =
at=20
any time with any difficulty, and the "hardest" chain always wins. The blo=
ck=20
period can be anything, and it is only the block reward that makes it=20
necessary to pick a particular period for block issuing (even that could be=
=20
worked around I guess with a variable reward, but why bother?).
(2) For the network clock; see util.cpp:GetAdjustedTime().
(3) Current clients do have an incentive: more time. The more time they ge=
t,=20
the more hashes they can try. The current client already checks the=20
timestamp:
main.cpp:CBlock::CheckBlock()
// Check timestamp
if (GetBlockTime() > GetAdjustedTime() + 2 * 60 * 60)
return error("CheckBlock() : block timestamp too far in the future"=
);
My suggestion only requires that the two hour window be reduced; and a lowe=
r=20
limit to be added. Also: while the miners have an incentive to lie about t=
he=20
time, the nodes they broadcast to have an incentive to reject mistimed bloc=
ks,=20
so you won't gain much by lying to your peers since your block won't be=20
accepted -- the incentive is therefore removed.
Note: my system also prevents an attack that is possible with current bitco=
in:=20
recalculating the entire chain. Let's say Visa want to take over bitcoin. =
=20
They buy enough computing power to significantly beat the current bitcoin=20
network; then they start recalculating the entire block chain; since early=
=20
blocks were low difficulty, it's not that hard to do. Once they overtake t=
he=20
real chain, they have effectively undone all previous transactions. (I'm n=
ot=20
suggesting this is likely; and it's actually mitigated by the hard-coded bl=
ock=20
hashes). The point is that blocks are only generatable for the time when t=
he=20
rest of the network is willing to add them to the chain.
Andy
=2D-=20
Dr Andy Parkins
andyparkins@gmail.com
--nextPart1588240.KrQuzvx5lf
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)
iEYEABECAAYFAk7M7REACgkQwQJ9gE9xL21CQQCgoI2nbLFSsjT+DL7ljd6rP63o
Mq0An0X/CaOv6y9rFaQ+nre9KuvzzpCt
=858G
-----END PGP SIGNATURE-----
--nextPart1588240.KrQuzvx5lf--
|
