public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [Bitcoin-development] Time
@ 2014-07-25  1:14 Ron OHara
  2014-07-25  1:41 ` Jeff Garzik
                   ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: Ron OHara @ 2014-07-25  1:14 UTC (permalink / raw)
  To: bitcoin-development


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I thought I should shortcut my research by asking a direct question here.

As I understand it, the blockchain actually provides an extra piece of
reliable data that is not being exploited by applications.

Which data?  The time.   In this case 'the time' as agreed by >50% of
the participants, where those participants have a strong financial
incentive to keep that 'time' fairly accurate. (+/- about 10 minutes)

Is this a reasonable understanding of 'time'? ... aka timestamps on the
block

Ok... 'time' on the blockchain could be 'gamed' ... but with great
difficulty. An application presented with a fake blockchain can use
quite a few heuristics to test the 'validity' of the block chain.
It can review the usual cryptographic proofs, and check that difficulty
is growing/declining only in a realistic manner up to the most recent
block. Even use some arbitrary test like difficulty > 10,000,000,000 
... on the presumption that any less means that the Bitcoin system has
failed massively from where it currently is and has become an unreliable
time source.

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.

So if this presumption is correct, then we can now build time capsule
applications that can not be tricked into exposing their contents too
early by running them in a virtual environment with the wrong system time.

Is this right? or did miss I something fundamental?

Ron

- -- 
public identify: https://www.onename.io/ron_ohara
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJT0a9sAAoJEAla1VT1+xc2ONQH/0R09guSNNCxP36KziAjfcBc
JEhxMpIlqTTYEvNXaBmuPy4BN+IZQ9izgrW/cvlEJJNMmc5/VIBk83WZltmDwcKl
oo4MIdmp6vz984GWToyyLcLSEDT60UE9Hhe+U9RyF5J9kwbN8Uy4ozUHhFVP/0EL
q4O1V6ggPbHWgH4q8m8E9qWOlIFXCDgCjxpL8Ptxsk+UlBq2NWMiwTz6Tbc9KOB4
hOffzXCZV+DkwjFZD2Rc4rHaxw1yLuYr7DzmzwZbhRQclv9tZt9hoVaAT+RQpE1k
X7pi+zVzeMMng0bzUv8t/G+gq0gaelyV41MJQRparEXhnuYkgU7rAPKIQEG8qpc=
=T5fw
-----END PGP SIGNATURE-----




^ permalink raw reply	[flat|nested] 14+ messages in thread

• * Re: [Bitcoin-development] Time
    2014-07-25  1:14 [Bitcoin-development] Time Ron OHara
  @ 2014-07-25  1:41 ` Jeff Garzik
    2014-07-25  2:35 ` Aaron Voisine
    2014-07-25 10:30 ` Mike Hearn
    2 siblings, 0 replies; 14+ messages in thread
  From: Jeff Garzik @ 2014-07-25  1:41 UTC (permalink / raw)
    To: Ron OHara; +Cc: Bitcoin Dev
  
  Miners are free to set the block's timestamp to whatever they please,
  within a certain +/- time window.  Time might even go backwards a tiny
  bit from the last block to the next block.
  
  
  On Thu, Jul 24, 2014 at 9:14 PM, Ron OHara <ron.ohara54@gmail•com> wrote:
  >
  > -----BEGIN PGP SIGNED MESSAGE-----
  > Hash: SHA1
  >
  > I thought I should shortcut my research by asking a direct question here.
  >
  > As I understand it, the blockchain actually provides an extra piece of
  > reliable data that is not being exploited by applications.
  >
  > Which data?  The time.   In this case 'the time' as agreed by >50% of
  > the participants, where those participants have a strong financial
  > incentive to keep that 'time' fairly accurate. (+/- about 10 minutes)
  >
  > Is this a reasonable understanding of 'time'? ... aka timestamps on the
  > block
  >
  > Ok... 'time' on the blockchain could be 'gamed' ... but with great
  > difficulty. An application presented with a fake blockchain can use
  > quite a few heuristics to test the 'validity' of the block chain.
  > It can review the usual cryptographic proofs, and check that difficulty
  > is growing/declining only in a realistic manner up to the most recent
  > block. Even use some arbitrary test like difficulty > 10,000,000,000
  > ... on the presumption that any less means that the Bitcoin system has
  > failed massively from where it currently is and has become an unreliable
  > time source.
  >
  > 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.
  >
  > So if this presumption is correct, then we can now build time capsule
  > applications that can not be tricked into exposing their contents too
  > early by running them in a virtual environment with the wrong system time.
  >
  > Is this right? or did miss I something fundamental?
  >
  > Ron
  >
  > - --
  > public identify: https://www.onename.io/ron_ohara
  > -----BEGIN PGP SIGNATURE-----
  > Version: GnuPG v2.0.20 (GNU/Linux)
  > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
  >
  > iQEcBAEBAgAGBQJT0a9sAAoJEAla1VT1+xc2ONQH/0R09guSNNCxP36KziAjfcBc
  > JEhxMpIlqTTYEvNXaBmuPy4BN+IZQ9izgrW/cvlEJJNMmc5/VIBk83WZltmDwcKl
  > oo4MIdmp6vz984GWToyyLcLSEDT60UE9Hhe+U9RyF5J9kwbN8Uy4ozUHhFVP/0EL
  > q4O1V6ggPbHWgH4q8m8E9qWOlIFXCDgCjxpL8Ptxsk+UlBq2NWMiwTz6Tbc9KOB4
  > hOffzXCZV+DkwjFZD2Rc4rHaxw1yLuYr7DzmzwZbhRQclv9tZt9hoVaAT+RQpE1k
  > X7pi+zVzeMMng0bzUv8t/G+gq0gaelyV41MJQRparEXhnuYkgU7rAPKIQEG8qpc=
  > =T5fw
  > -----END PGP SIGNATURE-----
  >
  >
  > ------------------------------------------------------------------------------
  > Want fast and easy access to all the code in your enterprise? Index and
  > search up to 200,000 lines of code with a free copy of Black Duck
  > Code Sight - the same software that powers the world's largest code
  > search on Ohloh, the Black Duck Open Hub! Try it now.
  > http://p.sf.net/sfu/bds
  > _______________________________________________
  > Bitcoin-development mailing list
  > Bitcoin-development@lists•sourceforge.net
  > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
  
  
  
  -- 
  Jeff Garzik
  Bitcoin core developer and open source evangelist
  BitPay, Inc.      https://bitpay.com/
  
  
  
  ^ permalink raw reply	[flat|nested] 14+ messages in thread

• * Re: [Bitcoin-development] Time
    2014-07-25  1:14 [Bitcoin-development] Time 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 10:30 ` Mike Hearn
    2 siblings, 1 reply; 14+ messages in thread
  From: Aaron Voisine @ 2014-07-25  2:35 UTC (permalink / raw)
    To: Ron OHara; +Cc: bitcoin-development
  
  [-- Attachment #1: Type: text/plain, Size: 3304 bytes --]
  
  The upcoming release of breadwallet uses the height of the blockchain to
  enforce timed pin code lockouts for preventing an attacker from
  quickly making multiple pin guesses. This prevents them changing the
  devices system time to get around the lockout period.
  
  Aaron
  
  On Thursday, July 24, 2014, Ron OHara <ron.ohara54@gmail•com> wrote:
  
  >
  > -----BEGIN PGP SIGNED MESSAGE-----
  > Hash: SHA1
  >
  > I thought I should shortcut my research by asking a direct question here.
  >
  > As I understand it, the blockchain actually provides an extra piece of
  > reliable data that is not being exploited by applications.
  >
  > Which data?  The time.   In this case 'the time' as agreed by >50% of
  > the participants, where those participants have a strong financial
  > incentive to keep that 'time' fairly accurate. (+/- about 10 minutes)
  >
  > Is this a reasonable understanding of 'time'? ... aka timestamps on the
  > block
  >
  > Ok... 'time' on the blockchain could be 'gamed' ... but with great
  > difficulty. An application presented with a fake blockchain can use
  > quite a few heuristics to test the 'validity' of the block chain.
  > It can review the usual cryptographic proofs, and check that difficulty
  > is growing/declining only in a realistic manner up to the most recent
  > block. Even use some arbitrary test like difficulty > 10,000,000,000
  > ... on the presumption that any less means that the Bitcoin system has
  > failed massively from where it currently is and has become an unreliable
  > time source.
  >
  > 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.
  >
  > So if this presumption is correct, then we can now build time capsule
  > applications that can not be tricked into exposing their contents too
  > early by running them in a virtual environment with the wrong system time.
  >
  > Is this right? or did miss I something fundamental?
  >
  > Ron
  >
  > - --
  > public identify: https://www.onename.io/ron_ohara
  > -----BEGIN PGP SIGNATURE-----
  > Version: GnuPG v2.0.20 (GNU/Linux)
  > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
  >
  > iQEcBAEBAgAGBQJT0a9sAAoJEAla1VT1+xc2ONQH/0R09guSNNCxP36KziAjfcBc
  > JEhxMpIlqTTYEvNXaBmuPy4BN+IZQ9izgrW/cvlEJJNMmc5/VIBk83WZltmDwcKl
  > oo4MIdmp6vz984GWToyyLcLSEDT60UE9Hhe+U9RyF5J9kwbN8Uy4ozUHhFVP/0EL
  > q4O1V6ggPbHWgH4q8m8E9qWOlIFXCDgCjxpL8Ptxsk+UlBq2NWMiwTz6Tbc9KOB4
  > hOffzXCZV+DkwjFZD2Rc4rHaxw1yLuYr7DzmzwZbhRQclv9tZt9hoVaAT+RQpE1k
  > X7pi+zVzeMMng0bzUv8t/G+gq0gaelyV41MJQRparEXhnuYkgU7rAPKIQEG8qpc=
  > =T5fw
  > -----END PGP SIGNATURE-----
  >
  >
  >
  > ------------------------------------------------------------------------------
  > Want fast and easy access to all the code in your enterprise? Index and
  > search up to 200,000 lines of code with a free copy of Black Duck
  > Code Sight - the same software that powers the world's largest code
  > search on Ohloh, the Black Duck Open Hub! Try it now.
  > http://p.sf.net/sfu/bds
  > _______________________________________________
  > Bitcoin-development mailing list
  > Bitcoin-development@lists•sourceforge.net <javascript:;>
  > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
  >
  
  
  -- 
  
  Aaron Voisine
  breadwallet.com
  
  [-- Attachment #2: Type: text/html, Size: 4235 bytes --]
  
  ^ permalink raw reply	[flat|nested] 14+ messages in thread

• • * Re: [Bitcoin-development] Time
      2014-07-25  2:35 ` Aaron Voisine
    @ 2014-07-25  2:39   ` Gregory Maxwell
      2014-07-25  3:21     ` William Yager
      0 siblings, 1 reply; 14+ messages in thread
    From: Gregory Maxwell @ 2014-07-25  2:39 UTC (permalink / raw)
      To: Aaron Voisine; +Cc: bitcoin-development, Ron OHara
    
    On Thu, Jul 24, 2014 at 7:35 PM, Aaron Voisine <voisine@gmail•com> wrote:
    > The upcoming release of breadwallet uses the height of the blockchain to
    > enforce timed pin code lockouts for preventing an attacker from quickly
    > making multiple pin guesses. This prevents them changing the devices system
    > time to get around the lockout period.
    
    Is breadwallet tamper resistant & zero on tamper hardware? otherwise
    this sounds like security theater.... I attach a debugger to the
    process (or modify the program) and ignore the block sourced time.
    
    
    
    ^ permalink raw reply	[flat|nested] 14+ messages in thread

  • • * Re: [Bitcoin-development] Time
        2014-07-25  2:39   ` Gregory Maxwell
      @ 2014-07-25  3:21     ` William Yager
        2014-07-25  5:56       ` Aaron Voisine
        0 siblings, 1 reply; 14+ messages in thread
      From: William Yager @ 2014-07-25  3:21 UTC (permalink / raw)
        Cc: bitcoin-development
      
      [-- Attachment #1: Type: text/plain, Size: 585 bytes --]
      
      On Thu, Jul 24, 2014 at 10:39 PM, Gregory Maxwell <gmaxwell@gmail•com>
      wrote:
      
      >
      > Is breadwallet tamper resistant & zero on tamper hardware? otherwise
      > this sounds like security theater.... I attach a debugger to the
      > process (or modify the program) and ignore the block sourced time.
      >
      >
      It's an iOS application. I would imagine it is substantially more difficult
      to attach to a process (which, at the very least, requires root, and
      perhaps other things on iOS) than to convince the device to change its
      system time.
      
      That said, the security benefits might not be too substantial.
      
      [-- Attachment #2: Type: text/html, Size: 1247 bytes --]
      
      ^ permalink raw reply	[flat|nested] 14+ messages in thread

    • • * Re: [Bitcoin-development] Time
          2014-07-25  3:21     ` William Yager
        @ 2014-07-25  5:56       ` Aaron Voisine
          2014-07-25 10:26         ` Mike Hearn
          0 siblings, 1 reply; 14+ messages in thread
        From: Aaron Voisine @ 2014-07-25  5:56 UTC (permalink / raw)
          To: William Yager; +Cc: bitcoin-development
        
        It's based on the block height, not the block's timestamp. If you have
        access to the device and the phone itself is not pin locked, then you
        can jailbreak it and get access to the wallet seed that way. A pin
        locked device however is reasonably secure as the filesystem is
        hardware aes encrypted to a combination of pin+uuid. This was just an
        easy way to prevent multiple pin guesses by changing system time in
        settings, so that isn't the weakest part of the security model.
        
        Aaron Voisine
        breadwallet.com
        
        
        On Thu, Jul 24, 2014 at 8:21 PM, William Yager <will.yager@gmail•com> wrote:
        > On Thu, Jul 24, 2014 at 10:39 PM, Gregory Maxwell <gmaxwell@gmail•com>
        > wrote:
        >>
        >>
        >> Is breadwallet tamper resistant & zero on tamper hardware? otherwise
        >> this sounds like security theater.... I attach a debugger to the
        >> process (or modify the program) and ignore the block sourced time.
        >>
        >
        > It's an iOS application. I would imagine it is substantially more difficult
        > to attach to a process (which, at the very least, requires root, and perhaps
        > other things on iOS) than to convince the device to change its system time.
        >
        > That said, the security benefits might not be too substantial.
        >
        > ------------------------------------------------------------------------------
        > Want fast and easy access to all the code in your enterprise? Index and
        > search up to 200,000 lines of code with a free copy of Black Duck
        > Code Sight - the same software that powers the world's largest code
        > search on Ohloh, the Black Duck Open Hub! Try it now.
        > http://p.sf.net/sfu/bds
        > _______________________________________________
        > Bitcoin-development mailing list
        > Bitcoin-development@lists•sourceforge.net
        > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
        >
        
        
        
        ^ permalink raw reply	[flat|nested] 14+ messages in thread

      • • * Re: [Bitcoin-development] Time
            2014-07-25  5:56       ` Aaron Voisine
          @ 2014-07-25 10:26         ` Mike Hearn
            2014-07-25 14:45           ` Aaron Voisine
            0 siblings, 1 reply; 14+ messages in thread
          From: Mike Hearn @ 2014-07-25 10:26 UTC (permalink / raw)
            To: Aaron Voisine; +Cc: bitcoin-development
          
          [-- Attachment #1: Type: text/plain, Size: 2790 bytes --]
          
          Given that the speed at which the block chain advances is kind of
          unpredictable, I'd think it might be better to just record the time to disk
          when a PIN attempt is made and if you observe time going backwards, refuse
          to allow more attempts until it's advanced past the previous attempt.
          
          
          On Fri, Jul 25, 2014 at 7:56 AM, Aaron Voisine <voisine@gmail•com> wrote:
          
          > It's based on the block height, not the block's timestamp. If you have
          > access to the device and the phone itself is not pin locked, then you
          > can jailbreak it and get access to the wallet seed that way. A pin
          > locked device however is reasonably secure as the filesystem is
          > hardware aes encrypted to a combination of pin+uuid. This was just an
          > easy way to prevent multiple pin guesses by changing system time in
          > settings, so that isn't the weakest part of the security model.
          >
          > Aaron Voisine
          > breadwallet.com
          >
          >
          > On Thu, Jul 24, 2014 at 8:21 PM, William Yager <will.yager@gmail•com>
          > wrote:
          > > On Thu, Jul 24, 2014 at 10:39 PM, Gregory Maxwell <gmaxwell@gmail•com>
          > > wrote:
          > >>
          > >>
          > >> Is breadwallet tamper resistant & zero on tamper hardware? otherwise
          > >> this sounds like security theater.... I attach a debugger to the
          > >> process (or modify the program) and ignore the block sourced time.
          > >>
          > >
          > > It's an iOS application. I would imagine it is substantially more
          > difficult
          > > to attach to a process (which, at the very least, requires root, and
          > perhaps
          > > other things on iOS) than to convince the device to change its system
          > time.
          > >
          > > That said, the security benefits might not be too substantial.
          > >
          > >
          > ------------------------------------------------------------------------------
          > > Want fast and easy access to all the code in your enterprise? Index and
          > > search up to 200,000 lines of code with a free copy of Black Duck
          > > Code Sight - the same software that powers the world's largest code
          > > search on Ohloh, the Black Duck Open Hub! Try it now.
          > > http://p.sf.net/sfu/bds
          > > _______________________________________________
          > > Bitcoin-development mailing list
          > > Bitcoin-development@lists•sourceforge.net
          > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
          > >
          >
          >
          > ------------------------------------------------------------------------------
          > Want fast and easy access to all the code in your enterprise? Index and
          > search up to 200,000 lines of code with a free copy of Black Duck
          > Code Sight - the same software that powers the world's largest code
          > search on Ohloh, the Black Duck Open Hub! Try it now.
          > http://p.sf.net/sfu/bds
          > _______________________________________________
          > Bitcoin-development mailing list
          > Bitcoin-development@lists•sourceforge.net
          > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
          >
          
          [-- Attachment #2: Type: text/html, Size: 4085 bytes --]
          
          ^ permalink raw reply	[flat|nested] 14+ messages in thread

        • • * Re: [Bitcoin-development] Time
              2014-07-25 10:26         ` Mike Hearn
            @ 2014-07-25 14:45           ` Aaron Voisine
              2014-07-25 16:03             ` Mike Hearn
              0 siblings, 1 reply; 14+ messages in thread
            From: Aaron Voisine @ 2014-07-25 14:45 UTC (permalink / raw)
              To: Mike Hearn; +Cc: bitcoin-development
            
            [-- Attachment #1: Type: text/plain, Size: 3615 bytes --]
            
            The problem is if someone moves system time forward between app launches.
            The lockout period doesn't have to be all that precise, it just makes you
            wait for the next block, then 5, then 25, and so on. Using a well
            known time server over https would also be a good option, but the wallet
            app already has the chain height anyway.
            
            On Friday, July 25, 2014, Mike Hearn <mike@plan99•net> wrote:
            
            > Given that the speed at which the block chain advances is kind of
            > unpredictable, I'd think it might be better to just record the time to disk
            > when a PIN attempt is made and if you observe time going backwards, refuse
            > to allow more attempts until it's advanced past the previous attempt.
            >
            >
            > On Fri, Jul 25, 2014 at 7:56 AM, Aaron Voisine <voisine@gmail•com
            > <javascript:_e(%7B%7D,'cvml','voisine@gmail•com');>> wrote:
            >
            >> It's based on the block height, not the block's timestamp. If you have
            >> access to the device and the phone itself is not pin locked, then you
            >> can jailbreak it and get access to the wallet seed that way. A pin
            >> locked device however is reasonably secure as the filesystem is
            >> hardware aes encrypted to a combination of pin+uuid. This was just an
            >> easy way to prevent multiple pin guesses by changing system time in
            >> settings, so that isn't the weakest part of the security model.
            >>
            >> Aaron Voisine
            >> breadwallet.com
            >>
            >>
            >> On Thu, Jul 24, 2014 at 8:21 PM, William Yager <will.yager@gmail•com
            >> <javascript:_e(%7B%7D,'cvml','will.yager@gmail•com');>> wrote:
            >> > On Thu, Jul 24, 2014 at 10:39 PM, Gregory Maxwell <gmaxwell@gmail•com
            >> <javascript:_e(%7B%7D,'cvml','gmaxwell@gmail•com');>>
            >> > wrote:
            >> >>
            >> >>
            >> >> Is breadwallet tamper resistant & zero on tamper hardware? otherwise
            >> >> this sounds like security theater.... I attach a debugger to the
            >> >> process (or modify the program) and ignore the block sourced time.
            >> >>
            >> >
            >> > It's an iOS application. I would imagine it is substantially more
            >> difficult
            >> > to attach to a process (which, at the very least, requires root, and
            >> perhaps
            >> > other things on iOS) than to convince the device to change its system
            >> time.
            >> >
            >> > That said, the security benefits might not be too substantial.
            >> >
            >> >
            >> ------------------------------------------------------------------------------
            >> > Want fast and easy access to all the code in your enterprise? Index and
            >> > search up to 200,000 lines of code with a free copy of Black Duck
            >> > Code Sight - the same software that powers the world's largest code
            >> > search on Ohloh, the Black Duck Open Hub! Try it now.
            >> > http://p.sf.net/sfu/bds
            >> > _______________________________________________
            >> > Bitcoin-development mailing list
            >> > Bitcoin-development@lists•sourceforge.net
            >> <javascript:_e(%7B%7D,'cvml','Bitcoin-development@lists•sourceforge.net');>
            >> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
            >> >
            >>
            >>
            >> ------------------------------------------------------------------------------
            >> Want fast and easy access to all the code in your enterprise? Index and
            >> search up to 200,000 lines of code with a free copy of Black Duck
            >> Code Sight - the same software that powers the world's largest code
            >> search on Ohloh, the Black Duck Open Hub! Try it now.
            >> http://p.sf.net/sfu/bds
            >> _______________________________________________
            >> Bitcoin-development mailing list
            >> Bitcoin-development@lists•sourceforge.net
            >> <javascript:_e(%7B%7D,'cvml','Bitcoin-development@lists•sourceforge.net');>
            >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
            >>
            >
            >
            
            -- 
            
            Aaron Voisine
            breadwallet.com
            
            [-- Attachment #2: Type: text/html, Size: 4982 bytes --]
            
            ^ permalink raw reply	[flat|nested] 14+ messages in thread

          • • * Re: [Bitcoin-development] Time
                2014-07-25 14:45           ` Aaron Voisine
              @ 2014-07-25 16:03             ` Mike Hearn
                2014-07-25 16:22               ` Natanael
                0 siblings, 1 reply; 14+ messages in thread
              From: Mike Hearn @ 2014-07-25 16:03 UTC (permalink / raw)
                To: Aaron Voisine; +Cc: bitcoin-development
              
              [-- Attachment #1: Type: text/plain, Size: 3716 bytes --]
              
              Sorry, you're right. I'd have hoped a delay that doubles on failure each
              time up to some max would be good enough, relying on the p2p network to
              unlock a PIN feels weird, but I can't really quantify why or what's wrong
              with it so I guess it's just me :-)
              
              
              On Fri, Jul 25, 2014 at 4:45 PM, Aaron Voisine <voisine@gmail•com> wrote:
              
              > The problem is if someone moves system time forward between app launches.
              > The lockout period doesn't have to be all that precise, it just makes you
              > wait for the next block, then 5, then 25, and so on. Using a well
              > known time server over https would also be a good option, but the wallet
              > app already has the chain height anyway.
              >
              >
              > On Friday, July 25, 2014, Mike Hearn <mike@plan99•net> wrote:
              >
              >> Given that the speed at which the block chain advances is kind of
              >> unpredictable, I'd think it might be better to just record the time to disk
              >> when a PIN attempt is made and if you observe time going backwards, refuse
              >> to allow more attempts until it's advanced past the previous attempt.
              >>
              >>
              >> On Fri, Jul 25, 2014 at 7:56 AM, Aaron Voisine <voisine@gmail•com> wrote:
              >>
              >>> It's based on the block height, not the block's timestamp. If you have
              >>> access to the device and the phone itself is not pin locked, then you
              >>> can jailbreak it and get access to the wallet seed that way. A pin
              >>> locked device however is reasonably secure as the filesystem is
              >>> hardware aes encrypted to a combination of pin+uuid. This was just an
              >>> easy way to prevent multiple pin guesses by changing system time in
              >>> settings, so that isn't the weakest part of the security model.
              >>>
              >>> Aaron Voisine
              >>> breadwallet.com
              >>>
              >>>
              >>> On Thu, Jul 24, 2014 at 8:21 PM, William Yager <will.yager@gmail•com>
              >>> wrote:
              >>> > On Thu, Jul 24, 2014 at 10:39 PM, Gregory Maxwell <gmaxwell@gmail•com>
              >>> > wrote:
              >>> >>
              >>> >>
              >>> >> Is breadwallet tamper resistant & zero on tamper hardware? otherwise
              >>> >> this sounds like security theater.... I attach a debugger to the
              >>> >> process (or modify the program) and ignore the block sourced time.
              >>> >>
              >>> >
              >>> > It's an iOS application. I would imagine it is substantially more
              >>> difficult
              >>> > to attach to a process (which, at the very least, requires root, and
              >>> perhaps
              >>> > other things on iOS) than to convince the device to change its system
              >>> time.
              >>> >
              >>> > That said, the security benefits might not be too substantial.
              >>> >
              >>> >
              >>> ------------------------------------------------------------------------------
              >>> > Want fast and easy access to all the code in your enterprise? Index and
              >>> > search up to 200,000 lines of code with a free copy of Black Duck
              >>> > Code Sight - the same software that powers the world's largest code
              >>> > search on Ohloh, the Black Duck Open Hub! Try it now.
              >>> > http://p.sf.net/sfu/bds
              >>> > _______________________________________________
              >>> > Bitcoin-development mailing list
              >>> > Bitcoin-development@lists•sourceforge.net
              >>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
              >>> >
              >>>
              >>>
              >>> ------------------------------------------------------------------------------
              >>> Want fast and easy access to all the code in your enterprise? Index and
              >>> search up to 200,000 lines of code with a free copy of Black Duck
              >>> Code Sight - the same software that powers the world's largest code
              >>> search on Ohloh, the Black Duck Open Hub! Try it now.
              >>> http://p.sf.net/sfu/bds
              >>> _______________________________________________
              >>> Bitcoin-development mailing list
              >>> Bitcoin-development@lists•sourceforge.net
              >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
              >>>
              >>
              >>
              >
              > --
              >
              > Aaron Voisine
              > breadwallet.com
              >
              
              [-- Attachment #2: Type: text/html, Size: 5263 bytes --]
              
              ^ permalink raw reply	[flat|nested] 14+ messages in thread

            • • * Re: [Bitcoin-development] Time
                  2014-07-25 16:03             ` Mike Hearn
                @ 2014-07-25 16:22               ` Natanael
                  2014-07-25 18:14                 ` Aaron Voisine
                  0 siblings, 1 reply; 14+ messages in thread
                From: Natanael @ 2014-07-25 16:22 UTC (permalink / raw)
                  To: Mike Hearn; +Cc: bitcoin-development
                
                [-- Attachment #1: Type: text/plain, Size: 5601 bytes --]
                
                Probably because the network isn't designed for interactive proofs. Most
                interactive algoritms AFAICT requires that some machine holds a secret
                state (or at least continuous and untampered state, but you still need to
                verify you're falling to the right machine), otherwise the machine can be
                mimicked and "rewound" to earlier states. Without a challenge-response that
                can't be faked, you've got problems.
                
                There's no trusted machines here that you can rely on. The certainty of
                having the right blockchain is a statistical one over longer periods of
                time, not enough for a PIN you want verified right now. So you can always
                be shown an old copy, and if your node isn't up to date yet then it can
                also be shown fake chains further into the future.
                
                Maybe you could throw in some kind of Secure Multiparty Computation among
                the miners to enable challenge-response, with state saved in the blockchain
                (so it can't be rolled back), but that would be fragile. How do you select
                what nodes may participate? How do you prevent the secret state from
                leaking? And performance would be absolutely horrible, and reliability is a
                huge problem.
                Den 25 jul 2014 18:03 skrev "Mike Hearn" <mike@plan99•net>:
                
                > Sorry, you're right. I'd have hoped a delay that doubles on failure each
                > time up to some max would be good enough, relying on the p2p network to
                > unlock a PIN feels weird, but I can't really quantify why or what's wrong
                > with it so I guess it's just me :-)
                >
                >
                > On Fri, Jul 25, 2014 at 4:45 PM, Aaron Voisine <voisine@gmail•com> wrote:
                >
                >> The problem is if someone moves system time forward between app launches.
                >> The lockout period doesn't have to be all that precise, it just makes you
                >> wait for the next block, then 5, then 25, and so on. Using a well
                >> known time server over https would also be a good option, but the wallet
                >> app already has the chain height anyway.
                >>
                >>
                >> On Friday, July 25, 2014, Mike Hearn <mike@plan99•net> wrote:
                >>
                >>>  Given that the speed at which the block chain advances is kind of
                >>> unpredictable, I'd think it might be better to just record the time to disk
                >>> when a PIN attempt is made and if you observe time going backwards, refuse
                >>> to allow more attempts until it's advanced past the previous attempt.
                >>>
                >>>
                >>> On Fri, Jul 25, 2014 at 7:56 AM, Aaron Voisine <voisine@gmail•com>
                >>> wrote:
                >>>
                >>>> It's based on the block height, not the block's timestamp. If you have
                >>>> access to the device and the phone itself is not pin locked, then you
                >>>> can jailbreak it and get access to the wallet seed that way. A pin
                >>>> locked device however is reasonably secure as the filesystem is
                >>>> hardware aes encrypted to a combination of pin+uuid. This was just an
                >>>> easy way to prevent multiple pin guesses by changing system time in
                >>>> settings, so that isn't the weakest part of the security model.
                >>>>
                >>>> Aaron Voisine
                >>>> breadwallet.com
                >>>>
                >>>>
                >>>> On Thu, Jul 24, 2014 at 8:21 PM, William Yager <will.yager@gmail•com>
                >>>> wrote:
                >>>> > On Thu, Jul 24, 2014 at 10:39 PM, Gregory Maxwell <gmaxwell@gmail•com
                >>>> >
                >>>> > wrote:
                >>>> >>
                >>>> >>
                >>>> >> Is breadwallet tamper resistant & zero on tamper hardware? otherwise
                >>>> >> this sounds like security theater.... I attach a debugger to the
                >>>> >> process (or modify the program) and ignore the block sourced time.
                >>>> >>
                >>>> >
                >>>> > It's an iOS application. I would imagine it is substantially more
                >>>> difficult
                >>>> > to attach to a process (which, at the very least, requires root, and
                >>>> perhaps
                >>>> > other things on iOS) than to convince the device to change its system
                >>>> time.
                >>>> >
                >>>> > That said, the security benefits might not be too substantial.
                >>>> >
                >>>> >
                >>>> ------------------------------------------------------------------------------
                >>>> > Want fast and easy access to all the code in your enterprise? Index
                >>>> and
                >>>> > search up to 200,000 lines of code with a free copy of Black Duck
                >>>> > Code Sight - the same software that powers the world's largest code
                >>>> > search on Ohloh, the Black Duck Open Hub! Try it now.
                >>>> > http://p.sf.net/sfu/bds
                >>>> > _______________________________________________
                >>>> > Bitcoin-development mailing list
                >>>> > Bitcoin-development@lists•sourceforge.net
                >>>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
                >>>> >
                >>>>
                >>>>
                >>>> ------------------------------------------------------------------------------
                >>>> Want fast and easy access to all the code in your enterprise? Index and
                >>>> search up to 200,000 lines of code with a free copy of Black Duck
                >>>> Code Sight - the same software that powers the world's largest code
                >>>> search on Ohloh, the Black Duck Open Hub! Try it now.
                >>>> http://p.sf.net/sfu/bds
                >>>> _______________________________________________
                >>>> Bitcoin-development mailing list
                >>>> Bitcoin-development@lists•sourceforge.net
                >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
                >>>>
                >>>
                >>>
                >>
                >> --
                >>
                >> Aaron Voisine
                >> breadwallet.com
                >>
                >
                >
                >
                > ------------------------------------------------------------------------------
                > Want fast and easy access to all the code in your enterprise? Index and
                > search up to 200,000 lines of code with a free copy of Black Duck
                > Code Sight - the same software that powers the world's largest code
                > search on Ohloh, the Black Duck Open Hub! Try it now.
                > http://p.sf.net/sfu/bds
                > _______________________________________________
                > Bitcoin-development mailing list
                > Bitcoin-development@lists•sourceforge.net
                > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
                >
                >
                
                [-- Attachment #2: Type: text/html, Size: 7571 bytes --]
                
                ^ permalink raw reply	[flat|nested] 14+ messages in thread

              • • * Re: [Bitcoin-development] Time
                    2014-07-25 16:22               ` Natanael
                  @ 2014-07-25 18:14                 ` Aaron Voisine
                    0 siblings, 0 replies; 14+ messages in thread
                  From: Aaron Voisine @ 2014-07-25 18:14 UTC (permalink / raw)
                    To: Natanael; +Cc: Bitcoin Development
                  
                  Yes, if the wallet isn't up to date yet, it uses the highest estimated
                  block height from connected peers, but that could be gamed by
                  controlling the network. The app has blockchain checkpoints in it
                  though, so you couldn't truncate the chain starting point below that.
                  The worst case is that you get a 4-5 extra guesses, but as I
                  mentioned, it'd be easier to just jailbreak the phone if the phone
                  itself isn't using a system wide pin lock. I just though it was a fun
                  and convenient way to prevent the system time hack. The system pin is
                  what protects your wallet in the event of physical theft, and the app
                  pin is just for when you lend your phone to a friend for a few
                  minutes.
                  
                  Aaron Voisine
                  breadwallet.com
                  
                  
                  On Fri, Jul 25, 2014 at 9:22 AM, Natanael <natanael.l@gmail•com> wrote:
                  > Probably because the network isn't designed for interactive proofs. Most
                  > interactive algoritms AFAICT requires that some machine holds a secret state
                  > (or at least continuous and untampered state, but you still need to verify
                  > you're falling to the right machine), otherwise the machine can be mimicked
                  > and "rewound" to earlier states. Without a challenge-response that can't be
                  > faked, you've got problems.
                  >
                  > There's no trusted machines here that you can rely on. The certainty of
                  > having the right blockchain is a statistical one over longer periods of
                  > time, not enough for a PIN you want verified right now. So you can always be
                  > shown an old copy, and if your node isn't up to date yet then it can also be
                  > shown fake chains further into the future.
                  >
                  > Maybe you could throw in some kind of Secure Multiparty Computation among
                  > the miners to enable challenge-response, with state saved in the blockchain
                  > (so it can't be rolled back), but that would be fragile. How do you select
                  > what nodes may participate? How do you prevent the secret state from
                  > leaking? And performance would be absolutely horrible, and reliability is a
                  > huge problem.
                  >
                  > Den 25 jul 2014 18:03 skrev "Mike Hearn" <mike@plan99•net>:
                  >
                  >> Sorry, you're right. I'd have hoped a delay that doubles on failure each
                  >> time up to some max would be good enough, relying on the p2p network to
                  >> unlock a PIN feels weird, but I can't really quantify why or what's wrong
                  >> with it so I guess it's just me :-)
                  >>
                  >>
                  >> On Fri, Jul 25, 2014 at 4:45 PM, Aaron Voisine <voisine@gmail•com> wrote:
                  >>>
                  >>> The problem is if someone moves system time forward between app launches.
                  >>> The lockout period doesn't have to be all that precise, it just makes you
                  >>> wait for the next block, then 5, then 25, and so on. Using a well known time
                  >>> server over https would also be a good option, but the wallet app already
                  >>> has the chain height anyway.
                  >>>
                  >>>
                  >>> On Friday, July 25, 2014, Mike Hearn <mike@plan99•net> wrote:
                  >>>>
                  >>>> Given that the speed at which the block chain advances is kind of
                  >>>> unpredictable, I'd think it might be better to just record the time to disk
                  >>>> when a PIN attempt is made and if you observe time going backwards, refuse
                  >>>> to allow more attempts until it's advanced past the previous attempt.
                  >>>>
                  >>>>
                  >>>> On Fri, Jul 25, 2014 at 7:56 AM, Aaron Voisine <voisine@gmail•com>
                  >>>> wrote:
                  >>>>>
                  >>>>> It's based on the block height, not the block's timestamp. If you have
                  >>>>> access to the device and the phone itself is not pin locked, then you
                  >>>>> can jailbreak it and get access to the wallet seed that way. A pin
                  >>>>> locked device however is reasonably secure as the filesystem is
                  >>>>> hardware aes encrypted to a combination of pin+uuid. This was just an
                  >>>>> easy way to prevent multiple pin guesses by changing system time in
                  >>>>> settings, so that isn't the weakest part of the security model.
                  >>>>>
                  >>>>> Aaron Voisine
                  >>>>> breadwallet.com
                  >>>>>
                  >>>>>
                  >>>>> On Thu, Jul 24, 2014 at 8:21 PM, William Yager <will.yager@gmail•com>
                  >>>>> wrote:
                  >>>>> > On Thu, Jul 24, 2014 at 10:39 PM, Gregory Maxwell
                  >>>>> > <gmaxwell@gmail•com>
                  >>>>> > wrote:
                  >>>>> >>
                  >>>>> >>
                  >>>>> >> Is breadwallet tamper resistant & zero on tamper hardware? otherwise
                  >>>>> >> this sounds like security theater.... I attach a debugger to the
                  >>>>> >> process (or modify the program) and ignore the block sourced time.
                  >>>>> >>
                  >>>>> >
                  >>>>> > It's an iOS application. I would imagine it is substantially more
                  >>>>> > difficult
                  >>>>> > to attach to a process (which, at the very least, requires root, and
                  >>>>> > perhaps
                  >>>>> > other things on iOS) than to convince the device to change its system
                  >>>>> > time.
                  >>>>> >
                  >>>>> > That said, the security benefits might not be too substantial.
                  >>>>> >
                  >>>>> >
                  >>>>> > ------------------------------------------------------------------------------
                  >>>>> > Want fast and easy access to all the code in your enterprise? Index
                  >>>>> > and
                  >>>>> > search up to 200,000 lines of code with a free copy of Black Duck
                  >>>>> > Code Sight - the same software that powers the world's largest code
                  >>>>> > search on Ohloh, the Black Duck Open Hub! Try it now.
                  >>>>> > http://p.sf.net/sfu/bds
                  >>>>> > _______________________________________________
                  >>>>> > Bitcoin-development mailing list
                  >>>>> > Bitcoin-development@lists•sourceforge.net
                  >>>>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
                  >>>>> >
                  >>>>>
                  >>>>>
                  >>>>> ------------------------------------------------------------------------------
                  >>>>> Want fast and easy access to all the code in your enterprise? Index and
                  >>>>> search up to 200,000 lines of code with a free copy of Black Duck
                  >>>>> Code Sight - the same software that powers the world's largest code
                  >>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
                  >>>>> http://p.sf.net/sfu/bds
                  >>>>> _______________________________________________
                  >>>>> Bitcoin-development mailing list
                  >>>>> Bitcoin-development@lists•sourceforge.net
                  >>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
                  >>>>
                  >>>>
                  >>>
                  >>>
                  >>> --
                  >>>
                  >>> Aaron Voisine
                  >>> breadwallet.com
                  >>
                  >>
                  >>
                  >>
                  >> ------------------------------------------------------------------------------
                  >> Want fast and easy access to all the code in your enterprise? Index and
                  >> search up to 200,000 lines of code with a free copy of Black Duck
                  >> Code Sight - the same software that powers the world's largest code
                  >> search on Ohloh, the Black Duck Open Hub! Try it now.
                  >> http://p.sf.net/sfu/bds
                  >> _______________________________________________
                  >> Bitcoin-development mailing list
                  >> Bitcoin-development@lists•sourceforge.net
                  >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
                  >>
                  >
                  
                  
                  
                  ^ permalink raw reply	[flat|nested] 14+ messages in thread

• * Re: [Bitcoin-development] Time
    2014-07-25  1:14 [Bitcoin-development] Time Ron OHara
    2014-07-25  1:41 ` Jeff Garzik
    2014-07-25  2:35 ` Aaron Voisine
  @ 2014-07-25 10:30 ` Mike Hearn
    2014-07-27 22:22   ` Peter Todd
    2014-07-28 17:33   ` Troy Benjegerdes
    2 siblings, 2 replies; 14+ messages in thread
  From: Mike Hearn @ 2014-07-25 10:30 UTC (permalink / raw)
    To: Ron OHara; +Cc: Bitcoin Dev
  
  [-- Attachment #1: Type: text/plain, Size: 1738 bytes --]
  
  >
  > 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.
  
  Also remember that currently the chain could be dominated by a coalition of
  just two pools.
  
  
  > 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.
  
  
  > 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 ......
  
  
  > So if this presumption is correct, then we can now build time capsule
  > applications that can not be tricked into exposing their contents too
  > early by running them in a virtual environment with the wrong system time.
  
  
  If you have a tamper resistant execution environment (TXT, SGX, Flicker
  etc) then yes. However trusted execution environments sometimes have tamper
  resistant clocks as well for exactly this reason. So whether this technique
  makes sense depends a lot on the details of your configuration, I think.
  
  [-- Attachment #2: Type: text/html, Size: 2612 bytes --]
  
  ^ permalink raw reply	[flat|nested] 14+ messages in thread

• • * Re: [Bitcoin-development] Time
      2014-07-25 10:30 ` Mike Hearn
    @ 2014-07-27 22:22   ` Peter Todd
      2014-07-28 17:33   ` Troy Benjegerdes
      1 sibling, 0 replies; 14+ messages in thread
    From: Peter Todd @ 2014-07-27 22:22 UTC (permalink / raw)
      To: Mike Hearn; +Cc: Bitcoin Dev, Ron OHara
    
    [-- 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 --]
    
    ^ permalink raw reply	[flat|nested] 14+ messages in thread

  • * Re: [Bitcoin-development] Time
      2014-07-25 10:30 ` Mike Hearn
      2014-07-27 22:22   ` Peter Todd
    @ 2014-07-28 17:33   ` Troy Benjegerdes
      1 sibling, 0 replies; 14+ messages in thread
    From: Troy Benjegerdes @ 2014-07-28 17:33 UTC (permalink / raw)
      To: Mike Hearn; +Cc: Bitcoin Dev, Ron OHara
    
    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.
    >
    >
    > Also remember that currently the chain could be dominated by a coalition of
    > just two pools.
    
    There's a solution to both of these problems..
    
    https://github.com/CatcoinOfficial/CatcoinRelease/commit/0d03a5b3d8bb7bc3c935e7196c5d807da997cf9c
    
    If you want a really reliable time source, use at least three block chains and
    make sure they all agree within an hour.
     
    > 
    > > 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.
    > 
    > 
    > > 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).
    
    Well, being as how I don't trust Bitcoin anyway because it includes SSL, yes,
    you could get 'bitcoin-level' trust.
    
    > If we crack the mining decentralisation problem then this argument becomes
    > a lot stronger, but for now ......
    
    But if you actually want something secure, you look at the altcoin space
    which solved the mining decentralization problem when Litecoin came out, 
    and this also solves the having to trust a single source code base. There
    is lots of code diversity out there in altcoins, and what appears to me to
    be a really strong cryptographically sound time source, but only if you use
    multiple diverse sources.
    
    
    -- 
    ----------------------------------------------------------------------------
    Troy Benjegerdes                 'da hozer'                  hozer@hozed•org
    7 elements      earth::water::air::fire::mind::spirit::soul        grid.coop
    
          Never pick a fight with someone who buys ink by the barrel,
             nor try buy a hacker who makes money by the megahash
    
    
    
    
    ^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2014-07-28 18:14 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-25  1:14 [Bitcoin-development] Time 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
2014-07-28 17:33   ` Troy Benjegerdes

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox