1 2012-05-10 00:00:21 <gmaxwell> phantomcircuit: the the third party says "oh sorry, we want $100,000 to access your money"  or "funny, we got this alamony order from your exwife"
  2 2012-05-10 00:01:07 <gmaxwell> Might as well just have an encrypted truly random string (no attacks from just he blockchain) ... and leave that with whatever trusted parties you like.
  3 2012-05-10 00:01:26 <phantomcircuit> gmaxwell, right but you could have more than one
  4 2012-05-10 00:01:46 <phantomcircuit> gmaxwell, well yes that's what i was implying
  5 2012-05-10 00:01:58 <phantomcircuit> you would print it out and put it in your safety deposit box
  6 2012-05-10 00:02:03 <phantomcircuit> could*
  7 2012-05-10 00:02:54 <sipa> gmaxwell: but i feel that this user interface to wallet (re)construction is outside of the scope of the BIP (though i would very much like to have that common between clients too)
  8 2012-05-10 00:03:02 <Yuio> i agree with sipa that retrive some informations can be good
  9 2012-05-10 00:03:30 <sipa> gmaxwell: still, adding a fixed slow step in going from 128(+) bits to 512 is a good idea
 10 2012-05-10 00:03:59 <gmaxwell> sipa: _much_ better than not.
 11 2012-05-10 00:04:10 <sipa> if it's going to be used as i hope, it won't matter
 12 2012-05-10 00:04:18 <sipa> but if it isn't (and indeed, it won't), it will
 13 2012-05-10 00:04:44 <gmaxwell> Thats why I brought it up.
 14 2012-05-10 00:05:09 <gmaxwell> another possibility is to burn some entropy to the sane use gods.
 15 2012-05-10 00:05:15 <sipa> ?
 16 2012-05-10 00:06:05 <gmaxwell> Explained:  Require that expensive('password')=x, such that the first n bits of x are zeros.. Where x is say, 16 or so.
 17 2012-05-10 00:06:14 <sipa> "the first 16 bits of the SHA256 sum should be 0, but we use the SHA512 as seed" ?
 18 2012-05-10 00:06:27 <sipa> right
 19 2012-05-10 00:06:31 <gmaxwell> Did you write that in parallel to me? crazy. Yes.
 20 2012-05-10 00:07:00 <sipa> i certainly started typing before i saw your response
 21 2012-05-10 00:07:28 <gmaxwell> This would make it impossible to use purely user provided passwords as the source.
 22 2012-05-10 00:07:56 <gmaxwell> They'd have to have at on average 16 bits of 'salt' ... and more likely just be randomly generated entirely.
 23 2012-05-10 00:08:26 <sipa> and the "security level" could define the number of zero bits
 24 2012-05-10 00:08:43 <sipa> (to make it future-proof)
 25 2012-05-10 00:10:03 <gmaxwell> it need to do the bit check on the other side of expensive() and also has to have the chain on the other side of expensive. Otherwise you'd just check the blockchain instead of running expensive. Or check for 16 zeros before running expensive.
 26 2012-05-10 00:10:20 <gmaxwell> But e.g. if expensive writes out more bits than needed just use bits that the rest won't use.
 27 2012-05-10 00:10:40 <sipa> the chain?
 28 2012-05-10 00:11:18 <sipa> you mean the key tree derivation?
 29 2012-05-10 00:11:23 <gmaxwell> Right.
 30 2012-05-10 00:11:32 <luke-jr> can we make Bitcoin accept preimages for POW? :P
 31 2012-05-10 00:11:56 <gmaxwell> I mean the cost of checking a candidate key either way needs to be fairly equal or the attacker will just use the easier one.
 32 2012-05-10 00:12:14 <sipa> gmaxwell: good point
 33 2012-05-10 00:13:03 <gmaxwell> So e.g. I'd say scrypt(pwd+seclevel)=768 bits, and the zeros test is just the last seclevel bits, and the key tree root is the first 512. Or the like.
 34 2012-05-10 00:14:51 <sipa> but that will make generation very slow
 35 2012-05-10 00:15:21 <sipa> as you need the slow scrypt (with many iterations, i assume), and run it 2^N times, if you require N zero bits
 36 2012-05-10 00:15:30 <gmaxwell> hm? Not with the right parameters for the scrypt,  small ones are justifyable becuase of the iterations.
 37 2012-05-10 00:16:54 <sipa> BIP32 is already mostly SHA512-based, but yes, i have some preference for not using too many algorithms
 38 2012-05-10 00:17:05 <sipa> though i like scrypt a lot too
 39 2012-05-10 00:18:59 <gmaxwell> I just wish we could build a device that sets people who build tools that encourage users to footgun on fire. That seems more satisifying and simpler.
 40 2012-05-10 00:20:20 <gmaxwell> Even 8 bits of entropy burning is probably enough to prevent the pure password use cases... that doesnt seem that slow and for stored wallets we only pay it once.
 41 2012-05-10 00:20:47 <gmaxwell> (because you'd store the (optionally encrypted) output of that step too)
 42 2012-05-10 00:21:35 <gmaxwell> and then only import/export in that form or the inner chain keys. .. but bleh, perhaps futile, people will just import inner chainkeys which were insecurely generated instead.
 43 2012-05-10 00:22:01 <sipa> but inner chain keys are 512 bits
 44 2012-05-10 00:23:02 <gmaxwell> right and someone will make some tool that does sha512('Imanidiot')= chainkeys.
 45 2012-05-10 00:23:09 <sipa> yup
 46 2012-05-10 00:23:39 <sipa> so whatever we're suggesting here should be simple enough that it's viable they choose the standard instead of that :)
 47 2012-05-10 00:24:23 <gmaxwell> well at least importing a chain key costs you functionality. but yea.. ::shrugs::
 48 2012-05-10 01:38:37 <twmz> sipa: I must be doing something wrong. neither sleep(0) nor sleep(1) prevented the 100% cpu issue for me.  I know gavinandresen said it fixed it, though which is why I think I may have done something wrong.  note, the 100% CPU is not right away.  it doesn't start until a minute or two after bitcoin starts up.
 49 2012-05-10 01:38:59 <DiabloD3> sleep(1) fixes normal dummy loop sleep bugs
 50 2012-05-10 01:39:11 <DiabloD3> ie, it tells it to actually sleep
 51 2012-05-10 01:40:41 <gmaxwell> twmz: yes, "it doesn't start until a minute or two after bitcoin starts up" expected for this bug, the busyloop only goes busy when you are full outbound wise.
 52 2012-05-10 01:41:16 <gmaxwell> twmz: try making it Sleep(100).  also, make sure you're actually running the version you just compiled. :)
 53 2012-05-10 01:44:27 <DiabloD3> gmaxwell: that shouldnt matter
 54 2012-05-10 01:44:47 <DiabloD3> sleep(1) still forces a context switch on your usual broken schedulers
 55 2012-05-10 01:45:07 <gmaxwell> DiabloD3: it's still busy which isn't really what we want here.
 56 2012-05-10 01:45:30 <DiabloD3> true
 57 2012-05-10 01:45:33 <DiabloD3> but I think its not that
 58 2012-05-10 01:45:45 <gmaxwell> the only purpose of the loop is to open more outbound connections if some close. We can handle a maximum 100ms wait for that.
 59 2012-05-10 01:46:21 <gmaxwell> DiabloD3: It's pretty clearly spending all that time in that loop, and the fact that it doesn't start until a bit after startup is also good evidence.
 60 2012-05-10 01:46:31 <DiabloD3> yes
 61 2012-05-10 01:46:33 <DiabloD3> which means
 62 2012-05-10 01:46:44 <DiabloD3> which meaaannnsss
 63 2012-05-10 01:46:46 <DiabloD3> I hate fglrx
 64 2012-05-10 01:47:02 <DiabloD3> because they should just gpl the fucking kenrel module and have upstream ship it in the fucking kenrel
 65 2012-05-10 01:47:12 <DiabloD3> Ive been fighting with this thing for the last two fucking hours
 66 2012-05-10 01:47:14 <DiabloD3> WORK ALREADY
 67 2012-05-10 01:49:39 <DiabloD3> seriously
 68 2012-05-10 01:50:12 <gmaxwell> DiabloD3: hey! hey!
 69 2012-05-10 01:50:22 <gmaxwell> I think you've butt dialed #bitcoin-dev
 70 2012-05-10 01:50:32 <gmaxwell> ... because this sure isn't #fglrx hate
 71 2012-05-10 01:50:37 <DiabloD3> heh
 72 2012-05-10 01:50:50 <DiabloD3> my problems are more important than twmz's problems
 73 2012-05-10 01:59:56 <k9quaint> ATI always had bad drivers
 74 2012-05-10 02:01:34 <DiabloD3> fuck off k9
 75 2012-05-10 02:51:31 <gribble> New news from bitcoinrss: luke-jr reopened pull request 1246 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1246>
 76 2012-05-10 03:46:18 <luke-jr> ;;bc,diff
 77 2012-05-10 03:46:19 <gribble> 1733207.5138484
 78 2012-05-10 04:25:57 <JFK911> wow difficulty
 79 2012-05-10 04:25:59 <gribble> Best bid: 5.04882, Best ask: 5.0492, Bid-ask spread: 0.00038, Last trade: 5.04882, 24 hour volume: 32932, 24 hour low: 5, 24 hour high: 5.09609
 80 2012-05-10 04:25:59 <JFK911> !ticker
 81 2012-05-10 04:26:02 <JFK911> ;;bc,,stats
 82 2012-05-10 04:26:03 <gribble> Error: "bc,,stats" is not a valid command.
 83 2012-05-10 04:26:06 <JFK911> ;;bc,stats
 84 2012-05-10 04:26:08 <gribble> Current Blocks: 179537 | Current Difficulty: 1733207.5138484 | Next Difficulty At Block: 181439 | Next Difficulty In: 1902 blocks | Next Difficulty In About: 1 week, 5 days, 15 hours, 47 minutes, and 30 seconds | Next Difficulty Estimate: 1824318.47085058 | Estimated Percent Change: 5.25678294578
 85 2012-05-10 06:03:52 <fpgaminer> Is 0x00 supposed to be base58 encoded as "1" or as "11"? Brainwallet shows "11", but reading the Bitcoin code it seems like it should be just "1".
 86 2012-05-10 08:30:53 <gribble> New news from bitcoinrss: olea opened issue 1249 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1249>
 87 2012-05-10 09:18:29 <twmz> gmaxwell: it still didn't help even with sleep(100).  we are talking about this line of code (right?)...
 88 2012-05-10 09:18:31 <twmz> do { while(!(condition)) { (name).wait(waitablecriticalblock.GetLock()); sleep(100);} } while(0)
 89 2012-05-10 09:18:45 <twmz> I confirmed I am running the version I compiled.
 90 2012-05-10 09:19:19 <drizztbsd> 100 seconds! :E
 91 2012-05-10 09:19:22 <twmz> Is it possible that the busy loop is *inside* the call to (name).wait() and so the sleep is getting called only once after the wait is entirely over?
 92 2012-05-10 09:19:25 <sipa> it's in millisecond
 93 2012-05-10 09:19:44 <sipa> twmz: if you've a means to test that, please do
 94 2012-05-10 09:20:09 <sipa> twmz: wait, sleep with a small or large s?
 95 2012-05-10 09:20:41 <twmz> exactly as I pasted it above.  which should it be?
 96 2012-05-10 09:20:43 <drizztbsd> Sleep should be milliseconds
 97 2012-05-10 09:20:57 <sipa> twmz: try Sleep(1) there
 98 2012-05-10 09:21:03 <sipa> Sleep is milliseconds, sleep is seconds
 99 2012-05-10 09:21:15 <drizztbsd> yes, I know :)
100 2012-05-10 09:21:56 <twmz> ok, well it's not stuck for 100 seconds.  It's still maxing out the CPU, so I don't think that loop is not spinning.  it almost has to be deeping in the stack.
101 2012-05-10 09:22:16 <twmz> I get different output in the profiler now that I am profiling the debug version also:
102 2012-05-10 09:22:44 <twmz> http://i.imgur.com/f2359.png
103 2012-05-10 09:23:14 <sipa> hmmm
104 2012-05-10 09:23:38 <sipa> the spinlock seems to be inside .wait(), it seems
105 2012-05-10 09:23:46 <sipa> still, could you try that Sleep(1) ?
106 2012-05-10 09:23:52 <twmz> yes, it's compiling
107 2012-05-10 09:25:15 <sipa> somehow i doubt it will make a difference
108 2012-05-10 09:25:30 <sipa> but still, as gavin reported that that seemed to fix the issue...
109 2012-05-10 09:25:59 <Diablo-D3> if you have more than one sleep in your loop, you've gone wrong somewhere
110 2012-05-10 09:26:43 <twmz> only thing I can think is gavin wasn't waiting long enough (the busyloop doesn't happen until enough outbound connections are established, gmaxwell said
111 2012-05-10 09:29:39 <twmz> ok, it's still at 100% with Sleep(1)
112 2012-05-10 09:29:45 <twmz> after 8 connections, that is
113 2012-05-10 09:30:47 <sipa> bah
114 2012-05-10 09:30:59 <sipa> how is one supposed to wait for a condition variable in OSX?
115 2012-05-10 09:33:16 <sipa> gavinandresen: see above; are you sure the Sleep(1) fixes the 100% usage?
116 2012-05-10 09:36:21 <twmz> IMHO, the boost guys should have the Sleep() in their busy loop.  It's obsurd that they feel is is ok to just spin in a tight loop.  Of course, there probably is also some kind of OS X specific API for doing this kind of thing that maybe they should take advantage of, but sometimes those APIs are not available to C++ apps (and are only available to Objective C apps).  Not sure if that is the case here.
117 2012-05-10 09:36:35 <Diablo-D3> boost is fucktarded, please dont use it.
118 2012-05-10 09:37:12 <sipa> twmz: i'll try to reimplement it using a semaphore, as suggested by jgarzik
119 2012-05-10 09:37:18 <sipa> that is actually more appropriate here
120 2012-05-10 09:37:33 <sipa> though i would have liked to just be able to use conditions
121 2012-05-10 09:39:36 <TuxBlackEdo> i have a question, what still needs to be done with the bitcoin client?
122 2012-05-10 09:41:51 <TuxBlackEdo> or is the bitcoin client pretty much done?
123 2012-05-10 10:01:29 <ronaz> is the language still forced to be localized based on os settings? seems to be in 0.6.0.6-beta at least. it sucks, big time.
124 2012-05-10 10:03:13 <sipa> ronaz: 0.7.0 will have it configurable from the options panel
125 2012-05-10 10:04:21 <ronaz> great news!
126 2012-05-10 10:05:37 <Blitzboom> http://wiki.eth-0.nl/images/9/9e/Great_success.jpg
127 2012-05-10 10:06:25 <sipa> ronaz: personally, i never liked translated programs, so even though my native language isn't english, my OS always is
128 2012-05-10 10:07:20 <ronaz> sipa: same for me, my win7 is in english but the client runs in my native language based on some other setting there is
129 2012-05-10 10:07:29 <sipa> hmm, strange
130 2012-05-10 10:55:26 <kinlo> sipa: many programs request the region settings from windows to deduct the language
131 2012-05-10 10:55:33 <kinlo> it is indeed extreamly anoying
132 2012-05-10 10:55:57 <kinlo> I'd like to tell the os that I speak english but I like to use dutch conventions etc
133 2012-05-10 11:40:21 <gribble> New news from bitcoinrss: Diapolo opened pull request 1250 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1250>
134 2012-05-10 11:45:31 <gribble> New news from bitcoinrss: Diapolo opened pull request 1251 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1251>
135 2012-05-10 13:28:48 <luke-jr> gmaxwell: do you think it would be a bad idea to add support for alternative block hashing algorithms scheduled for 2 years from now?
136 2012-05-10 13:29:10 <drizztbsd> like sha512?
137 2012-05-10 13:29:14 <luke-jr> yes
138 2012-05-10 13:29:18 <luke-jr> and preimage proofs
139 2012-05-10 13:29:33 <drizztbsd> fpgas needs new firmare
140 2012-05-10 13:29:35 <sipa> why preimage proofs?
141 2012-05-10 13:29:39 <luke-jr> sipa: preimage proofs can solve the whole block withholding issue, in theory
142 2012-05-10 13:29:46 <sipa> explain
143 2012-05-10 13:30:45 <luke-jr> sipa: I haven't figured out the details for p2pool/GMP style mining, but for getwork, the pool can include the preimage in the coinbase, and not tell miners what they're looking for in a block
144 2012-05-10 13:30:56 <luke-jr> then miners won't know which shares to withhold
145 2012-05-10 13:31:21 <sipa> luke-jr: the block header would need to contain the preimage
146 2012-05-10 13:31:29 <luke-jr> sipa: it could be in the coinbase
147 2012-05-10 13:31:30 <sipa> since you can't decide it in advance
148 2012-05-10 13:31:36 <sipa> agree, in the coinbase would be fine
149 2012-05-10 13:32:09 <sipa> i'd wait until SHA-3 is chosen, and has had a few years of testing
150 2012-05-10 13:34:37 <gmaxwell> What sipa says.. though interesting thing about withholding.
151 2012-05-10 13:35:56 <sipa> i wonder if it's necessary to have the PoW hash be equal to the id hash
152 2012-05-10 13:36:31 <gmaxwell> It makes some forms of DOS resistance easier...
153 2012-05-10 13:52:59 <luke-jr> sipa: gmaxwell: any comments on https://github.com/bitcoin/bitcoin/pull/1240#issuecomment-5627356 notes?
154 2012-05-10 13:57:59 <sipa> luke-jr: i'll have a look at it later
155 2012-05-10 13:58:22 <sipa> anyone want to test http://bitcoin.sipa.be/shatest/test.html in their browser? (it's a HMAC-SHA512 benchmark)
156 2012-05-10 13:59:07 <gmaxwell> There is a bunch of stuff going on to do SIMD in JS, plus webcl is almost usable... so a year from now the browser hashfunction performance may be very different.
157 2012-05-10 14:02:03 <Diapolo> sipa: I will test ^^ love benches :D
158 2012-05-10 14:02:15 <luke-jr> sipa: Chromium=1607 Konqueror/Webkit=1168 Rekonq=1162
159 2012-05-10 14:02:28 <sipa> painfully slow :(
160 2012-05-10 14:02:40 <sipa> ff 12.0 does 9500 here
161 2012-05-10 14:02:47 <Diapolo> sipa: 9478.67298578199 (FF 14.0a2 Aurora)
162 2012-05-10 14:03:14 <luke-jr> 10706 in FF here
163 2012-05-10 14:03:29 <Diapolo> sipa: IE9 1200 ^^ LOL
164 2012-05-10 14:03:45 <luke-jr> odd, I thought Chromium was the pioneer in fast JS
165 2012-05-10 14:04:21 <sipa> ff is also faster than chromium here
166 2012-05-10 14:04:27 <sipa> a factor 2 only, though
167 2012-05-10 14:04:55 <Diapolo> Mozilla did a great job with their JS engine!
168 2012-05-10 14:05:22 <Diapolo> sipa: IE9 x64 < 300 i/s
169 2012-05-10 14:05:45 <kinlo> I get 6788 in FF and 2282 in chrome
170 2012-05-10 14:06:22 <gmaxwell> luke-jr: Chromium is foremost a pioneer in marketing. They got a head start on faster JIT based JS.. but mozilla already had the trace based optimizer which is much better than JIT for many tasks. When they finally combined JIT+Trace they had faster performance.
171 2012-05-10 14:07:00 <sipa> Diapolo: that's... almost ridiculous
172 2012-05-10 14:07:14 <kinlo> if only firefox would just fix a few of the anoying rough edges
173 2012-05-10 14:07:24 <Diapolo> sipa: I can do better by hand :D.
174 2012-05-10 14:07:24 <sipa> thanks all
175 2012-05-10 14:07:34 <Diapolo> kinlo: What you mean?
176 2012-05-10 14:07:51 <kinlo> Diapolo: might sound stupid, but I don't like the error messages that firefox gives me
177 2012-05-10 14:08:09 <kinlo> they are almost as bad as ie nowadays
178 2012-05-10 14:08:25 <kinlo> ie just says "server error or dns error" or something like that
179 2012-05-10 14:08:32 <kinlo> you really have no clue why it failed
180 2012-05-10 14:08:40 <kinlo> but firefox aint much better either
181 2012-05-10 14:08:47 <Diapolo> kinlo: Well I don't see much of them so ... I consider this a minor glitch at max.
182 2012-05-10 14:08:52 <kinlo> I like a technical reason why it failed
183 2012-05-10 14:09:08 <luke-jr> I forget why I stopped using Firefox this last time
184 2012-05-10 14:09:11 <luke-jr> maybe it crashed too much
185 2012-05-10 14:09:15 <kinlo> Diapolo: don't you want to know wether you couldn't connect due a connection refused or an internal server error?
186 2012-05-10 14:09:19 <Diapolo> kinlo: Perhaps there is an Addon for this :)?
187 2012-05-10 14:09:20 <luke-jr> oh, and the latest version doesn't build
188 2012-05-10 14:09:30 <kinlo> if it's connection refused I know I just have to restart it
189 2012-05-10 14:10:13 <Diapolo> kinlo: Even as IT-pro (kind of ^^) I'm fine with what I get ... if a server is down I can do research by myself.
190 2012-05-10 14:10:17 <kinlo> Diapolo: I doubt if there is an addon, the core must support that
191 2012-05-10 14:10:34 <kinlo> Diapolo: so do I, I open a terminal and do a wget - as wget gives me a reliable error
192 2012-05-10 14:10:54 <kinlo> I don't like that step, coz when I have to help someone else it just takes too much time
193 2012-05-10 14:11:07 <Diapolo> You could also use an addon to look into the HTTP headers e.g.
194 2012-05-10 14:11:34 <kinlo> wouldn't tell me the difference between a dns error, timeout or connection refused
195 2012-05-10 14:12:27 <gavinandresen> sipa:  Sleep(1) doesn't fix the 100% cpu bug
196 2012-05-10 14:12:31 <sipa> gavinandresen: i know
197 2012-05-10 14:12:50 <sipa> gavinandresen: i've rewritten the waiting system using semaphores, testing it now
198 2012-05-10 14:13:45 <luke-jr> nice
199 2012-05-10 14:21:55 <sipa> hmm, how should the interaction between -addnode and the connectioncount be?
200 2012-05-10 14:25:19 <jgarzik> sipa: addnode is IMO advisory: "please connect to this node, along with the others", much weaker than -connect's "you MUST connect only to <these> nodes"
201 2012-05-10 14:25:26 <jgarzik> sipa: so I wouldn't make it separate
202 2012-05-10 14:25:40 <jgarzik> addnode in practice just adds an initial connection attempt
203 2012-05-10 14:25:56 <sipa> not at all
204 2012-05-10 14:26:11 <sipa> its semantics was changed some time ago to "try to maintain a connection to this node"
205 2012-05-10 14:26:14 <gmaxwell> jgarzik: Bzzt.
206 2012-05-10 14:27:16 <gmaxwell> Yea. The old addnode behavior meant that it largely did nothing. Bluematt made a -addnodenoreally that was persistent... and at merge time it was decided that it should just replace addnode.
207 2012-05-10 14:27:32 <sipa> it was originally called -keepnode, i think
208 2012-05-10 14:28:06 <gmaxwell> Thanks, couldn't remember.
209 2012-05-10 14:38:43 <helo> the qr code icon just looks like a fuzzy blob... suggesting again helo.org/qrcode.png
210 2012-05-10 14:40:10 <gmaxwell> helo: open a pull request, don't just request on IRC. :)
211 2012-05-10 14:40:23 <kinlo> is there a way to make a connect to automatically reconnect after a connection is lost?
212 2012-05-10 14:40:25 <helo> yeah...
213 2012-05-10 14:40:40 <kinlo> I now have to restart my bitcoind from time to time
214 2012-05-10 14:41:59 <gmaxwell> kinlo: huh? You're saying you have a -connect set and it doesn't reconnect on its own? It certantly should (and does for me). What OS?
215 2012-05-10 14:43:29 <Diapolo> helo: That Icon got updated recently, are you talking about the current one?
216 2012-05-10 14:44:08 <Diapolo> https://github.com/bitcoin/bitcoin/blob/037a8daee68907b6258c2421a6f0d7265cd1b3ad/src/qt/res/icons/qrcode.png
217 2012-05-10 14:44:41 <helo> ahh, yeah that one is just as good
218 2012-05-10 14:44:46 <kinlo> gmaxwell: it should?
219 2012-05-10 14:44:52 <sipa> twmz, gavinandresen: can you try compiling/running https://github.com/sipa/bitcoin/tree/semaphores ?
220 2012-05-10 14:45:07 <sipa> and tell whether it removes the 100% CPU issue
221 2012-05-10 14:45:12 <kinlo> gmaxwell: I just restarted it if it wasn't having enough connections, but perhaps I should test wether it would reconnect automatically :p
222 2012-05-10 14:45:15 <gavinandresen> sipa: sure
223 2012-05-10 14:45:25 <kinlo> gmaxwell: I was under the impression it would never do that
224 2012-05-10 14:46:59 <gmaxwell> kinlo: 'wasn't having enough connections'  What exactly are you doing?  if you use -connect it should only have one connection out (to the node you told it to connect to)
225 2012-05-10 14:47:52 <kinlo> gmaxwell: I use connect multiple times
226 2012-05-10 14:47:54 <kinlo> gmaxwell: that does work fine :)
227 2012-05-10 14:48:12 <gmaxwell> Okay that too.
228 2012-05-10 14:48:28 <gmaxwell> But then you should only have N connections. And it should keep them up.
229 2012-05-10 14:48:40 <kinlo> yeah, 2 exactly
230 2012-05-10 14:49:02 <kinlo> but sometimes I looked at it and it would be 1, so I restarted it, assuming it wouldn't do that by itself
231 2012-05-10 14:50:19 <gavinandresen> sipa:  compiled, running now...
232 2012-05-10 14:55:41 <gmaxwell> kinlo: well the backoffs used for connect are brain damaged.
233 2012-05-10 14:56:32 <kinlo> gmaxwell: I'll have a look at it and let you know if something is wrong with the connect
234 2012-05-10 14:56:40 <kinlo> it's production so I can't just test it
235 2012-05-10 14:56:53 <gmaxwell> I have no clue what satoshi was thinking here.
236 2012-05-10 14:57:02 <gavinandresen> sipa: 10 connections, 100% CPU
237 2012-05-10 14:57:19 <gmaxwell> The time between retries on connect tend to infinity as the uptime of the node increases.
238 2012-05-10 14:57:20 <sipa> grmbl
239 2012-05-10 14:58:02 <sipa> gavinandresen: can you find out where it's spending time now?
240 2012-05-10 14:58:14 <kinlo> gmaxwell: so I need to restart the node to make reconnect work fast enough ? :)
241 2012-05-10 14:58:36 <gavinandresen> sipa:  maybe...
242 2012-05-10 14:58:36 <kinlo> that does sound stupid, however, not that big of an issue, I can tolerate that bitcoind being offline for a while
243 2012-05-10 14:58:42 <gmaxwell> kinlo: well it should take a long time before its really slow.
244 2012-05-10 14:59:02 <kinlo> gmaxwell: as long as you guys keep releasing newer versions, that won't happen then :)
245 2012-05-10 14:59:30 <sipa> gmaxwell: if i read the code correctly, it will very quickly be one attempt every 5s
246 2012-05-10 14:59:43 <sipa> for -connect, if that's what you're still talking about
247 2012-05-10 15:00:17 <gmaxwell> sipa: okay apparently I am too stupid for code today. The && in my mind was becoming an or.
248 2012-05-10 15:00:39 <gmaxwell> Well never mind then. indeed all is fine.
249 2012-05-10 15:00:39 <kinlo> sipa: that would surprise me, in that case it would not be possible for me to see only 1 connection :)
250 2012-05-10 15:00:55 <kinlo> oh well, ignore it, connect isn't for the regular user
251 2012-05-10 15:00:57 <gmaxwell> kinlo: sure it would. It's failing to reconnect sometimes.
252 2012-05-10 15:01:11 <kinlo> gmaxwell: my bitcoins are always online :)
253 2012-05-10 15:01:19 <gmaxwell> kinlo: doesn't mean they aren't full.
254 2012-05-10 15:01:22 <kinlo> bitcoind's*
255 2012-05-10 15:01:45 <kinlo> gmaxwell: I assumed the limit was > 100, never got more then 20 connections on them
256 2012-05-10 15:03:09 <gmaxwell> well look at your logs... because it does retry every 5 seconds.
257 2012-05-10 15:04:08 <kinlo> I will if it happens again
258 2012-05-10 15:07:14 <gavinandresen> sipa: running again under valgrind --callgrind ....
259 2012-05-10 15:11:57 <sipa> gavinandresen: just gdb, wait untill 100%, interrupt somewhere, and see which thread is not sleeping?
260 2012-05-10 15:12:09 <sipa> gavinandresen: (ok, i admit, i don't know callgrind)
261 2012-05-10 15:13:16 <gavinandresen> mmm.  callgrind isn't being extremely helpful, it says interprocess_semaphore.hpp:boost::interprocess::interprocess_semaphore::wait() is being called a bunch
262 2012-05-10 15:15:35 <sipa> pfff, i'm inclined to just write a wrapper around it that does Sleep(100) and checks from time to time
263 2012-05-10 15:16:17 <gavinandresen> sipa: how do I get gdb to tell me which thread is not sleeping?
264 2012-05-10 15:17:09 <sipa> gavinandresen: info threads
265 2012-05-10 15:17:18 <gavinandresen> of course... (I trued show threads)
266 2012-05-10 15:17:56 <b4epoche> sipa:  5420 in Safari 5.1.7
267 2012-05-10 15:18:31 <Cryo> you're still fighting the threading issue with sleep?
268 2012-05-10 15:18:38 <gavinandresen> sipa: gdb isn't being very helpful either:  https://gist.github.com/2654539
269 2012-05-10 15:20:16 <gavinandresen> sipa: you don't suppose it's an issue that's been fixed in boost 1.49.... (I'm using 1.47)
270 2012-05-10 15:22:16 <Diapolo> http://www.boost.org/users/history/version_1_49_0.html
271 2012-05-10 15:23:32 <gavinandresen> I'll deactivate 1.47 and compile 1.49, see if that fixes the issue.
272 2012-05-10 15:24:08 <gavinandresen> (that'll take a while, though)
273 2012-05-10 15:24:43 <sipa> i don't see anything related in the changelog
274 2012-05-10 15:32:19 <Cryo> fixes osx deadlock
275 2012-05-10 15:45:45 <jgarzik> gmaxwell: noted
276 2012-05-10 15:45:47 <jgarzik> so
277 2012-05-10 15:46:06 <gmaxwell> Cryo: deadlock?
278 2012-05-10 15:46:26 <jgarzik> what is everybody's favorite python ECDSA module?  I see warner/python-ecdsa and pypi/ecdsa
279 2012-05-10 15:46:30 <jgarzik> phantomcircuit: ^^
280 2012-05-10 15:47:35 <Cryo> was reading the boost fixes
281 2012-05-10 15:48:15 <gmaxwell> ah.
282 2012-05-10 15:57:52 <sipa> jgarzik: *puke*
283 2012-05-10 16:14:38 <weex> jgarzik: seems legit
284 2012-05-10 16:33:21 <gavinandresen> sipa: no difference compiled against boost 1.49, still 100% cpu
285 2012-05-10 16:46:01 <sipa> gavinandresen: updated semaphores branch; it now uses a polling loop on OSX
286 2012-05-10 16:46:49 <gavinandresen> sipa: compiling....
287 2012-05-10 16:57:42 <gavinandresen> sipa: 9 connections, less than 1% CPU time... looking good
288 2012-05-10 16:58:17 <sipa> gavinandresen: i'm glad it already compiled the first time...
289 2012-05-10 16:58:49 <gavinandresen> can't be any bugs if it compiled the first time.....
290 2012-05-10 17:05:24 <sipa> gavinandresen: riiiight...
291 2012-05-10 17:06:33 <sipa> gavinandresen: i just hope mutexes still work on OSX...
292 2012-05-10 17:06:45 <sipa> even if condition variables and semaphores don't
293 2012-05-10 17:12:18 <sipa> gavinandresen: still compiles?
294 2012-05-10 17:18:24 <gribble> New news from bitcoinrss: sipa opened pull request 1252 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1252>
295 2012-05-10 18:00:06 <Matt_von_Mises> For my bitcoin library I'm making would it make more sense to use big-endian bignums or little-endian? What would be most compatible? Seems bitcoin uses a mixture of big-endian and little-endian.
296 2012-05-10 18:00:55 <sipa> internally, it's almost everywhere little-endian
297 2012-05-10 18:01:22 <sipa> some crypto encodings are big endian, but those are done by OpenSSL
298 2012-05-10 18:04:06 <Matt_von_Mises> Hmm, it seems the bitcoinj library uses big-endian. I got carried away and was just copying that. I guess it would make more sense to use little-endian to avoid conversions. Thanks.
299 2012-05-10 18:04:34 <TD> java is big endian
300 2012-05-10 18:04:38 <TD> bitcoin is a mix of big and little
301 2012-05-10 18:04:41 <TD> -> pain results
302 2012-05-10 18:06:11 <Matt_von_Mises> Big endian is nicer to visualise but it does cause issues with pointers and length adjustments
303 2012-05-10 18:06:22 <Matt_von_Mises> I'll use little-endian. Makes sense.
304 2012-05-10 18:16:42 <gavinandresen> sipa: could you backport a minimal 100% CPU fix to the 0.6.2 branch?  cherry-picking pulls from 1252 doesn't work because they depend on post-0.6 changes...
305 2012-05-10 18:17:05 <gavinandresen> I want to release a 0.6.2.something for osx to fix this one bug.
306 2012-05-10 18:22:13 <sipa> i'm on it
307 2012-05-10 18:28:54 <sipa> gavinandresen: https://github.com/sipa/bitcoin/tree/semaphores-v0.6.2
308 2012-05-10 18:29:00 <sipa> (very minimally tested only)
309 2012-05-10 18:29:52 <gavinandresen> sipa: thanks
310 2012-05-10 18:29:57 <gavinandresen> (i'll compile and test)
311 2012-05-10 18:30:49 <sipa> segfault
312 2012-05-10 18:35:37 <sipa> fixed
313 2012-05-10 18:36:22 <sipa> seems to work
314 2012-05-10 18:47:30 <gavinandresen> i hate c++ compiler error messages....
315 2012-05-10 18:47:47 <gavinandresen> sipa: compiler error here, let me see if I can figure out what it actually is...
316 2012-05-10 18:47:51 <BlueMatt> gavinandresen: I hate boost c++ compiler error messages
317 2012-05-10 18:48:30 <gavinandresen> error is src/qt/qtipcserver.cpp line 33 ...
318 2012-05-10 18:49:07 <BlueMatt> on osx? I thought that file was one big comment on osx?
319 2012-05-10 18:49:56 <gavinandresen> the ipcInit() does nothing on OSX and Windows
320 2012-05-10 18:49:56 <sipa> gavinandresen: muhuw?
321 2012-05-10 18:50:00 <sipa> i didn't touch that
322 2012-05-10 18:51:24 <Diapolo> I did touch this, but that's not in the master ^^.
323 2012-05-10 18:52:33 <gavinandresen> sipa:  checking to see where it broke....
324 2012-05-10 19:01:07 <gavinandresen> sipa:  it's not you, I think boost 1.49 broke it
325 2012-05-10 19:06:34 <gmaxwell> er did githum just merge all the issues and pull requests?
326 2012-05-10 19:06:39 <gmaxwell> er github
327 2012-05-10 19:07:55 <Diapolo> gmaxwell: no
328 2012-05-10 19:08:17 <Diapolo> but it seems Githup is having a hickup today ^^
329 2012-05-10 19:08:22 <Diapolo> -p +b
330 2012-05-10 19:08:34 <gmaxwell> https://github.com/bitcoin/bitcoin/issues  < this appears full of pull requests now
331 2012-05-10 19:09:12 <sipa> it's just empty here
332 2012-05-10 19:09:48 <gavinandresen> that's the final straw!  We should move to gitorious!   (kidding, just trolling luke....)
333 2012-05-10 19:09:51 <Diapolo> try to reload, they seem to change their layout / icons / graphics
334 2012-05-10 19:09:57 <jgarzik> github has been spotty for the past several days
335 2012-05-10 19:10:25 <jgarzik> clicking on sipa's IPv6 pull req would result in no discussion or commits.  <ctrl><shift><R> reload would usually fix it... but not always
336 2012-05-10 19:12:16 <sipa> gavinandresen: you mean you wouldn't like an empty issue list...?
337 2012-05-10 19:12:38 <sipa> it's a feature!
338 2012-05-10 19:12:44 <gavinandresen> rm -rf issues
339 2012-05-10 19:12:48 <gavinandresen> done!
340 2012-05-10 19:13:26 <sipa> comparing HMAC-SHA512 in JavaScript vs OpenSSL: slowdown between 50x and 500x
341 2012-05-10 19:14:30 <gmaxwell> And OpenSSL's implementation is probably fast but not the fastest possible.
342 2012-05-10 19:15:44 <sipa> the same is probably true about the two javascript implementations i tried
343 2012-05-10 19:16:25 <gavinandresen> sipa: testing semaphores-0.6.2 now....
344 2012-05-10 19:21:00 <gmaxwell> actually, looks like openssl is pretty good: http://bench.cr.yp.to/impl-hash/sha512.html
345 2012-05-10 19:23:09 <gribble> New news from bitcoinrss: gavinandresen opened issue 1253 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1253>
346 2012-05-10 19:25:07 <Diapolo> sipa: Could be done on GPUs I guess, so we need WebCL ^^.
347 2012-05-10 19:30:36 <gavinandresen> sipa: semaphores-v0.6.2 seems to be working nicely, I want to let it run overnight, if there are no issues I'll tag a 0.6.2.2 make an osx .dmg file and update the binaries on sourceforge and links tomorrow
348 2012-05-10 20:08:28 <egecko> wow, the man in the middle attack vulnerability is still unaddressed.. and here i thought i was actually helping by keeping that info limited in distribution
349 2012-05-10 20:09:46 <sipa> ?
350 2012-05-10 20:12:59 <gmaxwell> sipa: he's talking about the http auth reuse.
351 2012-05-10 20:14:46 <jgarzik> json-rpc auth reuse?
352 2012-05-10 20:15:13 <jgarzik> if you have remote hosts accessing your json-rpc, you have bigger problems than MITM
353 2012-05-10 20:15:22 <gmaxwell> jgarzik: if you (for some crazy crackheaded reason) write a browser app that http auths to your bitcoin RPC port, another page can CSRF you to make rpc calls.
354 2012-05-10 20:51:08 <luke-jr> gmaxwell: well, that's easily fixed; but I agree with your crazy crackheaded idea
355 2012-05-10 20:51:19 <luke-jr> (that is, it's stupid to auth to bitcoind in your browser)
356 2012-05-10 20:52:00 <gmaxwell> I didn't see a clean way to fix it that wouldn't potentially screw up things that persist the connections.
357 2012-05-10 20:52:15 <gmaxwell> egecko pointed out that IE will pass the CSRF request over the same socket.
358 2012-05-10 20:52:52 <luke-jr> gmaxwell: if Referrer, refuse?
359 2012-05-10 20:52:59 <luke-jr> Referer*
360 2012-05-10 20:53:13 <luke-jr> or do browsers let pages hide that now?
361 2012-05-10 20:53:51 <gmaxwell> I think XmlHttpRequest requests won't have them.
362 2012-05-10 20:53:57 <gmaxwell> (or will let them be forged)
363 2012-05-10 20:55:17 <gmaxwell> The standard way to prevent CSRF is to include some cookie that the attacker won't know. But thats sort of crazy for our purpose.
364 2012-05-10 21:02:58 <sipa> gmaxwell: if you want to find stuck node to sync with with a pre-BIP16-datemove node, to test the unstuck patch, see seeds.txt :)
365 2012-05-10 21:03:26 <gmaxwell> oh brillian idea.
366 2012-05-10 21:11:48 <gmaxwell> pulling from someone with 05/10/12 23:09:52 version message: version 60000, blocks=176947
367 2012-05-10 21:12:24 <gmaxwell> sipa: I wonder if DNSseed was returning this node I bet it was.
368 2012-05-10 21:12:44 <gmaxwell> Hell, I bet thats actually trapping some new users on startup if indeed we can't reorg off it still.
369 2012-05-10 21:13:10 <gmaxwell> e.g. first node you connect is some stuck node, now you're stuck too.
370 2012-05-10 21:18:49 <sipa> but as soon as another node you're connected to tells you about the real chain, you should be fine
371 2012-05-10 21:18:57 <sipa> the side chains aren't ever long, are they
372 2012-05-10 21:18:58 <sipa> ?
373 2012-05-10 21:20:43 <gmaxwell> sipa: if it was long enough to prevent the stuck node from unsticking why isn't it long enough to prevent you from doing the same?
374 2012-05-10 21:22:36 <sipa> gmaxwell: because the stuck node remains stuck if the new chain is >500 blocks long, but it will never get those in its main chain
375 2012-05-10 21:22:54 <sipa> even if the side chain is only 1 block long
376 2012-05-10 21:23:32 <sipa> while the bootstrapping node will just the side chain, never having heard about the new long chain (so it can't be marked already downloaded, preventing further download)
377 2012-05-10 21:23:48 <sipa> ").correctGrammar();
378 2012-05-10 21:24:07 <gmaxwell> ah. duh. Today is a mentally slow day for me.
379 2012-05-10 21:24:11 <sipa> the first time the new node hears about the real chain, it will just download it and accept it
380 2012-05-10 21:24:58 <sipa> but you're quite right my dns seed should check for reasonable number of blocks
381 2012-05-10 21:26:14 <sipa> maybe i could link it up with bitcoind, now getblockhash() exists
382 2012-05-10 21:26:30 <sipa> and request some random recent block
383 2012-05-10 21:26:40 <gmaxwell> Thats a grand idea.
384 2012-05-10 21:27:44 <gmaxwell> if the height is high enough request a random block from 3-6 back or so just to make sure it's on the same chain as you.
385 2012-05-10 21:36:26 <jgarzik> Loading wallet...
386 2012-05-10 21:36:27 <jgarzik> nFileVersion = 69900
387 2012-05-10 21:36:35 <jgarzik> sipa: ^^ is this normal for brand new wallets?
388 2012-05-10 21:37:02 <jgarzik> seems a bit strange to "upgrade" a wallet that did not exist before the current program run
389 2012-05-10 21:38:22 <jgarzik> and "Added 10 addresses from 0:0:0:0:0:0:0:0: 0 tried, 10 new" is interesting
390 2012-05-10 21:39:39 <sipa> jgarzik: haha; agree, reporting could be better
391 2012-05-10 21:39:55 <sipa> in both cases
392 2012-05-10 21:40:25 <sipa> if it's ::0, it should just be hidden (and it should be ::0, not 0:0:0:...)
393 2012-05-10 21:53:56 <jgarzik> sipa: is the importprivkey format actually documented anywhere?
394 2012-05-10 21:54:26 <sipa> jgarzik: it's on the wiki, and here: http://sourceforge.net/mailarchive/forum.php?thread_name=CAPg%2BsBhDFCjAn1tRRQhaudtqwsh4vcVbxzm%2BAA2OuFxN71fwUA%40mail.gmail.com&forum_name=bitcoin-development
395 2012-05-10 21:54:41 <jgarzik> sipa: do I have this right:  <version byte> <base58-encoded 256 bits> <last 4 bytes of sha256 checksum> ?
396 2012-05-10 21:54:49 <Matt_von_Mises> "inline bool DecodeBase58(const char* psz, std::vector<unsigned char>& vchRet)" What would the largest length be for psz?
397 2012-05-10 21:55:09 <sipa> jgarzik: yes, for uncompressed ones
398 2012-05-10 21:55:25 <sipa> jgarzik: for compressed ones, there is a 0x01 byte after the 256 bits
399 2012-05-10 21:57:16 <sipa> Matt_von_Mises: currently used, 52 characters
400 2012-05-10 21:57:58 <Matt_von_Mises> I figured out 51, not including the termination character. I guess 52 includes the termination character?
401 2012-05-10 21:58:16 <sipa> Matt_von_Mises: see what i told jgarzik the line above
402 2012-05-10 21:59:01 <Matt_von_Mises> Oh right so an extra byte making it 53 including termination character?
403 2012-05-10 21:59:06 <sipa> yes
404 2012-05-10 21:59:16 <Matt_von_Mises> Thanks.
405 2012-05-10 21:59:29 <sipa> but it may be used for longer data structures in the future, maybe
406 2012-05-10 22:00:29 <splatster> Any easy way to get a recent version of bitcoind on debian?
407 2012-05-10 22:00:50 <splatster> aptitude only has a 0.3.x version available
408 2012-05-10 22:04:12 <gmaxwell> sipa: fetching a recent block from the peers you probe would also let you avoid giving out useless halfnodes that just exist for monitoring purposes.
409 2012-05-10 22:27:11 <gribble> New news from bitcoinrss: jgarzik opened pull request 1254 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1254>
410 2012-05-10 23:24:32 <helo> About Bitcoin: Bitcoin version vCLIENT_VERSION_MAJOR.CLIENT_VERSION_MINOR.
411 2012-05-10 23:25:02 <helo> oO
412 2012-05-10 23:57:50 <jgarzik> and that's why it's nice to have a built-in CPU miner...
413 2012-05-10 23:59:36 <jgarzik> "difficulty" : 0.06249911
414 2012-05-10 23:59:58 <Garr255Mobi> haha. testnet isnfun to play around with.