| 06:05:11 | nsh_: | nsh_ is now known as nsh |
| 06:50:24 | gmaxwell: | Oh The 4764 showed up... weee! |
| 07:42:14 | sipa: | the 4764? |
| 08:04:36 | Emcy: | wasnt that a tv show |
| 15:05:25 | nsh_: | nsh_ is now known as nsh |
| 16:26:22 | jgarzik: | jgarzik is now known as home_jg |
| 19:29:14 | shinybro__: | shinybro__ is now known as shinybro_ |
| 19:53:43 | diesel_: | diesel_ is now known as Dizzle |
| 20:55:07 | warren: | https://bitcointalk.org/index.php?topic=581411.0 more bad random numbers |
| 20:56:09 | nsh_: | ouch |
| 20:56:15 | hearn: | bitcoinj uses deterministic ecdsa in git master |
| 20:56:33 | hearn: | this sort of thing happens way too often :( |
| 20:56:42 | nsh_: | when are we likely to have blind/deterministic signing? ever? |
| 20:56:58 | hearn: | deterministic ecdsa _is_ deterministic signing. |
| 20:57:15 | hearn: | that said, the usual root cause is bad RNGs, and if you have a bad RNG the keys can still be breakable even if the signatures aren’t |
| 20:57:22 | hearn: | so i’m not sure how much it really helps |
| 20:57:26 | nsh_: | true |
| 20:57:58 | sipa: | hearn: for generating your deterministic wallet seed, you can afford to spend a lot more effort in gathering randomness etc |
| 20:57:59 | nsh_: | but you can't fix everyone's RNGs, whereas you can steel-cap their boots a bit |
| 20:58:14 | hearn: | that’s true |
| 20:58:17 | phantomcircuit: | warren, lol, cant say i feel bad for people using bc.i and counterparty |
| 20:58:19 | sipa: | after which, assuming no ECDSA and SHA256 breaks, deterministic signatures are safe |
| 20:58:23 | phantomcircuit: | talk about playing with fire |
| 20:58:36 | hearn: | i was thinking on mobile phones you could ask the user to take a photo and then just hash the pixels and mix it into the rng entropy |
| 20:58:44 | hearn: | though … again …. if your rng is bad …. that might just do nothing :) |
| 20:59:03 | sipa: | it can't hurt (except false sense of security) |
| 20:59:19 | tacotime: | Counterparty made a formal statement about it |
| 20:59:21 | tacotime: | https://bitcointalk.org/index.php?topic=395761.msg6354587#msg6354587 |
| 20:59:22 | gmaxwell: | can also contribute to paranoia. |
| 20:59:49 | tacotime: | unfortunately the second major security flaw to be exploited, but at least it wasn't in the protocol this time. |
| 21:00:01 | sipa: | "take a picture of your face, your fingerprints, your house, the street sign and your bank records" |
| 21:00:09 | gmaxwell: | yea... |
| 21:00:14 | nsh_: | (there's probably better/more-reliable hardware entropy in a phone than the camera, depending on what you can garner from the radio circuits) |
| 21:00:18 | gmaxwell: | tacotime: what was the bitcoin-js bug? was it the wrapping the rng code in a try block and doing nothing useful if it failed? If so I've complained about that many times. :( |
| 21:00:53 | nsh_: | nsh_ is now known as nsh |
| 21:00:54 | tacotime: | gmaxwell, I think that was it, apparently the vulnerability for counterwallet was well known in some circles for weeks now. |
| 21:00:56 | gmaxwell: | nsh_: The camera is probably the best accessible thing, though you may have fun like the OS keeping a copy of the picture. |
| 21:01:20 | nsh: | mmm |
| 21:01:41 | sipa: | "please sing your national hymn into the microphone" |
| 21:01:46 | nsh: | * nsh smiles |
| 21:01:53 | hearn: | https://gist.github.com/dcousens/7a54e59a98e445c5ec2f |
| 21:02:02 | hearn: | root cause of the failure - lack of type safety in javascript |
| 21:02:54 | hearn: | writing wallet code in java scares me because the type system is so weak. doing it in js would make me want to cry |
| 21:02:57 | tacotime: | ah, thanks hearn |
| 21:03:12 | phantomcircuit: | hearn, the Java type system is weak? |
| 21:03:13 | phantomcircuit: | wat |
| 21:03:50 | gmaxwell: | phantomcircuit: yes, it's overly helpful. |
| 21:04:02 | hearn: | nsh: yes sure. but remember the android screwup. the system random source … wasn’t. hashing camera pixels and mixing them in via sha256(pixels||system entropy) is robust |
| 21:04:06 | phantomcircuit: | gmaxwell, example? |
| 21:04:08 | sipa: | phantomcircuit: ever used haskell? :p |
| 21:04:16 | hearn: | phantomcircuit: it’s nowhere near as strong as i’d like. |
| 21:04:24 | nsh: | * nsh nods |
| 21:04:31 | phantomcircuit: | sipa, explicit conversion everywhere... |
| 21:04:34 | hearn: | there are things like Checker Framework that can help a lot, using annotations magic. |
| 21:04:48 | hearn: | and of course modern JVM languages tend to have much better type systems. but i can’t use those :( |
| 21:04:52 | gmaxwell: | Interesting to see that this was actually something using a determinstic nonce, and their use of the hashfunction was undermined by high level abstractions that didn't do what they thought they did. |
| 21:04:59 | hearn: | stupid android still being on java 6 |
| 21:07:41 | hearn: | phantomcircuit: e.g. it’s hard to define custom numeric types. no operator overloading, autoboxing is custom magic, etc. it’s hard to enforce immutability without insanely ugly patterns |
| 21:07:47 | gmaxwell: | Also, this might be an example of the importance of using a specified actually determinstic DSA: it would have been caught by unit tests that checked that the signature for a given private key and message was precisely what it was expected to be. But wouldn't have been caught with rests expecting a signer that used H(private||message||entropy). |
| 21:08:03 | hearn: | no real notion of constness |
| 21:08:34 | hearn: | no compiler enforced purity. just lots of things where it’s lacking. |
| 21:09:05 | gmaxwell: | s/rests/tests/ |
| 21:10:03 | phantomcircuit: | gmaxwell, H(H(private||message)||entropy) and have the unit tests be for H(private||message) |
| 21:10:22 | phantomcircuit: | that wont catch entropy being static though |
| 21:10:56 | gmaxwell: | phantomcircuit: I'm not following you. How do you catch that the K is a constant when you can't test for K because its unpredictable? |
| 21:11:56 | sipa: | you can have unit tests that pass the entropy explicitly |
| 21:12:00 | sipa: | but that is a different issue |
| 21:12:04 | phantomcircuit: | gmaxwell, this would at least catch the hash function being broken but i guess it would be easier to just do H(k) |
| 21:12:21 | gmaxwell: | You can, but say E.g. say that the code that is supposted to compute G*K instead computes G*constant (because some crazy library changed and now casting any H() output to an integer yields 1)? |
| 21:13:09 | gmaxwell: | vs a fully determinstic signer is a bit easier to test, since you can have a list of private keys, messages, and signatures.. and they just have to match. |
| 21:13:42 | gmaxwell: | I suppose as sipa notes you could break out the entropy input and have the tests and that would be equally good. |
| 21:14:14 | gmaxwell: | private key, message, entropy, signature... and its still secure if the entropy is bad due to the structure. |
| 21:16:41 | phantomcircuit: | gmaxwell, that's what i was trying to get at but yeah just using static entropy values would probably work better |
| 22:55:54 | gavinandresen_: | gavinandresen_ is now known as gavinandresen |
| 22:55:56 | Dizzle: | Dizzle is now known as Guest93781 |
| 22:59:49 | nsh: | what might this mean? "Found an address which has had a lot of blocks mined into it, and its been flagged for double spending." (blockchain.info) https://blockchain.info/address/1ALA5v7h49QT7WYLcRsxcXqXUqEqaWmkvw |
| 23:01:09 | Luke-Jr: | nsh: it means blockchain.info is stupid as usual? |
| 23:01:18 | nsh: | sounds plausible |
| 23:01:24 | Luke-Jr: | for me it says: 警告！此比特币地址的交易中可能存在多重支付。凡与此地址进行任何付款或收款操作时，都要保持高度警惕。 |
| 23:01:33 | Luke-Jr: | * Luke-Jr kicks blockchain.info for forcing him into Japanese |
| 23:01:41 | sipa: | also, offtopic |
| 23:02:46 | nsh: | someone thought it might be related to the Finney attacks discussed on the list recently, is why i asked. but i guess it's not |
| 23:03:06 | gmaxwell: | just addressing the technical thing; I think orphaned coinbases may trigger that warning. |