1 2013-12-30 00:05:01 <maaku> greyox: did you get your problem sorted out?
 2 2013-12-30 00:08:46 <maaku> goodbtc: what is that sf site?
 3 2013-12-30 00:09:36 <niston> brb
 4 2013-12-30 00:10:26 <greyox> please does someone uses VS2012 here?
 5 2013-12-30 00:10:52 <maaku> greyox: bitcoin doesn't compile under msvc
 6 2013-12-30 00:11:44 <greyox> I already compiled it...but the debugger is throwing exception dialog even when the code is inside a try block....
 7 2013-12-30 00:15:40 <greyox> evalscript throwns exception, but it doesn go to catch (...) ...
 8 2013-12-30 00:16:29 <Luke-Jr> we warned you that MSVC is broken..
 9 2013-12-30 00:18:12 <greyox> but is there some other good debugger then?
10 2013-12-30 00:18:33 <maaku> greyox: gdb
11 2013-12-30 00:18:48 <edcba> which kind of exception greyox ?
12 2013-12-30 00:20:41 <maaku> greyox: if you can get MSVC to work, great
13 2013-12-30 00:20:43 <greyox> Unhandled exception at 0x0135E793 in BitcoinQt.exe: An invalid parameter was passed to a function that considers invalid parameters fatal.    -- but this is something just in VS2012 settings...
14 2013-12-30 00:20:46 <maaku> you are in uncharted territory though
15 2013-12-30 00:37:45 <sipa> BlueMatt: that was just the march 11 fork again, for people who did not upgrade
16 2013-12-30 00:42:39 <jcorgan> did anyone figure our what happened with the 277595 split?
17 2013-12-30 00:43:00 <sipa> my guess just the march 11 fork again?
18 2013-12-30 00:43:18 <sipa> if you didn't upgrade to 0.8 or increase your lock count
19 2013-12-30 00:43:36 <niston> yeah someone reported running out of locks
20 2013-12-30 00:43:54 <jcorgan> seems more involved than that
21 2013-12-30 00:43:57 <sipa> why?
22 2013-12-30 00:44:21 <sipa> was anyone on 0.8 affected?
23 2013-12-30 00:44:51 <jcorgan> bc.i was "stuck" at 277595, then 45 mins later reorg'd with a new 277595-277603
24 2013-12-30 00:45:14 <sipa> seems to me they are running 0.7, and figured it out after being stuck for a while
25 2013-12-30 00:45:23 <jcorgan> its possible that was manual intervention
26 2013-12-30 00:45:48 <jcorgan> and blockexplorer.com is still stuck
27 2013-12-30 00:45:58 <sipa> doesn't surprise me
28 2013-12-30 00:46:04 <sipa> iirc it's running an ancient bitcoind
29 2013-12-30 00:46:50 <jcorgan> then the 277596 that got mined was ~900k in size
30 2013-12-30 00:47:15 <jcorgan> and caused about 20k of changed transactions to be committed
31 2013-12-30 00:47:16 <andytoshi> and it had half a dozen tx's which were over 64kb by themselves
32 2013-12-30 00:47:47 <sipa> transactions with many inputs have a larger impact
33 2013-12-30 00:47:56 <jcorgan> so maybe 277596 was the "killer block"
34 2013-12-30 00:48:01 <sipa> yes, seems obvious
35 2013-12-30 00:48:22 <sipa> but unless anyone on 0.8 complains about it, i consider it a known but fixed bug
36 2013-12-30 00:48:43 <gmaxwell> wow, pretty wild to see people getting hit by that.
37 2013-12-30 00:48:52 <jcorgan> but do we really know that it was a resource issue?
38 2013-12-30 00:49:26 <gmaxwell> 16:43 < niston> yeah someone reported running out of locks
39 2013-12-30 00:49:32 <gmaxwell> is pretty much the red flag.
40 2013-12-30 00:49:32 <sipa> either saying "a 900 kb block" or "bdb running out of locks" or "old bitcoind getting stuck" would lead me to conclude this
41 2013-12-30 00:49:53 <sipa> all of them together is everything as expected
42 2013-12-30 00:49:57 <jcorgan> oh, didn't see the out of locks report
43 2013-12-30 00:50:57 <niston> [20:30:09] <thermoman> Lock table is out of available object entries
44 2013-12-30 00:51:01 <jcorgan> ok then, if you guys are happy i'm happy :)
45 2013-12-30 00:51:25 <sipa> so b.i is still running 0.7? :o
46 2013-12-30 00:52:13 <niston> bbiab im gonna fix the rear window of my car :D
47 2013-12-30 00:52:42 <gmaxwell> sipa: makes sense, they've problably patched the everlasting crap out of it to extract the data they need.
48 2013-12-30 00:52:54 <gmaxwell> If so, upgrading to 0.8+ would be an enormous undertaking.
49 2013-12-30 00:53:09 <gmaxwell> Thats what kept block explorer and deepbit on 0.3.24 for such a long time.
50 2013-12-30 00:53:31 <gmaxwell> I belive deepbit is _still_ on 0.3.24 plus patches, though they're irrelevant now at least.
51 2013-12-30 00:53:59 <sipa> iirc they upgraded for bip30
52 2013-12-30 00:54:04 <gmaxwell> it's going to be even more awesome in the future with people running abandoned alternative implementations...
53 2013-12-30 00:54:07 <sipa> but i'm unsure and i don't care :)
54 2013-12-30 00:57:02 <jcorgan> unrelated, but when i was scouring my logs around that event, i came across a several hundred long series of "inputs already spent" receive TXs from a single node.  Someone said that's common.  What causes that?
55 2013-12-30 00:57:20 <sipa> attempted double spends
56 2013-12-30 00:58:19 <jcorgan> so that node itself was the one attempting the double spends, as a normal node wouldn't relay those, correct?
57 2013-12-30 00:58:46 <sipa> if that node didn't see the first spend, it will relay it
58 2013-12-30 00:59:21 <jcorgan> sure, i can see that, but several hundred?
59 2013-12-30 00:59:35 <sipa> it may just have started up
60 2013-12-30 00:59:48 <jcorgan> well, it's academic anyway, i would never have noticed otherwise
61 2013-12-30 01:00:37 <sipa> if a node just starts up and then gets fed a series on transactions which are all double-spends, it'd relay it
62 2013-12-30 01:00:54 <jcorgan> got it
63 2013-12-30 01:01:23 <jcorgan> #bitcoin could use a moderator right now
64 2013-12-30 01:49:36 <jcorgan> would it be useful to anyone else to have bitcoin* examine BITCOIN_DATADIR and/or BITCOIN_CONF environment variables?
65 2013-12-30 02:00:01 <ProfMac> Testing my registration.
66 2013-12-30 02:00:28 <kuzetsa> ProfMac: your what?
67 2013-12-30 02:02:56 <ProfMac> You have to register before you can post.  Apparantly I did it successfully.
68 2013-12-30 02:08:52 <maaku> jcorgan: it would be useful to have bitcoin* examine BITCOIN_* environment variables for configuration settings
69 2013-12-30 02:10:12 <sipa> agree, feel free to file a bug (or send a patch) :)
70 2013-12-30 02:13:52 <jcorgan> ok, i was just implementing BITCOIN_CONF and BITCOIN_DATADIR, but open to other suggestions.  There is no way to search for BITCOIN_* so each one would have to be manually tested.
71 2013-12-30 02:16:02 <sipa> you can surely iterate the environ variable?
72 2013-12-30 02:16:05 <jcorgan> also, i have no idea how/if getenv works on windows :)
73 2013-12-30 02:16:18 <sipa> but i would prefer not doing it
74 2013-12-30 02:16:51 <jcorgan> the argc/argv parsing already comes as a list that just populates mapArgs, etc.
75 2013-12-30 02:17:10 <sipa> environ is very much the same
76 2013-12-30 02:17:38 <sipa> except it's a global variable and not an argument to main
77 2013-12-30 02:17:51 <jcorgan> i could see then how to iterate over environ and extract BITCOIN_FOO=BAR and stuff it into mapArgs['FOO']='BAR'
78 2013-12-30 02:18:13 <sipa> yeah
79 2013-12-30 02:18:18 <sipa> but i don't think that would be wise
80 2013-12-30 02:18:32 <sipa> there may be unexpected behaviour with security consequences
81 2013-12-30 02:19:47 <jcorgan> so then we're back to manually getenv() known names to see if they are in use
82 2013-12-30 02:22:07 <jcorgan> i'd just like to not have to manually specify -conf=foo all the time on the command line when it is in a non-standard place
83 2013-12-30 02:24:41 <maaku> I would do the loop over environ mapping BITCOIN_FOO=bar into mapArgs['foo']='bar', but check 'foo' against a whitelist first
84 2013-12-30 02:25:42 <jcorgan> that sounds reasonable
85 2013-12-30 02:26:23 <jcorgan> the cli args aren't check against such a whitelist now, though
86 2013-12-30 02:27:32 <jcorgan> also, the plan is to check the environment, then parse the cli, so that cli overrides environment if desired
87 2013-12-30 02:29:14 <jcorgan> also, is using environ this way portable?
88 2013-12-30 02:29:16 <maaku> jcorgan: yes, you'd want the cli to override for sure
89 2013-12-30 02:29:51 <maaku> jcorgan: you mena the 3rd argument to main() right?
90 2013-12-30 02:29:53 <maaku> yes that's portable
91 2013-12-30 02:31:15 <maaku> using getenv is even more portable
92 2013-12-30 02:33:05 <jcorgan> i'd have to check the standard, but ISTR using 'extern char **environ' was preferred over main(..., ..., char *envp[])
93 2013-12-30 08:02:25 <jcorgan> pull request #3476 has the environment parsing for config we discussed earlier
94 2013-12-30 08:22:08 <melvster> trezor talk at ccc: http://www.youtube.com/watch?v=CgaBKNus1n0
95 2013-12-30 08:22:46 <nessence> how closer is the main client to supporting a thin-client version?
96 2013-12-30 08:22:55 <nessence> close*
97 2013-12-30 08:31:54 <maaku> jcorgan: thanks, looks good (modulo Iaan's comments already)