Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1R3xH1-0000n7-JT for bitcoin-development@lists.sourceforge.net; Wed, 14 Sep 2011 21:45:39 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of mm.st designates 66.111.4.27 as permitted sender) client-ip=66.111.4.27; envelope-from=theymos@mm.st; helo=out3.smtp.messagingengine.com; Received: from out3.smtp.messagingengine.com ([66.111.4.27]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1R3xH0-0005CT-Lv for bitcoin-development@lists.sourceforge.net; Wed, 14 Sep 2011 21:45:39 +0000 Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 42BDC2B23E for ; Wed, 14 Sep 2011 17:45:33 -0400 (EDT) Received: from web3.nyi.mail.srv.osa ([10.202.2.213]) by compute4.internal (MEProxy); Wed, 14 Sep 2011 17:45:33 -0400 Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 23C3DA805A1; Wed, 14 Sep 2011 17:45:33 -0400 (EDT) Message-Id: <1316036733.29037.140258141218893@webmail.messagingengine.com> X-Sasl-Enc: XFLpUFYyCQiIrzt1OWdr95USHSA4e5V5R+SD39uE721d 1316036733 From: "theymos" To: bitcoin-development@lists.sourceforge.net MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: References: Date: Wed, 14 Sep 2011 16:45:33 -0500 X-Spam-Score: -1.5 (-) 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 (theymos[at]mm.st) -0.0 SPF_PASS SPF: sender matches SPF record 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.0 T_TO_NO_BRKTS_FREEMAIL To: misformatted and free email service X-Headers-End: 1R3xH0-0005CT-Lv Subject: Re: [Bitcoin-development] Difficulty adjustment / time issues 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, 14 Sep 2011 21:45:39 -0000 A better retarget strategy might be to use the real average time between all of the blocks in the interval so that no blocks are treated specially in the calculation. I agree that this is not important enough to fork the chain over, though. An attacker would have to maintain control for a *very* long time because of Bitcoin's long retarget interval. (Maybe this kind of thing is why the retarget interval is so long?) I don't like requiring block times to be within minutes of reality. It would be fine if only miners had to keep accurate time, but clients will also need to have good time in order to see if a block will be discouraged. A discouraged block should not count toward confirmations. If relays will also discourage blocks, then they'll need accurate time as well. The network should not be allowed to adjust your time by more than 40 minutes to prevent the timejacking attack, but I don't see a problem with the other time rules. Time is only used for retargets and LockTime, so it only needs to be generally accurate.