From: Peter Todd <pete@petertodd•org>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>,
Ron OHara <ron.ohara54@gmail•com>
Subject: Re: [Bitcoin-development] Time
Date: Sun, 27 Jul 2014 18:22:52 -0400 [thread overview]
Message-ID: <20140727222252.GC14717@savin> (raw)
In-Reply-To: <CANEZrP2N6zf7RUtPzA+7-X5+UKBmrY-D_8Md+_=8nssoFNng9A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3304 bytes --]
On Fri, Jul 25, 2014 at 12:30:11PM +0200, Mike Hearn wrote:
> >
> > Ok... 'time' on the blockchain could be 'gamed' ... but with great
> > difficulty.
>
>
> Unfortunately not: miners have in the past routinely gamed the timestamp in
> order to use it as an extra nonce and squeeze some more gigahashes out of
> their hardware/pool.
That's correct, but irrelevant for this application. The "gaming"
possible is only a few bits; gaming more bits than that either makes
blocks invalid due to being >2hr in the future, or < the median time in
the past. In addition doing the latter causes difficulty to rise.
Also see: "Re: [Bitcoin-development] 32 vs 64-bit timestamp fields" -
Peter Todd - 08 May 2013
http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg02144.html
> > An application presented with a fake blockchain can use
> > quite a few heuristics to test the 'validity' of the block chain.
> >
>
> The app cannot tell if it was given a truncated chain. You could keep such
> an app stuck in the past forever. This is often a problem.
Only if the app is trying to use the blockchain non-interactively. The
right way to use the blockchain for determining the current time is to
create a nonce, timestamp it, wait for a confirmation, and get the
merkle path to the block header. This proves the attacker has spent at
least whatever resources it took to create a block considered valid by
your application. (you'll probably want to have a fairly high
min-difficulty)
> > Reliable 'time' has been impossible up until now - because you need to
> > trust the time source, and that can always be faked. Using the
> > blockchain as an approximate time source gives you a world wide
> > consensus without direct trust of any player.
> >
>
> Much though I hate to be a party pooper, you could currently get
> Bitcoin-level trusted time by just polling at least two or three
> independent servers e.g. google.com, baidu.cn, yandex.ru (they all serve
> time via HTTPS headers).
>
> If we crack the mining decentralisation problem then this argument becomes
> a lot stronger, but for now ......
See https://github.com/ioerror/tlsdate
Reminds me: anyone know if tlsdate is able to produce timestamp proofs
verifiable by third-parties? If it could in conjunction with the
blockchain as a random beacon you could at least show dishonesty by
showing that google.com/etc. signed a HTTPS header with a time prior to
when some block was created. Right now unlike the blockchain these
independent servers can easily get away with timestamp fraud,
particularly if they manage to target your specific application. (use
Tor!)
Equally, the blockchain has the advantage that it's easy to show that
invalid blocks are being created for the purpose of creating fake
timestamps; it'd be reasonable for the P2P network to relay any block
header seen with a difficulty > some anti-DoS threshold. Gavin already
did something similar with relaying invalid blocks in pull-req #3580.
It had the flaw of making network splits worse, but in conjunction with
a separate "invalid-block" inv type I think the issue goes away.
--
'peter'[:-1]@petertodd.org
0000000000000000201d505432d708aa2edb656f6fe34d686b37d4747e5ff389
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2014-07-27 22:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-25 1:14 Ron OHara
2014-07-25 1:41 ` Jeff Garzik
2014-07-25 2:35 ` Aaron Voisine
2014-07-25 2:39 ` Gregory Maxwell
2014-07-25 3:21 ` William Yager
2014-07-25 5:56 ` Aaron Voisine
2014-07-25 10:26 ` Mike Hearn
2014-07-25 14:45 ` Aaron Voisine
2014-07-25 16:03 ` Mike Hearn
2014-07-25 16:22 ` Natanael
2014-07-25 18:14 ` Aaron Voisine
2014-07-25 10:30 ` Mike Hearn
2014-07-27 22:22 ` Peter Todd [this message]
2014-07-28 17:33 ` Troy Benjegerdes
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=20140727222252.GC14717@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
--cc=ron.ohara54@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