1 2013-02-19 00:12:38 <gmaxwell> hm. after pulling boostrap my 0.8 test node didn't start pulling the chain immediately.
2 2013-02-19 00:16:47 <BlueMatt> god our test coverage is terrible
3 2013-02-19 00:17:19 <Diablo-D3> you just realized that?
4 2013-02-19 00:18:12 <BlueMatt> no, but seeing it staring you in the face is still a bit jarring
5 2013-02-19 00:18:26 <BlueMatt> http://jenkins.bluematt.me/job/Bitcoin/249/artifact/src/total.coverage/mnt/jenkins/jobs/Bitcoin/workspace/src/index.html
6 2013-02-19 00:18:39 <midnightmagic> ah good ol' jenkins.
7 2013-02-19 00:19:20 <Diablo-D3> is jenkins any good for c/c++ apps?
8 2013-02-19 00:19:44 <BlueMatt> it can listen to git and auto-run your bash scripts for each commit
9 2013-02-19 00:19:48 <BlueMatt> ^ all I use it for
10 2013-02-19 00:19:51 <gmaxwell> BlueMatt: sadly the branch coverage is worthless because of C++. :(
11 2013-02-19 00:20:10 <BlueMatt> gmaxwell: ok...neither line nor function coverage is much better
12 2013-02-19 00:20:13 <gmaxwell> Diablo-D3: it's fine. it's a batch scheduler. it runs commands. it can run them on remote machines. Tada.
13 2013-02-19 00:20:29 <Diablo-D3> is that it?
14 2013-02-19 00:20:31 <gmaxwell> BlueMatt: 35% vs 59% is a big difference.
15 2013-02-19 00:20:38 <Diablo-D3> I remember seeing lots of interesting shit on java projects
16 2013-02-19 00:20:44 <gmaxwell> Diablo-D3: I mean, jenkins does a lot of other stuff, most of it is kinda boring.
17 2013-02-19 00:21:04 <gmaxwell> you can make all of it work with C projects if you want to produce fun output.
18 2013-02-19 00:21:11 <BlueMatt> gmaxwell: well, yes, but 59% still sucks
19 2013-02-19 00:21:30 <gmaxwell> BlueMatt: yes, hey, I've bitched about this a lot too.
20 2013-02-19 00:22:23 <BlueMatt> everyone has, I was just pointing it out (again) because I was staring at it
21 2013-02-19 00:22:32 <Diablo-D3> actually, cant I make a git hook that makes git on the remote side run a script on push?
22 2013-02-19 00:22:37 <Diablo-D3> aaaaaactually
23 2013-02-19 00:22:47 <Diablo-D3> cant I use a git hook to run tests locally and fail to commit if they fail?
24 2013-02-19 00:22:57 <_W_> as I suspected, CoinBit private messages people joining this channel too; *CoinBit* Hi there, welcome to #bitcoin-dev !
25 2013-02-19 00:23:43 <midnightmagic> And #bitcoin
26 2013-02-19 00:23:50 <midnightmagic> GET HIM!
27 2013-02-19 00:25:56 <gmaxwell> CoinBit: Ahem?
28 2013-02-19 00:40:15 <Luke-Jr> Bitcoin-Qt non-determinism isn't fixed yet? :o
29 2013-02-19 00:43:49 <copumpkin> nondeterminism makes the world more fun
30 2013-02-19 00:47:48 <Luke-Jr> ACTION rebuilds his qt, since sipa's and gavinandresen's match
31 2013-02-19 00:50:07 <gavinandresen> Luke-Jr: hmm? sipa and my qt-win32-4.8.3 and our boost-win32-1.50.0 both did NOT match
32 2013-02-19 00:51:10 <gavinandresen> I'll try rebuilding those and see if I get a self-mismatch...
33 2013-02-19 00:52:16 <Luke-Jr> gavinandresen: but your bitcoin-qts did
34 2013-02-19 00:52:35 <Luke-Jr> mine differs still
35 2013-02-19 00:52:37 <gavinandresen> Luke-Jr: oh, Linux?
36 2013-02-19 00:52:47 <gavinandresen> yeah??? I thought you were talking win32.
37 2013-02-19 00:52:47 <Luke-Jr> Win32
38 2013-02-19 00:53:12 <gavinandresen> no, our win32 bitcoin-qt.exe's didn't match
39 2013-02-19 00:53:31 <Luke-Jr> O.o
40 2013-02-19 00:53:55 <Luke-Jr> ACTION pokes himself
41 2013-02-19 00:54:20 <gavinandresen> (daemon/bitcoind.exe's did, though, so it's not a problem with building leveldb any more)
42 2013-02-19 00:55:04 <Luke-Jr> ok, nevermind, I guess I was just epic failing or somethign
43 2013-02-19 00:55:36 <Luke-Jr> not quite sure how I messed up that diff
44 2013-02-19 00:56:21 <Luke-Jr> anyhow, if we ignore the -qt mismatch, we have 3 Win32 builds now
45 2013-02-19 00:57:15 <gmaxwell> jgarzik: Ah. Bitcoin development visualized: http://i.imgur.com/cD8Y7fh.gif
46 2013-02-19 01:01:07 <gavinandresen> gmaxwell: that's exactly right!
47 2013-02-19 01:01:58 <gmaxwell> (The reddit thread where I found that also linked to http://www.youtube.com/watch?v=5WLwRg3erm4 ??? in that one the people rotate the front and rear tires while driving)
48 2013-02-19 01:02:35 <jgarzik> gmaxwell: rofl
49 2013-02-19 01:07:19 <micah> what is the default rpcuser? ie. if I set rpcpassword but no user
50 2013-02-19 01:08:25 <gavinandresen> micah: empty string I think. But why wouldn't you set rpcuser?
51 2013-02-19 01:10:58 <micah> gavinandresen: was just wondering because I'm trying to debug why someone's bitcoind isn't responding
52 2013-02-19 01:11:03 <micah> and they had a passwd, but not a user
53 2013-02-19 01:11:18 <micah> i'm guessing it isn't responding because they haven't finished downloading the block chain
54 2013-02-19 01:12:40 <Luke-Jr> gavinandresen: why bother setting rpcuser? :P
55 2013-02-19 01:16:36 <gmaxwell> micah: it should respond while downloading the blockchain.
56 2013-02-19 01:17:21 <micah> gmaxwell: that is what I thought too... but it isn't listening on 8332
57 2013-02-19 01:17:42 <gmaxwell> if its not listening then its disabled.
58 2013-02-19 01:18:55 <micah> gmaxwell: this is the first time he ran bitcoin, and he's been downloading the blockchain for hours, so I've been trying to debug where it is at with him, but can't seem to query it
59 2013-02-19 01:25:19 <Luke-Jr> micah: Bitcoin-Qt is not a JSON-RPC server by default, you need -server
60 2013-02-19 01:25:38 <micah> Luke-Jr: it is just the regular bitcoind
61 2013-02-19 01:26:02 <Luke-Jr> O.o
62 2013-02-19 01:26:09 <micah> at least I think so
63 2013-02-19 01:26:14 <micah> he did start with bitcoin-qt
64 2013-02-19 01:26:16 <Luke-Jr> micah: AFAIK, it won't even start unless it succeeds in listening
65 2013-02-19 01:26:35 <micah> Luke-Jr: you are a genious, he is still running -qt
66 2013-02-19 01:27:09 <Luke-Jr> only reason I thought of it was gmaxwell's comment :p
67 2013-02-19 01:33:43 <SomeoneWeird> ;p;
68 2013-02-19 01:34:51 <gmaxwell> ah, I thought of that but then checked and saw "why someone's bitcoind" and didn't mention it. :)
69 2013-02-19 01:36:13 <gavinandresen> mmm??? unzipped my old and new qt-win32-4.8.3-gitian-r1.zip's and every file inside matches (but the .zip files themselves have different shasums, so must contain a different date or something)
70 2013-02-19 01:36:25 <Luke-Jr> ACTION facepalms
71 2013-02-19 01:36:32 <Luke-Jr> that should be easy to fix
72 2013-02-19 01:36:50 <Luke-Jr> gavinandresen: do the timestamps on the content files match?
73 2013-02-19 01:37:30 <gavinandresen> Luke-Jr: probably not, but I'm switching to looking at boost since timestamps on files shouldn't make bitcoin-qt.exe's mismatch
74 2013-02-19 01:37:41 <Luke-Jr> true
75 2013-02-19 01:38:18 <gavinandresen> it would be nice to make the gitian-zip's checksums match???.
76 2013-02-19 01:46:16 <gavinandresen> bah, every file in the old and new boost-win32-1.50.0-gitian2.zip match exactly, too. I give up for tonight.
77 2013-02-19 01:54:21 <SomeoneWeird> gavin really needs a bounce
78 2013-02-19 01:54:23 <SomeoneWeird> lol
79 2013-02-19 02:15:18 <micah> what is it that makes the blockchain download eat so much resources?
80 2013-02-19 02:15:45 <micah> i mean even with nice -n 19 ionice -c 3 it still causes a relatively powerful machine to choke
81 2013-02-19 02:16:29 <micah> it's writing like crazy to the DB files, but also asserting a lot of cache space in the ram, it's probably mmaping whole .dat files
82 2013-02-19 02:19:28 <doublec> it fsyncs a bit I think which causes other apps on my machine to freeze periodically
83 2013-02-19 02:20:53 <gmaxwell> micah: what version of bitcoin are you talking about?
84 2013-02-19 02:21:38 <micah> gmaxwell: 0.7.2-3 (non-qt version now)
85 2013-02-19 02:21:44 <gmaxwell> If you mean <0.8 it's because of synchronous writes. If you're talking about 0.8 then I don't know what you're expirencing.
86 2013-02-19 02:22:11 <micah> ah so 0.8 has async writes?
87 2013-02-19 02:22:22 <gmaxwell> 0.8 has a lot of things.
88 2013-02-19 02:22:33 <micah> \\o/
89 2013-02-19 02:24:18 <gmaxwell> petertodd: don't waste too much time on 2112.
90 2013-02-19 02:24:44 <micah> looks like 20% read, 20% write, 15% munmap, 12% open, 7% close
91 2013-02-19 02:24:56 <micah> based on strace -c
92 2013-02-19 02:24:59 <micah> http://paste.debian.net/235446/
93 2013-02-19 02:32:47 <muhoo> micah: try running 0.8
94 2013-02-19 02:33:36 <Diablo-D3> heh I spy a micah
95 2013-02-19 02:37:51 <micah> ACTION raises eyebrows at Diablo-D3
96 2013-02-19 02:38:07 <Diablo-D3> fine, a hacim.
97 2013-02-19 02:38:44 <micah> :D
98 2013-02-19 02:38:58 <micah> been a while since I've been hanging around on the bitcoin irc channels
99 2013-02-19 02:39:11 <Diablo-D3> it hasnt changed
100 2013-02-19 02:39:52 <micah> Diablo-D3: still making your miner?
101 2013-02-19 02:40:02 <Diablo-D3> off and on
102 2013-02-19 02:40:13 <Diablo-D3> Im seriously thinking of throwing the entire codebase out and just rewriting it in C
103 2013-02-19 02:40:21 <Diablo-D3> hate java so much
104 2013-02-19 02:40:29 <Luke-Jr> Diablo-D3: ever consider contributing to BFGMiner? <.<
105 2013-02-19 02:40:45 <micah> java needs to die :)
106 2013-02-19 02:40:58 <doublec> Luke-Jr: what does the "bfg" in bfgminer stand for?
107 2013-02-19 02:41:14 <Luke-Jr> doublec: St. Barbara's FPGA/GPU (Miner)
108 2013-02-19 02:41:30 <doublec> ah ok, thanks
109 2013-02-19 02:41:32 <Diablo-D3> Luke-Jr: no
110 2013-02-19 02:41:41 <Diablo-D3> Luke-Jr: and I'd contribute to cgminer not your trollfork
111 2013-02-19 02:41:55 <Luke-Jr> Diablo-D3: I agree you'd fit in better with that group, but just thought I'd ask.
112 2013-02-19 02:42:02 <Diablo-D3> cgminer inherited all the design flaws in diablominer
113 2013-02-19 02:42:07 <Diablo-D3> and you inherited those flaws in turn
114 2013-02-19 02:42:19 <Luke-Jr> indeed, I've been rewriting a lot of code to overcome them
115 2013-02-19 02:42:30 <Diablo-D3> you'd need to get rid of threads.
116 2013-02-19 02:42:35 <Diablo-D3> and that code just cant handle it
117 2013-02-19 02:42:36 <Luke-Jr> Diablo-D3: already did that, mostly.
118 2013-02-19 02:42:56 <Luke-Jr> it still uses threads, but once it starts it's done spawning new ones
119 2013-02-19 02:43:04 <Diablo-D3> yeah, if I redo my code
120 2013-02-19 02:43:07 <Diablo-D3> no threads
121 2013-02-19 02:43:16 <Diablo-D3> its all balls to the wall async networking
122 2013-02-19 02:43:25 <Luke-Jr> doublec: St. Barbara because patron of miners
123 2013-02-19 02:43:36 <Luke-Jr> Diablo-D3: good luck doing that with libusb
124 2013-02-19 02:43:37 <doublec> Luke-Jr: makes sense :)
125 2013-02-19 02:43:46 <Diablo-D3> Luke-Jr: well, remember
126 2013-02-19 02:43:49 <Diablo-D3> I dont support usb yet
127 2013-02-19 02:44:05 <Diablo-D3> I'd probably spawn seperate processes to baby sit devices though
128 2013-02-19 02:44:13 <Diablo-D3> and async communicate with them via pipe or some shit
129 2013-02-19 02:44:21 <Luke-Jr> Diablo-D3: that sounds like a viable model
130 2013-02-19 02:44:42 <Diablo-D3> what keeps making miners fall over is the single process multi thread model
131 2013-02-19 02:44:55 <Diablo-D3> multiple processes, as skinny as possible, should keep the box up even if devices die
132 2013-02-19 02:52:21 <micah> bfg doesn't = big fucking gun? :)
133 2013-02-19 02:52:28 <Diablo-D3> yes
134 2013-02-19 02:53:44 <Luke-Jr> micah: no :p
135 2013-02-19 02:54:35 <micah> Doom reference...
136 2013-02-19 03:33:08 <petertodd> gmaxwell: I think I just learned my lesson that 2112 is crazy...
137 2013-02-19 03:33:32 <Diablo-D3> petertodd: seriously?
138 2013-02-19 03:33:51 <Diablo-D3> petertodd: what was the final nail in the coffin for you?
139 2013-02-19 03:33:51 <Luke-Jr> lol
140 2013-02-19 03:35:22 <petertodd> I think the final nail was actually having like, one discussion with him... I don't follow the forums that closely...
141 2013-02-19 03:35:36 <Diablo-D3> lol
142 2013-02-19 03:35:55 <Diablo-D3> man, why does backing up 2TB take so loooooooooong
143 2013-02-19 03:36:24 <petertodd> Diabolo-D3: Probably because the fact that you can even store 2TB is proof we live in the fucking future.
144 2013-02-19 03:37:04 <Diablo-D3> I am not a Diabolo, I am a Diablo
145 2013-02-19 03:37:17 <Diablo-D3> wait, if thats the fucking future then
146 2013-02-19 03:37:47 <Diablo-D3> I have 2x400gb raid 1, 4x750gb raid 5 (= 2.1TB), one of those 750s is really a 2TB, and my external drive is 2TB, and another 2TB is coming in the mail
147 2013-02-19 03:37:54 <Diablo-D3> Im so far in the future I think I must be in Japan
148 2013-02-19 03:38:34 <petertodd> I have a theory that Satoshi was actually from Alabama, but figured if he admitted it no-one would believe him.
149 2013-02-19 03:39:08 <Diablo-D3> I wouldnt have
150 2013-02-19 03:39:24 <Diablo-D3> unless it was like, alabama quebec or something strange
151 2013-02-19 03:40:06 <petertodd> Yeah, I can imagine a revolutionary crypto-currency coming out of Quebec; French people are crazy.
152 2013-02-19 03:40:41 <Diablo-D3> they're not even real french people
153 2013-02-19 03:40:53 <Diablo-D3> france wont even accept them in as fellow fracophones
154 2013-02-19 03:41:17 <petertodd> Pff, what do you mean? It's those weirdo's in Paris that aren't real French people.
155 2013-02-19 03:41:35 <Diablo-D3> >french people
156 2013-02-19 03:41:37 <Diablo-D3> >in france
157 2013-02-19 03:41:40 <Diablo-D3> >not real french people
158 2013-02-19 03:41:45 <Diablo-D3> HAIL HITLER!
159 2013-02-19 03:42:53 <petertodd> ACTION is still bitter that France didn't do more than put up a struggle against overwhelming odds followed by years of underground resistance.
160 2013-02-19 03:43:55 <Luke-Jr> [04:36:56] <Diablo-D3> I am not a Diabolo, I am a Diablo <-- lol, ouch
161 2013-02-19 03:45:10 <Diablo-D3> petertodd: yes, well, I dont blame them for not fighting the whole "french fries are not from france" thing
162 2013-02-19 03:45:17 <Diablo-D3> they're delicious
163 2013-02-19 03:47:49 <petertodd> Ha, and poutine just gilds the lily, with a think layer of delicious and delicious.
164 2013-02-19 03:48:18 <Diablo-D3> petertodd: canada is going to hell for poutine
165 2013-02-19 03:48:45 <Diablo-D3> it looks disgusting, it sounds disgusting, I bet it even smells disgusting
166 2013-02-19 03:49:33 <gjs278> turn on directio then you won't have to waste time polluting the page cache and flushing
167 2013-02-19 03:49:41 <petertodd> Yes, but in our cold weather you can't smell it anyway.
168 2013-02-19 03:50:15 <Diablo-D3> petertodd: see
169 2013-02-19 03:50:21 <Diablo-D3> I have this special recipe for sauce
170 2013-02-19 03:50:37 <Diablo-D3> 1/4 thick bbq sauce, 1/4 thick steak sauce, 1/4 horseraddish mustard, 1/4 worshishire sauce
171 2013-02-19 03:50:47 <Diablo-D3> THICK worshishishsursheisre sauce
172 2013-02-19 03:50:58 <Diablo-D3> its perfect for burgers and fries
173 2013-02-19 03:51:11 <petertodd> You've invented a monster.
174 2013-02-19 03:51:26 <Diablo-D3> oh god its so delicious
175 2013-02-19 03:51:36 <Diablo-D3> you gotta be careful with the bbq sauce and steak sauce though
176 2013-02-19 03:51:43 <Diablo-D3> you want it more tangy than sweet
177 2013-02-19 03:51:44 <petertodd> Worcestershire sauce by itself is madness enough.
178 2013-02-19 03:53:49 <petertodd> ...you considered trying some vegimite in that mix?
179 2013-02-19 04:04:22 <Diablo-D3> not my kind of thing
180 2013-02-19 04:30:35 <micah> mmmm poutine
181 2013-02-19 04:37:47 <micah> hmm, 0.8 has a tag, but no release yet
182 2013-02-19 04:37:48 <TradeFortress> Can't compile bitcoind, internal compiler error: Kille (program cc1plus)
183 2013-02-19 04:37:55 <TradeFortress> make: *** [obj/main.o] Error 4
184 2013-02-19 04:38:18 <TradeFortress> is the master branch working?
185 2013-02-19 04:39:52 <SomeoneWeird> try a tag
186 2013-02-19 04:48:46 <gmaxwell> TradeFortress: thats your compiler crashing??? has nothing to do with bitcoin.
187 2013-02-19 04:48:56 <gmaxwell> Let me guess, you're trying to compile bitcoin on a small VPS?
188 2013-02-19 04:49:05 <gmaxwell> (say, something with 512mb ram and no swap?)
189 2013-02-19 04:49:23 <TradeFortress> gmaxwell, yeah amazon EC2 micro lol
190 2013-02-19 04:49:51 <gmaxwell> Yea, compile it on something with more ram and move the binary over. C++ compiling is very memory hungry.
191 2013-02-19 04:49:55 <gmaxwell> Or setup swap.
192 2013-02-19 04:49:58 <petertodd> TradeFortress: the easiest thing to do is temporarily upgrade the VPS to a faster one, compile, and then downgrade.
193 2013-02-19 04:50:13 <TradeFortress> Got it, thanks
194 2013-02-19 04:51:52 <phantomcircuit> TradeFortress, you're not going to be able to run a bitcoind node on a micro
195 2013-02-19 04:52:04 <phantomcircuit> you need at least 512 mb of ram for the initial blockchain sync
196 2013-02-19 04:52:36 <petertodd> phantomcircuit: Actually it's quite possible to do so once you sync. The trick is to turn the # of connections down with the -maxconnections setting.
197 2013-02-19 04:52:41 <TradeFortress> phantomcircuit, thanks, I'll bump it up
198 2013-02-19 04:52:45 <TradeFortress> :)
199 2013-02-19 04:52:53 <petertodd> I have a 0.7 node running on a micro node right now with no problems.
200 2013-02-19 04:55:56 <gmaxwell> phantomcircuit: you should be able to without issue, you may need to reduce connections and adjust dbcache for maxium goodness but it should be okay now.
201 2013-02-19 04:56:38 <phantomcircuit> at the very least you're going to be hitting swap without 512 mb of free ram
202 2013-02-19 04:56:49 <phantomcircuit> which will significantly delay sync
203 2013-02-19 04:57:17 <phantomcircuit> personally i download the blockchain on my workstation on a tmpfs and copy it to low memory environemnts
204 2013-02-19 05:04:04 <gmaxwell> phantomcircuit: one connection node here on x86_64 is using 160mb here.
205 2013-02-19 05:05:14 <phantomcircuit> gmaxwell, it's fully synced though right?
206 2013-02-19 05:05:31 <phantomcircuit> during initial sync memory usuage is swollen\\
207 2013-02-19 05:05:46 <Luke-Jr> phantomcircuit: not if you tweak -dbcache
208 2013-02-19 05:07:36 <gmaxwell> phantomcircuit: it shouldnt be if you tweak dbcache, and if it is we ought to figure out why and fix it.
209 2013-02-19 05:07:45 <phantomcircuit> maybe but either way you're going to slow things down
210 2013-02-19 05:08:18 <gmaxwell> Luke-Jr: do you have any 0.8 nodes running on x86? How much VM are they using?
211 2013-02-19 05:08:35 <phantomcircuit> oh and uh if you notice a lot of connections from an ovh ip
212 2013-02-19 05:08:37 <phantomcircuit> just ignore it
213 2013-02-19 05:08:44 <phantomcircuit> i promise not to break anythign
214 2013-02-19 05:09:18 <SomeoneWeird> lols
215 2013-02-19 05:10:54 <Luke-Jr> gmaxwell: ps reports SIZE=1,325,532
216 2013-02-19 05:11:07 <Luke-Jr> whether that's GB or MB I have nfc
217 2013-02-19 05:11:22 <Luke-Jr> for comparison, bash is 428 and grep is 244
218 2013-02-19 05:11:35 <muhoo> kb
219 2013-02-19 05:17:02 <Diablo-D3> gmaxwell: why do you care how much vm they are using?
220 2013-02-19 05:17:12 <Diablo-D3> vm has no bearing on how much an app uses
221 2013-02-19 05:17:19 <Diablo-D3> only res/rss does
222 2013-02-19 05:18:03 <petertodd> Diablo-D3: gmaxwell is talking about x86-32, where the 4GiB limit could be a problem
223 2013-02-19 05:18:28 <Diablo-D3> 4gb? no, 2.
224 2013-02-19 05:18:38 <petertodd> oh, yes, good point
225 2013-02-19 05:18:43 <petertodd> (stupid kernel)
226 2013-02-19 05:18:47 <Diablo-D3> and it doesnt matter how much you mmap
227 2013-02-19 05:19:01 <petertodd> why not?
228 2013-02-19 05:19:32 <Diablo-D3> as far as I can tell you CAN mmap an anonymous map >2gb on 32 bit and it still works
229 2013-02-19 05:19:35 <Diablo-D3> just dont try to use more than that
230 2013-02-19 05:19:48 <Diablo-D3> (that said, I have a slab allocator impl, it just mmaps 2gb and thats it)
231 2013-02-19 05:20:05 <petertodd> yeah, the limit isn't really 2GiB, the kernel uses less than that
232 2013-02-19 05:20:20 <Diablo-D3> 2gb is easy though
233 2013-02-19 05:20:21 <petertodd> but there still is a limit - mmapping all the block data won't work for instance
234 2013-02-19 05:20:23 <Diablo-D3> its 2**31
235 2013-02-19 05:20:31 <Diablo-D3> petertodd: aaacttuallly
236 2013-02-19 05:20:33 <Diablo-D3> it will
237 2013-02-19 05:20:35 <Diablo-D3> its on disk
238 2013-02-19 05:21:00 <petertodd> That has nothing to do with it. mmap uses VM space, and you only have 4GiB - kernel memory to play with on x32
239 2013-02-19 05:21:07 <Diablo-D3> thats not what I mean
240 2013-02-19 05:21:12 <petertodd> (per process)
241 2013-02-19 05:21:19 <Diablo-D3> you can use fseek64 somewhere in there
242 2013-02-19 05:21:39 <petertodd> Sure, but then you aren't mmapping the whole file.
243 2013-02-19 05:21:40 <Diablo-D3> its been awhile since I had to do that, so I forget exactly what needs to be done
244 2013-02-19 05:21:44 <Diablo-D3> no, you're not
245 2013-02-19 05:21:59 <Diablo-D3> but you can still mmap it =P
246 2013-02-19 05:22:16 <petertodd> (there are some x32 extensions that do paging, but IIRC they aren't very well supported in userspace)
247 2013-02-19 05:22:41 <Diablo-D3> yeah I wonder why you cant somehow use pae to solve this
248 2013-02-19 05:22:42 <petertodd> ACTION goes of an mmaps a file, one page at a time.
249 2013-02-19 05:23:14 <coingenuity> detected spam
250 2013-02-19 05:23:17 <coingenuity> detected spam
251 2013-02-19 05:23:17 <petertodd> The kernel uses pae, but you'd need a lot of code to enable userspace pae. Dunno that code has been written yet.
252 2013-02-19 05:23:38 <Diablo-D3> easier to just use 64bit really
253 2013-02-19 05:23:44 <petertodd> Yup.
254 2013-02-19 05:23:58 <petertodd> Even $100 computers support 64bit these days.
255 2013-02-19 05:26:29 <gmaxwell> In any case, thats bad.
256 2013-02-19 05:26:38 <gmaxwell> Anyone know if the fragmentation is that bad on windows?
257 2013-02-19 05:26:45 <Diablo-D3> gmaxwell: yes
258 2013-02-19 05:26:47 <Diablo-D3> even in 8
259 2013-02-19 05:26:51 <gmaxwell> You can clear it up on linux by LD_PRELOADing TC malloc.
260 2013-02-19 05:27:11 <gmaxwell> (or jemalloc for that matter)
261 2013-02-19 05:27:31 <Diablo-D3> this is why I like my slab alloc
262 2013-02-19 05:27:35 <Diablo-D3> it doesnt fragment system memory
263 2013-02-19 05:27:57 <gmaxwell> Thats basically what jemalloc is (and I assume tcmalloc, though I'd not looked inside it much)
264 2013-02-19 05:28:13 <Diablo-D3> yeah, Ive seen the internals of jemalloc
265 2013-02-19 05:28:20 <Diablo-D3> problem is, it adds all this crap on top
266 2013-02-19 05:28:26 <Diablo-D3> like thread safety
267 2013-02-19 05:28:47 <gmaxwell> I keep expecting that getting rid of the insane little short lived heap allocations would also improve performance, but anywhere I've tried doing that in bitcoin it hasn't seemed to matter much.
268 2013-02-19 05:28:56 <gmaxwell> Diablo-D3: yea, well, we need that. :P
269 2013-02-19 05:29:07 <Diablo-D3> yes, but I dont =P
270 2013-02-19 05:29:14 <Diablo-D3> I have rejected threads.
271 2013-02-19 05:29:33 <Diablo-D3> btw, why the fuck are you allocating heap temporarily?
272 2013-02-19 05:29:37 <Diablo-D3> allocate it on the stack
273 2013-02-19 05:29:37 <petertodd> gmaxwell: I
274 2013-02-19 05:30:07 <petertodd> gmaxwell: I'll bet you the performance problems of insane little short-lived heap allocations are well known, so malloc is designed to support that case efficiently...
275 2013-02-19 05:30:18 <Diablo-D3> petertodd: it does BUT
276 2013-02-19 05:30:22 <Diablo-D3> not calling malloc at all is faster yet
277 2013-02-19 05:30:35 <petertodd> gmaxwell: HLL's use the heap a lot after all; Python for instance, and it uses malloc directly IIRC.
278 2013-02-19 05:30:50 <Diablo-D3> default malloc impls arent too swift though
279 2013-02-19 05:31:08 <Diablo-D3> like, glibc's isnt a slab allocator
280 2013-02-19 05:31:12 <petertodd> Diablo-D3: Sure if you can avoid it, like with stack allocation, but as I say the performance hit might not be as bad as you'd think.
281 2013-02-19 05:31:29 <Diablo-D3> it'll happily split pages into all sorts of strange non-power-of-two sizes
282 2013-02-19 05:31:40 <Diablo-D3> petertodd: Ive done heavy research into this
283 2013-02-19 05:31:53 <Diablo-D3> gcc basically takes malloc calls apart if it can
284 2013-02-19 05:32:04 <petertodd> Diablo-D3: I haven't, so don't take my word for it. :P
285 2013-02-19 05:32:09 <Diablo-D3> when it cant, you're stuck with the horror that is the default malloc
286 2013-02-19 05:32:11 <gmaxwell> petertodd: if it were supporting them efficiently it wouldn't get fragmented all to heck and thus us a _ton_ of VM.
287 2013-02-19 05:32:33 <Diablo-D3> gmaxwell: yeah thats nuts, wtf are you doing
288 2013-02-19 05:33:16 <petertodd> gmaxwell: Right, but that can easily be a micro-optimization vs. macro problem. IE, taking some out doesn't change things much, because the per-allocation cost isn't high. But anyway, it's not like I've researched this much myself.
289 2013-02-19 05:33:32 <gmaxwell> Diablo-D3: unless there is some mystery cause I think it's just the zillion and one short lived C++ container objects. Tc/je eliminate most of the bloat.
290 2013-02-19 05:33:48 <Diablo-D3> meh
291 2013-02-19 05:33:52 <Diablo-D3> this is why I dont use c++
292 2013-02-19 05:34:01 <Diablo-D3> c++ has no concept of stack allocation
293 2013-02-19 05:34:02 <gmaxwell> petertodd: well, you're obviously objectively right. Because none of it seems to matter much...
294 2013-02-19 05:34:11 <Diablo-D3> well, c++ programmers dont, anyways
295 2013-02-19 05:34:38 <petertodd> gmaxwell: Lol, technically correct, the best kind... gah.
296 2013-02-19 05:35:12 <Diablo-D3> btw, best part about my slab alloc? it keeps split pages around for reuse, an the linked list of those is insert at head instead of tail
297 2013-02-19 05:35:25 <Diablo-D3> ergo, the page could still be in cpu cache so lets reuse it
298 2013-02-19 05:36:40 <Diablo-D3> (this is why I hate designs that zero out pages at free instead of malloc, it fails to trigger useful cache behavior)
299 2013-02-19 05:38:15 <Diablo-D3> btw, unrelated but
300 2013-02-19 05:38:43 <Diablo-D3> gcc refuses to line vaargs functions, even if its in the same unit and the args are known at compile time
301 2013-02-19 05:40:05 <Diablo-D3> *inline
302 2013-02-19 05:40:23 <Diablo-D3> __attribute__((always_inline)), it does nothing!
303 2013-02-19 05:41:29 <Diablo-D3> the best part is
304 2013-02-19 05:41:40 <Diablo-D3> gcc'll inline printf magic.
305 2013-02-19 05:43:05 <Diablo-D3> it wont inline a vaargs function that just calls vprintf eventually
306 2013-02-19 05:48:10 <petertodd> Special-cased optimization is an ugly beast...
307 2013-02-19 05:50:37 <Diablo-D3> well
308 2013-02-19 05:50:46 <Diablo-D3> even if I apply the printf attribute to it
309 2013-02-19 05:50:47 <Diablo-D3> it wont do it
310 2013-02-19 05:52:01 <petertodd> Weird. Read the GCC source?
311 2013-02-19 05:52:08 <Diablo-D3> hell no
312 2013-02-19 05:52:21 <petertodd> You sound scarred.
313 2013-02-19 05:52:27 <Diablo-D3> what little sanity I have left I wish to hold onto
314 2013-02-19 05:53:12 <Diablo-D3> anyhow, going to bed
315 2013-02-19 05:53:16 <petertodd> night
316 2013-02-19 05:53:20 <Diablo-D3> hopefully this backup will be done when I wake up
317 2013-02-19 05:54:13 <petertodd> heh, mine too, I've got like a million itty-bitty files and it's taking for ever...
318 2013-02-19 05:54:51 <petertodd> a few dozen ops/second isn't cutting it, need more flash storage
319 2013-02-19 08:13:02 <gribble> The operation succeeded.
320 2013-02-19 08:13:02 <sipa> ;;later tell gavinandresen full match on 0.8.0; sigs pushed
321 2013-02-19 08:14:01 <jouke> :)
322 2013-02-19 08:16:19 <SomeoneWeird> woo
323 2013-02-19 08:16:21 <SomeoneWeird> lol
324 2013-02-19 08:44:41 <jouke> When bitcoind receives a doublespend transaction it will say it is not valid, but will I be able to get the transaction details of the not-valid transaction?
325 2013-02-19 08:45:39 <sipa> no, it's simply ignored
326 2013-02-19 08:45:44 <sipa> and not relayed
327 2013-02-19 08:45:54 <sipa> so chances are high you won't ever see it
328 2013-02-19 08:46:09 <jouke> Ok, thanks! :)
329 2013-02-19 08:48:24 <jouke> not-valid >_<
330 2013-02-19 08:48:48 <sipa> ?
331 2013-02-19 08:49:15 <jouke> invalid
332 2013-02-19 09:06:51 <epscy> sipa: what if the first tx has no fee and the second one does
333 2013-02-19 09:13:34 <sipa> epscy: even then
334 2013-02-19 09:13:47 <sipa> epscy: doing it otherwise would make double spend attacks ridiculously more easy
335 2013-02-19 09:14:03 <epscy> right
336 2013-02-19 09:19:53 <gmaxwell> Miners may eventually change their behavior there??? unlike some other things where the defaults being altrustic are effective, that one is pretty fragle. Even a few miners doing that is almost as bad as all miners doing it.
337 2013-02-19 09:22:37 <petertodd> epscy: Probably the biggest reason miners don't is because they would have to write code to enable the double spends, yet there is no guarantee of a market to make the effort worthwhile.
338 2013-02-19 09:23:10 <petertodd> You also need to make some nodes known so people know where to send the double-spending transactions; they won't get relayed by the normal codebase.
339 2013-02-19 09:23:32 <jouke> Hmmm, you should be able to exclude nodes.
340 2013-02-19 09:23:59 <jouke> hmm, I am not sure what that solves.
341 2013-02-19 09:24:14 <petertodd> I suspect if anyone actually did this they'd have to setup a tor site explaining it all, and then have access to a decent-sized pile of mining capacity to make it worthwhile. A pool isn't good, because miners would likely jump to other pools after hearing about the dishonesty.
342 2013-02-19 09:24:39 <petertodd> Someone with some ASICs could, but why bother, they'd be making a huge amount just mining with them as is, so why risk it?
343 2013-02-19 09:25:00 <petertodd> *by some, a lot of ASCIs...
344 2013-02-19 09:25:03 <gmaxwell> petertodd: nah, most evil is boring. "Uberpool GETS YOU THE MOSTEST INCOME BY MINING THE TRANSACTIONS WITH THE HIGEST FEES! MINE HERE NOW! PROFIT PROFIT PROFIT!"
345 2013-02-19 09:25:25 <petertodd> gmaxwell: I suggest you start uberpool then. :)
346 2013-02-19 09:25:44 <gmaxwell> Alas, I'm not coin operated.
347 2013-02-19 09:25:47 <petertodd> (of course, the Pirate did exactly that, but I haven't seen any evidence he used it to do double-spends)
348 2013-02-19 09:26:09 <petertodd> ACTION thinks gmaxwell is an economically irrational actor.
349 2013-02-19 09:26:24 <gmaxwell> I am an economically irrational actor, in fact.
350 2013-02-19 09:26:32 <petertodd> Me too. :P
351 2013-02-19 09:29:17 <sipa> an economically rational actor can always be brided (for the right amount), no?
352 2013-02-19 09:30:00 <petertodd> Well, lets test your theory and ask jgarzik to mine us some satoshidice double-spends
353 2013-02-19 09:31:01 <gmaxwell> You might want to choose a more sympathetic victim there.
354 2013-02-19 09:32:04 <petertodd> Alright, blockchain.info's mixer.
355 2013-02-19 09:32:36 <gmaxwell> well, pirates thing wasn't unique??? see hashpower.
356 2013-02-19 09:33:09 <petertodd> Interesting, never heard of hashpower before.
357 2013-02-19 11:06:11 <neo> Hi There.
358 2013-02-19 11:06:46 <Guest55601> Anyone have any idea how can we min bitcoin on a linux web server?
359 2013-02-19 11:07:49 <SomeoneWeird> you can't
360 2013-02-19 11:08:04 <Guest55601> thanks
361 2013-02-19 11:08:14 <Guest55601> So if possible on any webserver?
362 2013-02-19 11:08:19 <SomeoneWeird> nope
363 2013-02-19 11:08:59 <Guest55601> I am trying to use proxy with GUI miner and Slush's pool
364 2013-02-19 11:09:12 <SomeoneWeird> what are you mining on?
365 2013-02-19 11:09:35 <Guest55601> Not sure what it.
366 2013-02-19 11:09:42 <Guest55601> Sorry very new to the thing
367 2013-02-19 11:10:32 <Guest55601> Not sure where to change the link of proxy in the GUIminer
368 2013-02-19 11:12:03 <Guest55601> I am talking abut this http://mining.bitcoin.cz/mining-proxy-howto
369 2013-02-19 11:19:48 <SomeoneWeird> what graphics card do you have?
370 2013-02-19 11:19:56 <SomeoneWeird> (on the computer you're trying to run guiminer on)
371 2013-02-19 11:31:04 <t7> Guest26812, how many rooted servers do you have? if it like 1000 it might be worth it
372 2013-02-19 11:33:05 <Luke-Jr> ACTION wonders how long until t7 gets banned
373 2013-02-19 11:33:40 <Luke-Jr> Guest26812: off-topic here, #bitcoin-mining ; do answer quickly, mining requires custom hardware now (ASICs) and mere computers or graphics cards aren't very useful
374 2013-02-19 11:34:09 <Hasimir> you have the wrong guest
375 2013-02-19 11:34:13 <Hasimir> I'm not a miner
376 2013-02-19 11:34:36 <Hasimir> you were after this one: [23:16:18] * Guest55601 has quit (Ping timeout: 245 seconds)
377 2013-02-19 11:36:38 <SomeoneWeird> t7, wow, really.
378 2013-02-19 11:36:52 <t7> wut?
379 2013-02-19 11:37:09 <t7> bitcoin cant buy you a sense of humour?
380 2013-02-19 11:37:52 <SomeoneWeird> >.<
381 2013-02-19 12:12:48 <Tritonio> Does anyone know if I can get the weighted average BTC/USD as displayed on MT Gox's top bar using some API? API v0 and v1 return a different average and v3 needs authentication which needs a verified account AFAIK and I don't intend to make one...
382 2013-02-19 15:14:21 <alexwaters> does bluematt's jenkins run builds from each pull-request anymore? I only see one job in the dashboard
383 2013-02-19 15:14:45 <sipa> alexwaters: iirc, the pullrequest builds are not done by jenkins
384 2013-02-19 15:14:54 <alexwaters> hmm
385 2013-02-19 15:15:41 <alexwaters> it looks like he has a lighttpd server serving a list of them, but I don't know how they're generated
386 2013-02-19 15:16:28 <sipa> some script that loops over requests
387 2013-02-19 15:16:40 <sipa> and tries building those that are modified
388 2013-02-19 15:18:54 <alexwaters> i only ask because i'm working on something that will use them. and I would like to know which pull they reference, and if any tests are run (like check if rebased)
389 2013-02-19 15:26:23 <gavinandresen> alexwaters: pull-tester stuff is at https://github.com/TheBlueMatt/test-scripts/
390 2013-02-19 15:27:52 <gavinandresen> alexwaters: ??? except for the github integration code, which contains the pulltester's authentication tokens so can't be open source
391 2013-02-19 15:30:21 <alexwaters> gavinandresen: awesome, thank you
392 2013-02-19 15:33:40 <TD> good morning
393 2013-02-19 15:35:17 <gavinandresen> good morning TD.
394 2013-02-19 15:39:37 <gavinandresen> sipa: do you still have the build inputs you used to create your first 0.8.0 build? My builds are stubbornly 100% reproducible this morning.
395 2013-02-19 15:41:33 <sipa> gavinandresen: no
396 2013-02-19 15:42:16 <sipa> gavinandresen: changing my boost build to yours didn't change my resulting binary though
397 2013-02-19 15:42:19 <sipa> only qt did
398 2013-02-19 15:42:33 <gavinandresen> good to know
399 2013-02-19 15:42:51 <TD> BlueMatt: i think there may have been an issue with the formula used to calculate nHashFuncs in bitcoinj. there was a missing (double) cast on the right hand side of the division. i think it means the result may have been incorrectly rounded at that point. FindBugs found it.
400 2013-02-19 15:44:34 <sipa> gavinandresen: i vaguely remember being lazy at some point and doing a copy between two gitian inputs at some point - may have been from 4.8.2 to 4.8.3
401 2013-02-19 15:44:54 <sipa> perhaps i should try doing a qt build myself, and redoing the 0.8.0 at some point
402 2013-02-19 15:45:28 <gavinandresen> sipa: that'd be helpful. I get different checksums for the .zips, but identical files in the .zips and identical bitcon-qt.exe's
403 2013-02-19 15:46:22 <gavinandresen> (TODO: figure out why the zips have different checksums and fix that part of the gitian build??? probably just changing file timestamps before zipping everything up)
404 2013-02-19 15:46:58 <gavinandresen> Right now, I'm going to codesign the windows setup and OSX .app, then upload binaries to sourceforge.
405 2013-02-19 15:47:03 <ThomasV> gavinandresen: "a hacked Electrum download server could feed you an evil executable" <-- same for other clients :)
406 2013-02-19 15:48:33 <gavinandresen> TD: RE: code signing: codesigning the executable inside the -setup.exe or the .App : pro would be slightly happier anti-virus detectors. con would be a checksum mismatch against the gitian-built binaries. I think the con outweighs the pro, because the gitian checksum is a second line of defense....
407 2013-02-19 15:48:54 <gavinandresen> ThomasV: true, excellent point
408 2013-02-19 15:49:59 <ThomasV> lol
409 2013-02-19 15:50:44 <Luke-Jr> second? first IMO
410 2013-02-19 15:51:04 <gavinandresen> ThomasV: ??? although code-signing does help protect against Evil Binaries.
411 2013-02-19 15:51:24 <sipa> in theory, gitian is a much nicer mechanism
412 2013-02-19 15:51:37 <sipa> in practice, much more people will be doing validations based on code signing
413 2013-02-19 15:52:25 <sipa> gavinandresen: one comment about release notes: due to the reduced working set, you need less memory for the same performance, but it's not actually true that 0.8 uses less memory than 0.7
414 2013-02-19 15:52:31 <sipa> by default
415 2013-02-19 15:52:36 <ThomasV> gavinandresen: binaries are signed by their creators (slush and animazing). slush is also working on a deterministic compilation method, so that his binaries can be checked by other people
416 2013-02-19 15:53:36 <gavinandresen> ThomasV: signed??? how? Y'all have an X.509 code-signing cert, or you gpg-signing? As sipa says, most users will just click-and-download and rely on their OS to keep them safe.
417 2013-02-19 15:54:06 <ThomasV> right, for the moment we only gpg sign
418 2013-02-19 15:55:45 <ThomasV> omg price is > 29
419 2013-02-19 15:55:47 <gavinandresen> With OSX's GateKeeper and Windows AuthentiTrustedCode (or whatever they call it) it's getting really important to get an Official Code Signing Key???.
420 2013-02-19 15:56:18 <sipa> gavinandresen: you don't have one?
421 2013-02-19 15:56:25 <gavinandresen> don't have one what?
422 2013-02-19 15:56:27 <ThomasV> gavinandresen: yes. we have funds to buy one
423 2013-02-19 15:56:38 <sipa> oh, you're talking about electrum
424 2013-02-19 15:56:47 <TD> gavinandresen: hum. i thought the gitian toolchain would erase the signature field before checking?
425 2013-02-19 15:56:56 <TD> seems like a simple fix
426 2013-02-19 15:57:18 <TD> sipa: well, the next step after gitian is to split the code signing keys
427 2013-02-19 15:57:33 <gavinandresen> TD: nope. Patches welcome. Erasing a signature inside a binary inside an .
428 2013-02-19 15:57:35 <TD> but that's harder. i've yet to find a threshold RSA implementation. just papers explaining how to do it.
429 2013-02-19 15:57:54 <TD> gavinandresen: you find it and then set those bytes to zero. but yeah walking the headers involves a bit of code. i've done it before.
430 2013-02-19 15:57:55 <gavinandresen> TD: Seems like Verisign was offering that
431 2013-02-19 15:58:04 <TD> oh, they have a commercial implementation?
432 2013-02-19 15:59:05 <gavinandresen> TD: I ran across some marketing-speak at I-think-it-was-Verisign for what looked like split code signing keys
433 2013-02-19 16:00:04 <gavinandresen> TD: ??? although I'm probably mis-remembering and it was split PKI root certificates
434 2013-02-19 16:01:38 <gavinandresen> In any case??? yes, it would be a nifty project for somebody to make it possible for us to code-sign with a certificate based on a (say) 2-of-5 split key.
435 2013-02-19 16:02:19 <TD> hm
436 2013-02-19 16:02:22 <TD> yeah
437 2013-02-19 16:05:03 <Pucilowski> How can I use blockchain.info to give me a transaction in its raw hex form?
438 2013-02-19 16:06:36 <jgarzik> Pucilowski: this isn't really the best forum for website support questions
439 2013-02-19 16:12:59 <TD> http://googleblog.blogspot.ch/2013/02/an-update-on-our-war-against-account.html
440 2013-02-19 16:13:18 <TD> my non-bitcoin work, in a blog post! :)
441 2013-02-19 16:14:52 <gavinandresen> TD: grumble grumble giving me more interesting things to think about when my TODO list is already too long???.
442 2013-02-19 16:15:22 <TD> isn't everyones? :)
443 2013-02-19 16:15:24 <gavinandresen> sipa: tweaked the release notes to say "???uses less working memory and does much less I/O"
444 2013-02-19 16:16:40 <gavinandresen> I also removed the mention of -dbcache from the top of the release notes, so we should see fewer out-of-memory problems.
445 2013-02-19 16:19:31 <sipa> good
446 2013-02-19 16:19:36 <sipa> though it's still mentioned?
447 2013-02-19 16:20:11 <gavinandresen> Yes, under New/changed settings. We could un-document it....
448 2013-02-19 16:20:51 <SomeoneWeird> TD, you work for google?
449 2013-02-19 16:20:56 <sipa> as things are, -dbcache mostly has an effect on IBD time, and not so much on normal performance
450 2013-02-19 16:21:24 <TD> SomeoneWeird: yeah
451 2013-02-19 16:21:33 <SomeoneWeird> sweet
452 2013-02-19 16:25:07 <Luke-Jr> sipa: I'm tempted to reply "MtGox" >_<
453 2013-02-19 16:25:48 <sipa> Luke-Jr: if you're talking about that JSON-RPC issue: he has a point
454 2013-02-19 16:34:20 <phantomcircuit> TD, you wouldn't happen to know the incident rate of people setting up 2 factor auth and then losing their phone/whatever and being screwed would you?
455 2013-02-19 16:35:32 <TD> high
456 2013-02-19 16:35:43 <TD> the actual numbers, i know out of date figures but they're confidential
457 2013-02-19 16:35:44 <phantomcircuit> that's what i figured
458 2013-02-19 16:35:59 <phantomcircuit> users be dumb :/
459 2013-02-19 16:36:23 <phantomcircuit> is there anything people can do when that happens? or are they just screwed
460 2013-02-19 16:36:41 <TD> yes
461 2013-02-19 16:36:44 <TD> there are still ways you can recover
462 2013-02-19 16:36:53 <phantomcircuit> also what the hell i was just directed to google.fr when i clicked sign out
463 2013-02-19 16:37:38 <phantomcircuit> call someone and start crying? :P
464 2013-02-19 16:38:12 <muhoo> call?
465 2013-02-19 16:38:20 <SomeoneWeird> whats call
466 2013-02-19 16:38:25 <SomeoneWeird> is that like hitech irc
467 2013-02-19 16:38:56 <TD> phantomcircuit: sorta. it's complicated. there are lots of rules
468 2013-02-19 16:39:19 <phantomcircuit> i can imagine that would be a complicated procedure and probably something you dont want to tell people
469 2013-02-19 16:39:22 <phantomcircuit> so i'll stop asking
470 2013-02-19 16:39:34 <TD> right. 2SV is a lot more complicated than it looks
471 2013-02-19 16:39:45 <TD> it's not just good guys losing their phones. it's bad guys adding 2SV to keep control of accounts they've hacked
472 2013-02-19 16:40:17 <phantomcircuit> account logout is disconcerting with RequestPolicy all the redirects to signout of youtube
473 2013-02-19 16:40:56 <phantomcircuit> TD, heh i've actually seen 2SV setup so you could add it to anybodies account
474 2013-02-19 16:41:01 <phantomcircuit> oh rails you so silly
475 2013-02-19 16:41:04 <TD> that's single-sign-on for you
476 2013-02-19 16:42:59 <phantomcircuit> btw a suggestion the backup codes you can print dont have the account name on the print out
477 2013-02-19 16:43:27 <gavinandresen> 0.8.0 release signed and uploaded: https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.0/
478 2013-02-19 16:43:30 <TD> ok
479 2013-02-19 16:43:52 <gavinandresen> ACTION notices the OSX binary didn't upload....
480 2013-02-19 16:43:54 <TD> blog post and 0.8.0 out simultaneously, high fives all round
481 2013-02-19 16:45:18 <sipa> \\o/
482 2013-02-19 16:47:02 <muhoo> nice work
483 2013-02-19 16:49:07 <andytoshi> congrats guys
484 2013-02-19 16:53:56 <gavinandresen> Can I get some volunteers to sanity-test the downloads while I eat lunch? Just make sure they actually download and run and say they are "version 0.8.0 beta" (make sure I didn't accidently upload the wrong thing).
485 2013-02-19 16:54:34 <helo> no
486 2013-02-19 16:55:45 <phantomcircuit> helo, play nice or dont play at all
487 2013-02-19 16:56:42 <helo> lol joking...
488 2013-02-19 16:57:50 <helo> linux tarballs look good
489 2013-02-19 17:01:00 <MC1984> link then?
490 2013-02-19 17:01:25 <MC1984> derp i got it
491 2013-02-19 17:01:28 <sipa> 18:43:20 < gavinandresen> 0.8.0 release signed and uploaded: https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.0/
492 2013-02-19 17:01:54 <helo> should i be surprised to see "Error initializing database environment ... <backup instructions>" when starting 0.8.0? git head runs fine
493 2013-02-19 17:03:51 <helo> no i shouldn't... different bdb i'm sure
494 2013-02-19 17:07:00 <sipa> yeah
495 2013-02-19 17:11:50 <coingenuity> spam detected
496 2013-02-19 17:13:25 <sipa> ?
497 2013-02-19 17:13:55 <coingenuity> er, sorry
498 2013-02-19 17:14:00 <coingenuity> thing needs to be turned down even more
499 2013-02-19 17:14:48 <coingenuity> sipa: there's been some bots targeting bitcoin channel users
500 2013-02-19 17:15:15 <coingenuity> generally will spam in-channel, but a few of them are doing a PM-blast
501 2013-02-19 17:16:25 <hsy> ok, 0.8.0 loads, but since the unity menu is broken, no idea if the version number is correct ;-)
502 2013-02-19 17:16:47 <sipa> hsy: check debug.log
503 2013-02-19 17:17:34 <hsy> v0.8.0-beta (2013-02-18 18:38:34 -0500)
504 2013-02-19 17:28:10 <gavinandresen> hsy: perfect, thanks
505 2013-02-19 17:28:48 <Luke-Jr> gavinandresen: Mac user: [18:27:43] <B0g4r7_> "About" box shows "v0.8.0-beta"
506 2013-02-19 17:30:06 <B0g4r7_> The Finder version string however (the one taken from info.plist) just says "Created by Qt/Make", same as 0.7.2 did. Ideally it should show the version there also.
507 2013-02-19 17:35:21 <MC1984> that google account security thing is great
508 2013-02-19 17:35:45 <MC1984> still waiting for microsoft to do some basic goddamn heuristics re: xbox live accounts
509 2013-02-19 17:38:03 <gavinandresen> windows setup.exe is sane (tested in a Windows 8 VM)??? I'm going to announce
510 2013-02-19 17:40:09 <MC1984> want me to try it in xp?
511 2013-02-19 17:42:31 <MC1984> aww it still doesnt take account of my previous install not being on C: drive
512 2013-02-19 17:43:00 <gavinandresen> MC1984: patches welcome (you'll have to figure out the NSIS installer....)
513 2013-02-19 17:43:27 <MC1984> i might have a look actually, its just scripting
514 2013-02-19 17:43:53 <MC1984> lets see if it loads this chain then
515 2013-02-19 17:44:15 <MC1984> the setup icon is still the OLD bitcoin logo btw
516 2013-02-19 17:44:36 <MC1984> not exactly a showstopper i know
517 2013-02-19 17:44:47 <sipa> is there a new one?
518 2013-02-19 17:44:53 <Luke-Jr> ^
519 2013-02-19 17:45:13 <sipa> well to be honest, i have no idea what logo the installer uses
520 2013-02-19 17:45:15 <MC1984> theres the yellow one and th orange tilty one
521 2013-02-19 17:45:42 <Luke-Jr> I'm not aware of Bitcoin-Qt using more than one logo ever
522 2013-02-19 17:45:43 <MC1984> the installer uses the tilty one in the dialogue box
523 2013-02-19 17:45:44 <sipa> i know there have been dozens of proposed logos
524 2013-02-19 17:46:32 <Luke-Jr> setting a common logo really feels like something the Foundation should be involved in, given the documented goals
525 2013-02-19 17:46:42 <MC1984> yea
526 2013-02-19 17:46:46 <Luke-Jr> not so much developers necessarily
527 2013-02-19 17:47:06 <MC1984> branding is important
528 2013-02-19 17:47:38 <MC1984> same reason you see those little visa logos everywhere
529 2013-02-19 17:47:42 <Luke-Jr> there seems to be a lot of push for the ??
530 2013-02-19 17:48:27 <MC1984> the box?
531 2013-02-19 17:48:49 <MC1984> dont think my irc likes that character
532 2013-02-19 17:49:04 <sipa> get unicode :p
533 2013-02-19 17:49:22 <MC1984> lol how
534 2013-02-19 17:49:23 <sipa> it's the capital B with a horizontal dash through the bottom left bar
535 2013-02-19 17:49:32 <MC1984> oh yeah i like that
536 2013-02-19 17:49:52 <MC1984> OTOH the vrertical bar one says "money"
537 2013-02-19 17:50:13 <MC1984> but its too similar to thailands symbol or something
538 2013-02-19 17:50:13 <sipa> yeah, and bitcoin does things sort-of-differently :p
539 2013-02-19 17:50:36 <sipa> it *is* thailand's symbol
540 2013-02-19 17:50:43 <sipa> that baht
541 2013-02-19 17:50:48 <sipa> thai baht
542 2013-02-19 17:50:57 <MC1984> i thought thailands symbol used a double bar
543 2013-02-19 17:51:20 <sipa> http://www.fileformat.info/info/unicode/char/e3f/index.htm
544 2013-02-19 17:51:58 <MC1984> oh fuck nop its the baht symbol
545 2013-02-19 17:52:07 <MC1984> we cant just steal thailands symbol
546 2013-02-19 17:52:43 <Luke-Jr> sipa: no, the baht only has 1 bar
547 2013-02-19 17:52:53 <Luke-Jr> the classic BTC symbol has 2
548 2013-02-19 17:53:04 <Luke-Jr> B???
549 2013-02-19 17:53:17 <MC1984> theres no character for the double bar symbol
550 2013-02-19 17:53:24 <Luke-Jr> B??? <-- right there
551 2013-02-19 17:53:44 <MC1984> whats the altcode for it
552 2013-02-19 17:54:08 <Luke-Jr> U+0042 U+20E6
553 2013-02-19 17:54:35 <gmaxwell> Where is the setup for the win32 installer?
554 2013-02-19 17:54:49 <MC1984> this bitcoin still shows 0.8-beta in the about mind
555 2013-02-19 17:54:58 <Luke-Jr> MC1984: all releases are beta until 1.0
556 2013-02-19 17:54:58 <sipa> yes?
557 2013-02-19 17:55:13 <MC1984> oh
558 2013-02-19 17:58:56 <MC1984> well itloadedmy chain and building on it
559 2013-02-19 17:59:00 <MC1984> looks good
560 2013-02-19 18:00:03 <MC1984> when you say this release is signed, in what way, by whom and how can i check/verify it?
561 2013-02-19 18:03:31 <gavinandresen> MC1984: linux and windows binary checksums/ signatures are at: https://github.com/bitcoin/gitian.sigs
562 2013-02-19 18:04:25 <gavinandresen> MC1984: the OSX .app and the Windows -setup.exe are further signed by an X.509 code signing certificate that belongs to the Bitcoin Foundation and that I use to sign them.
563 2013-02-19 18:05:14 <MC1984> lindasy
564 2013-02-19 18:05:22 <MC1984> lindsay
565 2013-02-19 18:05:34 <gavinandresen> what about Lindsay?
566 2013-02-19 18:05:53 <MC1984> dunno
567 2013-02-19 18:06:14 <helo> do unconfirmed transactions still need to be manually removed from a wallet?
568 2013-02-19 18:06:28 <helo> (so that the coin becomes available again)
569 2013-02-19 18:06:52 <gavinandresen> helo: yes, if they can never be confirmed (how'd you manage to do that, if you did?)
570 2013-02-19 18:09:21 <helo> was wondering if that is likely to change before block space restrictions come into play
571 2013-02-19 18:09:36 <gmaxwell> I went through hell helping someone fix one the other day. Turns out that basically nothing works on stripping txn out of an encrypted wallet.
572 2013-02-19 18:10:34 <gmaxwell> (including things like b.i just failing silently to import, ??? I wonder how many coins have been lost forever because some import tool showed a zero balance and so the user threw the wallet out)
573 2013-02-19 18:10:49 <gavinandresen> gmaxwell: how did they manage to get it stuck? Copying wallet.dat's to different computers?
574 2013-02-19 18:10:55 <gmaxwell> Playing SD.
575 2013-02-19 18:11:13 <helo> it will be interesting to see how users will set their fees, given that they can't know ahead of time that a particular fee is sufficient
576 2013-02-19 18:11:21 <gavinandresen> oy vey???.
577 2013-02-19 18:11:45 <gavinandresen> helo: client software needs to be smarter about fees. That will happen.
578 2013-02-19 18:11:59 <gmaxwell> helo: I had some useful ideas on that??? at least for full nodes you can observe txn failing to make it into blocks and infer the just-insufficient fees.
579 2013-02-19 18:12:13 <helo> so it will maybe include statistics about the fees in the last N blocks?
580 2013-02-19 18:13:21 <helo> allow the user to select a fee, and see "% chance of getting in the next block (if this block behaves like the previous N blocks wrt size and fees)"
581 2013-02-19 18:13:52 <gmaxwell> helo: e.g. a manual interface could potentially have a slider that as you adjust it it tells you the expected time to confirmation, and expected 95%tile time to confirmation.
582 2013-02-19 18:15:11 <gmaxwell> Even more importantly, with a payment protocol, the reciever can pay the fees and choose them. And I expect reciever to generally have more concerns and be better informed.
583 2013-02-19 18:15:47 <helo> sounds like a Good Thing
584 2013-02-19 18:16:26 <gavinandresen> gmaxwell: payment protocol proposal doesn't include receiver-pays, by the way-- consensus was to implement that as child-pays-for-parent
585 2013-02-19 18:18:09 <gmaxwell> I expect it will eventually??? child-pays-for-parent is less efficient??? requires the parent to issue another transaction. At some point in time "some specification work for half the txn size" will be pretty attractive.
586 2013-02-19 18:18:50 <gmaxwell> helo: care need to be taken, if you use stats from the transactions _in_ the blocks your data will be distorted by miners mining according to invisible agreements. (or, worse, miners will pad space in their own blocks with fake fat fee transactions to drive the stats up??? you can't drive the stats up with mempool txn without actually spending fees)
587 2013-02-19 18:19:14 <helo> hah, good point
588 2013-02-19 18:20:44 <helo> seems bizarre that the non-confirmed transactions are more accurate
589 2013-02-19 18:20:52 <gmaxwell> gavinandresen: right now you have things like coinbase making four transctions per transaction, but you know that can't last forever.
590 2013-02-19 18:21:37 <gmaxwell> helo: yea, not so odd if you think at it as this: If you want fees to be trustworthy they must be at stake. Fees in a block may have been at stake (if they were announced) or may not be...
591 2013-02-19 18:24:02 <gavinandresen> cool, Foundation got eleven-times-two grant proposals by the deadline???
592 2013-02-19 18:30:14 <helo> how might a non-full-node recommend appropriate fees?
593 2013-02-19 18:31:19 <helo> a client would have to have been online for consecutive blocks to get a feel for current fee behavior
594 2013-02-19 18:32:38 <kuzetsa> gavinandresen: you said I should tell you if it happened again on 0.8.x...
595 2013-02-19 18:32:48 <kuzetsa> which I haven't tried yet (still RC status last I checked)
596 2013-02-19 18:32:49 <kuzetsa> http://pastebin.com/rcSb4HaM <--- IRC log from February 6th 2013 (an exception happened) ... it just happened again last night ---> http://i49.tinypic.com/2prts9u.png
597 2013-02-19 18:33:14 <gavinandresen> kuzetsa: just released 0.8.0 a couple hours ago.
598 2013-02-19 18:33:20 <kuzetsa> oh
599 2013-02-19 18:34:00 <kuzetsa> according to bitcointalk forum --> News: Version 0.7.2 is now available.
600 2013-02-19 18:34:08 <kuzetsa> I didn't check sourceforge directly
601 2013-02-19 18:35:01 <MC1984> when does 0.8 go front and centre on bitcoin.org?
602 2013-02-19 18:35:08 <MC1984> who controls that domain anyhow
603 2013-02-19 18:35:37 <kuzetsa> yeah good point... bitcoin.org still says 0.7.2 as well
604 2013-02-19 18:35:58 <gavinandresen> MC1984: I pulled the version change, there's a mysterious process that I don't understand that SHOULD automatically update it (but seems to mysteriously sometimes not)
605 2013-02-19 18:36:27 <MC1984> i...see
606 2013-02-19 18:36:49 <gavinandresen> MC1984: bitcoin.org is hosted at github: https://github.com/bitcoin/bitcoin.org
607 2013-02-19 18:38:15 <MC1984> so you can host whole websites at github but not binaries
608 2013-02-19 18:38:19 <MC1984> github logic
609 2013-02-19 18:41:26 <Scrat> sourceforge is full of ads ;x
610 2013-02-19 18:54:58 <HM> congrats on shipping 0.8
611 2013-02-19 18:55:10 <HM> i hope you receive cake from the competing cryptocurrencies
612 2013-02-19 18:56:22 <TD> hah
613 2013-02-19 18:57:42 <helo> bitcoin needs to send paypal a cake when 1.0 comes out :)
614 2013-02-19 18:58:10 <helo> the bitcoin dude, that is
615 2013-02-19 18:58:43 <MC1984> what happened to solid coin
616 2013-02-19 19:04:41 <Eliel_> MC1984: My understanding is that they lost the leader like character and there's now nothing going on anymore.
617 2013-02-19 19:08:31 <MC1984> theres a shame
618 2013-02-19 19:37:44 <comboy> some random user feedback - holy crap this 0.8 is fast! is this thanks to leveldb?
619 2013-02-19 19:38:00 <Luke-Jr> comboy: half
620 2013-02-19 19:38:21 <comboy> what's the other half?
621 2013-02-19 19:38:34 <etotheipi_> any integrity issues observed so far with LevelDB?
622 2013-02-19 19:38:39 <Luke-Jr> comboy: ultraprune
623 2013-02-19 19:38:52 <Luke-Jr> comboy: oh, and there's also the parallelization stuff
624 2013-02-19 19:39:07 <comboy> ah, rings a bell but I don't know details anyway
625 2013-02-19 19:39:11 <comboy> but awesome work, keep it up
626 2013-02-19 19:39:11 <Luke-Jr> in short, it's all thanks to TD and sipa mainly :P
627 2013-02-19 19:39:23 <TD> ultraprune is a lot more than half
628 2013-02-19 19:39:24 <TD> but thanks
629 2013-02-19 19:39:39 <comboy> :)
630 2013-02-19 19:40:07 <Luke-Jr> lol
631 2013-02-19 19:40:13 <Luke-Jr> sipa blames TD; TD blames sipa
632 2013-02-19 19:40:20 <gmaxwell> comboy: basically level db or the database design alone each give something like 85% of the total speed up??? the the blend depends on the hardware (e.g. slow IO gets more from leveldb). They don't quite combine additively.
633 2013-02-19 19:40:40 <TD> right
634 2013-02-19 19:40:58 <gmaxwell> Well total speedup before the parallelism changes, which themselves easily double speed at the tip of the chain.
635 2013-02-19 19:41:22 <comboy> I keep blockchain on ssd, but difference is very noticable anyway
636 2013-02-19 19:42:04 <gmaxwell> yea, on an SSD you would be seeing more ultraprune and parallel sigchecking improvements than leveldb, but really it's all the parts that matter.
637 2013-02-19 19:42:23 <etotheipi_> gmaxwell: any comments on levelDB integrity, so far?
638 2013-02-19 19:42:37 <gmaxwell> comboy: I'm glad to hear you noticed in any case. I kinda wondered if we'd get complaints that it was slow simply because the reindex takes a while because it redoes the whole database.
639 2013-02-19 19:43:31 <gmaxwell> etotheipi_: uh. It's surprisingly robust to fuzzing its data, even with the checksums disabled. BDB would crash all over the place.
640 2013-02-19 19:46:14 <etotheipi_> gmaxwell: any reports so far of corrupted DBs?
641 2013-02-19 19:46:38 <etotheipi_> obviously, it may be some time before you can collect statistics... you just released it
642 2013-02-19 19:46:57 <gmaxwell> etotheipi_: there have been some comments, but they're hard to yet reason about.
643 2013-02-19 19:48:28 <etotheipi_> gmaxwell: well, despite his trollish behavior, 2112 is making a fuss about LevelDB being a toy and unreliable when I mentioned I wanted to use it for Armory stuff (my own speed & storage tests have been extremely promising)
644 2013-02-19 19:48:54 <gmaxwell> It's 2112. He calls all kinds of things toys. He thinks casting in C is a toy.
645 2013-02-19 19:49:06 <etotheipi_> and despite him being a dick, he has justifiably caused me to pause and question whether I want to actually use it
646 2013-02-19 19:49:30 <gmaxwell> LevelDB may ultimately turn out to suck, but there it is implausable that it it could be worse than BDB.
647 2013-02-19 19:49:40 <etotheipi_> haha
648 2013-02-19 19:50:01 <etotheipi_> well, that's why I'm asking about integrity... it's got *everything else* I want
649 2013-02-19 19:50:29 <gmaxwell> We have reasonably high levels of observed corruption in the wild with BDB. If you manually screw up BDB's databases it will viciously crash in a seemingly infinite number of different ways.
650 2013-02-19 19:50:35 <TD> leveldb is basically a refactored out part of BigTable
651 2013-02-19 19:50:40 <TD> or at least, a reimplementation of a very similar design
652 2013-02-19 19:50:52 <etotheipi_> gmaxwell: I'm not looking for a comparison to BDB... I already have had bad experiences with that
653 2013-02-19 19:50:52 <TD> so if you have a gmail account, i'd hope you trust it :)
654 2013-02-19 19:51:33 <etotheipi_> since I'm starting from scratch with the new blockchain management stuff... it definitely deserves spending some time to make sure I'm using a good tool
655 2013-02-19 19:51:39 <gmaxwell> TD: to be fair, isn't it the case that most google applications have redundancy at multiple levels? e.g. a single leveldb instance blowing up wouldn't tend to lose anyone's data?
656 2013-02-19 19:52:00 <TD> yes, of course, but it's still a problem if your database randomly eats data. backups are great but they still have to be restored.
657 2013-02-19 19:52:28 <gmaxwell> etotheipi_: what has 2112's point actually been on the subject? Simply staying it is a toy isn't an argument.
658 2013-02-19 19:52:31 <TD> data corruption is especially problematic as it can of course fail to be detected and then propagated.
659 2013-02-19 19:52:41 <TD> etotheipi_: fyi i've had him on my ignorelist for ages now
660 2013-02-19 19:53:26 <MC1984> wow bitcoin looks strange without the dire warning in it now
661 2013-02-19 19:54:13 <etotheipi_> gmaxwell, TD: I understand
662 2013-02-19 19:54:37 <etotheipi_> I recognize he has useful information in his brain, he's just has no interest in really helping people
663 2013-02-19 19:55:00 <TD> ?
664 2013-02-19 19:55:00 <TD> etotheipi_: are you going to implement a full node, or re-use the leveldbs built by bitcoind or ???.
665 2013-02-19 19:55:38 <gmaxwell> If there is useful information there??? it's been encrypted. Perhaps there is some protocol where you can pass him through a number of transformations and get useful work to occur using that information without ever discovering it, but I'm skeptical. :P
666 2013-02-19 19:55:40 <etotheipi_> TD: I'm switching Armory from maintaining an file-pointer index in RAM (mapping 32-byte TxIDs to locations in the Bitcoin-Qt/bitcoind blk*.dat files)
667 2013-02-19 19:55:57 <etotheipi_> TD: switching to actually maintaining my own copy of all the data
668 2013-02-19 19:56:04 <Luke-Jr> etotheipi_: boo :P
669 2013-02-19 19:56:10 <TD> ok. so with your own block chain management, etc?
670 2013-02-19 19:56:20 <Luke-Jr> etotheipi_: would be wonderful if Armory could just share LevelDB+blk0*.dat with bitcoind
671 2013-02-19 19:56:30 <etotheipi_> TD: I'm still relying on Bitcoin-Qt/bitcoind to do the validation for me
672 2013-02-19 19:56:33 <TD> ok
673 2013-02-19 19:56:37 <etotheipi_> and all the network/P2P stuff
674 2013-02-19 19:57:14 <gmaxwell> meh. 2x resource usage is not fun.
675 2013-02-19 19:57:16 <etotheipi_> but by managing my own DB, I can later do somethign different with it -- some kind of pruning, filtering, UTXOs, etc
676 2013-02-19 19:57:55 <etotheipi_> gmaxwell: obviously not, but Armory is using like 2 GB of RAM now just to maintain the mapping of TxIDs to tx locations
677 2013-02-19 19:57:55 <gmaxwell> (it'll just encourage users to put their armory behind random public untrusted nodes)
678 2013-02-19 19:58:26 <gmaxwell> ah, well. that seems urgent. Though you could just throw that in leveldb and be done with it without making a seperate copy of the data.
679 2013-02-19 19:58:30 <etotheipi_> I mean, not 2GB just for that mapping... there's a variety of things contributing to it
680 2013-02-19 19:58:42 <etotheipi_> gmaxwell: I had started to do that
681 2013-02-19 19:59:26 <etotheipi_> I have long wanted to start maintaining my own copy of the data anyway, and implementing that partial solution turned out to be a lot trickier than I'd hoped
682 2013-02-19 20:00:09 <gmaxwell> (I still would really perfer you abstract out your backend enough that users could just point it at the bitcoind rpc if they were running it??? but I guess I only can start whining at you about that if I start cutting you a paycheck. :P )
683 2013-02-19 20:00:55 <etotheipi_> gmaxwell: I understand
684 2013-02-19 20:01:01 <etotheipi_> but I want to leave my options open
685 2013-02-19 20:01:37 <etotheipi_> by maintaining my own data, I can connect to remote nodes, Armory super-nodes (in the future), create lite or pruned local nodes, etc
686 2013-02-19 20:01:50 <etotheipi_> if I piggyback 100% on Bitcoin-Qt/bitcoind, I've lost that flexibility
687 2013-02-19 20:02:48 <gmaxwell> Well thats why I said 'abstract out'. ... if you're going to talk to untrusted nodes there is a lot of annoying detail work to do to make things actually secure. Far more work than writing just a simple database backend shim.
688 2013-02-19 20:03:15 <etotheipi_> gmaxwell: the goal right now is not to really be possible to talk to untrusted nodes
689 2013-02-19 20:03:40 <TD> armory is in c++?
690 2013-02-19 20:03:42 <etotheipi_> it will still require a localhost bitcoind... and if it's possible to to connect to different, untrusted nodes, I won't make it easy
691 2013-02-19 20:03:44 <gmaxwell> I certantly support you doing all that work (hurray, more work for someone who isn't me!), but so long as you haven't done it yet and are going to depend on a bitcoin node ... it would be nicer to not double the resource requirements.
692 2013-02-19 20:04:10 <etotheipi_> gmaxwell: in the future ,I hope that Armory *won't* double it
693 2013-02-19 20:04:10 <TD> you could consider compiling bitcoinj to C++ using gcj/cni and then using SPV mode connected to a local node
694 2013-02-19 20:04:26 <etotheipi_> gmaxwell: I hope that Armory will simply hold/copy a subset
695 2013-02-19 20:04:48 <etotheipi_> but for now it's simplest to keep the CONOPs I have (which is to maintain a full database with full tx lookup capabilities)
696 2013-02-19 20:04:51 <gmaxwell> etotheipi_: well at the moment, I expect you'll more than double it, since we don't index all txn by default, and don't index addresses at all, and you do.
697 2013-02-19 20:05:31 <gmaxwell> (though we can optionally index all the txn- it's a configuration parameter, and sipa wrote code to do the same with addresses, but isn't happy with it yet)
698 2013-02-19 20:06:36 <etotheipi_> gmaxwell: I actually setup a full index (txid--> tx)
699 2013-02-19 20:06:40 <etotheipi_> as part of my tests
700 2013-02-19 20:06:49 <etotheipi_> I only did it for the first 2GB of the blockchain
701 2013-02-19 20:06:53 <etotheipi_> the resulting DB was about 2.3 GB
702 2013-02-19 20:07:16 <etotheipi_> and doing a full scan was stupid fast
703 2013-02-19 20:07:48 <etotheipi_> gmaxwell: btw 2112 was basically saying that the integrity aspect of LevelDB is lacking, and of course integrity is very important
704 2013-02-19 20:08:47 <gmaxwell> etotheipi_: did he actually say _how_? He says a lot of things which I think are indistinguishable from a topically trained markov model. He invokes a lot of the right sounding words, they don't always mean a whole lot.
705 2013-02-19 20:09:15 <etotheipi_> and also telling me I should use a relational database, though I don't agree with that for such simple data structure
706 2013-02-19 20:09:20 <etotheipi_> I'd prefer speed
707 2013-02-19 20:09:41 <etotheipi_> well my understanding was that LevelDB doesn't have all the ACID pieces there
708 2013-02-19 20:10:30 <TD> gmaxwell: hah, excellent burn.
709 2013-02-19 20:10:44 <gmaxwell> It's not a full relational database. It does have transactions??? basically its integrity model is exactly what we need for blockchain data. Your usage may be different.
710 2013-02-19 20:11:29 <gmaxwell> For blockchain data we need ordered transactions that apply completely or not at all. And if data is lost it only gets lost in the form of forgetting the most recent transaction.
711 2013-02-19 20:11:43 <etotheipi_> gmaxwell: I totally agree with you about 2112, but that doesn't mean his comments are exactly 0% useful
712 2013-02-19 20:11:58 <Skav> Luke-Jr: got a min
713 2013-02-19 20:12:01 <etotheipi_> his point that I should consider more options was a good one, I think
714 2013-02-19 20:12:08 <gmaxwell> No, well, thats why I was asking what he said. I assume that 2112 via etotheipi filter is likely to produce something useful.
715 2013-02-19 20:12:18 <etotheipi_> lol
716 2013-02-19 20:12:26 <Luke-Jr> Skav: barely
717 2013-02-19 20:12:42 <gmaxwell> (likewise, I'd also listen if you told me that you found useful solutions to problems in the digits of pi... :P )
718 2013-02-19 20:14:19 <bonks> bitcoin.org down?
719 2013-02-19 20:14:26 <HM> the long term memory usage of 0.8 still seems way too high
720 2013-02-19 20:14:32 <gmaxwell> etotheipi_: In any case, I'm not aware of a better option. As you're aware, requring a full relational database would be a huge burden on the users. ... and the performance of them is surprisingly lackluster for our narrow usecase (go install ABE).
721 2013-02-19 20:14:42 <gmaxwell> HM: how are you measuring memory usage?
722 2013-02-19 20:15:05 <HM> rss
723 2013-02-19 20:15:06 <etotheipi_> gmaxwell: that was exactly my opinion, too... glad to see you agree
724 2013-02-19 20:15:23 <etotheipi_> i didn't like the other options, because they're not easy to bundle into an end-user app
725 2013-02-19 20:15:29 <kuzetsa> yikes
726 2013-02-19 20:15:29 <Skav> gmaxwell: i know your good with this using https://blockchain.info/api/json_rpc_api than with my store opencart what should the status of a new order should be set to
727 2013-02-19 20:15:38 <TD> HM: are you tweaking any flags?
728 2013-02-19 20:15:39 <etotheipi_> if they even have an acceptable license
729 2013-02-19 20:15:44 <HM> not that i know of
730 2013-02-19 20:15:47 <kuzetsa> switching from 0.7.2 --> 0.8 blockchain format is currently more than 10GB on disk
731 2013-02-19 20:16:08 <kuzetsa> 13.2 GB (14,279,483,392 bytes) ... that's huge!
732 2013-02-19 20:16:27 <Skav> gmaxwell: i have digital downloads in my store but they are just sitting there waiting do they need to wait for 6 confs. before they will recieve a link
733 2013-02-19 20:16:33 <gmaxwell> HM: what are you seeing?
734 2013-02-19 20:16:57 <HM> basically 512MB VPS, with 1 GB swap. I increased the swap, few days later the swap is full
735 2013-02-19 20:16:59 <HM> all Bitcoind
736 2013-02-19 20:17:03 <HM> this was 0.8-rc1 though
737 2013-02-19 20:17:23 <gmaxwell> HM: whats the RES/RSS though?
738 2013-02-19 20:17:30 <HM> 1.5 GiB
739 2013-02-19 20:17:42 <gmaxwell> yea, thats broken, we need to figure out why.
740 2013-02-19 20:17:48 <gmaxwell> On my x86_64 tor only node with 30 connections I'm seeing 272MiB, which I think it quite reasonable.
741 2013-02-19 20:18:04 <gmaxwell> HM: are you _sure_ you're not looking at virt?
742 2013-02-19 20:18:14 <TD> kuzetsa: where is most of the space used?
743 2013-02-19 20:18:24 <TD> HM: have you tried restarting the app?
744 2013-02-19 20:18:36 <HM> it'd make no difference unless there's some gigantic file backed mmaps
745 2013-02-19 20:18:54 <gmaxwell> kuzetsa: From that size I'd say he's just ending up with two copies of the blockchain.
746 2013-02-19 20:18:58 <HM> and that wouldn't explain swap
747 2013-02-19 20:19:02 <gmaxwell> HM: ...
748 2013-02-19 20:19:29 <HM> i had to kill the process to make the machine usable again
749 2013-02-19 20:20:08 <gmaxwell> HM: please don't give me bad data. There are no gigantic file based mmaps, but the heap allocation patterns in Bitcoin is pretty pessimal, and causes a LOT of VM bloat. Though yes, it wouldn't impact your swap usage or performance.
750 2013-02-19 20:20:20 <kuzetsa> gmaxwell: well it's still reindexing, so maybe the disk usage will settle once it's done
751 2013-02-19 20:20:25 <Skav> gmaxwell: can i set it to procssed because they have to send the coin right
752 2013-02-19 20:20:44 <HM> gmaxwell: i mean virtual memory is going to be close rss+swap
753 2013-02-19 20:20:56 <gmaxwell> HM: it is not.
754 2013-02-19 20:21:03 <gmaxwell> HM: not even remotely close.
755 2013-02-19 20:21:12 <HM> based on what being mmaped?
756 2013-02-19 20:21:24 <gmaxwell> Nothing is being mmaped, it's just from VM fragmentation.
757 2013-02-19 20:21:33 <Skav> can the json rpc api have to use the bitcoin-qi client to confirm purchase or can someone send it and it will acknowledge it? if so after how many confirmations, 2 has done nothing so far.
758 2013-02-19 20:21:33 <TD> HM: huh?
759 2013-02-19 20:21:46 <TD> HM: yeah restarting the app can make a difference
760 2013-02-19 20:22:01 <gmaxwell> VIRT gives the address space span, if you end up with holes in the address space due to a lot of small allocaitons with different lifetimes, then you can fragment the memory address space.
761 2013-02-19 20:22:09 <HM> it's a 64bit machine, the only fragmentation that matters is internal fragmentation by the allocator
762 2013-02-19 20:22:16 <TD> yes
763 2013-02-19 20:22:35 <gmaxwell> HM: sure, it doesn't matter. I agree.. but it does mean that VIRT and RES are unrelated.