From: John Dillon <john.dillon892@googlemail•com>
To: Pieter Wuille <pieter.wuille@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] 32 vs 64-bit timestamp fields
Date: Thu, 9 May 2013 01:27:33 +0000 [thread overview]
Message-ID: <CAPaL=UW_uvMpLx2sv4o3yONcAnY8xwLQWT2Act6por7CdHBJNw@mail.gmail.com> (raw)
In-Reply-To: <20130509011338.GA8708@vps7135.xlshosting.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Thu, May 9, 2013 at 1:13 AM, Pieter Wuille <pieter.wuille@gmail•com> 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-----
next prev parent reply other threads:[~2013-05-09 1:27 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-08 23:39 Addy Yeow
2013-05-08 23:42 ` Jeff Garzik
2013-05-08 23:44 ` Peter Todd
2013-05-09 1:00 ` John Dillon
2013-05-09 1:08 ` Jeff Garzik
2013-05-09 1:13 ` Pieter Wuille
2013-05-09 1:27 ` John Dillon [this message]
2013-05-09 1:57 ` Peter Todd
2013-05-09 2:33 ` John Dillon
2013-05-09 2:42 ` Peter Todd
2013-05-09 11:12 ` Pieter Wuille
2013-05-09 15:40 ` Mike Hearn
2013-05-09 15:43 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPaL=UW_uvMpLx2sv4o3yONcAnY8xwLQWT2Act6por7CdHBJNw@mail.gmail.com' \
--to=john.dillon892@googlemail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pieter.wuille@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox