Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UaFe0-0005sX-Gm for bitcoin-development@lists.sourceforge.net; Thu, 09 May 2013 01:27:40 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of googlemail.com designates 74.125.82.176 as permitted sender) client-ip=74.125.82.176; envelope-from=john.dillon892@googlemail.com; helo=mail-we0-f176.google.com; Received: from mail-we0-f176.google.com ([74.125.82.176]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UaFdz-0003tY-Kt for bitcoin-development@lists.sourceforge.net; Thu, 09 May 2013 01:27:40 +0000 Received: by mail-we0-f176.google.com with SMTP id p60so2302076wes.7 for ; Wed, 08 May 2013 18:27:33 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.210.225 with SMTP id mx1mr25586452wic.15.1368062853413; Wed, 08 May 2013 18:27:33 -0700 (PDT) Received: by 10.194.135.239 with HTTP; Wed, 8 May 2013 18:27:33 -0700 (PDT) In-Reply-To: <20130509011338.GA8708@vps7135.xlshosting.net> References: <20130508234422.GA30870@savin> <20130509011338.GA8708@vps7135.xlshosting.net> Date: Thu, 9 May 2013 01:27:33 +0000 Message-ID: From: John Dillon To: Pieter Wuille Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.4 (-) 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 (john.dillon892[at]googlemail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (john.dillon892[at]googlemail.com) -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: 1UaFdz-0003tY-Kt Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] 32 vs 64-bit timestamp fields 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: Thu, 09 May 2013 01:27:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Thu, May 9, 2013 at 1:13 AM, Pieter Wuille wrote: > On Wed, May 08, 2013 at 09:08:34PM -0400, Jeff Garzik wrote: >> Guffaw :) The year 2038 is so far in the future that it is not really >> relevant, from that angle. > > "Meh". I think it's highly unlikely we'll break the block header format, as it > pretty much means invalidating all mining hardware. Doesn't most mining hardware at the ASCI level start with a SHA256 midstate given that the nonce is at the end? Adding further information to the block should be possible at the beginning of the block without major changes to the mining hardware. > There's also no need: 32 bits is plenty of precision. Hell, even 16 bits would > do (assuming there's never more than a 65535s (about 18 hours) gap between two > blocks). Just assume the "full" 64-bit time is the smallest one that makes > sense, given its lower 32 bits. I feel somewhat uncomfortable about the "after-the-fact" auditing possible in this scenario. Besides the timestamping provided by the block headers appears to be useful in some payment protocols, not to mention in general. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRivnmAAoJEEWCsU 4mNhiPUIYH/AlxK4DHvIdq0khNH0nfK65E F1ZyYZTGLNHKqrJLCU2kc7zteGadQuccmFsYpmViIr14tzpU7xMImUHpj7fEHO3R S/1zy59rx2+VYcevYdwMDTywanjeForRpli93Hz570GfwfG/D7VPejfLo6iq5dOt EG5m3Z8F7wNzWBmfBYBHKLrNBJe6iw0qJ2nNiHXcELt6gaqG3C9wI9NAPtQWQKjB 57h7yTnFCRmjA3HDdCe2s0FVJgRP5cJqz3e62qZrY/BRmw/Vrx8ExuX1LJFqUx3k 5tg+BxXH4DJbNIojuq9lLl5lWxKOI1iSJJuCAixo/6s/manLFggJv7KtYgzhhjI= =BxDb -----END PGP SIGNATURE-----