Re: [Bitcoin-development] Time
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' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Time
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 201d505432d708aa2edb656f6fe34d686b37d4747e5ff389 signature.asc Description: Digital 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
Re: [Bitcoin-development] Time
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. -- 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
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 vois...@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.ya...@gmail.com wrote: On Thu, Jul 24, 2014 at 10:39 PM, Gregory Maxwell gmaxw...@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 -- 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
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 m...@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 vois...@gmail.com javascript:_e(%7B%7D,'cvml','vois...@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.ya...@gmail.com javascript:_e(%7B%7D,'cvml','will.ya...@gmail.com'); wrote: On Thu, Jul 24, 2014 at 10:39 PM, Gregory Maxwell gmaxw...@gmail.com javascript:_e(%7B%7D,'cvml','gmaxw...@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 -- 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
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 vois...@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 m...@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 vois...@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.ya...@gmail.com wrote: On Thu, Jul 24, 2014 at 10:39 PM, Gregory Maxwell gmaxw...@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
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 m...@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 vois...@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 m...@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 vois...@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.ya...@gmail.com wrote: On Thu, Jul 24, 2014 at 10:39 PM, Gregory Maxwell gmaxw...@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!
Re: [Bitcoin-development] Time
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 natanae...@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 m...@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 vois...@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 m...@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 vois...@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.ya...@gmail.com wrote: On Thu, Jul 24, 2014 at 10:39 PM, Gregory Maxwell gmaxw...@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
[Bitcoin-development] Time
-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
Re: [Bitcoin-development] Time
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.ohar...@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 -- 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
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.ohar...@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/ -- 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
On Thu, Jul 24, 2014 at 7:35 PM, Aaron Voisine vois...@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. -- 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
On Thu, Jul 24, 2014 at 10:39 PM, Gregory Maxwell gmaxw...@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
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.ya...@gmail.com wrote: On Thu, Jul 24, 2014 at 10:39 PM, Gregory Maxwell gmaxw...@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
[Bitcoin-development] Time for a 0.8.2 release
Consensus in #bitcoin-dev chat is that it is time to do a 0.8.2 release. A few important bugs have been fixed, and the goal will be to get a 0.8.2 final release before the May 15'th hard fork deadline. Pieter has already started going through the issues list; help with testing, debugging, and fixing high-priority issues is very welcome. I'll also be going through the issues list and marking any issues I think need to be fixed with the '0.8.2' milestone. If translation work needs to be done, now is a great time to do it. We still don't have a basic QA checklist for testing of release candidates; I'll commit to spending a little of the remaining Bitcoin Testing Project bitcoins to whoever contributes to creating one. -- -- Gavin Andresen -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
