From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UaGfX-0001co-Jo for bitcoin-development@lists.sourceforge.net; Thu, 09 May 2013 02:33:19 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of googlemail.com designates 209.85.212.170 as permitted sender) client-ip=209.85.212.170; envelope-from=john.dillon892@googlemail.com; helo=mail-wi0-f170.google.com; Received: from mail-wi0-f170.google.com ([209.85.212.170]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UaGfV-0002hn-Po for bitcoin-development@lists.sourceforge.net; Thu, 09 May 2013 02:33:19 +0000 Received: by mail-wi0-f170.google.com with SMTP id hq12so5957807wib.3 for ; Wed, 08 May 2013 19:33:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.122.166 with SMTP id lt6mr14606656wjb.14.1368066791646; Wed, 08 May 2013 19:33:11 -0700 (PDT) Received: by 10.194.135.239 with HTTP; Wed, 8 May 2013 19:33:11 -0700 (PDT) In-Reply-To: <20130509015731.GA26423@savin> References: <20130508234422.GA30870@savin> <20130509011338.GA8708@vps7135.xlshosting.net> <20130509015731.GA26423@savin> Date: Thu, 9 May 2013 02:33:11 +0000 Message-ID: From: John Dillon To: Peter Todd 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: 1UaGfV-0002hn-Po 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 02:33:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Thu, May 9, 2013 at 1:57 AM, Peter Todd wrote: > Remember that interpreting the timestamp on a block for the purposes of > timestamping is a lot more subtle than it appears at first. I actually just meant how Pieter Wuille was talking about a blocktime accurate to only within 18 hours. :) But it is a nice writeup! In any case, for many things simple relative ordering is enough rather than absolute time. > There are two types of timestamps possible: proofs that data existed > before a time, and proofs that data existed after. With the former type > the *later* the proof says the data existed, the more conservative the > assumptions behind the proof. So simply adding two hours to the block's > timestamp is relatively reasonable. (this assumes the attack managed to > mine a single block, and all nodes have accurate clocks) Nope. The attacker can make the timestamp on the block they mine as little as the minimum from GetMedianTimePast(), and adding two hours to that number could easily be well before true time. What you probably need to do is some sort of median time calculation for the blocks around your timestamp. The proof becomes probabalistic based on the % of hashing power the attacker controls and in turn depends on if the time they created their timestamp was of their own choosing. IE, if you just want to create an inaccurate timestamp, but don't care when, you can just mine blocks and wait until you get lucky. If you need to create an inaccurate timestamp *now* the problem is much harder. But all this analysis can be developed later, and data timestamped now. :) > Back to the block header time... Frankly, the easiest thing to do is > just have a flag day where blocks after a certain height are considered > to have a different epoch from the standard 1970 one when computing > their time. Boring, but it works fine and only needs to be updated every > few decades. Oh, right, yes, that is a much more simple idea and far less prone to bugs. Many SPV clients wouldn't even need upgrades if they don't acturally validate the blocks they receive and just look for the biggest PoW. > > You're midstate idea is very clever though and could come in handy in > the future for different purposes. Eventually we should discuss this > with the ASIC manufacturers - if it can be implemented as a firmware or > FPGA upgrade in the field all the better. Yes Anyway, you are being distracted from what we were talking about before, get back to work! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRiwrGAAoJEEWCsU4mNhiPvYAH/3kjlg5diWeyYUJlKPKRpygQ XAU8a2D3h9bABacmmhx5yW3AmtV0QqLgKlB76t41JB4O6Jer5FT8tBBwPnjDijtI KrBWwPqNhVZiyTSDZQTF6BR1a0DDCZVtOXlpOTj6NL1+hy7NYTYsqxAVzS8QgZUH RXt7QTYGrrmMbmm75NdWhK59mbv22UEaDHfDW0qqgSzdb7f1EQv1fou3MfKScQSd 7OsGU3k5PM+KQ/FGBy+r+07GY5yj85YMooGky0MCjtkOiU/qr+pxfs1uT2R8/512 TyZxzn1vtgWUEGOUeMCml+bgjUOvOgcIvAarzZmyLyAAY15S/LT8MvAr2RUjAfY= =UDyE -----END PGP SIGNATURE-----