[Bitcoin-development] Time

[Bitcoin-development] Time

[Ron OHara]

-----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-----

Re: [Bitcoin-development] Time

[Jeff Garzik]

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/

Re: [Bitcoin-development] Time

[Aaron Voisine]

[-- 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 --]

Re: [Bitcoin-development] Time

[Gregory Maxwell]

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.

Re: [Bitcoin-development] Time

[William Yager]

[-- 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 --]

Re: [Bitcoin-development] Time

[Aaron Voisine]

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
>

Re: [Bitcoin-development] Time

[Mike Hearn]

[-- 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 --]

Re: [Bitcoin-development] Time

[Aaron Voisine]

[-- 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 --]

Re: [Bitcoin-development] Time

[Mike Hearn]

[-- 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 --]

Re: [Bitcoin-development] Time

[Natanael]

[-- 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 --]

Re: [Bitcoin-development] Time

[Aaron Voisine]

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
>>
>

Re: [Bitcoin-development] Time

[Mike Hearn]

[-- 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 --]

Re: [Bitcoin-development] Time

[Peter Todd]

[-- 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 --]

Re: [Bitcoin-development] Time

[Troy Benjegerdes]

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