Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RTETL-00051L-B5 for bitcoin-development@lists.sourceforge.net; Wed, 23 Nov 2011 15:10:51 +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=timon.elviejo@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 1RTETH-0007M8-MG for bitcoin-development@lists.sourceforge.net; Wed, 23 Nov 2011 15:10:51 +0000 Received: by bkbzs2 with SMTP id zs2so1780428bkb.34 for ; Wed, 23 Nov 2011 07:10:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.205.126.15 with SMTP id gu15mr24899689bkc.108.1322061041032; Wed, 23 Nov 2011 07:10:41 -0800 (PST) Received: by 10.223.132.194 with HTTP; Wed, 23 Nov 2011 07:10:40 -0800 (PST) In-Reply-To: <201111231254.41426.andyparkins@gmail.com> References: <201111231035.48690.andyparkins@gmail.com> <201111231130.58785.andyparkins@gmail.com> <201111231254.41426.andyparkins@gmail.com> Date: Wed, 23 Nov 2011 16:10:40 +0100 Message-ID: From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= To: Andy Parkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.0 (-) 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 0.6 AWL AWL: From: address is in the auto white-list X-Headers-End: 1RTETH-0007M8-MG 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 15:10:51 -0000 2011/11/23, Andy Parkins : > 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 > mining a block is 100% in my system. Instead, it becomes "the probabilit= y > of > your block being the hardest" and that requires actual hashing power > regardless of the timestamp you write on the block. I could write that m= y > block was generated next year; but I can't fake the hashing power it need= s > to > generate one year's worth of hashes. 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. > (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. 2) I haven't read the code but I'm pretty sure that's not a perfect decentralized clock. I will be more specific. Where's the network clock in the chain (in the protocol)? --=20 Jorge Tim=F3n