--- Log opened Sun Mar 17 00:00:28 2013 01:29 < warren> grau_: saw your bitsofproof git today. I'm curious how big is the data if you use a SQL backend, and how fast is that? 01:29 < grau_> warren: about 12GB 01:30 < grau_> I tried derby and ProgreSQL 01:30 < grau_> The performance is a magnitude below of leveldb 01:30 < grau_> It is only interesting if you want to do quieries of the blockchain 01:31 < warren> I've wondered what kind of backend blockchain uses, you think it is anything like tihs? 01:31 < grau_> warren: I guess so. Performance with relational database is just a question of budget 01:31 < warren> I'd guess they can't achieve that kind of response time with a single SQl db. 01:31 < warren> ah 01:32 < grau_> Having a cluster of Teradata e.g. I would get the performance of LevelDB 01:32 < grau_> likelzy. Did not try 01:33 < grau_> warren: My relational store is also fully normalized 01:34 < grau_> BitcoinJ eg had relational store too but un-normalized. That way you can speed up a lot 01:34 < grau_> but data mining then is not that simple 01:34 < grau_> so it forgoes the point of relational db actually 01:34 < warren> how's memory usage of this? 01:35 < warren> grau_: is anything using this in production? 01:35 < grau_> Well it is Java, so it uses a heap you give it 01:35 < grau_> warren: I would not run under 500mb 01:35 < grau_> I have this running constantly on bitsofproof.com 01:35 < grau_> I do not claim production quality but its beta 01:36 < warren> no website I can load there 01:36 < warren> I just randomly found the git 01:36 < grau_> I know. but there is a bitcoin if you connect and it is bitsofproof 01:36 < warren> ooh 01:36 < grau_> warren: I have not yet pushed it besides dev forums until it is high quality 01:37 < grau_> I want to launch it big in San Jose 02:02 < warren> grau_: does this rely on openssl ecdsa too? 02:02 * warren didn't look at code yet 02:04 < grau_> warren: no, its bouncy castle 21:45 < sipa> just added signing code to my secp256k1... it's not exactly constant time, but close at least 21:45 < warren> sipa: awesome! 21:45 < warren> sipa: will you eventually have a replacement for openssl/ec.h ? 21:46 < sipa> yes, isn't hard now anymore 21:46 < sipa> still need key generation and probably (hell :S) parsing/saving in openssl's secret key format 21:49 < warren> sipa: might as well publish it as an independent library that can be used by other apps then. 21:50 < warren> that might encourage more eyes 21:57 < warren> sorry, meant to make that a question 21:57 < sipa> it's a good suggestion 21:57 < warren> sipa: haven't looked into it yet, but bitmessage is in a similar pickle here 22:27 <@gmaxwell> warren: I don't think bitmessage should care about ecdsa performance. 22:32 < warren> gmaxwell: performance is not the issue, the desire to use bit* without replacing openssl 22:35 < jgarzik> Sigh. The only python irc library in Fedora repos handles its own I/O selecting/looping, presuming that it is the main process 22:38 < warren> jgarzik: writing the irc micropayment thing? 22:38 < jgarzik> warren: Looking into doing so, yes 22:47 < jgarzik> Everybody tells me not to use twisted, but twisted sure seems to have all the gadgetry in their framework. 22:47 < jgarzik> Another option is process-based plugins: have a master process, and then sub-processes (like IRC) are python scripts that the master will fork+exec, and communicate with via stdin/stdout 22:48 < jgarzik> then I don't care whether my IRC library and my Jabber library want to use different frameworks 22:48 < jgarzik> and things are largely language independent 22:51 <@gmaxwell> +1 to processes. :P 22:51 <@gmaxwell> makes isolation for security easier. --- Log closed Mon Mar 18 00:00:30 2013