1 2012-10-08 00:58:49 <jgarzik> sipa: cool, will take a look at the RPCs
2 2012-10-08 01:03:55 <DBordello> Is a transaction id (transaction hash?) always the same length?
3 2012-10-08 01:05:42 <DBordello> 64 characters?
4 2012-10-08 01:06:11 <copumpkin> should be
5 2012-10-08 01:06:47 <DBordello> peachy
6 2012-10-08 04:26:04 <amiller> okay my first draft attempt at a c++ red black tree is..... 350 times faster than my python one
7 2012-10-08 04:28:11 <amiller> that's including a ton of ridiculous templating i came up with, i'm not sure whether the compiler can see through the haze or not
8 2012-10-08 04:32:45 <phantomcircuit> amiller, naive order processor i wrote in c++ is about 200x faster than the python version
9 2012-10-08 04:32:46 <amiller> but the templating is necessary (as is writing my own red black tree, rather than using sys/tree.h) because the point is to use the same code in two places, 1) is the normal case where you have pointers and random access memory, but 2) is the 'merkle' validation scenario where you're simulating operations on a graph that you aren't even storing, using hashes to keep from losing your place
10 2012-10-08 04:33:11 <phantomcircuit> it's expected
11 2012-10-08 04:45:43 <Joric> bitcoinfoundation, save us! price went down 20% in two days
12 2012-10-08 04:57:58 <jgarzik> amiller: if only python permitted a reasonable amount of static analysis...
13 2012-10-08 05:00:25 <amiller> my naive/overtemplated c++ llrb tree is only 3x slower than this super-tuned C version (which competes with bsd's sys/tree.h) http://www.25thandclement.com/~william/projects/llrb.h.html
14 2012-10-08 05:03:50 <jgarzik> amiller: JFYI, this work is also on-going in the Linux kernel: "Generic red-black trees" http://lwn.net/Articles/500355/
15 2012-10-08 05:12:49 <amiller> that's really interesting, thanks jgarzik
16 2012-10-08 05:13:03 <amiller> i'm especially interested in the comment by ncm about how binary trees are horrible on caches
17 2012-10-08 05:13:54 <amiller> he mentions "page-aware (or page-oblivious)" structures as an alternative, i read a lot about page-oblivious structures last week
18 2012-10-08 05:16:28 <amiller> what i have in mind for batch merkle-tree validation involves a cache-oblivious priority queue
19 2012-10-08 05:16:39 <Evilmax> ahahaha fall!...fall!
20 2012-10-08 05:28:11 <dr00t2nesux{away> hellos
21 2012-10-08 05:29:09 <dr00t2nesux> interested
22 2012-10-08 05:30:43 <Adlai> When mining with a pool, what do H-not-zero, unknown-work, etc mean?
23 2012-10-08 05:31:04 <Adlai> most (but not all!) of my mined shares are getting rejected
24 2012-10-08 05:33:24 <amiller> anyway here's my code for now https://github.com/amiller/redblackmerkle/blob/llrb/c_redblack.hpp
25 2012-10-08 05:35:00 <amiller> now lets see if i can get through the whole blockchian
26 2012-10-08 11:01:31 <TD> BlueMatt: ping
27 2012-10-08 14:07:47 <Guest20783> @ wizkid057 nic frontend for eloipool but i have no idea how to set it up, some documentation would be nice - ie what tables have to be created and how.
28 2012-10-08 14:08:00 <CrazyMF> Luke-Jr, you there?
29 2012-10-08 14:08:14 <Luke-Jr> .
30 2012-10-08 14:08:29 <CrazyMF> I've tried the libblkmaker
31 2012-10-08 14:08:42 <CrazyMF> not getting field "expires" from bitcoind
32 2012-10-08 14:08:45 <CrazyMF> is this normal?
33 2012-10-08 14:09:09 <Luke-Jr> CrazyMF: yes, bitcoind doesn't expire
34 2012-10-08 14:09:58 <Luke-Jr> bitcoind<->libblkmaker still needs some work - especially a base58 parser :/
35 2012-10-08 14:10:19 <CrazyMF> blktmpl_add_jansson seems to require expires
36 2012-10-08 14:10:35 <CrazyMF> safe to just comment out?
37 2012-10-08 14:11:17 <Guest20783> @ luke-jr, do i have to creaet tables for eloipool manually, and if yes what is the command?
38 2012-10-08 14:12:00 <Luke-Jr> Guest20783: you're expected to know how to use the DB engine you want
39 2012-10-08 14:12:28 <Luke-Jr> CrazyMF: probably yes
40 2012-10-08 14:12:45 <Guest20783> yeah cool, solved [not]
41 2012-10-08 14:13:08 <Luke-Jr> CrazyMF: you will find it won't work with bitcoind unless you implement coinbasevalue support (or implement coinbasetx in bitcoind)
42 2012-10-08 14:13:46 <Luke-Jr> Guest20783: I don't think any two Eloipool installs use the same db schema
43 2012-10-08 14:14:39 <Guest20783> in the config it looks lieke there are standard tables, however im out for the wizkid frontend which has a schema i can import as i guess
44 2012-10-08 14:16:55 <Luke-Jr> pretty sure wk's frontend does NOT match the example Eloipool config, FWIW
45 2012-10-08 14:17:09 <Luke-Jr> in fact, wk probably uses the schema on Eligius's site
46 2012-10-08 14:17:25 <Luke-Jr> http://eligius.st/wiki/index.php/PostgreSQL_Schema
47 2012-10-08 14:17:59 <Guest20783> ill try that
48 2012-10-08 14:19:12 <CrazyMF> uhhhm
49 2012-10-08 14:19:15 <CrazyMF> what you mean won't work?
50 2012-10-08 14:19:41 <Luke-Jr> CrazyMF: libblkmaker only implements coinbasetx mode right now
51 2012-10-08 14:20:01 <Luke-Jr> implementing coinbasevalue requires building a coinbase tx itself, which needs a base58 parser to accept a payout address
52 2012-10-08 14:20:37 <CrazyMF> i see
53 2012-10-08 14:20:45 <Luke-Jr> and base58 in plain old C is ??? ugh
54 2012-10-08 14:21:00 <CrazyMF> there's no way to make getblocktemplates without coinbase ?
55 2012-10-08 14:21:37 <CrazyMF> oh yeah =/
56 2012-10-08 14:22:01 <CrazyMF> k, googling on base58 :D
57 2012-10-08 14:23:57 <Luke-Jr> CrazyMF: Eloipool sends coinbasetx
58 2012-10-08 14:24:18 <Luke-Jr> CrazyMF: making bitcoind do the same would be pretty easy too, but you'd need to disable some caching
59 2012-10-08 14:25:43 <CrazyMF> not that proficient with bitcoind sources ATM =/
60 2012-10-08 14:30:50 <CrazyMF> wait so, how does BFG do this?
61 2012-10-08 14:31:08 <Luke-Jr> CrazyMF: it doesn't support bitcoind/coinbasevalue right now
62 2012-10-08 14:33:21 <CrazyMF> yeah I'm kinda lost here =/
63 2012-10-08 14:33:46 <CrazyMF> where it's actually used? cbValue
64 2012-10-08 14:33:55 <CrazyMF> at the miner side
65 2012-10-08 14:34:18 <Luke-Jr> CrazyMF: it's not
66 2012-10-08 14:34:45 <CrazyMF> so why do we need it?
67 2012-10-08 14:35:11 <Luke-Jr> CrazyMF: well, the idea is to implement coinbasevalue support eventually :P
68 2012-10-08 14:37:06 <CrazyMF> I see
69 2012-10-08 14:37:32 <gavinandresen> Did I say how much I hate bdb yet today?
70 2012-10-08 14:37:45 <Luke-Jr> I must have missed it.
71 2012-10-08 14:37:48 <CrazyMF> wait so, can I make the example.c do some work without coinbase[tx/value] ?
72 2012-10-08 14:37:50 <CrazyMF> who bdb ?
73 2012-10-08 14:37:53 <kjj_> what now?
74 2012-10-08 14:38:01 <gavinandresen> berkeley database == bdb
75 2012-10-08 14:38:17 <Luke-Jr> CrazyMF: no, at least one of coinbasetx or coinbasevalue is required for GBT, and libblkmaker only works with coinbasetx right now
76 2012-10-08 14:38:27 <gavinandresen> Anybody know if there is a way to tell the version of a bdb environment ?
77 2012-10-08 14:38:29 <Luke-Jr> CrazyMF: example.c should work out-of-the-box
78 2012-10-08 14:38:34 <helo> byzantine db
79 2012-10-08 14:39:12 <Joric> you must try using sqlite it would be so much faster !!11
80 2012-10-08 14:39:55 <CrazyMF> it does work out the box, as long as it's using "supplied" json data :(
81 2012-10-08 14:40:59 <Joric> speaking of, if bdb will be replaced with leveldb (eventually), what are you considering to do about wallet.dat?
82 2012-10-08 14:41:01 <Luke-Jr> CrazyMF: well, any other JSON data will take forever to find a nonce for using libgcrypt's SHA256 :p
83 2012-10-08 14:41:28 <kjj_> gavinandresen: do you mean in the software, or from the command line?
84 2012-10-08 14:41:58 <CrazyMF> Luke-Jr, I understand that point very well. But the thing is, I want to hook this thing to Bitcoind somehow
85 2012-10-08 14:42:13 <gavinandresen> I mean in software. I'm trying to figure out how to gracefully handle the case where a user runs a bitcoin compiled against bdb 5.* and then downgrades to bdb 4.*
86 2012-10-08 14:42:26 <Luke-Jr> CrazyMF: yeah, for that you'll need to either 1) make bitcoind use coinbasetx, or 2) implement coinbasevalue in libblkmaker
87 2012-10-08 14:42:43 <Luke-Jr> CrazyMF: #1 is far easier, but #2 is far more useful to others :P
88 2012-10-08 14:42:50 <sipa> gavinandresen: can't we focus on getting rid of BDB instead? :(
89 2012-10-08 14:43:00 <CrazyMF> is there a .conf switch for #1 ?
90 2012-10-08 14:43:10 <gavinandresen> sipa: sure, but we'll need to support users upgrading for a very long time
91 2012-10-08 14:43:14 <Luke-Jr> CrazyMF: no, you'd need to write a few lines of code
92 2012-10-08 14:43:15 <sipa> gavinandresen: sure, agree
93 2012-10-08 14:43:18 <kjj_> gavinandresen: in the C API, looks like there is a db_full_version call
94 2012-10-08 14:43:30 <Joric> sipa, what about wallet.dat? json? binary blob? ascii?
95 2012-10-08 14:43:34 <gavinandresen> kjj_: yeah, that gives you the version you're compiled against.
96 2012-10-08 14:43:45 <Luke-Jr> Joric: sipa's custom append-only format
97 2012-10-08 14:43:48 <sipa> Joric: binary append-only file with checksums
98 2012-10-08 14:43:54 <kjj_> gavinandresen: ahh, but not the on-disk version... hmm
99 2012-10-08 14:44:00 <CrazyMF> gavinandresen, why can't we have a transitional version which converts the db to sqlite ?
100 2012-10-08 14:44:20 <Luke-Jr> CrazyMF: Joric was trolling???
101 2012-10-08 14:44:31 <gavinandresen> CrazyMF: ummm, and you're going to compile that transitional version against what version of bdb ???
102 2012-10-08 14:44:47 <CrazyMF> I don't mind the compiling
103 2012-10-08 14:44:51 <CrazyMF> writing stuff is a bit harder
104 2012-10-08 14:45:48 <CrazyMF> wrong read. well yeah, that's a problem
105 2012-10-08 14:47:04 <CrazyMF> can't we add a couple ./configure lines to check which one is available and do the same in "conversion" logic part inside code
106 2012-10-08 14:47:57 <kjj_> gavinandresen: well, what can you do about it anyway? put out a utility that is smart enough to read the new version and write the old version?
107 2012-10-08 14:48:32 <Luke-Jr> kjj_: even with such a utility, users want the client to automatically upgrade an old install
108 2012-10-08 14:49:03 <gavinandresen> kjj_: telling the user that something is wrong in a friendly way is what I was hoping to do about it.
109 2012-10-08 14:49:16 <CrazyMF> Luke-Jr, about that switch. Do you know where to read up on that? because it's a bit of forest full of woods for me =/
110 2012-10-08 14:49:38 <kjj_> gavinandresen: ahh. exec a shell to run "file $datadir/blkindex.dat" and look at the on-disk version number
111 2012-10-08 14:49:51 <gavinandresen> e.g. "You're data directory was created with berkeley db version 5.12; this version of bitcoin can only read up to berkeley db version 4.8."
112 2012-10-08 14:49:57 <Luke-Jr> CrazyMF: you could read the specs, but nobody's written the code for it yet; it's just not very difficult
113 2012-10-08 14:50:05 <gavinandresen> kjj_: yeah, exec a shell doesn't work on Windows
114 2012-10-08 14:50:13 <kjj_> heh, neither would file
115 2012-10-08 14:51:15 <kjj_> I suppose you could check /etc/file/magic for the bytes file examines and replicate the logic. that seems icky
116 2012-10-08 14:51:30 <Luke-Jr> ???
117 2012-10-08 14:52:18 <CrazyMF> you can always bundle a protable bdb with the software
118 2012-10-08 14:52:24 <kjj_> you'd think that this would have come up at some point in the last 20 years or so and BDB would have a call built in
119 2012-10-08 14:56:02 <kjj_> hmm. register a callback with DB_ENV->set_errcall() to intercept the crappy error message?
120 2012-10-08 14:57:29 <gavinandresen> catching the error message isn't the problem, the problem is the error is DB_RUNRECOVERY which doesn't tell me that the problem is a version mismatch
121 2012-10-08 14:58:34 <gavinandresen> I think the best I can do with the effort I'm willing to put in is detect the DB_RUNRECOVERY and tell the user to run with a (new) -recoverdb.
122 2012-10-08 14:59:16 <gavinandresen> -recoverdb will erase/recreate the database/ logfile directory, leaving just the .dat files. Which are pretty compatible between bdb version.
123 2012-10-08 14:59:51 <kjj_> er, won't that cause problems when an actual recovery is needed?
124 2012-10-08 15:00:46 <gavinandresen> kjj_: we erase log files at every shutdown, so "actual recovery" is never really possible.
125 2012-10-08 15:01:25 <sipa> gavinandresen: just the .dat files are not compatible between 5.x and 4.x
126 2012-10-08 15:01:41 <sipa> afaik
127 2012-10-08 15:01:51 <gavinandresen> sipa: I created a wallet.dat/blkindex.dat on 5.x, and 4.x seems to read them just fine.
128 2012-10-08 15:01:53 <sipa> though maybe enough to be salvaged by an earlier version
129 2012-10-08 15:02:05 <sipa> oh, really? good that i'm wrong
130 2012-10-08 15:02:37 <gavinandresen> sipa: is peers.dat a bdb file?
131 2012-10-08 15:07:29 <jgarzik> gavinandresen: no
132 2012-10-08 15:07:29 <kjj_> gavinandresen: doesn't appear to be
133 2012-10-08 15:07:46 <jgarzik> gavinandresen: peers.dat is straightforward serialization, 100% written to disk from memory each time
134 2012-10-08 15:08:03 <jgarzik> gavinandresen: using the write-to-temp-file, then rename, process.
135 2012-10-08 15:08:33 <jgarzik> gavinandresen: so the "file format" is simply addrman serialization
136 2012-10-08 15:10:38 <Guest20783> @ luke, well i have to admit that i dont have the slightest clue how to get the frontend working for eloipool, any idea who i have to pay for this job and how much it should cost?
137 2012-10-08 15:12:05 <Luke-Jr> Guest20783: wizkidO57 is the expert on that all
138 2012-10-08 15:13:00 <Guest20783> he did not reply on any contact
139 2012-10-08 15:14:10 <gavinandresen> jgarzik: that's what I thought I remembered. Getting: ERROR: CAddrman::Read() : invalid network magic number ... which is confusing me
140 2012-10-08 15:14:24 <Luke-Jr> Guest20783: give him time :P
141 2012-10-08 15:15:51 <kjj_> gavinandresen: I hate to ask the "is it plugged in?" question, but did you move the addr.dat from test to main or the reverse?
142 2012-10-08 15:17:01 <jgarzik> gavinandresen: sounds like a corrupted file
143 2012-10-08 15:17:23 <jgarzik> gavinandresen: and for all intents and purposes, peers.dat is a one-record file. You read 100%, or 0%.
144 2012-10-08 15:17:50 <jgarzik> gavinandresen: "invalid network magic number" -- pchMessageStart is often used in files as a magic number, starting a file or record
145 2012-10-08 15:18:06 <jgarzik> gavinandresen: such as how each blk000n.dat record begins with pchMessageStart
146 2012-10-08 15:19:15 <jgarzik> CDataStream ssPeers(SER_DISK, CLIENT_VERSION);
147 2012-10-08 15:19:15 <jgarzik> ssPeers << FLATDATA(pchMessageStart);
148 2012-10-08 15:23:12 <gavinandresen> jgarzik: mmm. pushing investigating that problem onto the stack (started with empty testnet directory. Synced using bdb 5.*. Then re-reading with bdb 4.*... didn't touch peers.dat, so not sure how it would get corrupted)
149 2012-10-08 15:29:48 <jgarzik> gavinandresen: that's the entire data file format, right there in db.cpp (CAddrDB): pchMessageStart, data, hash
150 2012-10-08 15:30:50 <jgarzik> gavinandresen: I do notice a minor ordering bug, though. We should check pchMessageStart earlier in the process.
151 2012-10-08 15:39:47 <jgarzik> gavinandresen: it might not be corrupted -- as the error message indicates, that peers.dat might be from a different network.
152 2012-10-08 15:39:59 <jgarzik> gavinandresen: if you are on mainnet, and you use a testnet3 peers.dat, you would see that error.
153 2012-10-08 15:40:52 <gavinandresen> jgarzik: I'll see if I can recreate when I'm done fixing DbEnv::Open() so it actually catches errors properly
154 2012-10-08 15:43:30 <gmaxwell> gavinandresen: See my fun zzuf results? everything still failing. :(
155 2012-10-08 15:45:30 <gavinandresen> gmaxwell: yup. I may relax my goals to just handling the common cases of downgrading BDB versions and crash/copy without -detachdb
156 2012-10-08 15:47:38 <gmaxwell> The segfault strengthened an expectation I've had in the past: don't run wallet files from untrusted sources outside of safe sandboxes
157 2012-10-08 15:48:58 <jgarzik> for 0.8, I like sipa's logdb solution: https://github.com/sipa/bitcoin/commits/logdb
158 2012-10-08 15:49:02 <jgarzik> for wallet
159 2012-10-08 15:49:19 <jgarzik> ufasoft-coin has a simple BDB importer, that looks interesting
160 2012-10-08 15:49:40 <jgarzik> we would write our own, but that provides a nice outside reference for the BDB file format
161 2012-10-08 15:49:57 <jgarzik> (thus you may import BDB wallets ad infinitum, without linking BDB)
162 2012-10-08 15:50:07 <gavinandresen> that's appealing.
163 2012-10-08 15:51:32 <jgarzik> gmaxwell: even the most perfectly checksummed file format is vulnerable to software bugs and malicious construction... thus every single bit of input must be considered hostile and corrupt, regardless of magic number/checksum validity
164 2012-10-08 15:52:16 <Guest20783> is there any bitcoin rep that is supported by https://github.com/p2k/ecoinpool
165 2012-10-08 15:52:32 <jgarzik> the data stream might be nicely serialized, checksummed, magic'd... crap ;p
166 2012-10-08 15:52:56 <gmaxwell> jgarzik: Sure. I'm well aware of this. This is why it's wise to test with the checksums bypassed. :P
167 2012-10-08 15:53:19 <gmaxwell> But if it goes explody without doing any instrumentation you still have a problem. :P
168 2012-10-08 16:26:25 <sipa> jgarzik: i remember i wanted to make some changes to the logdb file format, but i actually can't remember anymore what or why
169 2012-10-08 16:26:30 <sipa> do you feel anything is missing?
170 2012-10-08 16:30:35 <amiller> sipa, i wonder if the logdb file format is comparable to SequenceFiles? http://hadoop.apache.org/docs/current/api/org/apache/hadoop/io/SequenceFile.html
171 2012-10-08 16:34:59 <Guest20783> is it possible to have 2 differrent versions of bitcoind on linux or will each time i start the second one the blockchain be downloaded again from scratch?
172 2012-10-08 16:35:28 <midnightmagic> hey gmaxwell, if I have a transaction rejection patch, does it record the txid of rejected transactions so as not to pull them from other conections, or does it forget the txid immediately, and thus if it hears about it multiple times, it actually downloads it multiple times from peers?
173 2012-10-08 16:36:49 <Guest20783> ~hello world!
174 2012-10-08 16:37:28 <midnightmagic> .. it occurred to me that perhaps a simple tx rejection patch might actually be amplifying bitcoin traffic.
175 2012-10-08 16:40:14 <midnightmagic> ;;bc,stats
176 2012-10-08 16:40:16 <gribble> Current Blocks: 202407 | Current Difficulty: 3054627.5269486 | Next Difficulty At Block: 203615 | Next Difficulty In: 1208 blocks | Next Difficulty In About: 1 week, 1 day, 13 hours, 41 minutes, and 44 seconds | Next Difficulty Estimate: 2995498.83138218 | Estimated Percent Change: -1.93570885631
177 2012-10-08 16:42:27 <TD> gavinandresen: what platforms have that issue? you mean people downgrading their bitcoin-qt install?
178 2012-10-08 16:44:07 <gavinandresen> TD: we are (or try to be) consistent with the version of BDB we compile against, but since we're open source people can (and do) run versions that are compiled against up-rev versions of BDB. They run into uncaught BDB_RUNRECOVERY exceptions if they then "upgrade" to a new version of bitcoin that we distribute.
179 2012-10-08 16:44:35 <TD> :(
180 2012-10-08 16:44:55 <TD> the way andreas handles this sort of problem for the android app is just to export private keys to a text file. if there's an issue loading the wallet, recreate, reimport and rescan
181 2012-10-08 16:47:56 <BlueMatt> TD: pong
182 2012-10-08 16:48:08 <TD> gavinandresen: alternatively, you could ??? you know ???.. just import the bdb sources into the bitcoin tree :-)
183 2012-10-08 16:48:26 <BlueMatt> TD: also, my hdd is on the frizt (seems to be dying) so in terms of responding to review/comments I may be a bit slow till the new one gets here...
184 2012-10-08 16:48:27 <TD> BlueMatt: never mind, i replied on a bunch of commits as you weren't around. got quite a bit merged today, phew!
185 2012-10-08 16:48:33 <TD> oh, that sucks. ok no worries
186 2012-10-08 16:48:42 <TD> my main query was over the coinbase spend depth change
187 2012-10-08 16:48:50 <TD> i don't see what makes it only apply to spends of coinbases
188 2012-10-08 16:49:47 <jgarzik> sipa: I haven't looked in-depth at logdb
189 2012-10-08 16:50:09 <BlueMatt> for non-coinbase txn the value of depth is -200, or whatever it was set to in StoredTransactionOutput
190 2012-10-08 16:50:11 <jgarzik> sipa: in broad strokes, an append-only format simulating a key/value database in memory works for me, as a wallet solution
191 2012-10-08 16:50:22 <jgarzik> sipa: and you appear to have done that
192 2012-10-08 16:50:33 <jgarzik> sipa: so I would rather move forward with logdb and add/fix as needed
193 2012-10-08 16:51:34 <BlueMatt> TD: re: throwing a VerificationException while adding a orphan block: no, probably shouldnt do that, that exception will disconnect the peer, and in this case disconnect a good peer and leave a bad peer connected
194 2012-10-08 16:51:37 <jgarzik> gavinandresen, TD, sipa: what is the leveldb disaster recovery story? are there external dump/fsck utilities? must we create these?
195 2012-10-08 16:51:55 <jgarzik> just restart, with corrupted data silently elided?
196 2012-10-08 16:53:21 <gavinandresen> I don't know nuthin about leveldb recovery.... but I will note that we have approximately zero recoverability with bdb right now
197 2012-10-08 16:53:26 <TD> leveled doesn't have disasters. in the unlikely event of a cosmic ray causing data corruption, Jeff Dean will fly over from California and fix things for you by hand
198 2012-10-08 16:54:09 <TD> BlueMatt: yes, though a new peer will be selected. and the exception will leave a trace in the logs. silently swallowing it doesn't really work either
199 2012-10-08 16:55:02 <BlueMatt> TD: mmm, fair enough...I was thinking at some point adding an equivalent nDoS flag to Exceptions and using those to selectively disconnect peers sometime in the future (very similar to the way the reference client does it?)
200 2012-10-08 16:55:20 <gmaxwell> TD: hah. I've seen many clients with bitflips.
201 2012-10-08 16:55:29 <gmaxwell> "Windows quality hardware"
202 2012-10-08 16:55:44 <TD> we did an analysis of chrome crashes. it turns out that chrome crashes in Brazil more often than anywhere else.
203 2012-10-08 16:56:22 <TD> i.e., the software is stable enough that the bulk of all crashes are caused by hardware flakes, and in hot places like brazil where low quality parts dominate, that means more random bogosity
204 2012-10-08 16:56:45 <TD> BlueMatt: yeah, well, i'm not a fan of how the reference client handles DoS
205 2012-10-08 16:57:04 <TD> at least not in every case
206 2012-10-08 16:57:12 <gmaxwell> TD: The bitsquatting paper has nice graphs of temperature vs observed iphone bitflips in dns queries.
207 2012-10-08 16:57:15 <TD> but sure, we could always go and fix it then. my main concern is that block validation failures shouldn't be silently swallowed
208 2012-10-08 16:57:21 <BlueMatt> TD: true, but the general "score" idea is not bad...
209 2012-10-08 16:57:30 <midnightmagic> ACTION pokes gmaxwell
210 2012-10-08 16:57:34 <TD> LevelDB has some options around aggressive checksumming
211 2012-10-08 16:57:43 <gmaxwell> midnightmagic: non-standard txns get refetched.
212 2012-10-08 16:57:53 <TD> I believe sipa tried it and found there was no performance hit
213 2012-10-08 16:57:59 <TD> however it only detects corruptions
214 2012-10-08 16:58:18 <TD> it does not try to fix them. i guess if you end up with a bit flip in the database, your node is hosed and will have to rebuild its index from scratch
215 2012-10-08 16:58:19 <gmaxwell> TD: if they don't slay performance then we should enable... mystery corruption is much worse than detected!
216 2012-10-08 16:58:19 <midnightmagic> gmaxwell: doh. speculation of a good solution?
217 2012-10-08 16:58:24 <jgarzik> http://www.scientificamerican.com/article.cfm?id=3-years-in-bitcoin-digital-money-gains-momentum </minor plug>
218 2012-10-08 16:58:47 <gmaxwell> midnightmagic: we should stop doing that. :P
219 2012-10-08 16:59:10 <gmaxwell> midnightmagic: it's mostly harmless in any case.
220 2012-10-08 16:59:24 <jgarzik> gavinandresen: "zero recoverability with BDB" -- hyperbole surely, since you may always use bdb external tools to dump whatever key/value pairs and pages survived the $Corruption_Event
221 2012-10-08 16:59:24 <TD> jgarzik: was quite a good article i thought. obv the author was at the conference and was paying attention. factual corruption was low
222 2012-10-08 16:59:34 <midnightmagic> gmaxwell: :-) okay then, thanks for the braintime
223 2012-10-08 16:59:44 <midnightmagic> .. and the triangulation.
224 2012-10-08 16:59:58 <jgarzik> gavinandresen: it requires a programmer's knowledge of bitcoin to do it effectively in bitcoin... but that's not BDB's fault
225 2012-10-08 17:00:50 <jgarzik> TD: she sat next to me during amiller's talk. Knew she was a journalist, but had no idea it would hit Scientific American
226 2012-10-08 17:01:32 <TD> oh, morgan is a female name? thought it was a guy
227 2012-10-08 17:01:46 <gavinandresen> jgarzik: if a private key gets bit-flipped, then you're screwed unless you have a backup.
228 2012-10-08 17:02:01 <Luke-Jr> sigh, more "news" articles claiming anonymity
229 2012-10-08 17:02:18 <gavinandresen> jgarzik: ... and if your master wallet key gets bit-flipped then you're even more screwed.
230 2012-10-08 17:02:22 <jgarzik> gavinandresen: yup
231 2012-10-08 17:02:33 <BlueMatt> TD: re: asserting if a tx is double-inserted into the inactive pool: why can you do that, could happen easily in prodnet bitcoin?
232 2012-10-08 17:02:45 <gavinandresen> jgarzik: ... and both of those may be completely undetected by the bdb layer.
233 2012-10-08 17:03:10 <TD> you mean because duplicated transactions are allowed? i thought they would be rejected by miners
234 2012-10-08 17:03:13 <gavinandresen> jgarzik: All of which makes me think that dealing with $corruption_events at the database layer is the wrong approach
235 2012-10-08 17:03:17 <jgarzik> gavinandresen: Of course. I was thinking more about recoverability at the database level. It is easier for the process if tools already exist to reconstruct whatever database records survived
236 2012-10-08 17:03:21 <jgarzik> rather than binary editing
237 2012-10-08 17:03:32 <BlueMatt> TD: on a fork sure they are
238 2012-10-08 17:03:46 <jgarzik> gavinandresen: nothing is the whole story, wrt data corruption
239 2012-10-08 17:03:54 <BlueMatt> TD: "at some point I changed the wallet to assert if double-inserting transactions into the inactive pool"
240 2012-10-08 17:04:20 <jgarzik> gavinandresen: The main question to me: if a user detects corruption $somehow, and cannot immediately jump to a backup... what is their path?
241 2012-10-08 17:04:24 <BlueMatt> TD: or did it fail because of wallet exception instead of verificationexception?
242 2012-10-08 17:04:32 <jgarzik> gavinandresen: right now, there are bdb tools that assist key/value record recovery
243 2012-10-08 17:04:41 <jgarzik> gavinandresen: leveldb, not so, AFAIK
244 2012-10-08 17:05:06 <gavinandresen> jgarzik: the main question to me is "is that common enough to worry about, or should we spend our time creating good backup solutions that solve that problem AND a bunch of others"
245 2012-10-08 17:05:32 <TD> wallet exception. if you look at receive() then it's OK for a transaction to appear multiple times on forks and it's handled. the codepath being taken in the unit test was causing issues because it hit addWalletTransaction() for some reason. maybe i need to look closer.
246 2012-10-08 17:05:49 <TD> jgarzik: leveldb for a wallet would be annoying, as a wallet would end up being multiple files
247 2012-10-08 17:05:50 <BlueMatt> ah, ok, fair enough
248 2012-10-08 17:05:52 <gmaxwell> Well recovery doesn't help you if you don't detect the error.
249 2012-10-08 17:06:06 <gavinandresen> jgarzik: my 'graceful wallet recovery' branch tried automatically recovering using the dump/restore stuff, and as gmaxwell found out that doesn't do a good job of recovering bit-flipped wallets
250 2012-10-08 17:06:13 <gmaxwell> e.g. get a bitflip, only notice a year later when you're failing to generate a transaction spending that particular input.
251 2012-10-08 17:06:21 <TD> BlueMatt: right the issue was that b7 extends b4 but contained an identical transaction
252 2012-10-08 17:06:29 <jgarzik> gavinandresen: usre
253 2012-10-08 17:06:32 <jgarzik> gavinandresen: sure
254 2012-10-08 17:06:33 <gmaxwell> You have backups... but you've rotated out ones old enough to not have the flip.
255 2012-10-08 17:06:35 <TD> BlueMatt: because of how the unit test code is creating test transactions. so it was hitting an assert.
256 2012-10-08 17:06:45 <jgarzik> gavinandresen: that does not imply corruption recovery is free of value
257 2012-10-08 17:07:17 <BlueMatt> TD: ok, as long as its not hitting an error that could happen in production
258 2012-10-08 17:07:23 <gmaxwell> gavinandresen: I think the recovery stuff making backup copies when things go wrong; I've seen plenty of users totally hose themselves when they start trying to fix things because they don't make backups.
259 2012-10-08 17:07:25 <TD> no, i don't think so
260 2012-10-08 17:07:39 <jgarzik> gmaxwell: people _do_ use bitcointools in case of disaster. make backups easier all you want... that does not absolve the need for recovery tools
261 2012-10-08 17:07:40 <TD> unless you get duplicated transactions in the main chain, i guess. that could cause an assert.
262 2012-10-08 17:07:49 <jgarzik> "good backups" has not been solved at a macro level
263 2012-10-08 17:07:50 <amiller> this is a question about error correction rather than checksumming isn't it?
264 2012-10-08 17:07:51 <gmaxwell> e.g. "bitcoin won't start, I'll restore my wallet backup.. oh that wasn't it. Deleted addr.dat now it starts.. where did half my coin go?"
265 2012-10-08 17:08:00 <jgarzik> so blaming lack of backups is just silly
266 2012-10-08 17:08:18 <jgarzik> real world shows Smart People continue to need to send their hard drives to expensive recovery specialists
267 2012-10-08 17:08:25 <gmaxwell> jgarzik: I wasn't blaming lack of backups, see I'm talking about a specific failure mode where they don't engage in safe recovery.
268 2012-10-08 17:08:42 <gmaxwell> E.g. they recover by destructively twiddling stuff.
269 2012-10-08 17:09:13 <gmaxwell> The best 'recovery' tool currently is the private key extractor; but I don't think it works on encrypted wallets.
270 2012-10-08 17:09:39 <midnightmagic> in some kinds of commercial software structural database corruption is corrected at the database layer when possible. database contents are then corrected later, or reconstructed as much as possible from the old semi-recovered structure. and this pair of mechanisms is built directly into the server binaries.
271 2012-10-08 17:10:06 <gavinandresen> gmaxwell: -salvagewallet in my wallet recovery branch extracts all keys into a new wallet.
272 2012-10-08 17:12:21 <jgarzik> yeah, duh, good point -- we are not moving to leveldb. if anything, it will be logdb.
273 2012-10-08 17:12:35 <midnightmagic> something the tahoe people have pushed relatively far ahead is erasure-coded storage blocks with user-configurable k-of-n redundancy. zfec is open source software. i don't see why something like it couldn't be used by users looking for more careful and error-resistant key storage.
274 2012-10-08 17:12:47 <jgarzik> leveldb is just for indices we may rebuild
275 2012-10-08 17:13:12 <jgarzik> and wallet+logdb recoverability is straightforward
276 2012-10-08 17:15:03 <gmaxwell> gavinandresen: I know. ??? and I do think we should merge that.
277 2012-10-08 17:15:15 <amiller> jgarzik, sipa, i don't understand why logdb uses a chain of secure hashes, rather than erasure coding? isn't that solving the wrong problem w.r.t wallets?
278 2012-10-08 17:15:25 <gmaxwell> midnightmagic: wallets are small. Screw RS codes. Just make N copies.
279 2012-10-08 17:15:54 <gavinandresen> gmaxwell: I'm about to push another change, specifically for "ran a different version of BDB" problem.
280 2012-10-08 17:15:58 <gmaxwell> Also internal file reduancy gets tripped up dealing with the underlying filesystem screwing you.
281 2012-10-08 17:16:19 <gavinandresen> gmaxwell: after much experimentation, I think just telling the user there is a problem and telling them how to fix it is the right thing to do.
282 2012-10-08 17:16:35 <midnightmagic> gmaxwell: RS-type codes could also be in the form of shamir's secret-sharing, in which case < k = provably perfect secret-keeping.
283 2012-10-08 17:16:45 <gavinandresen> "Error initializing database environment %s; To recover, BACKUP THAT DIRECTORY, then remove everything from it except for wallet.dat."
284 2012-10-08 17:17:00 <jgarzik> amiller: chain-of-hashes is what bitcoin and git both use :)
285 2012-10-08 17:17:03 <jgarzik> it is quite familiar :)
286 2012-10-08 17:17:07 <gmaxwell> midnightmagic: an RS code achieves that too, so long as you don't use the 0 basis polynomial (the original data) as one of the syndromes.
287 2012-10-08 17:17:16 <jgarzik> I think we like chain-of-hashes around here. ;p
288 2012-10-08 17:17:26 <gmaxwell> midnightmagic: but that has ?? applicablity here.
289 2012-10-08 17:17:43 <gmaxwell> midnightmagic: if you want to split up your wallet thats fine. I think that has no business in the reference client.
290 2012-10-08 17:17:55 <jgarzik> also, logdb enables total separate of wallet from [BDB | leveldb] database environment
291 2012-10-08 17:17:56 <jgarzik> yay!
292 2012-10-08 17:18:03 <jgarzik> -wallet=FILE is easy
293 2012-10-08 17:18:09 <jgarzik> wallets become more transportable
294 2012-10-08 17:18:12 <gmaxwell> Indeed.
295 2012-10-08 17:18:46 <midnightmagic> gmaxwell: it does when you guys are discussing the bitflip problem, and it solves the nature of secure wallet storage too, without worrying about a single bitflip ruining any dependent encryption.
296 2012-10-08 17:19:35 <jgarzik> Meta: why am I thumping logdb? Because wallet format should change at the same time as block/tx index format... easier to get all the format changes done at once.
297 2012-10-08 17:19:56 <jgarzik> Users understand big upgrades are occurring under the hood, with 0.8
298 2012-10-08 17:20:29 <gmaxwell> midnightmagic: making N copies solves errors much better. (and efficient erasure codes can't be used with erasure detection in any case)
299 2012-10-08 17:21:13 <midnightmagic> RS coding itself is information dispersal; but it is not secret-holding information dispersal.
300 2012-10-08 17:21:18 <gmaxwell> jgarzik: you think? hm. How should wallet updates work? I was contemplating that when we do the wallet upgrade we should actually break the upgrader into a seperate executable, one that bitcoin could invoke for the user.
301 2012-10-08 17:21:43 <midnightmagic> gmaxwell: the error-correcting aspects of RS can be used to recover limited subset of data. RS is *NOT* secret-keeping.
302 2012-10-08 17:22:19 <jgarzik> gmaxwell: read bdb, write logdb, rename bdb to intentionally break downgrades
303 2012-10-08 17:22:47 <jgarzik> gmaxwell: treat it similarly to the event of wallet plaintext -> encrypt
304 2012-10-08 17:22:55 <gmaxwell> midnightmagic: Yes, wtf I've written several RS implementations. I know what it is. I don't think it's applicable to this.
305 2012-10-08 17:22:58 <Luke-Jr> ideal would be a bidirectional conversion program the client invokes, but I'm not sure how much effort people want to put into it <.<
306 2012-10-08 17:23:52 <gmaxwell> midnightmagic: I think m of n is not a good model for wallet protection both for user factors reasons and for basic reliablity and software complexity.
307 2012-10-08 17:24:34 <jgarzik> gmaxwell: theoretically we delete the bdb linkage entirely. leveldb will recreate blockchain indices. some wallet bdb import code should remain, possibly for a very long time.
308 2012-10-08 17:24:57 <gmaxwell> midnightmagic: evading the fs crapping on you requires putting the syndromes in seperate files. And users will not interact well with 'you need N of these M files, and you can't mix them up'
309 2012-10-08 17:25:14 <jgarzik> maybe force re-encryption with new wallet passphrase?
310 2012-10-08 17:25:21 <gmaxwell> jgarzik: I think luke and I are thinking that the bdb linkage should be in a seperate conversion util that is packaged with, which bitcoin could invoke.
311 2012-10-08 17:25:23 <jgarzik> or would that open up more security problems than it solves
312 2012-10-08 17:25:37 <gmaxwell> jgarzik: making users change passphrases == coin loss.
313 2012-10-08 17:26:23 <gmaxwell> it should be possible to migrate an already encrypted wallet without decrypting anything.
314 2012-10-08 17:26:24 <jgarzik> gmaxwell: separate conversion util seems more likely to generate user reports of "where did my money go?" than built-in conversion
315 2012-10-08 17:27:18 <gmaxwell> jgarzik: It could be functionally built in. E.g. bitcoin could invoke the utility. But going that route lets us get BDB completely out of the process.
316 2012-10-08 17:27:20 <midnightmagic> gmaxwell: n copies and verification of n copies is almost all the way there anyway. it sounds like what you're really arguing against is n copies of the wallet strewn across storage mediums.
317 2012-10-08 17:27:35 <Qasaur> Hey guys
318 2012-10-08 17:27:42 <Qasaur> Is it worth buying Bitcoins now?
319 2012-10-08 17:27:45 <Qasaur> or should I wait
320 2012-10-08 17:28:05 <jgarzik> gmaxwell: no, since we have to support this external wallet conversion utility, BDB is effectively always with us
321 2012-10-08 17:28:22 <gmaxwell> midnightmagic: No. I'm saying that using an RS code to achieve M!=N is not interesting, will cause coin loss, extra implementation complexity (not just for us but for any tools that works with wallets), etc.
322 2012-10-08 17:28:32 <midnightmagic> gmaxwell: the complexity difference is minimal for rs- and/or sss-based wallet storage vs. n copies. in any event, you guys were discussing bitflipped wallets where encrypted keys are essentially lost. sss- or rs-based or n copies is the solution.
323 2012-10-08 17:28:36 <jgarzik> gmaxwell: unless by "completely out of process" you simply mean bitcoind, rather than the Bitcoin Build Process
324 2012-10-08 17:28:54 <gmaxwell> jgarzik: It's not in the bitcoind address space shitting on valgrind output with uninitilized reads to suppress and such.
325 2012-10-08 17:28:59 <gavinandresen> can we switch to talking about 0.7.1 for a bit?
326 2012-10-08 17:29:04 <jgarzik> we should drop BDB as a dependency, and such a wallet conversion utility prevents that.
327 2012-10-08 17:29:16 <gmaxwell> jgarzik: I don't really have a strong opinion though.
328 2012-10-08 17:30:12 <gavinandresen> I want to pull https://github.com/bitcoin/bitcoin/pull/1917 then rebase 1895 on top of it.
329 2012-10-08 17:30:13 <gmaxwell> gavinandresen: I dread another release ... because it seems like a lot of people are having their database files not survive 0.6.3->0.7.0 and I don't know why since the bdb version is the same.
330 2012-10-08 17:30:37 <gmaxwell> oh you're pondering some of the same problems.
331 2012-10-08 17:30:43 <midnightmagic> gmaxwell: i think it's interesting if it's sss-based. I disagree with the coin loss thing, but it is extra implementation complexity. I am not saying *do this* I'm just saying it's a good solution/alternative to transaction logs.
332 2012-10-08 17:31:13 <midnightmagic> anyway, shower time. thanks for the triangulation.
333 2012-10-08 17:31:32 <gmaxwell> gavinandresen: So, advising people to remove the database directory is quite risky.
334 2012-10-08 17:32:07 <gmaxwell> gavinandresen: if the wallet was not flushed (bad shutdown timing) and you remove the database directory I think none of the BDB tools will ever read it again.
335 2012-10-08 17:32:23 <gavinandresen> gmaxwell: ... hence the advice to BACKUP
336 2012-10-08 17:32:54 <gavinandresen> gmaxwell: actually, I believe salvage WILL read it
337 2012-10-08 17:34:01 <jgarzik> it should
338 2012-10-08 17:34:24 <gmaxwell> OK. I wasn't completely sure, its certantly harder to recover from that.
339 2012-10-08 17:34:30 <gmaxwell> hm.
340 2012-10-08 17:35:18 <Luke-Jr> gmaxwell: gavinandresen: in case you missed it, someone was in here the other day with a corrupt environment from a "clean" exit of bitcoin-qt
341 2012-10-08 17:35:29 <jgarzik> gavinandresen: you will need to apply my just-posted comment to #1895
342 2012-10-08 17:35:37 <gmaxwell> what I've advised people to do before is go back to the other version and stop cleanly... but thats complicated and compliance with that is terrible. (They say they've done this, but when I eventually get their debug logs from them I find they were running the other version all along).. and doesn't work when the other version just crashes.
343 2012-10-08 17:36:27 <Luke-Jr> (I put "clean" in quotes because he wasn't using -detachdb)
344 2012-10-08 17:36:47 <gavinandresen> jgarzik: you mean 1917... RE: exception checks: ACK, will do that. Most of the code assumed returns-error-code error handling.
345 2012-10-08 17:37:11 <jgarzik> gavinandresen: I mean #1895, as I said :)
346 2012-10-08 17:37:29 <jgarzik> gavinandresen: it relies on env exceptions as well, which must change, if you disable them in #1917
347 2012-10-08 17:37:42 <gavinandresen> jgarzik: ACK
348 2012-10-08 17:46:03 <BlueMatt> jgarzik: why close NODE_VALIDATION, its clearly required moving forward, so discussion of how to do it needs to happen
349 2012-10-08 17:48:41 <BlueMatt> (and Id argue is a prerequisite to merging ultraprune)
350 2012-10-08 18:00:57 <jgarzik> BlueMatt: it is easy enough to recreate and put in the ultraprune pile
351 2012-10-08 18:01:47 <BlueMatt> dont really care, just seems counterproductive to close it now that it was opened...
352 2012-10-08 18:11:42 <jgarzik> BlueMatt: if it belongs in another pull request, then it just creates more coordination work to have another pull request open
353 2012-10-08 20:11:11 <jgarzik> ACTION needs to filter the string "optionsmodel" out of his email ;p
354 2012-10-08 20:30:42 <sipa> jgarzik: ok
355 2012-10-08 20:30:58 <sipa> jgarzik: in leveldb, i think "opening" and "recovering" is the same thing
356 2012-10-08 20:31:13 <sipa> and in my branch, checksum checking is enabled
357 2012-10-08 20:31:47 <sipa> i haven't ever seen any corruption, even when removing the power cable from the computer while doing IBD with -loadblock
358 2012-10-08 20:32:07 <sipa> (note, HEAD did get a corruption in similar circumstances)
359 2012-10-08 20:32:24 <sipa> but this is anecdotecal evidence at best
360 2012-10-08 20:42:21 <midnightmagic> huh. how about that..: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.80.2829&rep=rep1&type=pdf
361 2012-10-08 20:42:33 <midnightmagic> ACTION was misinformed.
362 2012-10-08 20:43:15 <sipa> hmm?
363 2012-10-08 20:44:24 <midnightmagic> re: reed-solomon codes. it turns out it is possible to construct not only a threshold-only reed-solomon, but it benefits from the error-correction of an rs.
364 2012-10-08 20:44:51 <midnightmagic> (and allows you to detect cheaters, apparently)
365 2012-10-08 20:50:18 <gmaxwell> midnightmagic: Yes, I thought that was my very first response to you when you started going about it.
366 2012-10-08 20:50:46 <gmaxwell> You just don't use the original point as any of the included syndromes... and you encrypt them.
367 2012-10-08 21:19:49 <bcb_> what is the min or avg tx_fee to sent for bitcoind
368 2012-10-08 21:19:55 <bcb_> set
369 2012-10-08 21:30:09 <slush> Are there some conditions under which testnet3 difficulty is restarted to 1?
370 2012-10-08 21:30:20 <sipa> not restarted
371 2012-10-08 21:30:32 <sipa> but after 20 minutes of no block, a single block with difficulty 1 is allowed
372 2012-10-08 21:30:42 <gmaxwell> There is also another one.
373 2012-10-08 21:30:55 <slush> I see difficulty 1 in ./bitcoind getinfo
374 2012-10-08 21:31:00 <gmaxwell> If the above condition happens at a retarget it can knock it back to 1..
375 2012-10-08 21:31:19 <gmaxwell> (persistantly, not just the 20 minutes thing)
376 2012-10-08 21:31:26 <gmaxwell> slush: yes, it shows that after the 20 minute thing.
377 2012-10-08 21:31:34 <sipa> ah yes, the joy of special rules for testnet, and its weird interactions with the rest of the code :)
378 2012-10-08 21:31:34 <slush> oh
379 2012-10-08 21:32:00 <sipa> slush: getinfo actually calls the block creation logic, and checks which difficulty was created, i think
380 2012-10-08 21:32:53 <slush> ok, thanks. Now I have to find why my code started producing invalid blocks in this situation :(
381 2012-10-08 23:06:12 <cryptorific> does anyone know if an increase in bitcoin hash rate increases the variance in the time between blocks being generated?
382 2012-10-08 23:11:08 <gmaxwell> cryptorific: No, it doesn't.
383 2012-10-08 23:11:37 <gmaxwell> cryptorific: Well depending on exactly what you're asking.
384 2012-10-08 23:12:10 <gmaxwell> E.g. if the hash rate is increasing right now then until difficulty catches up the time will be reduced.
385 2012-10-08 23:13:10 <gmaxwell> And that would increase the variance if you measured in that window when it changed. But I assumed what you were really asking is is the variance scale dependent.
386 2012-10-08 23:13:25 <gmaxwell> (e.g. does the overall hashrate / difficulty change it) and the answer to that is no.
387 2012-10-08 23:13:53 <cryptorific> so as i understand it, blocks should be generated every 10 mins, and theres going to be some variance, sometimes 8 minutes sometime 12, etc, theres gonna be a statistical variance (eg 95% of blocks will be generated within 10 minutes +/- x minutes),
388 2012-10-08 23:15:23 <cryptorific> does an increased network hash rate cause that vairence, x, to change, eg. high hashrate will lead to higher varience, versus lower hashrate to lower varience
389 2012-10-08 23:18:06 <cryptorific> i could see this being a problem, if everyone gets ASIC's and the hash rate goes up very high and the variance increases to the point where, the average time is 10 minutes but we end up with waves of blocks and long periods of no blocks, eg, 2-3 hours
390 2012-10-08 23:20:03 <cryptorific> if it is the case that the variance does increase with hash rate
391 2012-10-08 23:27:01 <cryptorific> hmmm, kind of an answer but not really http://bitcoin.stackexchange.com/questions/4668/does-variability-of-block-solution-time-change-as-difficulty-increases/4669#4669
392 2012-10-08 23:28:01 <cryptorific> nevermind
393 2012-10-08 23:28:07 <cryptorific> that is an answer