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