1 2012-09-18 00:35:47 <DBordello> Any reason I can't start 0.70 in place of a CVS version?
2 2012-09-18 00:38:09 <DBordello> Version 0.6.99 or somethign
3 2012-09-18 00:41:42 <ageis> ok, did anyone reply to my thing about soft-linking earlier?
4 2012-09-18 00:44:45 <DBordello> Why I try to start 0.70 the first time after using a git version from months ago:
5 2012-09-18 00:44:49 <DBordello> http://pastebin.com/r3HyJT7t
6 2012-09-18 00:45:33 <DBordello> Ideas?
7 2012-09-18 00:52:37 <denisx> DBordello: did you change your DB meanwhile?
8 2012-09-18 01:08:54 <enquirer> my blockchain is stuck
9 2012-09-18 01:09:07 <enquirer> version 0.70, windows xp)
10 2012-09-18 01:10:20 <enquirer> didn't this version promize to speed up downloads?
11 2012-09-18 01:11:28 <enquirer> oh, it moves slowly ... a block in a minute
12 2012-09-18 01:12:07 <DBordello> denisx, no. Using the same .bitcoin directory
13 2012-09-18 01:12:45 <DBordello> Version 0.6099 works fine
14 2012-09-18 01:16:07 <DBordello> Can I delete the database? I just don't want to grab the blockchain again
15 2012-09-18 01:17:28 <gmaxwell> DBordello: are you running 0.7 ?
16 2012-09-18 01:17:48 <gmaxwell> oh.. looking at your message.. bleh. you must shut down cleanly before upgrading.
17 2012-09-18 01:17:51 <gmaxwell> or you end up with that.
18 2012-09-18 01:17:57 <DBordello> gmaxwell, I thought I did....
19 2012-09-18 01:18:00 <DBordello> I'll try it again
20 2012-09-18 01:18:12 <gmaxwell> it would be best to start the old one with the -detach option, then shut it down cleanly.
21 2012-09-18 01:18:34 <DBordello> Okay, doing that
22 2012-09-18 01:18:43 <DBordello> I assume stop is a clean shutdown?
23 2012-09-18 01:18:48 <gmaxwell> yes
24 2012-09-18 01:19:26 <DBordello> -detachdb?
25 2012-09-18 01:19:38 <gmaxwell> if that doesn't work. Move your .bitcoin directory out of the way (but don't delete it). Then copy back your conf file and wallet. Then start up bitcoin with -loadblock=/path/to/old/blockchain/block001.dat (and don't use shorcuts like ~ in the path)
26 2012-09-18 01:19:50 <DBordello> Got it
27 2012-09-18 01:20:42 <gmaxwell> DBordello: yes. -detachdb sorry
28 2012-09-18 01:21:13 <DBordello> giving it a shot
29 2012-09-18 01:21:15 <enquirer> well i'd better install electrum ... can I import my old wallet into it?
30 2012-09-18 01:22:14 <DBordello> I assume gettransaction hasn't change since it was introduced?
31 2012-09-18 01:23:13 <gmaxwell> 20:11 < enquirer> oh, it moves slowly ... a block in a minute
32 2012-09-18 01:23:16 <gmaxwell> 0_o
33 2012-09-18 01:23:22 <gmaxwell> at what height?
34 2012-09-18 01:23:55 <DBordello> gmaxwell, how intensive is -detachdb? How long should I expect that to take?
35 2012-09-18 01:24:26 <gmaxwell> DBordello: it takes a bit longer to shut down because it puts the db in a maximally clean state. tens of seconds? thats the way bitcoin used to work prior to 0.6
36 2012-09-18 01:24:47 <DBordello> Gotcha, I am on a reasonably slow VPS, startup and shutdown are slow for me to start with
37 2012-09-18 01:24:55 <gmaxwell> Now it skips it, though this is proving to be a mistake.. makes upgrades more fragile. :(
38 2012-09-18 01:27:14 <DBordello> Even after a clean shutdown using -detatchdb, same error
39 2012-09-18 01:28:11 <DBordello> I"ll try moving .bitcoin out of the way
40 2012-09-18 01:28:48 <DBordello> hmmm, that isn't going to work, I don't have enough space for 2xblock001.dat
41 2012-09-18 01:29:07 <DBordello> Any other ideas?
42 2012-09-18 01:29:11 <DBordello> Other than make more space
43 2012-09-18 01:59:26 <Luke-Jr> https://gitorious.org/bitcoin/python-blkmaker for anyone who needs it
44 2012-09-18 02:00:23 <enquirer> i think utorrent with 3000 seeders would download the file pretty quick ...
45 2012-09-18 02:03:41 <gmaxwell> DBordello: welp, you should be able to loadblock until you run out of space.. then delete the oldone and at least get a headstart.
46 2012-09-18 02:03:48 <Luke-Jr> XD
47 2012-09-18 02:04:00 <DBordello> Haha. I am attempting to grow my EC2 volume now
48 2012-09-18 02:04:00 <Luke-Jr> gmaxwell: What do you think? https://en.bitcoin.it/wiki/Getblocktemplate
49 2012-09-18 02:04:05 <kjj_> any of you guys know where (or if) the windows client handles system events?
50 2012-09-18 02:05:10 <kjj_> in the RC thread, someone mentioned a problem with suspend/resume, so I figured I'd go looking for PBT_APMRESUMESUSPEND, but haven't found it anywhere
51 2012-09-18 02:23:19 <doublec> Luke-Jr: I just quickly skimmed it right now but looks great
52 2012-09-18 02:27:55 <Luke-Jr> doublec: thanks
53 2012-09-18 02:41:58 <DBordello> gmaxwell, trying loadblock
54 2012-09-18 02:42:09 <kjj_> hmm. it looks like it might be impossible to properly handle suspend/resume events using the QT model
55 2012-09-18 02:42:58 <DBordello> Hmm, it does not look like that is going to be fast
56 2012-09-18 02:43:19 <Luke-Jr> gmaxwell: sounds like the real reason BTCGuild doesn't like GBT is because they want to keep the miners in the dark after all
57 2012-09-18 02:44:02 <gmaxwell> Luke-Jr: but they're a PPS pool, what benefit does that serve them?
58 2012-09-18 02:44:33 <gmaxwell> DBordello: it's the fastest thing available to you, I suspect.
59 2012-09-18 02:44:51 <gmaxwell> DBordello: its fast.. if your IO subsubsystem isn't some ratelimited vps.
60 2012-09-18 02:44:53 <Luke-Jr> gmaxwell: dunno
61 2012-09-18 02:45:02 <gmaxwell> Bummer.
62 2012-09-18 02:45:06 <DBordello> gmaxwell, hmmm, the downtime looks like it'd be significant
63 2012-09-18 02:45:16 <DBordello> gmaxwell, it is an Amazon VPS, IO does seem to be awful
64 2012-09-18 02:45:25 <Diablo-D3> man
65 2012-09-18 02:45:32 <Diablo-D3> ACTION works on cloud computing harder
66 2012-09-18 02:45:50 <DBordello> It took about 5 minutes to get through 25 MB. That is going to take a while
67 2012-09-18 02:47:27 <weex> scariest line to see in tail -f debug.log: Flushed wallet.dat 67ms
68 2012-09-18 02:47:44 <Luke-Jr> gmaxwell: hmm, sounds like he's worried about bandwidth
69 2012-09-18 02:48:31 <jgarzik> it is a fair point that miners do not need to get/put all the transactions
70 2012-09-18 02:49:00 <kjj_> digging deeper, it appears to be possible to reack up QT's ass and tap into the windows message event handler to catch things that it ignores
71 2012-09-18 02:51:38 <kjj_> I never use suspend myself. anyone know what a p2p client "should" do when it gets a power resume event? do they just flush the old connections and make new ones?
72 2012-09-18 02:53:17 <jgarzik> consider a maximally sized block. a miner doesn't want to pull+push 1MB in the case of a found solution. that would especially be awful if GBT is presumed to be pool mining protocol, where a reduced target is offered, thereby resulting in a whole lot of 1MB pushes to pool server, simply to credit a share.
73 2012-09-18 02:53:36 <jgarzik> that's a whole lot of pointless bandwidth
74 2012-09-18 02:54:05 <jgarzik> I agree that GBT is not the best choice for pool server <-> miner communication
75 2012-09-18 02:54:24 <Luke-Jr> jgarzik: GBT doesn't send the whole block for shares
76 2012-09-18 02:54:29 <Luke-Jr> just the header + coinbase txn
77 2012-09-18 02:56:39 <jgarzik> Luke-Jr: where does it say in a BIP, that submitblock has a mode that accepts only header + coinbase?
78 2012-09-18 02:57:20 <Luke-Jr> https://en.bitcoin.it/wiki/BIP_0023#Submission_Abbreviation
79 2012-09-18 02:58:07 <denisx> so I can speed up my pool by ommitting transactions? ;)
80 2012-09-18 02:58:31 <jgarzik> Luke-Jr: ACK, I see it
81 2012-09-18 02:58:54 <jgarzik> Luke-Jr: this is very hidden and unclear, though, IMO
82 2012-09-18 02:59:14 <Luke-Jr> jgarzik: https://en.bitcoin.it/wiki/Getblocktemplate is the user-friendly page
83 2012-09-18 03:02:06 <jgarzik> Luke-Jr: yeah saw that, only missed it in BIP 23. still think last point stands. you really only have one sentence there " If the server has listed "submit/coinbase" in its "mutable" key, you may opt to omit the transactions after the coinbase."
84 2012-09-18 03:02:37 <jgarzik> Luke-Jr: this mode should IMO be required for BIP 23, and all examples show that usage first
85 2012-09-18 03:02:59 <Luke-Jr> hmm
86 2012-09-18 03:03:00 <jgarzik> Luke-Jr: that does not imply the client is required to use said feature
87 2012-09-18 03:03:08 <jgarzik> Luke-Jr: only required to support that mode
88 2012-09-18 03:03:33 <jgarzik> on the server side, for full BIP 23 compliance
89 2012-09-18 03:04:11 <jgarzik> The default-and-encouraged mode should not sling the entire block's worth of transactions back and forth.
90 2012-09-18 03:04:11 <Luke-Jr> well, I wasn't seeing "full BIP 23 compliance" as a goal; but you're probably right it should probably just be presumed required on the server side at some point
91 2012-09-18 03:05:47 <jgarzik> Luke-Jr: ideally, we would not want pool server implementations to -require- that the client pull+push the full list of transactions
92 2012-09-18 03:05:53 <Luke-Jr> jgarzik: think there'd be any merit to adding a "centralized template" mode that only sends the merkle links?
93 2012-09-18 03:06:02 <jgarzik> Luke-Jr: that is burdensome on most clients, which do not care
94 2012-09-18 03:07:14 <jgarzik> Luke-Jr: <shrug> I always liked sending header + coinbase + TX hashes, but maybe that's just me
95 2012-09-18 03:08:19 <jgarzik> they calc merkle, send back block header + coinbase. server rejects, if merkle does not match expected.
96 2012-09-18 03:08:21 <Luke-Jr> not sure how useful TX hashes are - if the miner has info on them, it could just select them itself; if they don't, then it's no more useful than the link hashes
97 2012-09-18 03:08:53 <jgarzik> it's not a big deal to me. I just hate losing a bit of information.
98 2012-09-18 03:09:00 <jgarzik> merkle is fine too
99 2012-09-18 03:09:12 <jgarzik> main point: consider the minimum that a future client will need
100 2012-09-18 03:09:23 <jgarzik> that's the block header + ability add extra nonce bits in coinbase
101 2012-09-18 03:09:49 <jgarzik> you don't really _need_ full coinbase TX even
102 2012-09-18 03:10:07 <Luke-Jr> well, I think centralized mining should be discouraged as much as possible - which the merkle links (or txids without a local tx db) don't allow for
103 2012-09-18 03:11:48 <jgarzik> too idealistic for reality, I fear
104 2012-09-18 03:11:56 <Luke-Jr> maybe :<
105 2012-09-18 03:12:12 <denisx> it already exists and is called solomining
106 2012-09-18 03:12:24 <Luke-Jr> denisx: yeah, if you want to give up collaboration
107 2012-09-18 03:12:34 <jgarzik> Luke-Jr: I hope that BIP 23 simply provides a "better getwork", and that means blockheader + minimal coinbase
108 2012-09-18 03:12:36 <Luke-Jr> and have a huge amount of ASICs
109 2012-09-18 03:13:20 <jgarzik> Luke-Jr: you would see greater pool server uptake, if so
110 2012-09-18 03:13:37 <jgarzik> I doubt miners will simply switch away from pool servers, as much as we would like that to happen
111 2012-09-18 03:39:43 <devrandom> gmaxwell: let me know what the current issue is. are you using lxc?
112 2012-09-18 03:46:20 <Luke-Jr> ACTION wonders if there's any viable use for share/coinbase and share/truncate
113 2012-09-18 05:21:33 <Varan> I just found: http://www.ludumdare.com/compo/ludum-dare-24/?action=preview&uid=2952 ... very cool game ... I think if would be very cool if this was adapted to use bitcoins.... I think it is very well suited ... some type of gambling game. Any thoughts?
114 2012-09-18 05:24:56 <fiesh> reminds me of these games where you program your robots in some scripting language and let it fight against others
115 2012-09-18 05:28:21 <Varan> indeed
116 2012-09-18 05:29:03 <Varan> there are many of those ... but what is cool about this is that it is very accessible ... you dont really need to a able to program at all
117 2012-09-18 05:47:25 <fiesh> Varan: yes, that's true
118 2012-09-18 06:02:22 <Crucials> Hey. How feasible is it setting up a bitcoin exchange, given the knowledge and funding?
119 2012-09-18 06:02:54 <Luke-Jr> Crucials: I suspect the legal processes are the biggest hurdle
120 2012-09-18 06:03:07 <Luke-Jr> exchanges are highly regulated
121 2012-09-18 06:03:21 <Crucials> What body are they regulated by?
122 2012-09-18 06:04:05 <Luke-Jr> whatever jurisdiction they want to do business in
123 2012-09-18 06:05:16 <Crucials> do you have any knowledge regarding the kind of process it takes, or perhaps point me in the right direction?
124 2012-09-18 06:08:59 <Luke-Jr> Crucials: probably varies quite a bit
125 2012-09-18 06:10:20 <Crucials> I can imagine. I also imagine setting it on an offshore company would make it easier
126 2012-09-18 06:13:08 <Crucials> but lets say I have the money and people to set up such a thing - I would still need a person or two who know the bitcoin system inside out, right?
127 2012-09-18 06:15:27 <Luke-Jr> Crucials: offshore doesn't change much; if you want to do business in <X>, you have to comply with <X> regulations
128 2012-09-18 06:15:55 <Luke-Jr> Crucials: probably a good idea; MtGox is (now) owned and operated by a top Bitcoin developer, and they run a completely custom client
129 2012-09-18 06:18:48 <Crucials> How much work is it setting up such an exchange in itself? Without the legal hurdles that are separate for now
130 2012-09-18 06:19:22 <Luke-Jr> probably a few weeks full time I'd imagine, but I don't have any personal experience in doing it
131 2012-09-18 06:20:31 <Luke-Jr> likely you would also want to have at least one security review of the code and setup before making it live, too
132 2012-09-18 06:20:33 <Crucials> The reason I am asking is because I was contacted today by a guy who would be interested in doing this, and has the money and resources.. But i personally know very little about the subject
133 2012-09-18 08:21:46 <tonikt> Hi guys. A quick question: I have an offline client... do I need to move the blk0001.dat every time when I want to sync it, or should this file never change anymore?
134 2012-09-18 08:22:49 <sipa> it won't change
135 2012-09-18 08:23:10 <tonikt> ok, thx
136 2012-09-18 08:23:43 <tonikt> btw, is there something on the dev roadmap that would make the blockchain sync easier/faster in a future?
137 2012-09-18 08:24:30 <tonikt> for instance: when I do -rescan it rescans everytging, starting from block 0...
138 2012-09-18 08:24:45 <tonikt> and it takes a hell lot of time on my old laptop
139 2012-09-18 08:34:37 <tonikt> the way I'd imagine it, would be to store the last processed block in wallet.dat, and then re-scan the chain from that block at startup (assuming that there are some new blocks in the chain)
140 2012-09-18 08:36:49 <Varan> Does anyone know how many requests per sec you can do at this api: https://blockchain.info/api/blockchain_api
141 2012-09-18 08:41:49 <Luke-Jr> tonikt: Armory has better offline storage support atm
142 2012-09-18 08:42:34 <tonikt> Luke-Jr: I know, but I'm more of a windows guy, and from what I read it does not go well with windows yet, does it?
143 2012-09-18 08:43:00 <tonikt> And it's python, isn't it?
144 2012-09-18 08:46:23 <tonikt> And my cold storage laptop is really old...
145 2012-09-18 09:38:17 <sipa> tonikt: since 0.3.23, the last known block *is* written in wallet.dat, and rescanned from that point at startup
146 2012-09-18 09:38:20 <sipa> eh, 0.3.21
147 2012-09-18 09:41:00 <tonikt> hmm... so it means I am such a sucker doing a full -rescan every time. thanks sipa! better to learn late than never.. :)
148 2012-09-18 10:37:53 <knotwork> Hmm I discovered my system was running an attempt to read a fingerprint reader over and over again so I turned that off
149 2012-09-18 10:37:55 <knotwork> then log showed
150 2012-09-18 10:37:57 <knotwork> bitcoin-rpchand[5675]: segfault at 0 ip 00000000004dcffa sp 00007fe5fd7f8080 error 4 in bitcoind[400000+3a0000]
151 2012-09-18 10:38:16 <knotwork> does new bitcoin try to use fingerprint reader?
152 2012-09-18 11:32:49 <knotwork> and bitcoind crashed again: bitcoin-rpchand[10688]: segfault at 0 ip (null) sp 00007fa742ff6218 error 14 in bitcoind[400000+3a0000]
153 2012-09-18 11:33:27 <knotwork> git pull claims I am up to date but that there is a new tag, v0.7.0 so I did git branch v0.7.0 and pulled again and it still said I am up to date
154 2012-09-18 11:33:50 <gmaxwell> knotwork: What RPC calls are you making to bitcoind?
155 2012-09-18 11:34:03 <knotwork> last thing in the log is a getblock call
156 2012-09-18 11:34:13 <gmaxwell> knotwork: this is a build you made?
157 2012-09-18 11:34:14 <knotwork> p2pool is what is doing calls to it
158 2012-09-18 11:34:24 <knotwork> yes its from gavin's github
159 2012-09-18 11:34:25 <gmaxwell> knotwork: ah, so this node is just being called by p2pool?
160 2012-09-18 11:34:39 <gmaxwell> gavin's github? link please?
161 2012-09-18 11:34:45 <knotwork> well manually I alsto do getinfo sometimes
162 2012-09-18 11:35:09 <knotwork> oh gee how do I get git to tell me where its pulling from?
163 2012-09-18 11:35:38 <knotwork> its bitcoin/bitcoin at github I think
164 2012-09-18 11:35:56 <gmaxwell> git remote show origin
165 2012-09-18 11:36:07 <gmaxwell> okay. I just wanted to make sure you weren't on some weird personal repo.
166 2012-09-18 11:36:27 <knotwork> Fetch URL: https://github.com/bitcoin/bitcoin.git
167 2012-09-18 11:36:32 <gmaxwell> Thats fine.
168 2012-09-18 11:36:42 <knotwork> Local branch configured for 'git pull':
169 2012-09-18 11:37:13 <gmaxwell> knotwork: what is the id of your top most commit? e.g. listed on git log
170 2012-09-18 11:37:28 <knotwork> hmm nothing it output indicates that my having tried git branch v0.7.0 did anything
171 2012-09-18 11:37:59 <gmaxwell> Id?
172 2012-09-18 11:38:03 <knotwork> commit 7fddf1210eca3919804aec5d6b405e59d2651970
173 2012-09-18 11:38:16 <gmaxwell> OKAY, you're in the right place.
174 2012-09-18 11:38:20 <gmaxwell> hmph.
175 2012-09-18 11:38:52 <sipa> anything in particular in debug.log?
176 2012-09-18 11:39:00 <knotwork> there was a thead saying 0.7.0 is out I thought what I had were just release candiates not the actual final version
177 2012-09-18 11:39:10 <gmaxwell> knotwork: It's out.
178 2012-09-18 11:39:26 <gmaxwell> and what you have now is the final version.
179 2012-09-18 11:39:57 <knotwork> ok so what would make it segfault after last thing written to log was getblock rpc
180 2012-09-18 11:40:29 <knotwork> all seemed fine before rebooting the machine
181 2012-09-18 11:41:04 <knotwork> possibly fedora 16 update might have caused some new stuff to be fired up tho on reboot
182 2012-09-18 11:41:11 <knotwork> I dont think it changed kernel though
183 2012-09-18 11:45:46 <gavinandresen> knotwork: if you can recompile -g and then run it inside gdb to get a stack trace that would be very helpful
184 2012-09-18 11:46:21 <gavinandresen> (make clean before recompile....)
185 2012-09-18 11:46:43 <knotwork> ok
186 2012-09-18 11:48:03 <gmaxwell> gavinandresen: our default builds have debugging symbols.
187 2012-09-18 11:49:02 <gmaxwell> er.
188 2012-09-18 11:49:10 <gmaxwell> Oh yea, they do.
189 2012-09-18 11:50:54 <knotwork> oh wait what do you mean by -g ? make -g makefile.whatever?
190 2012-09-18 11:51:01 <gavinandresen> does gdb still sometimes get confused with -O3 code?
191 2012-09-18 11:51:03 <knotwork> oh wait what do you mean by -g ? make -g -f makefile.whatever?
192 2012-09-18 11:51:46 <knotwork> its doing normal make right now what is this -g thing you mentioned?
193 2012-09-18 11:51:59 <gavinandresen> knotwork: I usually cp makefile.whatever makefile.local, then edit makefile.local to replace -O3 with -g , then make -f makefile.local
194 2012-09-18 11:52:29 <gmaxwell> gavinandresen: But we're using -O2 -g ...
195 2012-09-18 11:52:31 <andyrossy> CCFLAGS=-g make -f makefile.unix bitcoind
196 2012-09-18 11:52:39 <knotwork> ahh ok my makefile is makefile.fedora16 which tells it how to find specially compiled openssl and so on
197 2012-09-18 11:53:16 <andyrossy> you're using fedora?
198 2012-09-18 11:53:24 <knotwork> fedora 16 on 64 bit machine yes
199 2012-09-18 11:53:30 <gmaxwell> gavinandresen: and gdb is confused sometimes by O2 too, O3 somewhat more often. Though it's gotten a little better with more recent GCC versions (better symbols)
200 2012-09-18 11:53:31 <gavinandresen> gmaxwell: ACK. I was thinking of makefile.osx which uses -O3
201 2012-09-18 11:53:45 <andyrossy> just use makefile.unix
202 2012-09-18 11:53:48 <andyrossy> a lot of the fedora files
203 2012-09-18 11:53:50 <andyrossy> havnt been maintained afaik
204 2012-09-18 11:54:14 <knotwork> makefile.unix doesnt know that the openssl that has elliptic curves enabled is in ../../deps
205 2012-09-18 11:54:42 <knotwork> it also doesnt have -mt set for boots suffix
206 2012-09-18 11:54:49 <otimm> Fedora: breaking source code & compilings since 2003
207 2012-09-18 11:54:51 <knotwork> boost
208 2012-09-18 11:55:11 <gmaxwell> knotwork: we have a variable for that.
209 2012-09-18 11:55:16 <gmaxwell> knotwork: e.g. BOOST_LIB_SUFFIX='-mt' make -j4 -f makefile.unix bitcoind USE_UPNP=
210 2012-09-18 11:55:17 <helo> congrats on the release
211 2012-09-18 11:55:32 <epscy> gavinandresen: was the release the announcement?
212 2012-09-18 11:55:32 <gmaxwell> But not for openssl... personally I just replace the system openssl with a dehobbled one.
213 2012-09-18 11:55:54 <knotwork> gmax I'd never remember all that thats what makefiles are for
214 2012-09-18 11:56:16 <gmaxwell> knotwork: can you diff -u the makefile you're using it and pastebin?
215 2012-09-18 11:56:50 <gavinandresen> epscy: I don't want to talk about The Announcement, if I knew hinting that there was something coming would cause so much speculation I woulda taken a vow of silence and duct-taped my mouth shut
216 2012-09-18 11:56:57 <andyrossy> apt-get install boost-all-dev ?
217 2012-09-18 11:57:06 <andyrossy> or you're building boost yourself? becuase?
218 2012-09-18 11:57:18 <andyrossy> or maybe it's yum or pacman on fedora, never can remember
219 2012-09-18 11:57:24 <epscy> gavinandresen: ok fair enough
220 2012-09-18 11:57:27 <kjj_> heh. kinda sucked that an offhand remark would get picked up by the forum mob and turned into such a huge thing
221 2012-09-18 11:57:43 <gavinandresen> par for the course
222 2012-09-18 11:57:43 <knotwork> http://pastebin.com/Z1YZE6EU
223 2012-09-18 11:58:11 <kjj_> and now I have to go talk to a pair of management consultants that I've nicknamed "The Two Bobs"
224 2012-09-18 11:58:38 <helo> is there an example of createrawtransaction somewhere?
225 2012-09-18 11:58:45 <gavinandresen> kjj_ don't forget to bring your red stapler.
226 2012-09-18 11:58:50 <helo> i just get error parsing json
227 2012-09-18 11:59:19 <helo> i'm not sure where quotes are required
228 2012-09-18 11:59:25 <gavinandresen> helo: using the Qt RPC window ?
229 2012-09-18 11:59:34 <gmaxwell> knotwork: okay, that doesn't appear to be the source of your problems. Can you run bitcoind inside gdb now? e.g. gdb ./bitcoind -daemon=0 <enter> run <enter>
230 2012-09-18 11:59:42 <knotwork> so anyeay, tl;dr is, my already built bitcoind already has -g mode?
231 2012-09-18 12:00:10 <sipa> gmaxwell: gdb doesn't take program arguments afaik
232 2012-09-18 12:00:12 <gmaxwell> helo: http://people.xiph.org/~greg/signdemo.txt (I need to finish up these examples and publish them, not that 0.7 is out)
233 2012-09-18 12:00:24 <helo> gavinandresen: yes
234 2012-09-18 12:00:26 <helo> gmaxwell: thanks
235 2012-09-18 12:00:30 <knotwork> -daemon=0 ? how will that help? its the daemon thats segfaulting
236 2012-09-18 12:00:35 <sipa> so gdb ./bitcoind <enter> run -daemon=0 <enter>
237 2012-09-18 12:00:44 <gavinandresen> I was trying to do some raw transaction stuff in the Qt window last night and failed....
238 2012-09-18 12:00:47 <sipa> knotwork: "daemon" just means "program running in the background"
239 2012-09-18 12:00:50 <_dr> just gdb ./bincoind then on the gdb prompt run <params>
240 2012-09-18 12:00:55 <sipa> knotwork: -daemon means it doesn't background
241 2012-09-18 12:00:56 <gmaxwell> erp sorry. gdb --args ./bitcoind -daemon=0
242 2012-09-18 12:01:08 <sipa> eh -daemon=0
243 2012-09-18 12:01:17 <gmaxwell> (good morning!)
244 2012-09-18 12:01:47 <knotwork> all my ports addresses etc are in the start.sh script that usually starts it
245 2012-09-18 12:02:13 <gmaxwell> knotwork: erp. why aren't they in your bitcoin.conf? in any case you can gdb --args ./bitcoin -daemon=0 {your crap}
246 2012-09-18 12:02:22 <knotwork> oh no real bitcoin only sets user and pass and -gen=0 -daemon -resca
247 2012-09-18 12:02:30 <gmaxwell> or alternatively gdb ./bitcoind <enter> run -daemon=0 {your crap}
248 2012-09-18 12:02:34 <sipa> why -rescan?
249 2012-09-18 12:03:07 <knotwork> without rescan sometimes it turns out it needs a rescan following power corp implemented reboot for example
250 2012-09-18 12:03:15 <gmaxwell> That open is a trap. It should be renamed --debug-option-frobnisticator1
251 2012-09-18 12:03:32 <gmaxwell> knotwork: How do you know it needs a rescan?
252 2012-09-18 12:03:34 <helo> the debug console 'help' needs to show the proper escapes/quoting required
253 2012-09-18 12:03:46 <gavinandresen> helo: ah, figured it out.... two things were tripping me up
254 2012-09-18 12:03:54 <knotwork> I dont, so I do it ever time I fire up machine aka every time I start bitcoind
255 2012-09-18 12:04:06 <gavinandresen> helo: First, complex JSON objects/arrays must be in single quotes
256 2012-09-18 12:04:07 <helo> i need quotes around "everything", and single quotes around each bracket group
257 2012-09-18 12:04:18 <gmaxwell> knotwork: how did you know the first time?
258 2012-09-18 12:04:20 <gavinandresen> helo: and second, you have to remove spaces inside the single quotes
259 2012-09-18 12:04:26 <knotwork> since I hope most times it reboots I will not be present to worry about what needs rescan and what does not
260 2012-09-18 12:04:44 <helo> gavinandresen: good to know, thanks
261 2012-09-18 12:05:17 <knotwork> I ran pretty much every altcoin ever made, somewhere along the line of dealing with umpteen *coin daemons i found it easiest to just always do rescan
262 2012-09-18 12:05:38 <gmaxwell> knotwork: I mean, what failure mode were you trying to fix?
263 2012-09-18 12:05:50 <sipa> knotwork: since 0.3.21, it *should* store the last seen block in the wallet, and automatically rescan at startup from that point
264 2012-09-18 12:06:07 <gavinandresen> I wonder if json_spirit has a parse-from-stream mode, it would be nice if the format in the Qt debug window was just properly-formatted-json separated by whitespace
265 2012-09-18 12:06:16 <sipa> knotwork: -rescan just overrides that by assuming the wallet has only seen the genesis block
266 2012-09-18 12:06:19 <knotwork> I dont know, but once upon a time rescans used to fix something so I made it just do them so I would not have to wonder if a rescan would fix whatever new problem happened
267 2012-09-18 12:06:42 <sipa> the only time when -rescan is required is if you manually play with wallet.dat (using bdb tools)
268 2012-09-18 12:06:45 <sipa> or python scripts
269 2012-09-18 12:06:58 <knotwork> oh yeah, one use case is, ./coinstop.sh; replace wallet with other wallet; ./coinstart.sh
270 2012-09-18 12:07:07 <sipa> even that should just work
271 2012-09-18 12:07:31 <knotwork> oh new wallet no longer requires rescan? since what version? (some alts are still pretty old version)
272 2012-09-18 12:07:37 <sipa> 0.3.21
273 2012-09-18 12:08:00 <knotwork> hmm even most alts might not need rescan for wallet change then. cool
274 2012-09-18 12:08:48 <knotwork> once upon a time I had to stop daemon just to make copy of wallet, until the backup wallet rpc was added
275 2012-09-18 12:08:48 <sipa> oh... we didn't update the built-in seeds for 0.7
276 2012-09-18 12:08:59 <gavinandresen> helo: be very careful with the raw transaction API, it is easy to create transactions with huge fees and there are no training wheels to keep you from making a miner really happy
277 2012-09-18 12:09:32 <gavinandresen> sipa: I meant to ask nanotube if he could do that.
278 2012-09-18 12:09:52 <helo> is a gui planned for {create,sign,send}rawtransaction? maybe file-based for shuttling the data between offline/online machines?
279 2012-09-18 12:10:15 <sipa> gavinandresen: i have a script that produces such a list based on the output(s) of my crawler
280 2012-09-18 12:10:56 <knotwork> hmm p2pool is finally actually talking to bitcoind now instead of segfaulting it
281 2012-09-18 12:11:09 <gmaxwell> knotwork: what changed?
282 2012-09-18 12:11:10 <knotwork> so I wont kill it right now to do the gdb thing
283 2012-09-18 12:11:30 <knotwork> nothing changed, its third time lucky I guess, third time I started it, after two segfaults
284 2012-09-18 12:11:43 <_dr> with gdb?
285 2012-09-18 12:11:52 <helo> gavinandresen: not with my balance :P
286 2012-09-18 12:11:53 <knotwork> no gdb
287 2012-09-18 12:12:08 <knotwork> as I had already restarted it before coming to report the segfault
288 2012-09-18 12:12:37 <gmaxwell> I've had two p2pool miners running against 0.7(rcs) for weeks now, and are now running the final release. Hmph. I've also been running getinfo loops since this conversation started, no crashes.
289 2012-09-18 12:12:45 <gmaxwell> knotwork: did it crash _right_ at startup?
290 2012-09-18 12:12:45 <knotwork> as its taken hours justs to try to get everything up and running since the hours ago reboot - uptime 2:26
291 2012-09-18 12:13:05 <drizztbsd> hi, what is the md5 or sha256sum of https://github.com/bitcoin/bitcoin/tarball/v0.7.0 ?
292 2012-09-18 12:13:07 <knotwork> no, for long time it added addresses to wallet during rescan
293 2012-09-18 12:13:19 <drizztbsd> I need to check it before committing in archlinux :)
294 2012-09-18 12:13:27 <knotwork> while p2pool just kept complaming how long its been since it last heard from bitcoind
295 2012-09-18 12:13:41 <knotwork> meanwhile all the merged chains cannot mine until bitcoind is working
296 2012-09-18 12:13:49 <gmaxwell> drizztbsd: er... all we can do is just fetch that from github too. Github builds that tarball.
297 2012-09-18 12:13:58 <drizztbsd> I know
298 2012-09-18 12:14:16 <gmaxwell> drizztbsd: sounds like cargocult security. :-/
299 2012-09-18 12:14:17 <sipa> if you want a cryptographically secured download, use git itself
300 2012-09-18 12:14:18 <drizztbsd> the source code is not present in source forge repository
301 2012-09-18 12:14:27 <drizztbsd> file repository*
302 2012-09-18 12:14:33 <gmaxwell> drizztbsd: it's part of the linux download.
303 2012-09-18 12:14:40 <knotwork> it didnt even crash on first calls to getblock, I saw at least 4 getblocks in the log before that last line of the log one
304 2012-09-18 12:14:47 <drizztbsd> yes, but it's 12MB :P
305 2012-09-18 12:14:58 <drizztbsd> should I use it?
306 2012-09-18 12:15:14 <drizztbsd> for safety
307 2012-09-18 12:15:53 <sipa> if you want to build from source, use git
308 2012-09-18 12:16:10 <sipa> if you want binaries, use the provided ones
309 2012-09-18 12:16:55 <knotwork> the weird lagging I was experiencing has gone away too. I was getting lag even of keystroke echo periodically
310 2012-09-18 12:17:20 <knotwork> since that went away when I killed the bitcoind I suppose it could be related
311 2012-09-18 12:17:47 <knotwork> though free and top and ps didnt show any clue what could be lagging or why nor did dmesg nor /var/log/messages
312 2012-09-18 12:18:02 <knotwork> except that dmesg and the messages log did show me that bitcoind had segfaulted
313 2012-09-18 12:18:37 <knotwork> oh and befgore that mesages log showed constant attempts to use fingerprint reader so I turned that off but lagging didnt go away
314 2012-09-18 12:19:09 <knotwork> it was when I turned that off that next thing in log or around that time in log entry showed first bitcoind segfault
315 2012-09-18 12:19:25 <knotwork> so I wondered did disbling fingerprint reader kill bitcoind
316 2012-09-18 12:19:55 <knotwork> (fingerprint reader does sound like something bitcoin would like though bitcoind ought not expect anyone to be present)
317 2012-09-18 12:39:46 <jeremias> where is debug.log?
318 2012-09-18 12:39:59 <sipa> in the same place as wallet.dat is
319 2012-09-18 12:40:23 <sipa> https://en.bitcoin.it/wiki/Data_directory
320 2012-09-18 12:40:29 <jeremias> server=1 daemon=1 proxy=127.0.0.1:9050
321 2012-09-18 12:40:44 <sipa> and tor is running on that port?
322 2012-09-18 12:40:46 <jeremias> ERROR: Proxy error: TTL expired
323 2012-09-18 12:40:48 <jeremias> yep
324 2012-09-18 12:41:08 <sipa> tor needs some time to find outgoing routes
325 2012-09-18 12:41:13 <gavinandresen> sipa: now that 0.7.0 final is out, do you think there's any reason to bump the client version number? With the new get-subversion-info-from-git code I'm not sure there is....
326 2012-09-18 12:41:14 <jeremias> I'll restart tor
327 2012-09-18 12:41:18 <gmaxwell> how long has tor been running and is your clock correct?
328 2012-09-18 12:41:30 <jeremias> hooray, got one connection
329 2012-09-18 12:42:00 <jeremias> clock seems to be correct
330 2012-09-18 12:42:18 <jeremias> hmm now at one connection, let's see if I get more
331 2012-09-18 12:42:20 <jeremias> thanks guys
332 2012-09-18 12:42:28 <sipa> gavinandresen: client version numbers are still used in the wallet to determine features
333 2012-09-18 12:44:31 <gavinandresen> sipa: ok. so bumping version to 0.7.0.99 now might save us some heartache if we commit wallet format changes
334 2012-09-18 12:44:39 <sipa> right; indeed
335 2012-09-18 12:44:58 <sipa> it's also used in alert messages, no?
336 2012-09-18 12:45:16 <gavinandresen> sipa: yes, good point
337 2012-09-18 12:45:32 <kjj_> how hard is it to set up a bitcoin build environment for Windows?
338 2012-09-18 12:45:53 <gmaxwell> kjj_: very easy, ... first, install linux in a VM ... :P
339 2012-09-18 12:46:02 <kjj_> haha
340 2012-09-18 12:46:10 <sipa> gavinandresen: oh, seems alerts still function on network version and not client version
341 2012-09-18 12:46:31 <gavinandresen> kjj_: hard bit is getting all the dependencies built correctly...
342 2012-09-18 12:46:32 <sipa> not sure what the reasoning was for that
343 2012-09-18 12:46:35 <jeremias> hmm, seems to stay at 1 connections :/
344 2012-09-18 12:49:46 <gavinandresen> kjj_: hopelessly out of date, but: https://github.com/bitcoin/bitcoin/blob/v0.3.24/src/makefile.vc
345 2012-09-18 12:50:17 <gavinandresen> kjj_: and https://github.com/bitcoin/bitcoin/blob/v0.3.24/doc/build-msw.txt
346 2012-09-18 12:51:18 <kjj_> ok. I hope I don't regert this later, but I'll take a look
347 2012-09-18 12:51:30 <kjj_> are the windows builds really done through a VM today?
348 2012-09-18 12:51:44 <sipa> yes
349 2012-09-18 12:51:49 <sipa> a _linux_ VM
350 2012-09-18 12:52:28 <kjj_> wouldn't a regular linux box work just as well? or do you need to fuck it up to make the build work?
351 2012-09-18 12:53:05 <gavinandresen> kjj_: we build in a VM to get bit-for-bit-identical builds
352 2012-09-18 12:53:05 <sipa> the VM is not to make it work (if anything, it complicates things); it's to make sure the builds are deterministic (byte-for-byte reproducible)
353 2012-09-18 12:53:20 <sipa> gavinandresen even goes to the bit level!
354 2012-09-18 12:53:24 <kjj_> ahh, ok
355 2012-09-18 12:53:39 <kjj_> that is a distribution requirement, not necessary for some dude building his own at home
356 2012-09-18 12:53:45 <gavinandresen> right
357 2012-09-18 12:53:55 <sipa> sure, we have a makefile.mingw-linux
358 2012-09-18 12:54:13 <sipa> if you have the necessary dependencies, that should work for creating a windows binary on linux
359 2012-09-18 12:54:16 <sipa> without gitian
360 2012-09-18 12:54:24 <sipa> i never bothered trying to set that up, though
361 2012-09-18 12:54:33 <kjj_> are there any docs on this process?
362 2012-09-18 12:54:45 <sipa> yeah, you poke BlueMatt
363 2012-09-18 12:55:17 <gavinandresen> contrib/gitian-descriptors/gitian-win32.yml has the script that is run to do the build
364 2012-09-18 12:55:48 <kjj_> is there a need for more VM builders?
365 2012-09-18 12:55:50 <gavinandresen> (other -win32.yml files in that folder are the scripts to build dependencies)
366 2012-09-18 12:56:00 <gavinandresen> kjj_: yes, more VM builders are welcome.
367 2012-09-18 12:56:09 <kjj_> welcome, or needed?
368 2012-09-18 12:56:24 <gavinandresen> kjj_: needed. See the README in the gitian-descriptors file for how to get setup
369 2012-09-18 12:56:48 <kjj_> ok. I'll check that out too
370 2012-09-18 13:45:07 <Greee> what are nodes?
371 2012-09-18 13:50:23 <JFK911> thats where a leaf grows out of the stem
372 2012-09-18 13:57:20 <DBordello> -loadblock is not a fun process, it is bringing my server to its knees
373 2012-09-18 13:57:22 <DBordello> and it is slow
374 2012-09-18 14:01:21 <gmaxwell> DBordello: "get a faster VPS"
375 2012-09-18 14:02:08 <sipa> DBordello: if it's any confort: on BDB, importing the entire blockchain took over a day on my VPS; with leveldb it was close to 1 hour
376 2012-09-18 14:03:02 <DBordello> gmaxwell, probably true, but it is sufficient once blockchaind is all bootstrapped
377 2012-09-18 14:03:07 <DBordello> sipa, is leveldb in the future?
378 2012-09-18 14:03:15 <BlueMatt> kjj_: if you want to build using makefile.linux-mingw and something isnt working when trying to execute the build script from gitian manually, ping me, and we can see whats up
379 2012-09-18 14:03:19 <sipa> DBordello: yes
380 2012-09-18 14:03:39 <DBordello> I don't like the downtime, I might just sync the old fashion way after this gets far enough
381 2012-09-18 14:03:41 <gavinandresen> bootstrap on another machine running with -detachdb then copy over the data dir....
382 2012-09-18 14:04:02 <DBordello> gavinandresen, not a bad idea
383 2012-09-18 14:04:08 <sipa> DBordello: you mean from network? that's certainly slower than loadblock
384 2012-09-18 14:04:26 <DBordello> Is it safe to stop -loadblock with ctrl-c?
385 2012-09-18 14:04:43 <DBordello> sipa, yes, but bitcoind responds to API calls during that
386 2012-09-18 14:04:52 <arij> herro can some one look at the tx for me it hasn't confirmed in over 3 blocks :( http://blockchain.info/tx-index/24419676/b36e7385fa44f6ad3904cdedf63c24ac1d832d9903d7c56821ffb54cdcbfae17
387 2012-09-18 14:04:54 <DBordello> So I don't appear to be (as) down
388 2012-09-18 14:04:56 <arij> thanks
389 2012-09-18 14:05:20 <DBordello> What is required to properly bootstrap? Wallet.dat?
390 2012-09-18 14:05:27 <gmaxwell> arij: your input is unconfirmed.
391 2012-09-18 14:05:39 <jgarzik> hum
392 2012-09-18 14:05:45 <jgarzik> forum still down?
393 2012-09-18 14:05:50 <arij> i think i understand
394 2012-09-18 14:05:59 <arij> the previous tx that got sent to me is unconfirmed?
395 2012-09-18 14:06:01 <gmaxwell> arij: bitcoin will work better for you if you don't use dice. It gunks up your wallet.
396 2012-09-18 14:06:07 <arij> LOL your smart
397 2012-09-18 14:06:21 <arij> now i have to suffer the consequences
398 2012-09-18 14:07:23 <gmaxwell> arij: and the parent of _that_ transaction is unconfirmed. I have no idea how far back that chain goes... you may be waiting a while.
399 2012-09-18 14:08:08 <arij> alright
400 2012-09-18 14:08:19 <arij> well the .5 that i sent was confirmed afaik
401 2012-09-18 14:08:25 <arij> like 70+ times
402 2012-09-18 14:08:46 <sipa> DBordello: yes, you can kill bitcoin safely during loadblock
403 2012-09-18 14:09:03 <sipa> DBordello: how do you mean what is needed to properly bootstrap?
404 2012-09-18 14:09:20 <sipa> wallet.dat is your wallet, there isn't any resource-intensive stuff in there
405 2012-09-18 14:09:30 <DBordello> sipa, I assume bootstraping on another machine without your wallet.dat wouldn't be helpful, that is why I can't just download the datadir?
406 2012-09-18 14:10:20 <sipa> DBordello: on anoter machine: run bitcoind until IBD is done, stop it, start it again with -detachdb, exit, copy the blk* files over; done
407 2012-09-18 14:10:39 <DBordello> Okay
408 2012-09-18 14:10:44 <sipa> if the new machine already had a wallet, it should rescan automatically
409 2012-09-18 14:10:48 <sipa> if it doesn't, use -rescan
410 2012-09-18 14:11:05 <DBordello> Okay
411 2012-09-18 14:11:44 <DBordello> I am trying to upgrade from 0.6.99 (git) to 0.7. It won't start with the same db, (barfs with a db error). So I guess doing a clean bootstrap with 0.70 on another box is probably the best route, with the shortest downtime
412 2012-09-18 14:13:24 <jgarzik> MagicalTux: forum getting DDoS'd?
413 2012-09-18 14:19:23 <DBordello> Wow, the new bootstrap is impressive (on a decent machine). First 100k blocks flew
414 2012-09-18 14:21:08 <DBordello> Although those are probably the easy ones
415 2012-09-18 14:22:54 <jgarzik> DBordello: 0.7 or ultraprune?
416 2012-09-18 14:23:11 <jgarzik> DBordello: yeah, first 120k blocks fly by even on my slow pynode implementation
417 2012-09-18 14:24:50 <gavinandresen> ah, the good old days, when blocks were empty and bitcoins only cost a nickel....
418 2012-09-18 14:24:56 <DBordello> jgarzik, 0.7
419 2012-09-18 14:25:23 <DBordello> Ah yes, now things are grinding to a hault
420 2012-09-18 14:25:28 <jgarzik> hehehe
421 2012-09-18 14:26:32 <DBordello> The difficulty alone lets you know where you stand in time
422 2012-09-18 14:27:52 <DBordello> What files do I need to transfer between machines? Just blk*?
423 2012-09-18 14:28:34 <gmaxwell> DBordello: the whole directory save the wallet. Ideally. Though if you detached and the remote side doesn't have a database/ then just the blk files should work.
424 2012-09-18 14:29:22 <elkingrey> For the last several releases, I've been unable to get my Bitcoin toolbar to work. I run Ubuntu. Any suggestions?
425 2012-09-18 14:30:42 <DBordello> gmaxwell, okay
426 2012-09-18 14:30:45 <DBordello> Thank you
427 2012-09-18 15:27:34 <diki> phew, took me a while to figure out how to compute the public key in openssl but finally did it.
428 2012-09-18 15:28:37 <jgarzik> heh
429 2012-09-18 15:28:47 <jgarzik> wonder if anybody has ever worked on distributed forum software
430 2012-09-18 15:29:20 <jgarzik> I bet the entire bitcointalk dataset, all the wikitext and metadata, would be under 300MB compressed
431 2012-09-18 15:30:13 <jgarzik> administrative control occurs via crypto-signed metadata
432 2012-09-18 15:31:32 <kjj_> heh. we could embed that into the blockchain. /me ducks
433 2012-09-18 15:38:05 <SomeoneWeird> lawl kjj_
434 2012-09-18 15:59:13 <gavinandresen> sipa: so I'm working on making the wallet-loading code as tolerant as possible of wallet corruption, and am running into a problem with openssl's i2o_ECPublicKey() ...
435 2012-09-18 16:00:24 <gavinandresen> sipa: Is there an OpenSSL routine that can check if keys are ok? I randomly corruputed a test wallet, and i2o_ECPublicKey is crashing hard with EXC_BAD_ACCESS
436 2012-09-18 16:00:40 <gavinandresen> sipa: (not throwing an exception I can catch)
437 2012-09-18 16:02:21 <maaku> on the Coinbaser wiki entry, it says: ???Note that distributing all the available funds is undefined behaviour; remaining funds are generated to the original destination, and treated in the usual way??? <-- can anyone translate what that means? is one not allowed to use a coinbaser script to distribute all funds? is this a bug?
438 2012-09-18 16:04:21 <jgarzik> need a private wallet append-only wallet format, where each record is protected by Hash()
439 2012-09-18 16:09:02 <sipa> gavinandresen: how do you mean "crashing hard"
440 2012-09-18 16:09:32 <gavinandresen> Program received signal EXC_BAD_ACCESS, Could not access memory.
441 2012-09-18 16:10:12 <sipa> gavinandresen: in my canonical branch there is a test for public keys and signatures, that doesn't use openssl
442 2012-09-18 16:12:00 <kjj_> good to know that the OpenSSL guys still think it is funny to never check inputs
443 2012-09-18 16:12:36 <gavinandresen> sipa: ok, I'll take a look
444 2012-09-18 16:28:57 <gavinandresen> sipa: I think EC_KEY_check_key() is what I want....
445 2012-09-18 16:41:12 <diki> My cumulative difficulty of all the hashes I found in solo is just ~40k...
446 2012-09-18 16:54:25 <shamoon> i want to get involved in developing the bitcoin project. i know it's open source and everyone will tell me to dive right in and get a pull request going, but i want to tackle the low lying fruit. if there's any issues that maybe i can get started with?
447 2012-09-18 16:55:19 <lianj> shamoon: https://github.com/bitcoin/bitcoin/issues
448 2012-09-18 16:55:36 <shamoon> i saw that
449 2012-09-18 16:55:43 <shamoon> but there's so many, and i'm not sure which matter
450 2012-09-18 16:55:44 <shamoon> or don't
451 2012-09-18 16:56:05 <diki> dont they all matter?
452 2012-09-18 16:57:55 <shamoon> i'm not sure.
453 2012-09-18 16:57:57 <shamoon> that's why i'm here =)
454 2012-09-18 16:59:54 <gmaxwell> shamoon: what parts of the project interest you?
455 2012-09-18 17:00:20 <shamoon> philosophically, the whole concept of decentralized stores of value
456 2012-09-18 17:00:25 <gmaxwell> Really, beyond working on what interest you, also equally good is finding a bug and fixing it.
457 2012-09-18 17:00:30 <shamoon> technically, the way blocks / transactions interact
458 2012-09-18 17:00:38 <gmaxwell> (just as getting started stuff)
459 2012-09-18 17:00:47 <shamoon> ahhh
460 2012-09-18 17:00:53 <shamoon> probably small UI tweaks
461 2012-09-18 17:00:56 <shamoon> to get started
462 2012-09-18 17:01:11 <gmaxwell> And there are plenty of small bugs. UI issues, etc.
463 2012-09-18 17:01:36 <diki> Yes, I noticed that if you stop the client the icon still stays in the tray until you hover over it.
464 2012-09-18 17:01:52 <shamoon> things like https://github.com/bitcoin/bitcoin/issues/785
465 2012-09-18 17:01:53 <shamoon> ?
466 2012-09-18 17:01:54 <eian> lianj, have you ever used thrust? (part of nvidia's cuda tools)
467 2012-09-18 17:01:58 <gmaxwell> Although we do prever people don't bother with opening a bunch of utterly trivial changes "removes whitespace from menu items", especially from newer contributors; simply because every patch has a review overhead.
468 2012-09-18 17:02:18 <shamoon> how do i know if it's a "proposed" issue is an ACTUAL issue?
469 2012-09-18 17:02:25 <gmaxwell> shamoon: that sort of thing sounds okay.. though you'll get pulled into the mess of the URI handling. :)
470 2012-09-18 17:03:05 <gmaxwell> shamoon: As an outsider it can sometimes be hard to tell. Look at who comments on it, and who opened it. Follow other changes that go in... etc.
471 2012-09-18 17:03:22 <sipa> gavinandresen: that sounds like checking a public key, not its encoding
472 2012-09-18 17:03:36 <gmaxwell> shamoon: and well, if you do something and post a pull and the core devs say "huh? that wasn't in issue NAK" you still learned about the codebase. Life goes on. :)
473 2012-09-18 17:03:49 <shamoon> NAK?
474 2012-09-18 17:06:02 <otimm> http://en.wikipedia.org/wiki/NAK_(protocol_message)
475 2012-09-18 17:06:13 <gmaxwell> shamoon: as in "thanks but no thanks"
476 2012-09-18 17:06:18 <shamoon> gotcha
477 2012-09-18 17:06:32 <shamoon> gmaxwell: so you suggest i just do it, send a pull request
478 2012-09-18 17:06:35 <shamoon> and see what happens?
479 2012-09-18 17:06:41 <shamoon> is there a roadmap of any kind?
480 2012-09-18 17:07:23 <gmaxwell> shamoon: There is a set of more concrete shorter term things, mostly tracked with issues and pull requests. And longer things which are somewhat vague and the product of discussion in here mostly.
481 2012-09-18 17:08:09 <midnightmagic> Hey jgarzik do you happen by any chance to know what specific kernel RH 6.3 is using as a base? Like if I grabbed linux-2.6.32.59.tar.gz for example..
482 2012-09-18 17:08:45 <jgarzik> midnightmagic: I'm more on the upstream kernel (torvalds/linux.git), so don't know off the top of my head
483 2012-09-18 17:09:00 <jgarzik> midnightmagic: it's super-heavily patched to import newer APIs etc.
484 2012-09-18 17:10:24 <jgarzik> 09/18/12 19:09:48 SetBestChain: new best=000000000000014aeff9 height=199425 work=486524885632842252268 date=09/18/12 19:28:45
485 2012-09-18 17:10:26 <jgarzik> huh
486 2012-09-18 17:10:43 <jgarzik> I always thought block A time > block A+1 time was illegal
487 2012-09-18 17:11:00 <jgarzik> I know about the time range validity, but nonetheless...
488 2012-09-18 17:11:27 <BlueMatt> nope, never was (afaik)
489 2012-09-18 17:11:42 <BlueMatt> (just has to be > median of last N blocks)
490 2012-09-18 17:11:50 <midnightmagic> jgarzik: Yes, and I have a src.rpm here, but I'm looking to do a kernel-wide diff to see what they've done to it..
491 2012-09-18 17:11:52 <gmaxwell> jgarzik: no, and if it was it would have a lot of nasty negative consequences.
492 2012-09-18 17:12:17 <gmaxwell> jgarzik: like when you mine a block you could mine it right against the 2 hour limit and thus force anyone who builds on you to also do so.
493 2012-09-18 17:12:18 <midnightmagic> jgarzik: I think it's just limited by +/- 2 hours.
494 2012-09-18 17:12:30 <jgarzik> gmaxwell: ah, makes sense
495 2012-09-18 17:12:50 <gmaxwell> midnightmagic: it's clamp(median(last11)+1,now,now+2hrs)
496 2012-09-18 17:12:56 <midnightmagic> jgarzik: Thanks anyway.
497 2012-09-18 17:15:18 <jgarzik> trailing whitespace trimmed, 44 bytes total.
498 2012-09-18 17:15:31 <jgarzik> not the horror show predicted
499 2012-09-18 17:16:14 <jgarzik> 09/18/12 19:15:05 ERROR: CTxMemPool::accept() : not enough fees 5bf6ba2041, 0 < 10000
500 2012-09-18 17:16:15 <jgarzik> 09/18/12 19:15:05 ERROR: CTxMemPool::accept() : not enough fees 746aa55776, 0 < 10000
501 2012-09-18 17:16:37 <jgarzik> logging is much better for this case, now. we have the txid rejected, and the fees provided versus wanted
502 2012-09-18 17:16:55 <eian> My foreman grill just ruined 4 hamburgers. I am not pleased
503 2012-09-18 17:17:00 <gmaxwell> if only I could look up that transaction!
504 2012-09-18 17:17:27 <lianj> btw, with ECDSA_SIG_recover_key_GFp why is the pubkey still passed? would it be too slow? or a big protocol change?
505 2012-09-18 17:17:39 <lianj> jgarzik: thats only the fee wanted for relaying though
506 2012-09-18 17:17:44 <eian> gmaxwell, what is stopping your from looking them up?
507 2012-09-18 17:17:50 <jgarzik> lianj: correct
508 2012-09-18 17:17:53 <gmaxwell> lianj: because it would be major protocol change.
509 2012-09-18 17:17:54 <eian> (I claim completely ignorance)
510 2012-09-18 17:18:04 <jgarzik> eian: if the tx is rejected, it is not present to look up
511 2012-09-18 17:18:15 <eian> If it was relayed to me, I have it :)
512 2012-09-18 17:18:18 <gmaxwell> eian: we can only do looking by exact txid, not prefix. (for reasonable and prudent reasons)
513 2012-09-18 17:18:20 <jgarzik> nevertheless it is better than not logging + dropping
514 2012-09-18 17:18:38 <jgarzik> gmaxwell: would you prefer full txid? that is easy enough.
515 2012-09-18 17:18:42 <lianj> jgarzik: i would lke an option to print full hashes. have a hard coded branch for myself now, but thats pretty ugly
516 2012-09-18 17:19:14 <gmaxwell> jgarzik: I do. In all cases, and patch my own nodes to log them... but I think I was outnumbered on some pull request that twiddled the lenghts.
517 2012-09-18 17:20:05 <eian> jgarzik, what time zone is 19:15:05 - I want to try and look up the tx
518 2012-09-18 17:20:39 <jgarzik> eian: my local timezone, where the node that generated the above log lives, is US-Eastern
519 2012-09-18 17:20:50 <midnightmagic> gmaxwell: I thought that pull request went through?
520 2012-09-18 17:20:53 <lianj> maybe just exchange .substr(0,10) with .substr(0,[tx|block]_sublength) all over and have it default to 10,20 and the full hash length if a commandline option is set
521 2012-09-18 17:20:57 <midnightmagic> gmaxwell: That's the one I commented on wasn't it?
522 2012-09-18 17:21:21 <eian> jgarzik - are those hex digits a tx hash prefix or suffix
523 2012-09-18 17:21:26 <eian> I want to try and look this thing up
524 2012-09-18 17:21:40 <jgarzik> eian: hash.ToString().substr(0,10).c_str()
525 2012-09-18 17:21:47 <eian> thanks
526 2012-09-18 17:21:50 <eian> let me try this
527 2012-09-18 17:22:47 <jgarzik> w00t
528 2012-09-18 17:22:53 <gmaxwell> "meh" on configurability. It's easy enough to change if you're 'advanced'. But even that doesn't help you when someone else gives you log messages to help them with. :)
529 2012-09-18 17:23:03 <MC-Eeepc> wait
530 2012-09-18 17:23:07 <jgarzik> my laptop w/ 16GB RAM arrived in the office!
531 2012-09-18 17:23:16 <MC-Eeepc> built in and supported p2pool in satoshi?
532 2012-09-18 17:23:34 <jgarzik> MC-Eeepc: that refers to getmemorypool -> getblocktemplate/submitblock
533 2012-09-18 17:25:11 <jgarzik> gmaxwell: there, FTFY
534 2012-09-18 17:25:27 <midnightmagic> gmaxwell: A prefix search I guess is the "i'm on a horse" solution to that..
535 2012-09-18 17:26:23 <gmaxwell> midnightmagic: prefix search sucks. requires less space efficient indexes for no real gain.
536 2012-09-18 17:26:23 <jgarzik> it is a prefix no more, in git HEAD
537 2012-09-18 17:26:48 <MC-Eeepc> jgarzik is that good
538 2012-09-18 17:26:54 <gmaxwell> <3
539 2012-09-18 17:27:22 <midnightmagic> gmaxwell: Well.. gain of helping users with their debug.logs and also being able to look up random comments in irc.
540 2012-09-18 17:27:30 <midnightmagic> but I know what you mean
541 2012-09-18 17:27:35 <jgarzik> gmaxwell: many times it is only a prefix for pretty logs. if there is diagnostic value, by all means, point out places where logging the full txid is preferred.
542 2012-09-18 17:27:54 <jgarzik> e.g. CTxMemPool::accept() : accepted ad125b8779 (poolsz 56)
543 2012-09-18 17:27:57 <eian> jgarzik, I need to rummage through a bunch of files - it would help if I knew what country the 19:15:05 time was taken so that I can convert to EST on my end
544 2012-09-18 17:28:01 <jgarzik> we accepted it, so prefix search is easy
545 2012-09-18 17:28:18 <jgarzik> but for tx-relay-reject, we do not have the tx. logging full txid makes a lot more sense.
546 2012-09-18 17:28:26 <MC-Eeepc> well grats on .7 release guys
547 2012-09-18 17:28:34 <midnightmagic> yay
548 2012-09-18 17:28:40 <jgarzik> eian: that is the "US" part of "US-Eastern"
549 2012-09-18 17:29:25 <eian> I live in US eastern - the time now is only 15:30 - how did you grab data at 19:15?
550 2012-09-18 17:29:41 <sipa> -logtimestamp logs in gmt, iirc
551 2012-09-18 17:29:44 <lianj> jgarzik: why not have full hashes everywhere, maybe configurable like i suggested above
552 2012-09-18 17:30:05 <sipa> i'm in favor of logging full hashes
553 2012-09-18 17:31:20 <jgarzik> configurable is overkill
554 2012-09-18 17:31:38 <gmaxwell> Agree configurable is overkill.
555 2012-09-18 17:31:43 <jgarzik> unless it is a simple compile-time constant, which the current code needs anyway (if prefixes are to remain)
556 2012-09-18 17:31:56 <jgarzik> compile time constant > substr(0,10) magic numbers
557 2012-09-18 17:32:11 <jgarzik> easier just to remove substr()
558 2012-09-18 17:33:03 <sipa> indeed
559 2012-09-18 17:36:58 <lianj> please for blocks aswell
560 2012-09-18 17:45:18 <gavinandresen> sipa: I was away for a while... RE: EC_KEY_check_key : I'm in the middle of figuring out how to make key.cpp more robust if key data is corrupted
561 2012-09-18 17:46:10 <gavinandresen> sipa: The issue is o2i_ECPublicKey will happily create an invalid EC_KEY* structure if given bad data, so there needs to be a EC_KEY_check_key call in CKey::SetPubKey
562 2012-09-18 17:46:34 <Malophorus> there is a little signed integer issue on the socks5 code in the current client
563 2012-09-18 17:47:02 <Malophorus> signed extension from server can cause a recv of a negative length
564 2012-09-18 17:47:31 <Malophorus> recv should just error out but I'm not sure about that behavior on all OS's
565 2012-09-18 17:48:23 <gmaxwell> lots of DB exceptions being reported from people doing 0.7 updates. :-/
566 2012-09-18 17:48:24 <Malophorus> not a huge problem as one would need a malicious socks proxy and then to convince a client to connect to it
567 2012-09-18 17:52:35 <jgarzik> gmaxwell: corruption newly detected?
568 2012-09-18 17:52:47 <jgarzik> gmaxwell: maybe advice should be to -verify, in such cases
569 2012-09-18 17:53:43 <gmaxwell> jgarzik: I believe its all due to people upgrading without detaching first and BDB being unhappy but its really hard to tell.
570 2012-09-18 17:53:48 <gavinandresen> people upgrading from an Official 0.6.something release?
571 2012-09-18 17:53:48 <jgarzik> checkblocks=0, checklevel=6
572 2012-09-18 17:54:05 <gmaxwell> gavinandresen: or so they say.
573 2012-09-18 17:54:07 <gavinandresen> (I wonder if Luke's unofficial backports are compiled with the same bdb version....)
574 2012-09-18 17:54:14 <jgarzik> we've talked about turning on detachdb again
575 2012-09-18 17:54:18 <gmaxwell> gavinandresen: I was _just_ wondering the same thing...
576 2012-09-18 17:54:20 <jgarzik> safer, but slower
577 2012-09-18 17:54:34 <jgarzik> talked on IRC, at least
578 2012-09-18 17:54:42 <gmaxwell> jgarzik: they're not getting to a point where checkblocks=0, checklevel=6 would help, bdb is croaking out at open time.
579 2012-09-18 17:54:51 <jgarzik> hrm
580 2012-09-18 17:55:13 <gmaxwell> jgarzik: there is a tough tradeoff there, a minutes long (in some cases) shutdown gets the process hard killed on some systems.
581 2012-09-18 17:55:28 <gmaxwell> (and even if the system doesn't they user may assume its hung and kill it manually)
582 2012-09-18 17:55:53 <kjj_> bold warning at the top of the upgrade instructions?
583 2012-09-18 18:01:36 <gmaxwell> e.g. people getting this super informative outcome:
584 2012-09-18 18:01:37 <gmaxwell> Bound to [::]:8333
585 2012-09-18 18:01:38 <gmaxwell> Bound to 0.0.0.0:8333
586 2012-09-18 18:01:40 <gmaxwell> ErrorFile=/home/user/.bitcoin/db.log
587 2012-09-18 18:01:42 <gmaxwell> ************************
588 2012-09-18 18:01:45 <gmaxwell> EXCEPTION: 11DbException
589 2012-09-18 18:01:47 <gmaxwell> Db::open: Invalid argument
590 2012-09-18 18:01:50 <gmaxwell> bitcoin in Runaway exception
591 2012-09-18 18:02:07 <eian> gmaxwell, I found the transactions that had no fees: http://pastebin.com/rkNuhSfT
592 2012-09-18 18:02:14 <gmaxwell> then they go and try the old version which seems to have mixed results; works for some .. keeps failing for others.
593 2012-09-18 18:02:40 <eian> those are the ones jgarzik caught in his logs
594 2012-09-18 18:04:19 <gmaxwell> And lots of
595 2012-09-18 18:04:20 <gmaxwell> BDB2506 file blkindex.dat has LSN 1829/2194603, past end of log at 1/17990
596 2012-09-18 18:04:23 <gmaxwell> BDB2509 the log files from a database environment
597 2012-09-18 18:04:25 <gmaxwell> BDB1579 Database handles still open at environment close
598 2012-09-18 18:04:28 <gmaxwell> in the db.log
599 2012-09-18 18:05:25 <jgarzik> one hopes that TIBANNE-CO-LTD will not go out of business, considering how many bitcoin businesses use that network, however tangentially
600 2012-09-18 18:07:11 <kjj_> silly question... do you tell the database to detach when closing, or when opening?
601 2012-09-18 18:08:45 <jgarzik> sipa: how did leveldb sync mode perform?
602 2012-09-18 18:10:04 <eian> jgarzik, what is special about tibanne?
603 2012-09-18 18:10:22 <MC-Eeepc> maybe it would be interesting if tibanne folded
604 2012-09-18 18:10:41 <MC-Eeepc> if bitcoin came back from it
605 2012-09-18 18:10:50 <jgarzik> eian: tibanne is MagicalTux's ISP. tibanne == mtgox. just noting a large Single Point Of Failure
606 2012-09-18 18:10:58 <eian> ah :)
607 2012-09-18 18:11:32 <c_k> jgarzik: what leads you to think they may go out of business?
608 2012-09-18 18:12:57 <c_k> google news has no hits
609 2012-09-18 18:14:09 <jrmithdobbs> c_k: he didn't say anything did, he just said he hopes it doesn't happen and was pointing out a single point of failure
610 2012-09-18 18:14:25 <c_k> ah, right
611 2012-09-18 18:14:51 <jgarzik> Not saying there's anything wrong with their services. Just noting the community dependence. the forum, the wiki, mtgox itself, a few of my nodes, ...
612 2012-09-18 18:14:59 <c_k> to be honest there are many alternatives to their exchange waiting to fill the vacuum that would be left, when ever one disappears another fills it's void
613 2012-09-18 18:15:22 <jrmithdobbs> jgarzik: i don't like the wiki being hosted there at all
614 2012-09-18 18:15:22 <sipa> jgarzik: didn't benchmark yet; i'm in the middle of packing as i'm moving out next week
615 2012-09-18 18:15:24 <c_k> however it would certainly be concerning if there was a loss associated with their demise
616 2012-09-18 18:16:29 <c_k> I understand it is nice to have things behind their prolexic DDoS protection
617 2012-09-18 18:16:57 <c_k> however there is no real reason why the wiki etc. couldn't be hosted elsewhere in conjunction with CloudFlare
618 2012-09-18 18:17:26 <otimm> maybe it would even beneficial if mt.gox would go away. would create a real necessity for a bitcoin foundation for the wiki etc. to prevent such thing happen again
619 2012-09-18 18:20:41 <Luke-Jr> jgarzik: keep in mind MtGox failing would not necessarily mean Tibanne failing
620 2012-09-18 18:21:36 <kjj_> so, does no one know when the detach option has to be given to the database layer?
621 2012-09-18 18:21:58 <sipa> kjj_: if you want to migrate the database files to another environment
622 2012-09-18 18:22:27 <sipa> kjj_: that includes moving to a new bdb version (that bitcoin may be compiled against), or copying/moving .dat files without the corresponding database/ subdir
623 2012-09-18 18:22:34 <kjj_> what I'm getting at is "can there be a stop-and-detach RPC call, or does the database need to know that a detach will need to be issued when it starts?"
624 2012-09-18 18:22:53 <sipa> right; there could be such a call, but there isn't one right now
625 2012-09-18 18:23:18 <kjj_> ok. that's what I wanted to know. I wasn't sure if it needed to be given when the DB env was opened, or when it got closed
626 2012-09-18 18:24:00 <kjj_> in light of the 0.6.x -> 0.7.0 woes that some people are having, providing that RPC call (and a menu option for the GUI) might be a good idea
627 2012-09-18 18:24:36 <sipa> jgarzik: i did think of a solution that is safe and fast by the way; a separate process that writes out changed blocks and changed block index entries, and every write of the coin database first requiring a flush of said data
628 2012-09-18 18:24:42 <sipa> jgarzik: but that's a larger refactor
629 2012-09-18 18:25:29 <sipa> as there is no reason to block while even the block data is being written; it can be relayed/connected/sigchecked simultaneously
630 2012-09-18 18:27:07 <alezakos> ACTION
631 2012-09-18 18:42:23 <sipa> gavinandresen: you mean o2i_ECPublicKey returns succesfully on invalid data?
632 2012-09-18 18:43:04 <sipa> or you mean correctly-serialized data which represents an invalid public key; i suppose it doesn't check for that latter case
633 2012-09-18 18:45:08 <gavinandresen> sipa: o2i_ECPublicKey returns successfully on invalid data, and fills in the EC_KEY* structure with bogus version/group/etc.
634 2012-09-18 18:45:43 <sipa> eww
635 2012-09-18 18:45:56 <gavinandresen> sipa: EC_KEY_check_key knows that it is bogus, though. I'll push my fix so far...
636 2012-09-18 18:46:10 <Luke-Jr> >_<
637 2012-09-18 19:05:23 <jgarzik> "Dulwich is a pure-Python implementation of the Git file formats and protocols." Neat.
638 2012-09-18 19:09:08 <kjj_> am I correct in thinking that the contents of "bitcoind help" are generated from the dispatch table and the fHelp conditionals inside each handler?
639 2012-09-18 19:11:51 <sipa> yes
640 2012-09-18 19:23:11 <Diablo-D3> http://badassjs.com/post/18857332551/sql-js-sqlite-compiled-to-javascript-via-emscripten
641 2012-09-18 19:23:20 <Diablo-D3> ultra derp powers activate
642 2012-09-18 19:27:42 <helo> http://imgur.com/a/vYkP5 !!
643 2012-09-18 19:27:56 <helo> (re: ultra derp)
644 2012-09-18 19:28:49 <kjj_> I don't have time to learn git right now. anyone want a diff that implements a stopdetach RPC call?
645 2012-09-18 19:29:26 <D34TH> whats the repo?
646 2012-09-18 19:29:48 <D34TH> whoops, my dep
647 2012-09-18 19:29:52 <D34TH> **derp
648 2012-09-18 19:30:49 <lianj> when is the rms bitcoin talk again? is there video yet?
649 2012-09-18 19:33:23 <kjj_> http://pastebin.com/thHA0SMX <-- stopdetach RPC call
650 2012-09-18 19:34:42 <jgarzik> lianj: when? a while ago
651 2012-09-18 19:35:14 <jgarzik> kjj_: if that were ever merged, presumably it would be setdetach(true / false)
652 2012-09-18 19:35:41 <kjj_> jgarzik: yeah, that would make sense.
653 2012-09-18 19:36:18 <kjj_> I was just thinking that for people that don't normally detach, but want to for an upgrade without having to stop, then start, then stop again.
654 2012-09-18 19:36:25 <DBordello> I just upgraded to 0.70. I am using the same bitcoin.conf. However I am getting "error: no response from server" Ideas?
655 2012-09-18 19:36:44 <DBordello> Any changes with RPC or SSL?
656 2012-09-18 19:37:17 <Luke-Jr> DBordello: IPv6 support
657 2012-09-18 19:37:43 <DBordello> Luke-Jr, would that prevent the local bitcoind from communicating with the daemon?
658 2012-09-18 19:37:56 <Luke-Jr> DBordello: only if your OS is broken
659 2012-09-18 19:38:05 <Luke-Jr> DBordello: the bitcoind test client only supports IPv4
660 2012-09-18 19:38:40 <DBordello> hmmm
661 2012-09-18 19:40:06 <DBordello> tailing debug.log seems to confirm it is running fine, I just can't establish a RPC connection
662 2012-09-18 19:41:08 <DBordello> It appears to pick up the phone if I telnet to the RPC port
663 2012-09-18 19:41:44 <DBordello> Any ideas how to diagnose the RPC issue?
664 2012-09-18 19:41:50 <Luke-Jr> strace the client
665 2012-09-18 19:43:03 <DBordello> any easier ideas?
666 2012-09-18 19:43:25 <kjj_> does the debug.log indicate any RPC activity?
667 2012-09-18 19:43:42 <kjj_> does your client indicate any SSL problems?
668 2012-09-18 19:43:44 <DBordello> No
669 2012-09-18 19:43:51 <DBordello> I am using bitcoind as the client as well
670 2012-09-18 19:43:57 <DBordello> It appears to be SSL issues, disabling SSL works
671 2012-09-18 19:44:07 <jgarzik> DBordello: certificate issue, maybe?
672 2012-09-18 19:44:22 <kjj_> self-signed, or CA?
673 2012-09-18 19:44:31 <DBordello> jgarzik, perhaps, I am self-signed. I actually am only specifying rpcssl=1
674 2012-09-18 19:44:36 <DBordello> Is the only ssl I am doing
675 2012-09-18 19:46:32 <Luke-Jr> strace is pretty easy???
676 2012-09-18 19:46:39 <kjj_> https://en.bitcoin.it/wiki/Enabling_SSL_on_original_client_daemon
677 2012-09-18 19:46:41 <Luke-Jr> but won't help if it's SSL
678 2012-09-18 19:47:57 <DBordello> It is related to rpcsll=1
679 2012-09-18 19:47:57 <DBordello> <Mqrius> So I might switch at some point
680 2012-09-18 19:47:59 <DBordello> <Mqrius> registered has more customizability, volume bar-graph, multiple exchanges (tiled), more detailed quality
681 2012-09-18 19:48:02 <DBordello> <Mqrius> something like that
682 2012-09-18 19:48:04 <DBordello> <DBordello> ah
683 2012-09-18 19:48:06 <DBordello> Sorry!