1 2015-03-06 00:00:31 <Luke-Jr> hm
 2 2015-03-06 00:01:12 <maaku> Actually, "scan backwards" is wrong. The very first entry prior to where the node should be is the nearest (grand-)parent node.
 3 2015-03-06 00:01:57 <maaku> At least if the keys are lexicographically ordered
 4 2015-03-06 00:03:21 <phantomcircuit> hearn, because it's mildly annoying that sig checking is at equal priority as hexchat
 5 2015-03-06 00:03:23 <phantomcircuit> for example
 6 2015-03-06 00:08:36 <gavinandresen> Luke-Jr morcos:  re: -txconfirmtarget :  I’d want to get advice from a queueing theory expert before using a higher -txconfirmtarget. My intuition is fee estimates might swing wildly if the default was greater than 1, but I don’t know enough queueing theory to know if that is correct.
 7 2015-03-06 00:09:30 <gmaxwell> phantomcircuit: stop running windows?
 8 2015-03-06 00:09:57 <gmaxwell> hearn: windows scheduler is especially dumb, a background cpu soaker thread (or four) manages to really hose interactive response for some reason.
 9 2015-03-06 00:09:58 <phantomcircuit> gmaxwell, debian
10 2015-03-06 00:10:18 <Luke-Jr> gavinandresen: GUI default is 25 fwiw
11 2015-03-06 00:10:24 <hearn> hexchat?
12 2015-03-06 00:10:37 <phantomcircuit> a fork of xchat
13 2015-03-06 00:10:41 <phantomcircuit> xchat is adandonware
14 2015-03-06 00:10:43 <gmaxwell> phantomcircuit: hm! I've never noticed any interactivity impact on linux. (But seen lots of windows users complain; sorry for the assumption. :) )
15 2015-03-06 00:10:58 <hearn> i think on windows the issue is likely to be the disk io rather than the cpu
16 2015-03-06 00:11:03 <phantomcircuit> gmaxwell, this might have more to do with debian + binary nvidia drivers
17 2015-03-06 00:11:06 <gavinandresen> Luke-Jr: probably a good thing Bitcoin-Qt isn’t the dominant wallet…..
18 2015-03-06 00:11:38 <phantomcircuit> gmaxwell, i've only ran bitcoin on windows once and that was to test the bitcoin consultancy build which had connect timeouts
19 2015-03-06 00:11:42 <hearn> phantomcircuit: do you really see laggy ui because of signature checking in regular operation, or is this just during chain sync
20 2015-03-06 00:12:03 <phantomcircuit> hearn, everything was fine up until it hit the last checkpoint
21 2015-03-06 00:12:14 <gmaxwell> hearn: it's really not acceptable to make it laggy during chain sync either.
22 2015-03-06 00:12:18 <phantomcircuit> i renice'd all the threads and now it's fine
23 2015-03-06 00:12:21 <hearn> ok
24 2015-03-06 00:12:56 <hearn> how many threads are there, i wonder? normally X is given higher CPU priority than other apps. but it's been a while since i last had that issue.
25 2015-03-06 00:13:05 <gmaxwell> Any interactivity hit results in users being quite convinced that the software is broken and is just spinning pointlessly. (ugh, so annoying that people aren't accustomed to their computers being used. ) :)
26 2015-03-06 00:13:12 <gmaxwell> hearn: as many threads as cores, normally.
27 2015-03-06 00:14:37 <gmaxwell> gavinandresen: do you have some intution that explains why you're concerned about higher than 1?  (If anything I would have guessed a default of 1 would have bad behavior, since it suggests something of a race to pay the highest fee always.)
28 2015-03-06 00:15:37 <phantomcircuit> hearn, X by default has the default priority of 20 (nice value 0)
29 2015-03-06 00:15:54 <phantomcircuit> that's possibly a mistake on debian's part
30 2015-03-06 00:16:06 <hearn> i would not expect debian to be especially desktop optimised
31 2015-03-06 00:16:39 <gavinandresen> gmaxwell: if everybody tries to target (say) 11, then there is no data about fees until the queue fills up so it takes a transaction 11 blocks to confirm. But if it is backed up THAT far, and everybody is using the same minimum fees, seems like it would take a long time to get enough data to make a reasonable estimate.  And if everybody switches to that estimate, then it seems there’s likely to be a big jump as the queue fills up