00:52:38op_mul:gmaxwell: I'm not sure I'd call that suicidal so long as you're keeping track of which keys use which nonces. at that point though you'd probably be getting off getting a less-shit HSM though.
00:54:16op_mul:you also make it alarmingly obvious which transactions are yours. nobody else has that behaviour. part of the reason I think it's intentional is that the signer uses compressed points, if it was just a stupid Sony-level implementation they wouldn't be doing that.
02:23:05nanotube:BlueMatt, gmaxwell, do you want gribble here? can be easily arranged, once my server issues are solved.
07:52:38lclc_bnc:lclc_bnc is now known as lclc
08:22:36lclc:lclc is now known as lclc_bnc
08:43:53SubCreative:SubCreative is now known as Sub|zzz
08:47:24lclc_bnc:lclc_bnc is now known as lclc
09:05:17sinisalo.freenode.net: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
09:05:17sinisalo.freenode.net:Users on #bitcoin-wizards: andy-logbot soundx justanotheruser bvu adam3us NewLiberty RoboTeddy paveljanik kyletorpey Shiftos TheSeven zooko`` nullbyte gribble roconnor ryanxcharles ebfull Dr-G2 d1ggy_ hashtagg op_mul devrandom hashtag_ epscy PaulCapestany austeritysucks Greed shesek moa tacotime nuke1989 Iriez ajweiss cluckj mortale adlai BlueMatt mbelshe Emcy_ Graftec Guest79176 NikolaiToryzin Graet wizkid057 jaekwon DoctorBTC dansmith_btc waxwing Starduster luny
09:05:17sinisalo.freenode.net:Users on #bitcoin-wizards: Transisto midnightmagic butters starsoccer huseby samson_ nubbins` Grishnakh Luke-Jr Sub|zzz dgenr8 BrainOverfl0w yoleaux burcin [d__d] gavinandresen danneu catcow TD-Linux ryan-c smooth Alanius AdrianG tromp Fistful_of_coins pigeons Dyaheon- Cory jbenet livegnik bbrittain MRL-Relay atgreen lechuga_ pi07r sadgit throughnothing poggy JonTitor nsh iddo hollandais Guest8623 Tjopper LarsLarsen Muis kumavis michagogo artifexd lnovy cfields btc__
09:05:17sinisalo.freenode.net:Users on #bitcoin-wizards: rasengan gavink hguux_ Hunger-- Meeh yrashk a5m0 jgarzik Keefe berndj fluffypony morcos spinza bosma Logicwax maaku copumpkin stonecoldpat sl01 optimator wiz null_radix roasbeef_ hktud0 BigBitz [\\\] mappum gnusha otoburb mr_burdell s1w go1111111 HM2 Apocalyptic sdaftuar btcdrak CryptOprah jcorgan forrestv tromp_ PRab lclc harrow @gmaxwell isis brand0 eric Krellan @ChanServ jaromil petertodd helo v3Rve espes__ nickler ahmed_ warren fenn
09:05:17sinisalo.freenode.net:Users on #bitcoin-wizards: phantomcircuit kanzure bobke BananaLotus coryfields Anduck Eliel nanotube gwillen wumpus heath EasyAt asoltys_ K1773R comboy @andytoshi warptangent Guest38445 kinlo azariah sneak @sipa Taek crescendo so phedny
09:35:44lclc:lclc is now known as lclc_bnc
10:24:52lclc_bnc:lclc_bnc is now known as lclc
11:14:32lclc:lclc is now known as lclc_bnc
12:05:48thesnark:thesnark is now known as narwh4l
12:22:30lclc_bnc:lclc_bnc is now known as lclc
12:32:57jcluck:jcluck is now known as cluckj
13:44:17nsh:gmaxwell: " Anyone know if the 8 new OpenSSL CVE's affect LibreSSL as well?"
13:44:38nsh:what's the simplest advice i can give people to regression test against libsepc256k efficiently?
13:44:51nsh:or however elsewise you'd advise testing
13:45:14gmaxwell:nsh: I'm not sure of the context.
13:45:19Profreid_:Profreid_ is now known as Profreid
13:45:40nsh:presumably they want to know if the BN_sqr issue affects libre
13:45:45nsh:and other issues in the disclosure
13:45:55nsh:*advisory
13:46:00nsh:https://www.openssl.org/news/secadv_20150108.txt
13:46:48lclc:lclc is now known as lclc_bnc
13:47:10gmaxwell:nsh: almost certantly.
13:47:39gmaxwell:(and if not, thats even more concerning, perhaps)
13:47:47nsh:* nsh nods
13:48:57nsh:as a matter of curiosity, i found it (the relevant openssl code) an alarmingly complex a set of assembly and C hodgepodge just for squaring big numbers
13:49:26nsh:is that just a consequence of x86 legacy complexity and compiler complexity?
13:50:06nsh:i doesn't seem, intuitively, that there's very much,mm, scope - mathematically - to make a squaring operation on large numbers that complex to execute
13:50:31sl01:maybe ioccc was setup by the nsa to get ideas for openssl :x
13:51:02gmaxwell:nsh: well the C code is broken. And yes, all of openssl is ... uh... right.
13:51:17nsh:* nsh nods
13:51:28kanzure:"You are in a twisty maze. You see a broom."
13:52:00nsh:but let's say a coder who had attained the zen, making a BN_sqr implementation, would it be elegant and still performant relative to openssl's?
13:52:54nsh:or is there an < elegance | efficiency > relation due to how computers actually work electronically?
13:52:56gmaxwell:But really it's often the case that other people's code is opaque. I am somewhat unconvined by peoples seemingly unsubstantiated expected relation with "code smell" and code correctness. Not that I think smelly code is good, but beautiful code can, and often is wrong.
13:53:44gmaxwell:nsh: I dunno. Elegant is subjective. There is code I consider elegant that would probably strike you as smelly.
13:53:49kanzure:if i had the choice, i would take highly legible code that i can then apply a random-garbling-magic patch against
13:54:14op_mul:I'd have a switch between them, I think.
13:54:14gmaxwell:kanzure: sometimes magic hides dragons.
13:54:22kanzure:hey you're the one advocating for smelly magic
13:54:31op_mul:if(insanitymode)
13:54:41nsh:some of the elegance is objective in terms of algorithmic complexity theory
13:54:57kanzure:i would find it difficult to believe that the vast majority of code in openssl /should/ be smelly garbled magic
13:55:04kanzure:surely the vast majority is just boilerplate like everything else
13:55:06gmaxwell:The purpose of software is to communicate between programmers. But not just any programmers, ... the programmers working on the code in question.
13:55:13nsh:you can rate implementations of algorithms by kolmogorov, but optimizing that almost certainly deoptomizes maintainability
13:56:00gmaxwell:kanzure: Sure, it shouldn't be. I think people vastly overrate the correlation between smell and incorrectness though. Mostly because we often don't look at code unless its incorrect.
13:56:13gmaxwell:As a rule programmers don't spend enough time reading.
13:56:20kanzure:eh, in general i would have to agree, but i do try to read other people's code
13:56:31nsh:if we had to re-tell the story to the computer every time
13:56:38kanzure:and i think it's insane that programmers working on the same project don't read all of the other source code
13:56:45nsh:it would do us a lot of good, and we'd probably evolve languages that are more expressively laconic
13:56:59nsh:telling stories is one of the things we're evolutionarily adept at
13:57:11nsh:it's a toss-up between telling stories and endurance hunting
13:57:12kanzure:better language will not make your programmers do their jobs
13:57:18kanzure:i don't know what you're on about
13:57:19gmaxwell:nsh: hidden behavior is very important though. Clear communications abstracts away details, but that causes doom when the details matter.
13:57:39nsh:right
13:57:45gmaxwell:kanzure: programmers who do their job may demand better languages, however. :)
13:58:15nsh:the problem is that we're dealing with conceptual models of how the code works that are pretty strongly silo'd in developers' heads
13:58:21nsh:we hope they overlap extensively
13:58:50nsh:and things like git, increasing the degree of dialectic, can kind of help
14:00:12nsh:none of this helps me understand why squaring multi-limbed numbers should be a byzantine affair
14:00:18nsh:even if processors are weird and freaky
14:00:58kanzure:you're asking "why is a math failure a bad thing"?
14:02:08nsh:am i?
14:02:22kanzure:i was asing you if you were asking that.
14:02:51nsh:maths only fails if you find the godel number that encodes a self-referential proposition concerning its provability
14:03:02nsh:and no-one's ever shown me one so i'm still on the side of maths
14:05:18kanzure:implementations of math in physical matter (like our primitive forms of computronium) are not platonic ideals or whatever, they have real failures.... bits flip, sidechannels leak, "optimizations" of algorithms turn out to be wrong in some implementations.
14:06:34kanzure:see "In this case the reason our testing revealed the issue was because we used non-uniform numbers specifically constructed with low transition probability to better trigger improbable branches like carry bugs (https://github.com/bitcoin/secp256k1/blob/master/src/testrand_impl.h#L45). I used the same technique in the development of the Opus audio codec to good effect." ...
14:06:40kanzure:... http://np.reddit.com/r/programming/comments/2rrc64/openssl_security_advisory_new_openssl_releases/cnilq2w?context=3
14:08:00nsh:the irony is that the mathematic with which we model the indeterminism -- that we attempt (sometimes failingly) to supervene with deterministic logic -- with deterministic platonic equations of noble eternal truth
14:08:46nsh:s/-- with/-- are/
14:09:34nsh:although greg egan had this lovely idea in a novella about the laws of physics being determined in the struggle of proposition vs. counterproposition in the great axiomatic big bang or something to that effect
14:10:06nsh:which was nice. i mean, it's a long way up from fundamental color-dynamics until we get arithmetic maybe
14:10:08kanzure:gmaxwell: fwiw i highly recommend linking to git(hub) commits by commit id instead of master branches, so that line anchors always work even after people push commits that would impact those anchors
14:10:41kanzure:yes i was about to recommend that you read more greg egan to get over whatever illness you're currently experiencing
14:10:49kanzure:i'm glad that the generic telepathic link is working correctly today
14:12:35nsh:well, i'm completely materially impoverished now, so i can afford the opulence of undirected intuition
14:12:43nsh:it's quiet liberating
14:16:24nsh:oh another thing that came up recently
14:17:16nsh:.t https://twitter.com/craigstuntz/status/546147453414944768
14:17:16yoleaux:nsh: Sorry, I don't know a timezone by that name.
14:17:19nsh:.tw https://twitter.com/craigstuntz/status/546147453414944768
14:17:22yoleaux:Homomorphic encryption doesn't allow branching on secret data. But that's a feature! Allowing it makes you susceptible to timing attacks. (@craigstuntz)
14:17:45nsh:i don't think this is a valid intuition
14:17:56nsh:because you convert any branching computation into a one-pass circuit
14:18:17nsh:and i'd be *very* surprised if this magically eliminated all timing sidechannels
14:18:43nsh:though it may make their exploitation much less convenient than in branching flow
14:30:51jgarzik:* jgarzik wonders out loud,
14:31:09jgarzik:What should bitstamp implement, that is better than a hot-wallet-on-a-server?
14:31:54jgarzik:e.g. I always imagined a web server would indicate "withdraw X from user Y" to N different remote servers, each of which would examine the withdrawal flow in context, to class it as "abnormal" or "normal"
14:32:08jgarzik:If normal, the N servers all sign a multi-sig enabling the withdrawal.
14:32:39jgarzik:A bit simple-minded, but at least requires attacker to compromise multiple servers which are -not- the web server processing the withdrawal request from the user
14:32:50kanzure:how about not using a hot wallet at all
14:32:57hearn:in theory, the hot wallet concept already does this. the size of the hot wallet defines what "normal" is
14:33:17kanzure:having a hot wallet multiple times the size of your daily turnover is not a great idea
14:33:22jgarzik:single-key hot wallet doesn't do that
14:34:03kanzure:instead of using a hot wallet you could just have very slow withdrawals
14:34:10jgarzik:kanzure, indeed
14:34:24hearn:if we assume that bitstamp sized their hot wallet reasonably for their business (it was sized so when i visited them), it could be that they actually see withdrawals and deposits of such huge amounts of money
14:34:25jgarzik:kanzure, which I think translates into a business cost of "users go elsewhere" given competitive space
14:34:52kanzure:right... arguably you do not want users that are that bad at security.
14:34:54hearn:seems ridiculous i agree, but i've met financial types who didn't think anything of dropping millions on a risky FX bet
14:35:14jgarzik:Large amounts or small amounts, it sounds like the hot wallet was not multi-sig.
14:35:31hearn:they use vanilla Bitcoin Core for everything, so no multisig or even HD
14:35:39hearn:or rather, they did last year
14:35:46kanzure:multisig hot wallets is just an extra layer of indirection
14:36:03kanzure:especially if the threshold number of private keys are available on the same server
14:36:06hearn:but yeah, not clear what multi-sig would do. in most implementations you're gonna get both signers being very similar, running the same code, etc
14:36:11jgarzik:kanzure, it also raises attack difficulty and attacker costs, which is the point
14:36:23jgarzik:kanzure, my scheme as described would not keep N private servers on the same server ;p
14:36:28jgarzik:*private keys
14:36:37kanzure:hard to tell with VMs these days.....
14:36:37hearn:the thing you need is diversity, rather than just having multiple servers.
14:36:44hearn:N identical servers has the same security as one, really
14:36:49op_mul:hearn: they reuse addresses, so it's not bitcoin core wallet.
14:38:00hearn:i don't follow your logic there
14:38:18kanzure:yeah, you can hack bitcoind into doing anything you want, it's software
14:38:42op_mul:bitcoin core doesn't reuse change addresses. it seems unlikely anybody would add that in.
14:39:00kanzure:their transaction creation could be anything and they could still be using bitcoind for all you know
14:39:20hearn:my statement was based on what they were doing about little under a year ago. it might be totally different now
14:39:43op_mul:kanzure: I said not using the core wallet, not bitcoind.
14:41:32op_mul:given how poorly the wallet does under loads it's unlikely anybody would use it at scale.
14:41:37kanzure:jgarzik: at any rate, withdrawals should definitely be on totally separate servers
14:41:56kanzure:jgarzik: and also, they should not run anything connecting t othe p2p bitcoin network on any server or ip address that is associated with their user frontend or company etc
14:42:26jgarzik:yes, which independently examine the withdrawal requests, and put each request in context of an overall fraud framework
14:42:58jgarzik:ie. did 1,000,000 users each request withdrawal of 1 BTC to $same_address?
14:42:59kanzure:yep.. that's something i've been working towards, in part. (there are others. i shouldn't take that much credit!)
14:43:16jgarzik:kanzure, what are you working on, if I may ask?
14:43:24kanzure:pm is okay?
14:43:28jgarzik:kanzure, sure
14:44:51hearn:op_mul: you would be surprised ...
14:45:07hearn:op_mul: there are very few wallet implementations lying around. most of them don't scale well, afaik
14:45:44hearn:fraud risk analysis is ..... tough
14:45:57hearn:it's very hard to come up with rules that work, unless you have a constant stream of examples
14:46:18hearn:if you're getting hacked frequently enough to iterate on that, well, that's bad news. and if someone hacks your corp infrastructure, they can probably read your code, in which case forget about it
14:48:40hearn:long term, i fear there is no alternative but just to slowly deflate these huge pools of money by charging deposit fees and the like
14:49:41kanzure:jgarzik: having the private keys anywhere near the infrastructure is quite worrying, even if it is a hot wallet
14:49:49kanzure:jgarzik: that's probably the biggest gain to be had, here
14:50:04jgarzik:agree
14:50:09op_mul:hearn: not storing 21,000 BTC in your hot wallet would be a good start.
14:50:34jgarzik:op_mul, agree.... unless that was their normal flow
14:50:47kanzure:yesterday op_mul showed that it was definitely not their turnover rate
14:51:14hearn:if you have compromised a front end web server or the database, you don't have to compromise the hot wallet.
14:51:16op_mul:s/definitely/probably/ it doesn't justify 21,000 BTC there at any rate.
14:51:28hearn:you can make the system think you're about to do a huge withdrawal and wait for humans to top up the hot wallet to be big enough
14:51:41jgarzik:In general, I think it is clear that exchanges need some published, step-by-step best practices guides to avoid things like this. Everybody keeps reinventing the wheel, poorly.
14:51:51hearn:just having people in the loop is no panacea.
14:52:00kanzure:hearn: nah, that only works if your withdrawal queue is on those servers or in those databases
14:52:04hearn:one reason banks are slow is they manually review wire transfers
14:52:21op_mul:hearn: having "multisig" application databases might be nice, and have the wallet server verify with both.
14:52:47op_mul:have a third doing sanity checks and physically pulling the plug on failure.
14:53:09hearn:i think it's too early to speculate on what would help, given there is no public info about the exact nature of the hack
14:53:17kanzure:jgarzik: you shouldn't do their work for them, though
14:53:19hearn:i suspect it wasn't as simple as "we grabbed the keys" though
14:53:30hearn:otherwise all the money would have exited the wallet in one go, or within a few minutes
14:53:35jgarzik:multiple withdrawal servers need to act as third parties, independently verifying the withdrawal requests
14:53:47hearn:the public analysis by denno suggests that it took hours and bitstamp was able to actually stop some draining away
14:53:50op_mul:hearn: it wasn't, bitstamp managed to claw back 3000 BTC during the hack.
14:53:56hearn:exactly
14:54:08kanzure:jgarzik: i think the earlier argument a few minutes ago was that withdrawal requests are often stored in the same database, so why would your verifications ever return differently?
14:54:25hearn:so that isn't really consistent with key compromise.
14:54:34op_mul:interestingly both the attacker and bitstamps transactions were 300 BTC each.
14:54:45jgarzik:kanzure, Disagree slightly; at some point, community standards & practices avoid public bitcoin embarrassments like this. Ultimately we are all in it together. Sites are competitors, but also we are all learning on-the-fly about how to best secure bitcoins.
14:54:47op_mul:or some of them, at least
14:55:32kanzure:jgarzik: so far i have not seen strong evidence that the existing exchanges have actually taken any of the advice about storing bitcoin. i mean, coinbase mentions something about bank vaults, but they aren't using multisig either...
14:55:36jgarzik:kanzure, even if completely fraudulent withdrawal database traffic, an attacker would be unable to empty the hot wallet rapidly
14:55:42jgarzik:*even with
14:55:58kanzure:the attacker would be unable to do that rapidly with n=1 verifiers though
14:56:01hearn:yeah i think this is looking more like a frontend/db compromise
14:56:05kanzure:i mean, your statement holds for n=1
14:56:19hearn:the 16 hour+ exploit window can be explained by the hot wallet having velocity controls on it
14:56:40jgarzik:Related: multisig address analysis is naive. Some sites with big wealth use shamir
14:56:43hearn:i.e. the attacker can't get the keys directly, he can't get the wallet directly, but he can keep submitting huge withdrawals that will get processed and empty things out
14:56:48kanzure:jgarzik: good point
14:57:05jgarzik:hearn, yep
14:58:17kanzure:also another thing that is important is if you happen to implement multi-factor authentication then you should definitely not implement multi-factor authentication using the same database or frontend application, since compromising that means you can sidestep that sort of withdrawal verification process
14:58:35jgarzik:kanzure, there are multiple points of compromise. multiple servers simply prevents a low level key-stealing single server compromise. defense in depth. if the withdrawal stream is good but a signing server is bad, or the withdrawal stream is bad but signing servers are good, you still have defenses.
14:58:39kanzure:er, i mean user-based multi-factor, of course
14:58:45jgarzik:spreads out what must be compromised, and how.
14:59:20jgarzik:the goal in security is never "impenetrable" but "better than before"
15:00:38jgarzik:attacker must compromise M servers to perform low-level key stealing, or manipulate withdrawal request stream to trick signing servers.
15:01:18jgarzik:compromise the db, and signing servers notice odd withdrawal patterns
15:01:20hearn:what i'm worrying about is that the bitstamp hack boils down to something like, "found a code execution exploit in web server/framework, couldn't get further, but it didn't matter" because we don't have any great ideas for what to do about that
15:01:37hearn:it's easy to say "just have better anti fraud logic!" without really knowing what that'd look like
15:01:48hearn:what could help, potentially, is if clients of the exchange were digitally signing their withdrawal requests.
15:01:57hearn:so the exchanges main loop/hot wallet code can check signatures that don't come from frontends.
15:02:11kanzure:that signing verification could still be bypassed if the database is poorly designed
15:02:13hearn:however this would require exchange users to install an app
15:02:42hearn:IOW, users submit signed BIP70 PaymentRequest's that are verified by the exchange core, rather than just via the web. now you have to compromise user keys to withdraw from the exchange.
15:02:45jgarzik:I think that's reasonable for big withdrawals
15:02:52jgarzik:(installing an app)
15:03:09hearn:yeah. i wonder how feasible that is. it wouldn't be very hard to make a nice lighthouse-style tool that used e.g. free Comodo certs as proof of email address.
15:03:20jgarzik:hearn, +1, I like the idea
15:03:20hearn:if you lose your private key, perhaps you have to file a support ticket or go through KYC again.
15:03:28jgarzik:yep
15:03:53jgarzik:_this_ is the sort of best practice we should have in a doc somewhere
15:04:01kanzure:these are all sort of obvious things, though
15:04:18hearn:well, maybe. everything is obvious in hindsight.
15:04:44kanzure:"hindsight" doesn't apply here.. what do i have hindsight over?
15:04:49hearn:also it's easy to assume that exchanges have infinite skilled developer manpower. when i did the bitstamp client/fund reconciliation thing, obviously i asked why they aren't using multisig for their cold wallets
15:04:59kanzure:what did they say?
15:05:02hearn:and the answer was basically, the tools just aren't good enough and they already had a billion things on their plate
15:05:10hearn:so developing their own didn't seem attractive
15:05:25hearn:(at the time copay wasn't really fully launched, i think)
15:05:26kanzure:do they have any developers on their staff that i might know?
15:05:46hearn:doubt it. anyway, i don't want to get into the details of their setup too much, as it's all confidential
15:06:02kanzure:i mean, how did they pick their bitcoin people? just anyone that can setup a bitcoind node?
15:06:15hearn:no, it's not like that.
15:06:58jgarzik:Related: For the record, copay still has a "beta" label and a warning not to use it for large amounts.
15:07:21hearn:anyway, i'd rather not discuss it. when i was there i wrote a report for their investors exploring many aspects of the business and setup, but it was not public. so i should not discuss further. they can decide what they wish to discuss publicly.
15:07:27jgarzik:Agree w/ hearn. _In theory_ exchanges should know this stuff.
15:07:48kanzure:hearn: glad to hear that someone was doing due diligence
15:07:53jgarzik:In practice, they are small shops with strained resources and don't necessarily know bitcoin as well as we do.
15:08:15jgarzik:This is not just a bitstamp problem, which is why I kicked off the discussion.
15:08:18hearn:jgarzik, +1
15:08:27jgarzik:White label exchanges will make the problem worse, too
15:08:33hearn:i may contact them and ask if they want to discuss the app idea.
15:08:50hearn:really it should be a feature of wallets, of course, but in the short term a special purpose "withdrawal wallet app" would bridge the gap
15:08:52kanzure:haha will you also do free work for my exchange
15:09:03jgarzik:hearn, RE app, it should be a feature of the wallet indeed
15:09:08hearn:discuss in this context means, discuss a contract ;)
15:09:11gmaxwell:It would be helpful to know what the failure mode here was. The industry cannot learn when people keep their faults secret.
15:09:12jgarzik:(typing same thing at same time, it seems)
15:09:46jgarzik:I bet we could get copay to do withdrawal signing
15:09:48jgarzik:if there's interest
15:09:55jgarzik:It needs to be in every wallet
15:10:05gmaxwell:I believe all of the largest loss events actual fault modalities are all secret, there have also been loss events which are completely secret.
15:10:16jgarzik:gmaxwell, agree
15:10:18gmaxwell:This is going to cause regulatory ire against this industry if we don't fix it.
15:10:34gmaxwell:Because we cannot learn best practices if we can't even see what failed.
15:10:45jgarzik:gmaxwell, I would be hopeful that we can engineer some stupidity out of exchanges if things like withdrawal signing were general industry practice
15:10:53hearn:yeah. that's an industry wide issue though. i think US regulators are already getting annoyed just at general data breaches being secret.
15:10:54gmaxwell:All we can do is speculate; and our speculations will be rightfulyl ignored because they are uninformed.
15:11:00hearn:of CC track data, etc
15:11:24jgarzik:e.g. Create a situation where players cannot enter the market unless they support withdrawal signing, "because everyone else does"
15:11:25gmaxwell:hearn: CC industry has pretty substantial self regulation though; perhaps not enough (as you note) we don't even have that.
15:11:46jgarzik:hmmmmm.
15:11:56jgarzik:I wonder if there's an exchange that is willing to demo withdrawal signing.
15:12:03gmaxwell:jgarzik: why should e.g.bitstamp listen to our advice when we're totally ignorant as to what ill actually befell them?
15:12:17kanzure:gmaxwell: because i'd be stupid not to listen to you give me free advice?
15:12:25hearn:free advice, worth what you paid for it ;)
15:12:47kanzure:jgarzik: i know at least one that has been cooking such a thing
15:12:49jgarzik:gmaxwell, Make that rhetorical question irrelevant: If we implement good security practices in the wallets, they follow or get left behind.
15:12:51stonecoldpat:following kanzures earlier comment, you know how to do more than just run bitcoind ;)
15:12:54hearn:the problem with us giving advice is not so much that it'd be worthless or even wrong, but we have no insight into the priority queue and other factors that can be surprising
15:13:22jgarzik:A central problem throughout bitcoin's history is that it is _too easy to use [wrongly / insecurely]_
15:13:23gmaxwell:hearn: well and we value different things. I don't really give a crap about their market share if the tradeoff is against bitcoin's reputation or user security.
15:13:29hearn:e.g. when i checked the size of their cold wallet, of course i was happy just with them signing some nonces i chose with their keys, why actually move the money?
15:13:33jgarzik:it is too easy for a programmer to write naive bitcoin code
15:13:46jgarzik:and tough for programmers to automatically "know" how to write secure code
15:13:49hearn:and the answer was one i did not expect - the SEC loved being able to see the "audit" (i use the word loosely) on the block chain. it felt like star trek to them.
15:13:59hearn:so, ok, move the money then.
15:14:08op_mul:hearn: moving their 140k BTC in one transaction was just moronic.
15:14:15kanzure:they thought moving money was an audit??
15:14:21hearn:no, they know it's not
15:14:38jgarzik:hearn, that's a tweetable quote if ever there was one
15:14:41hearn:this is a language issue. substitute "proof of reserves" or your term of choice
15:15:08kanzure:haha what... wouldn't signing some other plaintext be a better idea, rather than signing a transaction?
15:15:15hearn:no
15:15:27hearn:put it on the block chain, send government regulators a link to the page on blockchain.info, done
15:15:39hearn:don't put it on the block chain, send a complicated 10 step procedure that they don't understand -> not done
15:16:06petertodd:I'll take "they have to work a bit" over $100 million single point of failure any day
15:16:11op_mul:hearn: did you know that anybody could fake a spendable balance on blockchain.info for years?
15:18:39petertodd:op_mul: ha, that would be an awesome fraud
15:18:43tacotime:the great thing about bitcoin is that we can see when someone stole the money at the very least.
15:19:05hearn:op_mul: never heard that, no
15:19:15kanzure:anyone can still fake blockchain.info data (it's a company and it's run by humans, it's not a truthsource)
15:19:44hearn:bear in mind all the existing financial system boils down to is trusted men/women in fancy suits writing letters to each other
15:19:52kanzure:that's not my fault
15:20:18petertodd:hearn: which works because transactions are revocable...
15:20:50hearn:my point is this - it's easy for armchair developers to say "XYZ thing is obvious and anyone who doesn't do it is insane or dumb", but often there are factors that aren't obvious
15:21:07tacotime:i don't fully understand the 'hotwallet' thing though... can't you just do everything on an offline machine, like sign the tx with an output to the recipient, print it out, walk it over to an online machine with a daemon, scan, and relay? why use hot wallets at all?
15:21:36tacotime:if the theft is internal though (as these seem to be) i guess that solves nothing
15:21:37kanzure:hearn: do you think there's anything obvious (like "use a cryptosystem" or "use a password") that you have to draw the line at?
15:21:38petertodd:tacotime: I've gone through this stuff with an exchange before that I did some consulting for... hotwallet vs. coldwallet isn't as important an issue as you'd think
15:21:50petertodd:tacotime: the real problem is authentication of user intent
15:22:17kanzure:er, stealing the private key can bypass any authentication of user intent
15:22:33hearn:kanzure: you know the US nuclear launch codes were 00000000, right?
15:22:59kanzure:that's also not my fault. nobody ever asked me for advice about nuclear launches.
15:23:07hearn:nobody is saying it is
15:23:11petertodd:kanzure: it can, but bad authentication of user intent can (nearly) just as easily steal money too
15:23:26kanzure:petertodd: yep, okay
15:23:46tacotime:well. if you have a person actually auditing every outgoing tx that shouldn't happen though.
15:23:51petertodd:kanzure: for instance, they wanted to use multisig, and by the time we were done they needed to essentially write two separate versions of the exchange software, each authenticating the user in a different way
15:24:09petertodd:tacotime: if you put a person in charge of that they get lazy, guaranteed
15:24:11kanzure:petertodd: were they running these two versions simultaneously...?
15:24:14tacotime:(at least not on a wide scale that would allow theft)
15:24:15tacotime:heh
15:24:30petertodd:kanzure: I haven't spoken to them in a bit, but that was the plan
15:24:32Luke-Jr:kanzure: what would you make the launch code be?
15:24:35ajweiss:gun clicks... "TURN YOUR KEY, SIR!"
15:24:46kanzure:Luke-Jr: i'm not sure a launch code is a good idea
15:25:13stonecoldpat:taxotime: just because a person is handling it - still doesnt authenticate that the person who requested it - really is the person they say, plus it requires a lot more staff than probably affordable
15:25:41Luke-Jr:kanzure: that's dodging the question :D
15:25:58tacotime:stonecoldpat: um, probably no more so than at a bank... and i assume they're making more than a bank, at least before this. and i meant, adding human audit on top of classical auth schemes
15:26:03kanzure:Luke-Jr: yep..... but really, i don't think any particular 8-digit launch code is a good idea...
15:27:18tacotime:small scale theft/fraud can be offset easily by revenue... but the most recent theft was anything but that.
15:27:49kanzure:there should definitely be proportional or exponential verification to linearly increasing withdrawal requests
15:27:57kanzure:*withdrawal request amounts
15:28:00hearn:kanzure: so what you're saying is, "do you think there's anything obvious (like "use a cryptosystem" or "use a password") that you have to draw the line at?" -> no
15:28:08hearn:kanzure: it's rare that things are obvious.
15:28:12hearn:sadly
15:28:31kanzure:hearn: for example, "don't tell every user your single private key" seems ridiculously obvious to me
15:28:34tacotime:yeah. if the theft was anything but internal (of 15k or whatever bitcoins) i'll be really saddened that they decided to have that much online at any given time
15:28:36kanzure:hearn: you have to draw the line somewhere
15:29:38tacotime:i mean, we rely on debug output to vet our own code and make sure it's not doing something weird.. i don't see why this is any different.
15:29:46stonecoldpat:hot wallets should be okay to use, (its just a till @ a shop at the end of the day), their hot wallet was just a bit too big, but thats always going to be a risk
15:31:21tacotime:btc-e has never had a bitcoin theft as far as i know (though they did have a liberty reserve theft), so this type of security can be done right i think.
15:31:31tacotime:(anyway, kind of OT, sorry)
15:31:42kanzure:what's the physics term for as-fast-as-possible signing of withdrawal requests? there's some limit. might be something about speed of light and number of bits per second. anyway, the hottest possible wallet is probably going to sign more things that you wouldn't want it to have signed, even more than the proportionally more number of requests it can process.
15:32:01kanzure:well, er, i don't have the formalism for that, i'm sure one of you physics junkies knows how to conceptualize a hottest possible wallet
15:32:31gmaxwell:hahah!
15:32:39gmaxwell:On the fundimental limits of Bitcoin wallets.
15:33:02kanzure:"or how i learned to expose my private keys to the soft flame of a neutron star"
15:33:58gmaxwell:"We construct a Bitcoin wallet from a quark gluon plasma on the basis of a linear model which indicated that Bitcoin users prefer the hottest possible wallets. If our analysis holds, our profits will be in excess of 500 million bitcoins per day."
15:34:09sipa:"My cold wallet is stored at negative kelvin temperature!" - "You realize that's means it's infinitely hot, right?"
15:34:37kanzure:i even have a snappy name ready to go: big bang wallet
15:37:06hearn:kanzure: that's a confidence inspiring name if there ever was one
15:37:07helo:QOTD "it's rare that things are obvious" - hearn
15:37:15hearn:"we're using the Big Bang Wallet, what could possibly go wrong?"
15:37:34gmaxwell:I've thought before that it might be fun to build some orgy of fail product to launch on april first. "Big bang wallet" by "John TotallyNotStealingYourMoney Doe" ... except people would use it. :(
15:37:35hearn:helo: i'm practicing for my next career as a fortune cookie writer
15:37:56hearn:gmaxwell: implemented in Visual Basic for extra safety :)
15:38:29gmaxwell:hearn: and call it mastercoin? ... Too much work. Might as well just take bitcoin-qt, change the name, and add a picture of a dog. oh wait.
15:38:33sipa:probably in a prl script that generates visual basic code
15:38:36hearn:lol
15:38:36fluffypony:plz, PHP
15:38:36sipa:*perl
15:38:45fluffypony:DarkTimeKoin
15:39:42gmaxwell:fluffypony: hehe. I thought that was a joke at first and was really disappointed when there was no references to Cubic Currency or racist rants.
15:40:03fluffypony:lol
15:41:31sipa:wow, webbtc.com has a script evaluator
15:41:38gmaxwell:(context: fluffypony is referring to TikeKoin a very weird PHP altcoin written by one of bitcoin's earliest users who was seemingly losing his mind. And when I saw the post I thought it was a timecube joke.)
15:41:57op_mul:hearn: that's because bc.i doesn't publish when they get owned.
15:41:59fluffypony:*TimeKoin
15:46:15petertodd:gmaxwell: 3716f21538060be06afda4197d00191e2e3b07500187a1e12a0abadfca9158f3 <- not quite a neutron star, but it's to the right audience at least
15:53:22kanzure:hrm it is not little-endian hex
15:53:38gmaxwell:kanzure: it's a transaction id, follow it
15:53:39petertodd:kanzure: you can tell by the pixels
16:01:19kanzure:whoops, yes
16:01:25lclc_bnc:lclc_bnc is now known as lclc
17:15:43OneNomos:OneNomos is now known as Guest10177
19:10:09execut3:execut3 is now known as shesek
19:11:37maaku:maaku is now known as Guest82541
19:17:06jgarzik:http://blog.rust-lang.org/2015/01/09/Rust-1.0-alpha.html
19:17:27MRL-Relay:[fluffypony] oh andytoshi will be happy
19:18:38gmaxwell:I believe that as it matures Rust will turn out to be a uniquely well suited language for general Bitcoin application development.
19:19:13gmaxwell:It's also, I think, the only language you can say that was created while a bitcoin developer was pestering the crap out of its main contributors.
19:19:52heath:gmaxwell: thoughts on haskell and haskoin?
19:22:03fluffypony:argh altcoins have ruined me - I immediately thought haskoin was an altcoin
19:22:27fluffypony:I also spent 2 minutes today thinking that Picocoin was a stupid name for an altcoin (sorry jgarzik) before realising it wasn't that at all
19:23:21gwillen:gmaxwell: bahaha. Was that bitcoin developer you?
19:24:14jgarzik:heh
19:25:01sipa:gwillen: andytoshi
19:25:06gmaxwell:yea. Well rust is not everything I could possibly want in a language; but there are serious usability tradeoffs; so it's unclear what optimal really is.
19:25:28gwillen:* gwillen nod
19:25:30gmaxwell:and yea, andytoshi actually contributed some not-totally trivial amount to the compiler.
19:27:27heath:* heath proudly holds his best troll today trophy with pride and continues idling
19:36:12jb55:I work for a record label, could you make a transaction to an address such that you could somehow guarantee commission splits to other addresses. That way when someone buys a track all rights holders get paid appropriately?
19:36:18jb55:I have a feeling this might not be possible...
19:37:21gmaxwell:on can straightforwardly pay to a multisignature address which lets you achieve "all signers agree on the distribution of the funds, or they don't move at all."
19:37:48gmaxwell:The payment protocol (BIP70) also allows the invoice to ask parties to pay to a split of multiple outputs.
19:39:36jb55:that sounds exactly what we do already informally. artists all sign a pdf contract before we start distributing funds. If I could encode that into a multisig address it would greatly simplify our payouts in the future...
19:42:18jb55:thanks!
19:46:28phantomcircuit:gmaxwell, does the invoice specify how much goes to each output?
19:47:04kanzure:jb55: i've implemented that and have a working pile of code. do you want it?
19:47:12jb55:kanzure: that would be awesome
20:11:09andytoshi:fluffypony: hooray! i'm gonna spend the rest of today working on updating my code (i couldn't keep up with the changes over the last couple months so there is extreme bitrot)
20:11:27fluffypony::)
20:13:44lclc:lclc is now known as lclc_bnc
21:39:51d1ggy_:d1ggy_ is now known as d1ggy
22:31:12kanzure:attacks on ecdsa signatures with single-bit nonce bias http://www.irisa.fr/celtique/zapalowicz/papers/asiacrypt2014.pdf
22:36:07gmaxwell:kanzure: yep, fortunately the mechenism they use to get a single bit bias is not applicable to our curve.
22:36:21gmaxwell:(not that there aren't other ways to screw up... :( )
22:36:41andytoshi:gmaxwell: you mean this GLV mechanism is not applicable to the curve, or do you mean something more specific?
22:36:55gmaxwell:They focus on a bias created by not correctly handling that the curve order is much smaller than a power of two.
22:37:06gmaxwell:oh maybe I'm confusing the paper.
22:37:32andytoshi:i'm aware that libsecp256k1 does not do anything like this k1 + λk2 thing, but it's not obvious to me that we couldn't if we wanted to
22:37:42andytoshi:i don't have a clue what openssl does :)
22:37:47gmaxwell:oh it's the right paper but I'm only remembering part of it.
22:38:21gmaxwell:andytoshi: no one else does. AFAICT no public implementation except secp256k1 has use of the endomorphism. (you can google for the constant)
22:40:24andytoshi:ah, i see that this is not applicable ... because our entire group has prime order there are no interesting prime subgroups worth decomposing into
22:40:40andytoshi:s/interesting/proper/
22:40:58gmaxwell:I can't load the URL.
22:41:15andytoshi:kk i will rehost it, one sec
22:41:24kanzure:http://diyhpl.us/~bryan/papers2/security/cryptography/Attacks%20on%20ECDSA%20signatures%20with%20single-bit%20nonce%20bias.pdf
22:42:06gmaxwell:if it's the paper talks I'm thinking about about two things, one is getting a bias from doing an endomorphism split k1 + lambda*k2, which is one reason we wouldn't bother doing generation that way ... so I misspoke, secp256k1 would happily befall that, it's just its a kind of stupid optimization; the other thing it talks about is handling the order mod incorrectly
22:42:30andytoshi:it definitely talks about the first; i've only read the first 2 pages so not sure about the second
22:43:20andytoshi:would it be an optimization even? we'd be using endomorphisms of the whole group (as opposed to a subgroup whose elements are smaller)
22:44:26andytoshi:(i totally don't know what i'm talking about btw)
22:44:46gmaxwell:yes. but not really. Because for signing you always compute kG with constant point G then you do not need the endomorphism to split your number.
22:46:33gmaxwell:andytoshi: basically on GLV curves there is a magic beta number such that P.x*beta,P.y = lambda*P and lambda is helpfully large enough that one can split some secret k, like k = k1 + lambda*k2 such that k1, k2 are both 128 bit numbers (instead of 256 bit numbers).
22:47:38andytoshi:ah, yes, i think sipa explained this to me out of band a few months ago (or was it you?)
22:47:48gmaxwell:And then you can go about computing kG as k1G + k2*lambda*G with reduced operations via multi-exponentiation because the scalars are half the size.
22:48:17sipa:andytoshi: i believe i did
22:48:20andytoshi:gotcha. i misread the paper to think that you only got the size-halving by restricting the endomorphism to a small subgroup
22:49:26gmaxwell:now some 'genius' signing implementation might think it could skip the splitting step by just randomly picking k1,k2 ... but the result is non-uniform. And I really doubt anyone has ever done this without knowing it was non-uniform, but maybe they thought it was acceptable.
22:49:58gmaxwell:But if G is a constant there is no need to use the endormorphism for this. You can just precompute 2^128*G, and then do your split on a power of two boundary and your splitting is free.
22:50:53gmaxwell:In fact, you can carry that to its logical conclusion of precomputing every power of two. Or even ever window of 4 bits.. and have no doubling at all in your multiply by G; and this is what libsecp256k1 does for signing.
22:51:46gmaxwell:so I don't see any reason you'd ever use the endomorphism in signing... You basically can't save memory using it even, since the beta constant takes almost as much memory as another precomputed point. (well okay you might save 32 bytes)
22:51:57andytoshi:ah, yes, this part is what sipa explained to me
22:55:30gmaxwell:hm, okay actually, for large amounts of memory you could halve your memory usage.
22:55:38gmaxwell:so maybe someone would actually want to do that.
22:56:37gmaxwell:e.g. you build a great big table for the first 128 bits, and then use the beta to get you a table for the next 128 bits. So the saving is only large if your table is large relative to one entry.