|hearn: there's a difference between your node degrading, and your node breaking entirely
|i'm not so sure. by analogy to RNGs, a degraded RNG looks like it's operating correctly, but is often the same as a fully broken rng (i.e. giving you all zeros)
|but one is a lot more detectable than another
|and the issue for me is detectability. e.g. i'd be totally cool with an -spv switch that says to a full node "don't run scripts for now", and then if your node starts saying "I think I don't know about some rules used by the new majority" such as triggered by block version, it'd require a restart with that flag
|then the operator can reason about what impact that might have on their business, if any, and the node can stop serving the block chain to other peers, etc.
|anyway, in the end, i don't care all that much. we'll muddle through no matter what
|hearn: Detectability can be fully addressed though. E.g. transactions showing up with 'future' versions and using nopcodes are something you could notice... more formalism could be given to detection there.
|s1w is now known as SomeoneWeird
|SomeoneWeird is now known as s1w
|I'm just surprised broken RNGs like the one from blockchain even happen very often, as an easy spot check would be to call the RNG twice and generate a signature using the same data aside from what you called from the RNG, and then see if it ever outputs the same thing twice.
|I imagine you could make it do this lots and lots of times in testing.
|It would have caught the reused R-values, I would guess..
|01swap.com - Make money by selling your files for Bitcoins!
|andytoshi has kicked swap01 from #bitcoin-wizards
|tacotime, broken prngs aren't generally that easy to spot
|Sub|afk is now known as SubCreative
|they often look random, but if you can guess the seed value (often time) then you can eventually re-generate the privkey with a little luck
|tacotime: i bet you could come up with half a dozen rng failure modes on the same order of "obviously broken" as a constant output .. agreed that sanity checking wouldn't work, but i also think it's probably not worth the effort
|as brand0 says, no matter what you do it can break just as seriously in a way you didn't consider
|o.O s/wouldn't work/couldn't hurt/
|yeah i was wondering about that bit
|but right, i feel like you should at least sanity check to vs simple mistakes
|there's always stuff you can't control, but you should make sure that it meets some minimum sane behaviour. at least in terms of signature generation that people's money is relying on. :/
|yeah, that's the problem with prng
|they can be difficult to audit
|looking at the source is helpful, but you don't always get it
|tacotime: that ssuggests software is tested. My expirence is that most software is not tested at all, most of what is ... is only tested lightly.
|* kanzure wrote +1000 lines of tests today
|maybe we should make a wiki page of Bad Things That Happen When You Don't Make Test Cases.
|Writing software that can be tested in a meaningful way is a substantial increase in effort. And from from toolsets its not really reasonably possible to say that you've actually tested all of the execution space of the program.
|(as of a few seconds ago, actually... what year is this? who are you people?)
|tacotime: but even those words are bad. right, unit testing isn't enough. Unit testing would have hapily passed the prior bc.i rng bug with webworkers... because the unit test doesn't run in an identical enviroment to the code. They're just one tool in the box.
|Yeah, I know with btcd we have a lot of test coverage (100% in a lot of places), but a lot of it is just cursory testing to tell you if you've obviously broken something.
|i wonder if abusing webworkers through webkitgtk+ gobject bindings still counts as a unit test
|tacotime: often coverage driving testing produces pretty meaningless tests that just happen to make the code go. Better than nothing, perhaps, though it lowers the usefulness of coverage analysis.
|unit testing is mostly a defense against regression -- problems you
|already know about
|devising tests for scenarios i don't know about is definitely tricky :)
|In complex systems most tests are ineffective ... they're not going to tell you about race conditions, or about an attacker being able to drive the system into a state where a exception is thrown because you've run out of memory and doom results, etc.
|Well. Golang has a race tester, though I'm not sure how effective it is. Though I have seen it catch races.
|tacotime: sure, it's somewhat similar to DRD. ... useful but it isn't sound.
|(I mean, it can tell you if there is a race that you're triggering, but it can't prove your software free of races.)
|For security we actually want soundness.
|testing it one tool, nothing can replace careful programming practices and auditing
|kanzure: well I know how to do it. You use mutation testing: Once the tests are complete enough, you start adding bugs in the software (including randomly).
|and then there's things like internal consistency vs consistency against your local bitcoind node's knowledge of the current blockchain
|(for which i think i can probably safely steal bitcoind-related tests)
|Keefe_ is now known as Keefe
|gmaxwell: although automated testing wouldn't have caught the webworkers bug with bc.i, or the bug where msCrypto wasn't being used, or the bug where window.crypto wasn't being used, a codebase with tests at least suggests that there's some oversight of your codebase.
|to generalize what greg said earlier: the problem often seems to be not realizing what types of errors could exist
|not testing those is just a symptom of that
|especially in security-critical systems there are many more classes of mistakes that are relevant
|op_mul: to be fare, for propritary systems there may be substantial testing thats just not visible to the public. (not that I'd recommend depending on that...)
|well; the bc.i problem could have been tested for if the testing came shipped in the code and was performed before publishing the generated sig to the user (e.g. make 256 signatures first to verify that even in this environment R values are not being reused).
|but maybe having your code self-slowing that much is a problem to the end user.
|tacotime: that requires 1) realizing that the RNG is a relevant part of the cryptographic system and 2) that reusing R is dangerous
|tacotime: if they would have realized those two things, they 1) wouldn't have written the same code and 2) likely have tests for it
|tacotime: that's not even the problem. having a weak k is just as dangerous as duplicating R. if they had say, a 64 bit RNG rather than an 8 bit one, people would still have lost money and that test would have passed.
|that predicatable R is dangerous. (arguably that it was predictable was much worse; and a lot of people mistakingly believe that reuse is required for key leaking)
|but saying "testing this is easy!" is not relevant - the problem wasn't that this is hard, the problem is not knowing it could be wrong
|yea, "For knowing where to put the chalk mark, $9,999."
|yeah. i guess comprehension of the signing algos is not always a requirement for using them.
|( for context http://web.mit.edu/president/communications/com99.html )
|sony has proven that too.
|I don't know how sony managed that. gross misreading of the docs?
|tacotime: not even implementing them. Virtually none of the people writing software for this stuff have even the foggiest clue what they're doing, they follow tutorials (often also written by people learning the subject)
|tacotime: you don't need to know algorothms, implementation or security prpofs for cryptpgraphic systems
|tacotime: but you do need to know under what conditions they are safe to use, and for what purpose and against what attacks
|yeah. i'll probably ask questions about stealth addresses once i get to playing with coding for that. and the chaumian blinding stuff from oleg, i meant to turn that code snippet into something useful. though i'm not sure it's implemented 100% correctly, i'm just going by the snippet posted to gist.
|This is part of the reason that all these straight into the weeds tutorials on ECC make me sad. They dive straight into a blow by blow implementation written in english and fail to convey any overarching understanding. The reader walks away able to implement but maybe not safely use, or implement correctly.
|is there an ECC list of "Things To Look Out For" somewhere?
|Cryptography list of things to look out for: look out for lists of thing to look out for.
|I'm not actually sure that lists are counterproductive, but they're less helpful than they can appear, because every darn part matters... and no formula can make things right. Certantly if you _only_ apply the checklist you're in trouble.
|a little bit of knowledge about ECC is quite dangerous too, there's a number of people on reddit running around telling people not to reuse addresses because it saves you from RNG problems.
|if you only use the address once, dup R can't hurt you right? right?
|even if that were true, signing two outputs would reveal your private key and then it would just be a double spend race.
|gmaxwell: Well, maybe a list of "bad things that happened when someone did something they thought did something else, and here's why it didn't work the way they thought it did."
|tacotime: common failure modes are not handling the group vs field order quite right or tracking what values are what. Everyone that gives 101 tutorials gives people group law which has special cases which must be implemented right, involving comparisons you can get wrong. Most academic discussions ignore details like having to multiply points by the cofactor to avoid subgroup confinement attack
|It would be kind of an interesting read at least.
|s (fortunately not an issue for secp256k1), or having to verify that points recieved from the network are actually on the curve.
|A lot of crypto code has fallen due to seralization bugs or interactions with seralization and the crypto.
|That makes sense.
|Similar to the group law stuff that everyone describes in a way that is harder to implement correctly, the tutorial grade explinations of this stuff have huge timing sidechannels, which maybe more things should worry more about.
|ahmed_ is now known as ahmed_bodi
|ahmed_bodi is now known as ahmedbodi
|Adlai` is now known as adlai
|maaku is now known as Guest17958
|Guest17958 is now known as maaku
|o3u is now known as Fistful_of_Coins
|topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
|Users on #bitcoin-wizards: andy-logbot Guyver2 paveljanik samson_ e1782d11df4c9914 ryanxcharles zooko` maaku vmatekole NewLiberty TheSeven catlasshrugged Emcy roconnor Starduster op_mul dgenr8 copumpkin mortale MoALTz_ tacotime DougieBot5000 stonecoldpat Shiftos sl01 optimator jaekwon atgreen [d__d] koshii rasengan cluckj ysangkok adlai wiz shesek null_radix ebfull JonTitor pigeons pi07r_ OneFixt Fistful_of_Coins roasbeef_ SubCreative Keefe hktud0 grandmaster luny
|Users on #bitcoin-wizards: digitalmagus8 Transisto hollandais BigBitz_ [\\\] michagogo Muis_ mappum epscy gnusha poggy _Iriez Meeh_ otoburb mr_burdell s1w go1111111 bsm117532 HM2 Apocalyptic sdaftuar waxwing btcdrak CryptOprah kumavis btc__ jbenet nuke1989 nsh Guest19027 jcorgan wizkid057 PaulCapestany forrestv jgarzik Luke-Jr tromp_ PRab c0rw1n hashtagg LarsLarsen Greed Dyaheon lclc_bnc spinza harrow @gmaxwell gavinandresen NikolaiToryzin Cory isis iddo sadgit brand0 eric
|Users on #bitcoin-wizards: Krellan berndj @ChanServ jaromil petertodd tromp helo v3Rve midnightmagic espes__ fluffypony butters nickler Logicwax lnovy ahmedbodi warren fenn phantomcircuit Graet morcos BrainOverfl0w phedny so crescendo throughnothing Taek burcin livegnik sipa harrigan sneak yoleaux azariah kinlo Guest38445 warptangent lechuga_ andytoshi Nightwolf comboy a5m0 K1773R asoltys_ Alanius mmozeiko smooth ryan-c TD-Linux catcow danneu starsoccer EasyAt DoctorBTC
|Users on #bitcoin-wizards: bbrittain heath toddf dansmith_btc wumpus gwillen AdrianG hguux_ nanotube Eliel Anduck cfields BlueMatt coutts coryfields artifexd amiller BananaLotus huseby bobke Graftec MRL-Relay gribble kanzure
|SubCreative is now known as Sub|zz
|ahmedbodi is now known as ahmed_
|wallet421 is now known as wallet42
|BigBitz_ is now known as BigBitz
|Aquent1 is now known as Aquent
|Sub|zz is now known as SubCreative
|Aquent is now known as aquentin
|aquentin is now known as Aquent
|Guyver2 has left #bitcoin-wizards
|Sorry if this has been covered, but is storj following the original idea? If so, why does it need its own blockchain?
|justanotheruser, it is not following the original idea at all
|justanotheruser, two totally different things, same project names!
|their claims seem to be very close to the original idea
|are they lying, or using fancy wording to make it sound like it does the same thing/
|Meeh_ is now known as Meeh
|justanotheruser, something tells me you can make an educated guess on that one
|Well naming it something that it isn't is a form of lying, so I'm going to go with A) They are saying it follows the original idea perfectly when it doesn't.