1 2012-06-24 00:11:43 <gmaxwell> Unless someone screams, I'm going to pull hidden service support now.  There are still some things that should be improved... but it tests out well generally for me.
  2 2012-06-24 00:12:28 <luke-jr> gmaxwell: sipa keeps revising it, so dunno&
  3 2012-06-24 00:12:53 <luke-jr> gmaxwell: how about gmp_bip instead? <.<
  4 2012-06-24 00:15:56 <gmaxwell> The only thing that has been changed recently is the docs and the tests, which was what gavin requested.
  5 2012-06-24 00:16:56 <luke-jr> ah
  6 2012-06-24 00:17:46 <gmaxwell> ::nods::
  7 2012-06-24 00:23:36 <gmaxwell> luke-jr: the way you're packing in the metadata seems kinda kludgey.
  8 2012-06-24 00:23:47 <gmaxwell> I dunno if there is any better way though
  9 2012-06-24 00:24:27 <luke-jr> gmaxwell: ?
 10 2012-06-24 00:24:49 <luke-jr> oh
 11 2012-06-24 00:25:08 <luke-jr> I did it that way intentionally so using an older version doesn't destroy it
 12 2012-06-24 00:25:19 <luke-jr> it worked out nicely
 13 2012-06-24 00:25:21 <luke-jr> IMO
 14 2012-06-24 00:26:34 <gmaxwell> ah. thats an interesting point.
 15 2012-06-24 00:29:30 <gmaxwell> I suppose if you change a txn's comments with an old version it'll destroy the data there?
 16 2012-06-24 00:30:17 <luke-jr> maybe. but I don't think any current version lets you do that.
 17 2012-06-24 00:30:28 <luke-jr> note it's only for accounting data, which Bitcoin-Qt ignores
 18 2012-06-24 01:31:47 <jgarzik> gmaxwell: are 'inv' common with multiple MSG_TX?
 19 2012-06-24 01:31:52 <jgarzik> gmaxwell: repeatedly?
 20 2012-06-24 01:32:41 <jgarzik> gmaxwell: I'm trying to understand how your comment applies to #1511
 21 2012-06-24 01:34:34 <gmaxwell> 06/17/12 14:47:31 askfor tx 51a3ccbef6fb2a2bc3be   0
 22 2012-06-24 01:34:34 <gmaxwell> 06/17/12 14:47:31   got inventory: tx 51a3ccbef6fb2a2bc3be  new
 23 2012-06-24 01:34:37 <gmaxwell> 06/17/12 14:47:31   got inventory: tx 51a3ccbef6fb2a2bc3be  new
 24 2012-06-24 01:34:39 <gmaxwell> 06/17/12 14:47:31 askfor tx 51a3ccbef6fb2a2bc3be   1339944571000000
 25 2012-06-24 01:34:50 <gmaxwell> (random example)
 26 2012-06-24 01:36:48 <jgarzik> gmaxwell: I don't see any impacted log lines there.  The only impacted lines are those with the format "received getdata for: %s"
 27 2012-06-24 01:38:10 <gmaxwell> Oh for some reason I thought you were supressing all the lines related to INV on a new transaction. Ignore me then.
 28 2012-06-24 02:04:17 <ageis> this channel is nothihng but a list of incomprehensible hashes and programmer jargon to me.
 29 2012-06-24 02:11:05 <jgarzik> not true.  it is full of Diablo-D3 rants too.
 30 2012-06-24 02:11:19 <jgarzik> :)
 31 2012-06-24 02:12:23 <luke-jr> lol
 32 2012-06-24 02:36:42 <gmaxwell> ageis: And the problem is?
 33 2012-06-24 02:40:44 <ageis> gmaxwell: no problem ;)
 34 2012-06-24 02:44:23 <Karmaon> Don't forget Diablo-D3's singing.
 35 2012-06-24 04:08:53 <gribble> New news from bitcoinrss: jgarzik opened pull request 1512 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1512>
 36 2012-06-24 04:09:24 <jgarzik> gmaxwell: so.... any chance you could revise your comment on https://github.com/bitcoin/bitcoin/pull/1511 ?
 37 2012-06-24 04:10:05 <jgarzik> any action will do.. just want to eliminate confusion
 38 2012-06-24 04:10:48 <gmaxwell> jgarzik: Done.
 39 2012-06-24 04:10:55 <jgarzik> gmaxwell: tnx
 40 2012-06-24 05:36:26 <sipa> helo: read BIP 32, that uses a key tree
 41 2012-06-24 05:36:42 <sipa> helo: it has nothing to do with p2sh though
 42 2012-06-24 05:39:17 <sipa> jgarzik: i didn't mean to say you have to use my code - some variation in seed providers is a good thing; i just mean that at least my node will spread
 43 2012-06-24 05:39:35 <sipa> jgarzik: i didn't mean to say you have to use my code - some variation in seed providers is a good thing; i just mean that at least my node will spread out load somewhat
 44 2012-06-24 05:44:57 <sipa> jgarzik: and if your static list is based on the wiki seed list, people do kinda choose being the first target for new nodea
 45 2012-06-24 06:05:40 <gmaxwell> sipa: It's a little odd that we'll return our onion address to RFC1918 (or otherwise unroutable) peers. It could lead to some avoidable address leaks in some odd configurations.
 46 2012-06-24 06:09:30 <sipa> gmaxwell: it's certainly safer then returning other addresses
 47 2012-06-24 06:10:30 <gmaxwell> Not safer than returning 0.0.0.0 though.
 48 2012-06-24 06:10:36 <sipa> and it's a simple default, if the origin is unknown, reply with your "anonymous" address
 49 2012-06-24 06:11:14 <sipa> though the correct way would probably be detecting connections coming from your onion proxy, and only return it then
 50 2012-06-24 06:12:10 <sipa> and return :: or 0.0.0.0 for unknown origins
 51 2012-06-24 06:12:13 <gmaxwell> sipa: Right, but just because it's unknown to you doesn't mean it's unknown to the peer.  E.g. you've enabled listening, I scan the network and find you, now I know your hidden service address. Best practice is probably to use a seperate hidden service address for bitcoin though.
 52 2012-06-24 06:13:11 <gmaxwell> Yea, in any case I wasn't sure what to do otherwise I'd be posting a pull rather than a comment. 0.0.0.0 is probably more conservative, but it wasn't obvious to me how we can figure out if the peer is the tor inbound.
 53 2012-06-24 06:13:58 <sipa> maybe a CNode field that contains the network the connection is assumed to be on
 54 2012-06-24 06:14:37 <sipa> and you can check at the time of accepting a connection that it's from the onion proxy
 55 2012-06-24 06:15:05 <sipa> but what if you don't have an onion proxy, and only want to accept inbound tor connections?
 56 2012-06-24 06:15:48 <gmaxwell> It's harmless to send zeros still in that case.
 57 2012-06-24 06:16:21 <sipa> true, but that would mean no way of advertizing your service at all
 58 2012-06-24 06:17:51 <sipa> in general, if someone can connect to you from an RFC1918 address, i suppose there is at least some trust
 59 2012-06-24 06:18:03 <sipa> but that assumption won't always be true
 60 2012-06-24 06:18:35 <gmaxwell> or you've just left some proxy open. Or your on some kind of corporate network / dorm.. or it's some proxy running inside a java applet in your browser.
 61 2012-06-24 06:19:18 <gmaxwell> I don't think the risks are especially great, but the benefit of sending something other than zeros isn't great either.
 62 2012-06-24 06:19:29 <sipa> true
 63 2012-06-24 06:22:26 <gmaxwell> In general a multi-network node isn't a super secure thing... but listening for tor ends up leaving you open to listening to v4 soo...
 64 2012-06-24 06:22:50 <sipa> -bind=127.0.0.1
 65 2012-06-24 06:23:14 <sipa> which may still be accessible to java applets and other thinga
 66 2012-06-24 08:42:09 <gribble> New news from bitcoinrss: nanpanman opened issue 1513 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1513>
 67 2012-06-24 09:17:00 <MysteryBanshee> Bitcoin Challenge Promotion for #btc-mystery - Public Address 1FabzebwRtz7fu3iMUz7FHak31ormmHXy3 (0.195 BTC) - Private key is 5K1MysteryBansheePromotion1KKKKKKKKKKKKKKKKKKKuLH7t
 68 2012-06-24 09:24:48 <sipa> MysteryBanshee: that seems kinda hard to crack
 69 2012-06-24 09:25:04 <sipa> oh wait
 70 2012-06-24 09:25:09 <sipa> what is the challenge?
 71 2012-06-24 09:26:05 <MysteryBanshee> you just import the key
 72 2012-06-24 09:26:11 <MysteryBanshee> it was solved in like 30 seconds tho
 73 2012-06-24 09:26:17 <MysteryBanshee> someones already taken it
 74 2012-06-24 09:26:49 <sipa> boring :)
 75 2012-06-24 09:26:55 <MysteryBanshee> (it was more of a test for creating vanity addresses)
 76 2012-06-24 09:27:03 <MysteryBanshee> ill be coming up with more interesting ones later
 77 2012-06-24 09:28:52 <sipa> this is the thread that started the whole key importing thing: https://bitcointalk.org/index.php?topic=3638.0
 78 2012-06-24 09:29:33 <MysteryBanshee> lol yeh, I got my idea from the forums :)
 79 2012-06-24 09:30:01 <sipa> back then, people posted challenged with 20 BTC in this ;)
 80 2012-06-24 09:30:08 <MysteryBanshee> how much was 20 btc worth?
 81 2012-06-24 09:30:10 <PK> MysteryBanshee: how about generating vanity qr codes? like that: http://upload.wikimedia.org/wikipedia/commons/2/2c/Wikipedia_extreme_qr_code_mobile_de.png
 82 2012-06-24 09:30:25 <MysteryBanshee> thats pretty nice pk
 83 2012-06-24 09:31:01 <MysteryBanshee> is it possible to encode a private key as a qr code?
 84 2012-06-24 09:31:07 <PK> yes
 85 2012-06-24 09:31:10 <sipa> why not?
 86 2012-06-24 09:31:18 <sipa> qr codes just contain text
 87 2012-06-24 09:31:29 <sipa> s/contain/encode/
 88 2012-06-24 09:31:33 <PK> MysteryBanshee: check https://www.bitaddress.org for an example
 89 2012-06-24 09:31:41 <sipa> MysteryBanshee: i think 1 BTC was close to 1 USD back then
 90 2012-06-24 09:32:03 <MysteryBanshee> im thinking of taking a private key qr code with 1 btc
 91 2012-06-24 09:32:07 <MysteryBanshee> splitting it into 4 pieces
 92 2012-06-24 09:32:14 <MysteryBanshee> and posting it in different places as a treasure hunt
 93 2012-06-24 09:32:48 <PK> split the QR in 4 pieces like old pirate maps and hide the pieces in different places :)
 94 2012-06-24 09:33:02 <PK> oh, I'm typing too slow :)
 95 2012-06-24 09:34:54 <MysteryBanshee> yup
 96 2012-06-24 10:06:35 <gribble> New news from bitcoinrss: muggenhor opened pull request 1514 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1514>
 97 2012-06-24 10:08:53 <MysteryBanshee> Ive got my idea at https://en.bitcoin.it/wiki/Plug-in_System ... does anyone know if it might be possible to make it into a BIP ?
 98 2012-06-24 10:09:18 <MysteryBanshee> its not really network-specific but client-related
 99 2012-06-24 10:12:55 <galambo> m
100 2012-06-24 10:15:45 <sipa> doesn't really look like BIP material
101 2012-06-24 10:17:07 <MysteryBanshee> oh
102 2012-06-24 10:18:45 <luke-jr> MysteryBanshee: BIP is for Bitcoin stuff, not client-specific stuff
103 2012-06-24 10:19:12 <MysteryBanshee> luke-jr: I was hoping the plugin system could be more like a cross-client protocol
104 2012-06-24 10:19:24 <MysteryBanshee> ie, so any client can implement the standards and use a plugin
105 2012-06-24 10:20:44 <sipa> that sounds even harder than making wallets cross-client compatibl
106 2012-06-24 10:21:31 <MysteryBanshee> i dont think its going to be that hard sipa, the modules would use a standard scripting language like lua
107 2012-06-24 10:21:34 <MysteryBanshee> the interface will be html
108 2012-06-24 10:21:47 <MysteryBanshee> and there would be an IPC system that would be relatively simple
109 2012-06-24 10:21:49 <MysteryBanshee> (so its secure)
110 2012-06-24 10:22:00 <sipa> so you'll have to standardize the functions exposed to the script language
111 2012-06-24 10:22:07 <MysteryBanshee> indeed
112 2012-06-24 10:22:56 <MysteryBanshee> i dont expect it to be implemented now of course, its just like a proposal for several months (or years) in the future
113 2012-06-24 10:23:01 <luke-jr> MysteryBanshee: but nobody knows Lua
114 2012-06-24 10:23:14 <MysteryBanshee> luke-jr, then another scripting language that you like
115 2012-06-24 10:23:19 <luke-jr> also, HTML really makes a terrible interface
116 2012-06-24 10:23:31 <luke-jr> it shouldn't matter what I like :p
117 2012-06-24 10:23:34 <MysteryBanshee> luke-jr: how would you do it then?
118 2012-06-24 10:23:47 <sipa> MysteryBanshee: if you want something like that, i'd say implement it :)
119 2012-06-24 10:24:14 <luke-jr> MysteryBanshee: I wouldn't open that can of worms.
120 2012-06-24 10:24:20 <MysteryBanshee> oh lol
121 2012-06-24 10:26:20 <galambo> can i make a BIP for my windows client to build :/
122 2012-06-24 10:26:29 <sipa> ?
123 2012-06-24 10:27:05 <galambo> i get a 7.6 meg executable that doesn't do anything when i run it
124 2012-06-24 10:27:50 <sipa> does it create a debug.log ?
125 2012-06-24 10:30:43 <galambo> nope
126 2012-06-24 10:31:37 <galambo> i built everything myself though. i am going to try it again using qt_deps (i thought it was out of date for all packages)
127 2012-06-24 10:32:25 <galambo> i assume it goes under /AppData/Roaming/Bitcoin/debug.log
128 2012-06-24 11:41:41 <jgarzik> sipa: (RE DNS seeds)  I agree, RE spreading out load.  I just think that our client code could do better, e.g. by NOT downloading from the very first peer we successfully connect to.  Wait for a connect, get more addresses, then prospect around for IBD nodes
129 2012-06-24 11:42:10 <jgarzik> by IBD'ing from the first peer we find, we punish any DNS seed unduly
130 2012-06-24 11:44:25 <sipa> jgarzik: agree
131 2012-06-24 12:59:41 <galambo> weird guys
132 2012-06-24 13:01:06 <galambo> import master branch to another folder and copied my bitcoin-qt.pro over and it works now
133 2012-06-24 13:01:29 <galambo> i guess i broke something trying to fix it :/
134 2012-06-24 13:10:49 <xorgate> syncing with the blockchain, about 150 new blocks. Takes about a minute on my desktop, about 30 minutes on my 32bit winxp laptop. What's happening that's so much slower on 32 than 64bit?
135 2012-06-24 13:12:16 <sipa> is the hardware similar?
136 2012-06-24 13:12:27 <sipa> in particular, CPU and RAM
137 2012-06-24 13:12:29 <xorgate> deinitely not
138 2012-06-24 13:12:56 <sipa> also, are you downloading from a local network or importing from a file?
139 2012-06-24 13:13:12 <sipa> otherwise it's possible you just picked a slow peer to download from on the laptop
140 2012-06-24 13:13:43 <xorgate> it's standard opening of bitcoin-qt, same network (though wireless for laptop). it's just that it seems to me to be out of proportionally slow
141 2012-06-24 13:13:58 <sipa> what hardware is the laptop?
142 2012-06-24 13:14:19 <xorgate> intel atom, 1.6 ghz
143 2012-06-24 13:14:25 <xorgate> 2 gb ram
144 2012-06-24 13:14:33 <xorgate> and 32bit
145 2012-06-24 13:14:47 <xorgate> so i'm guessing it's falling back on slower code maybe?
146 2012-06-24 13:15:04 <sipa> the code is the same
147 2012-06-24 13:15:14 <sipa> but there could be many reasons for speed difference
148 2012-06-24 13:15:36 <sipa> * you accidentally picked a slow peer to download
149 2012-06-24 13:15:57 <sipa> * the initial block download was interrupted (connection broke?) and only continued when a new block was announced
150 2012-06-24 13:16:20 <xorgate> it's not just this time though
151 2012-06-24 13:17:24 <sipa> * low ram could mean not enough of the database indexes fit in memory
152 2012-06-24 13:17:48 <sipa> though i run a bitcoind without problems on a VPS with 1 GB ram
153 2012-06-24 13:18:04 <xorgate> i'm not complaining mind you, it's that people might get upset if things are this slow
154 2012-06-24 13:18:42 <guruvan> also - differences in filesystems can make a very significant difference
155 2012-06-24 13:19:43 <guruvan> (i.e using NTFS vs. FAT)
156 2012-06-24 13:25:13 <jrmithdobbs> sipa: so long as you don't have a wallet loaded it's not bad with low resources
157 2012-06-24 13:27:20 <gribble> New news from bitcoinrss: muggenhor opened pull request 1515 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1515>
158 2012-06-24 13:36:02 <jgarzik> sipa: for nodes that (a) appear stuck and (b) are not already asking for blocks, I wondered about offering them the height+1 block only, to see if that would get them going again
159 2012-06-24 13:37:10 <sipa> jgarzik: meh, not the responsability of the sender, imho
160 2012-06-24 13:37:22 <sipa> though improvements are definitely possible
161 2012-06-24 13:51:55 <nolybab> hi all...i'm back
162 2012-06-24 13:59:03 <nolybab> bye all...i'm gone
163 2012-06-24 14:08:20 <gribble> New news from bitcoinrss: Diapolo opened pull request 1516 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1516>
164 2012-06-24 14:13:27 <gribble> New news from bitcoinrss: Diapolo opened pull request 1517 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1517>
165 2012-06-24 14:38:41 <gribble> New news from bitcoinrss: Diapolo opened pull request 1518 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1518>
166 2012-06-24 15:47:37 <gmaxwell> 08:36 <@jgarzik> sipa: for nodes that (a) appear stuck and (b) are not already asking for blocks, I wondered about offering them the height+1 block only, to see if that
167 2012-06-24 15:47:54 <gmaxwell> I tried unsticking stuck nodes a few weeks ago and couldn't come up with anything to do it.
168 2012-06-24 15:48:54 <gmaxwell> (I tried advertising and pushing every block from their last common point to current and a couple of different patterns of responding when they pulled current blocks)
169 2012-06-24 16:08:08 <topi`> about the qt ui, is there any way to disable the progress bar when the client is catching up with blocks? it causes a slight load on my snow leopard (the rest of the cpu goes to tx sig checking)
170 2012-06-24 16:09:57 <tcatm> You could remove the code. How did you figure out that the progressbar causes load?
171 2012-06-24 16:10:17 <topi`> how do I know the progress bar consumes cpu? if I minimize the window, then I never get >100% cpu usage for the task Bitcoin-Qt
172 2012-06-24 16:10:36 <topi`> the gfx stuff runs in a separate thread.
173 2012-06-24 16:11:03 <tcatm> That might also be some scheduler giving higher priority to focused/foreground windows.
174 2012-06-24 16:11:24 <gmaxwell> topi`: what version are you running?
175 2012-06-24 16:11:48 <topi`> well, updating *anything* in a window on an OSX system 60 times per second causes some CPU load.
176 2012-06-24 16:11:56 <topi`> gmaxwell: 0.6.2.2
177 2012-06-24 16:12:47 <gmaxwell> There was some issue in a prior version where every block recieved caused a gui refresh (not just progress but everything).. and this did make things obviously slower.
178 2012-06-24 16:13:38 <gmaxwell> It would probably be worth testing to see if it was the progress bar causing trouble, but if so I actually wouldn't expect minimizing the window to really fix it.
179 2012-06-24 16:16:37 <topi`> well, I'll just suffer the howling of the fan :)
180 2012-06-24 16:24:58 <galambo> wow these builds do not really play well with a blk0000.dat from another version
181 2012-06-24 16:25:00 <galambo> :)
182 2012-06-24 16:25:28 <sipa> that would surprise me
183 2012-06-24 16:25:39 <sipa> blk0001.dat just contains a concatenation of blocks
184 2012-06-24 16:26:10 <galambo> i switched from MASTER to 6.2.2 and now it crashes berkeley db
185 2012-06-24 16:26:18 <sipa> however, it may be incompatible with blkindex.dat, as that is a BDB database file, and BDB has some incompatibilities between versions
186 2012-06-24 16:26:19 <galambo> no loss i just deleted the dat file
187 2012-06-24 16:26:36 <galambo> oh i see
188 2012-06-24 16:26:36 <sipa> blk0001.dat is not a database file
189 2012-06-24 16:26:46 <galambo> i will do -loadblock
190 2012-06-24 16:26:54 <galambo> thank you i understand now
191 2012-06-24 16:27:11 <sipa> delete blkindex.dat, move blk0001.dat out of the way, and delete the database subdir
192 2012-06-24 16:30:33 <topi`> the biggest glaring omission in the Qt client is that there seems to be no way of seeing at which block it is syncing
193 2012-06-24 16:30:46 <topi`> so I have no idae whether to leave it on for the whole night or not
194 2012-06-24 16:30:57 <galambo> check your debug.log
195 2012-06-24 16:31:05 <galambo> that information is there
196 2012-06-24 16:31:09 <topi`> ah,t rue
197 2012-06-24 16:31:10 <topi`> thanks
198 2012-06-24 16:31:35 <sipa> topi`: hover over the sync icon
199 2012-06-24 16:31:51 <topi`> ERROR: ProcessBlock() : already have block 185590 000000000000014883e0
200 2012-06-24 16:31:54 <topi`> I wonder what's causing these
201 2012-06-24 16:32:03 <sipa> topi`: ignore that
202 2012-06-24 16:32:12 <topi`> ok
203 2012-06-24 16:32:22 <topi`> how does the client know what's the max # of blocks at the moment?
204 2012-06-24 16:32:27 <sipa> it doesn't
205 2012-06-24 16:32:36 <sipa> it guesses, based on reports from other nodes
206 2012-06-24 16:32:46 <topi`> aha
207 2012-06-24 16:33:07 <topi`> is there a rpc to find out other nodes' top count?
208 2012-06-24 16:33:15 <galambo> thats another thing i noticed. when i import blk0001.dat from MASTER  to 0.6.2 with -loadblock all of the blocks were rejected for too low of difficulty
209 2012-06-24 16:33:43 <gmaxwell> galambo: are you talking about testnet?
210 2012-06-24 16:33:48 <galambo> Yes
211 2012-06-24 16:33:50 <gmaxwell> ...
212 2012-06-24 16:33:56 <sipa> master uses testnet3
213 2012-06-24 16:34:01 <sipa> 0.6.2 uses testnet2
214 2012-06-24 16:34:02 <gmaxwell> It would help to specify that! testnet has been reset for 0.7.0.
215 2012-06-24 16:34:27 <gmaxwell> There is a new testnet chain. It's curently at height 75xx or so.
216 2012-06-24 16:34:47 <galambo> oh strange
217 2012-06-24 16:35:18 <galambo> that would explain the behavior
218 2012-06-24 16:35:33 <galambo> it would only download ~7000 blocks and no more
219 2012-06-24 16:35:44 <galambo> but the client was reporting 50000 remaining
220 2012-06-24 16:42:48 <gmaxwell> sipa: my testnet3 node now is listening on 6hgmaxwellgpv2oe.onion too.
221 2012-06-24 16:43:47 <sipa> gmaxwell: could you try -addnode='ing my node? (kjy2eqzk4zwi5zd3.onion:8333)
222 2012-06-24 16:43:57 <sipa> the non-testnet one of course
223 2012-06-24 16:44:41 <sipa> (i didn't check whether they're already connected, actually)
224 2012-06-24 16:45:02 <sipa> but if they are connected for some time, i suppose they should learn eachother's address, and my crawler should pick it up
225 2012-06-24 16:45:22 <gmaxwell> Sure.
226 2012-06-24 16:47:16 <gmaxwell> hm.
227 2012-06-24 16:49:25 <gmaxwell> 06/24/12 18:48:37 send version message: version 60001, blocks=186052, us=6hgmaxwellgpv2oe.onion:8333, them=kjy2eqzk4zwi5zd3.onion:8333, peer=kjy2eqzk4zwi5zd3.onion:8333
228 2012-06-24 16:49:28 <gmaxwell> 06/24/12 18:48:39 receive version message: version 60001, blocks=186052, us=0.0.0.0:0, them=kjy2eqzk4zwi5zd3.onion:8333, peer=kjy2eqzk4zwi5zd3.onion:8333
229 2012-06-24 16:51:12 <sipa> looks good
230 2012-06-24 17:03:48 <c4pt-otc> is there a problem with the bitcoin client?
231 2012-06-24 17:04:06 <copumpkin> you tell us?
232 2012-06-24 17:04:06 <sipa> that's very vague...
233 2012-06-24 17:04:12 <copumpkin> I'm sure there are many problems with it
234 2012-06-24 17:04:16 <copumpkin> most of which we don't know about yet :)
235 2012-06-24 17:04:21 <gmaxwell> It doesn't give me unlimited free money.
236 2012-06-24 17:04:36 <gmaxwell> whooo!
237 2012-06-24 17:04:45 <c4pt-otc> no i mean for the last 17 hrs i havent been able to download any blocks
238 2012-06-24 17:04:45 <your_king> loool
239 2012-06-24 17:04:59 <sipa> ok, that's more interesting
240 2012-06-24 17:05:07 <gmaxwell> c4pt-otc: What does the end of your debug log say?
241 2012-06-24 17:05:16 <GTRsdk> copumpkin: could you give me that too? :)
242 2012-06-24 17:05:29 <copumpkin> GTRsdk: sorry, I only have one person worth of unlimited free money
243 2012-06-24 17:06:11 <c4pt-otc> gmaxwell, where is that in /var/log ?
244 2012-06-24 17:06:31 <sipa> ~/.bitcoin/debug.log
245 2012-06-24 17:20:24 <c4pt-otc> sipa, gmaxwell thanx
246 2012-06-24 17:20:27 <c4pt-otc> here
247 2012-06-24 17:20:40 <c4pt-otc> ERROR: FetchInputs() : 0cd399a857 mempool Tx prev not found 4bbb5b1602
248 2012-06-24 17:20:41 <c4pt-otc> ERROR: CTxMemPool::accept() : FetchInputs failed 0cd399a857
249 2012-06-24 17:22:04 <sipa> can you give a bit more, on a paste site or upload the debug.log somewhere?
250 2012-06-24 17:23:45 <gmaxwell> c4pt-otc: those messages are completely normal.  Can you get us more of the debug.log? ideally the whole file?
251 2012-06-24 17:23:50 <gmaxwell> If you want you could email it to us.
252 2012-06-24 17:26:21 <c4pt-otc> http://pastie.org/4144264
253 2012-06-24 17:27:56 <sipa> c4pt-otc: all very normal still, can you leave it open for a while (in particular until the next block), and paste again?
254 2012-06-24 17:28:04 <sipa> by the way: your disk isn't full, is it?
255 2012-06-24 17:28:25 <c4pt-otc> sipa, no
256 2012-06-24 17:29:40 <sipa> ;;bc,tslb
257 2012-06-24 17:29:41 <gribble> Time since last block: 27 minutes and 10 seconds
258 2012-06-24 17:31:46 <c4pt-otc> when i tried a rescan
259 2012-06-24 17:31:47 <c4pt-otc> ************************
260 2012-06-24 17:31:47 <c4pt-otc> c4pt@hpz800:~$ bitcoin-qt -rescan
261 2012-06-24 17:32:18 <sipa> that looks like a corrupted blockchain db...
262 2012-06-24 17:33:30 <galambo> do you suggest doing a loadblock to people using the real network
263 2012-06-24 17:34:06 <galambo> or are you afraid they will accidentally delete their wallets in the process :)
264 2012-06-24 18:28:34 <jgarzik> c4pt-otc: try -upgradewallet
265 2012-06-24 18:28:55 <c4pt-otc> jgarzik, i deleted the blkindex already
266 2012-06-24 18:29:06 <c4pt-otc> jgarzik, ill keep it in mind though thanx
267 2012-06-24 18:35:41 <jgarzik> c4pt-otc: note that deleting blkindex.dat but leaving blk0001.dat in your data dir won't work
268 2012-06-24 18:36:06 <jgarzik> c4pt-otc: if you want to reload blk0001.dat, you must move it outside the data dir, then run with -loadblock=FILE
269 2012-06-24 18:38:08 <c4pt-otc> jgarzik, i deleted both already
270 2012-06-24 18:38:13 <jgarzik> for some reason, eu3.exmulti.net sure does attract incoming connections...  93 total at present
271 2012-06-24 18:38:25 <c4pt-otc> jgarzik, i am downloading the blockchain mirror .tar to try and extract in ~/.bitcoin
272 2012-06-24 18:38:27 <jgarzik> other nodes in the US brought online at the same time have 50-60
273 2012-06-24 19:18:52 <gmaxwell> jgarzik: the /16 filtering sometimes has weird results.
274 2012-06-24 20:12:10 <doublec> I have a server that's similar. As soon as I start bitcoind, instant 100 connections.
275 2012-06-24 20:12:56 <gmaxwell> doublec: instant? that sounds odd.. Are all the connections from the ukrane and russia?
276 2012-06-24 20:13:28 <gmaxwell> There were a whole bunch of ukrainian hosts super agressively connecting to me, and I just blocked them.
277 2012-06-24 20:13:32 <doublec> well, instant for some definition of it. over an hour or so.
278 2012-06-24 20:13:38 <luke-jr> lol
279 2012-06-24 20:14:13 <doublec> is there some tool that geolocates an shows where a list of ip's come from?
280 2012-06-24 20:14:47 <gmaxwell> doublec: there are lots of tools for this. Most popular of the freely available stuff uses this database: http://www.maxmind.com/
281 2012-06-24 20:15:16 <doublec> ra.mining.eligius is connected to it, I feel special
282 2012-06-24 20:15:46 <doublec> this is my cjdns/bitcoin bridge node
283 2012-06-24 20:23:20 <luke-jr> doublec: ?
284 2012-06-24 20:23:49 <luke-jr> ra has a node that tries to connect to everything
285 2012-06-24 20:24:48 <doublec> great, now I don't feel special, thanks a lot
286 2012-06-24 20:25:18 <luke-jr> lol
287 2012-06-24 22:02:44 <jgarzik> seeing this a lot on one node, but not on the others:
288 2012-06-24 22:02:49 <jgarzik> ^M^M^MPROCESSMESSAGE SKIPPED 20 BYTES^M^M^M
289 2012-06-24 22:03:53 <jgarzik> would be nice to put 'getnetstats' stuff under rrdtool
290 2012-06-24 22:07:01 <gmaxwell> jgarzik: is the clock on that node like.. a year off? :)
291 2012-06-24 22:25:45 <D34TH> ntpdate pool.ntp.org
292 2012-06-24 22:25:46 <D34TH> :D
293 2012-06-24 22:29:09 <gmaxwell> In any case, I haven't seen any of those for some time.