1 2015-08-04 03:18:49 <phantomcircuit> wumpus, i think it's handling it correctly now
  2 2015-08-04 03:19:15 <phantomcircuit> was the intent of the whitelisting patch thing to allow whitelisted connections to exceed the 125 connections limit?
  3 2015-08-04 04:02:36 <pouta> hi!
  4 2015-08-04 04:02:50 <pouta> I've git pulled and made some refractoring to code
  5 2015-08-04 04:03:03 <pouta> to comply with best coding design and practices
  6 2015-08-04 04:03:11 <pouta> how do I create a pull request?
  7 2015-08-04 04:03:40 <pouta> I already comited changes
  8 2015-08-04 04:05:58 <drazisil> pouta: if you save changes as a new branch, when you go back to the bitcoin repo on github it should suggest a pull request
  9 2015-08-04 04:06:16 <pouta> okok
 10 2015-08-04 04:06:21 <pouta> I have to fork it right?
 11 2015-08-04 04:06:52 <drazisil> fork, make changes on a new branch, create pull request.
 12 2015-08-04 04:07:39 <drazisil> Although I'm not sure how likely a refactor is to get accepted.
 13 2015-08-04 04:08:00 <phantomcircuit> sigh
 14 2015-08-04 04:08:29 <phantomcircuit> 0.11.0 on a windows system required rebuild after a power failure
 15 2015-08-04 04:08:58 <drazisil> phantomcircuit: how the heck does that happen?
 16 2015-08-04 04:09:22 <phantomcircuit> drazisil, im guessing some leveldb fuck up
 17 2015-08-04 04:09:29 <phantomcircuit> or possibly windows lying about writes completing
 18 2015-08-04 04:09:33 <phantomcircuit> or maybe both
 19 2015-08-04 04:09:51 <phantomcircuit> leveldb on windows is still mixing mmap and normal read/write calls
 20 2015-08-04 04:10:00 <phantomcircuit> im assuming they fuck it up even worse than unix systems do
 21 2015-08-04 04:10:21 <drazisil> probably.
 22 2015-08-04 04:10:56 <drazisil> so you can't just rebuld the chain, the actual client borked?
 23 2015-08-04 04:11:22 <phantomcircuit> no im reindexing
 24 2015-08-04 04:11:28 <phantomcircuit> it's going to take hours though
 25 2015-08-04 04:11:31 <phantomcircuit> which is ridiculous
 26 2015-08-04 04:11:39 <pouta> did it
 27 2015-08-04 04:11:45 <drazisil> oh. Yah. I read that as had to recompile
 28 2015-08-04 04:12:05 <pouta> Why is code refractoring not accepted?
 29 2015-08-04 04:12:57 <drazisil> pouta: I didn't say it wasn't. I said it might not be...I can think there's a decent chance for things to get changed by mistake.
 30 2015-08-04 04:13:46 <pouta> how do i delete the pull request? xDD
 31 2015-08-04 04:13:56 <drazisil> just close it
 32 2015-08-04 04:14:04 <pouta> I didnt commit pull requested the right commit
 33 2015-08-04 04:14:26 <pouta> where is it?
 34 2015-08-04 04:14:45 <drazisil> may have to wait for travis to finish checking it, not sure
 35 2015-08-04 04:15:07 <pouta> can i just create a new one
 36 2015-08-04 04:15:09 <pouta> ?
 37 2015-08-04 04:15:13 <pouta> with the right commit?
 38 2015-08-04 04:15:55 <drazisil> yes, but make sure you close the wrong one so it's not still hanging out
 39 2015-08-04 04:16:08 <pouta> I dont find the close button
 40 2015-08-04 04:16:46 <pouta> so I commited the changes
 41 2015-08-04 04:16:55 <pouta> and the pull request just updated to latest change
 42 2015-08-04 04:16:58 <pouta> awesome
 43 2015-08-04 04:19:20 <drazisil> pouta: Honestlt I would think the old is faster/better. Why use mem to create a variable that isn't needed/isn't used?
 44 2015-08-04 04:19:38 <pouta> I justified
 45 2015-08-04 04:19:47 <pouta> to improve readability
 46 2015-08-04 04:20:15 <pouta> but if its not significant enough to accept I'm okay with that
 47 2015-08-04 04:20:31 <drazisil> I'm not a bitcoin dev *shrugs*
 48 2015-08-04 04:20:40 <pouta> and I'm sure the compiler will optimize it anyway
 49 2015-08-04 04:41:43 <Kireji> Luke-Jr: phantomcircuit: wumpus:  thank you all for your help earlier.  reindexed and all appears to be running fine.
 50 2015-08-04 11:00:58 <jonasschnelli> call for review: https://github.com/bitcoin/bitcoin/pull/6315 thanks.
 51 2015-08-04 13:22:15 <pouta> Hello!
 52 2015-08-04 13:22:34 <pouta> I was wondering what kind of level of code refractoring is accepted?
 53 2015-08-04 13:23:23 <pouta> I dont know the bitcoin code enough to implement new features or bugfixes so if I want to help I must refractor and maybe unit test.
 54 2015-08-04 13:28:14 <Hans-Martin> pouta: I'm not a developer but I'd suspect that code refactoring is still somewhat risky. Do you have any specific spots in mind where refactoring would make the code better readable and maintainable?
 55 2015-08-04 13:29:06 <Hans-Martin> pouta: but adding meaningful unit tests might be a welcome contribution (as long as they're not redundant)
 56 2015-08-04 13:29:30 <wumpus> pouta: adding tests is very welcome!
 57 2015-08-04 13:29:42 <pouta> Hans-Martin: Yes sure, if you go arround the code you will find so many functions with two or 3 return statements
 58 2015-08-04 13:29:44 <wumpus> pouta: please do that; they're much easier to review, and concretely help the project
 59 2015-08-04 13:30:16 <wumpus> refactorings just for refactoring just increase the review load; there's 100 pulls open at least :(
 60 2015-08-04 13:30:31 <pouta> Aplying software engineering codig practices we should try to make our return very explicit.
 61 2015-08-04 13:30:49 <wumpus> yes, yes, but everyone has their own opinion on that, and we also just inherited this code
 62 2015-08-04 13:30:50 <pouta> wumpus: all those pulls are for refractor?
 63 2015-08-04 13:31:48 <pouta> One question, I know that software engineering part of a project is the most important and not the code itself
 64 2015-08-04 13:32:12 <pouta> Why isnt a well estabilished UML to explain bitcoin from head to toe?
 65 2015-08-04 13:32:26 <wumpus> pouta: no, some are for features too, or improvements, or bug fixes, but in general there's a lot happening at the same time
 66 2015-08-04 13:32:48 <wumpus> pouta: you can also help a lot by testing existing pulls
 67 2015-08-04 13:32:55 <wumpus> pouta: because no one did that?
 68 2015-08-04 13:33:12 <pouta> Is it a good idea to do that?
 69 2015-08-04 13:33:19 <pouta> or completly unnecessary?
 70 2015-08-04 13:33:28 <wumpus> feel free to make a UML diagram of the code, if that helps you - most seem to do well without, and it's hell to keep up to date
 71 2015-08-04 13:33:43 <pouta> I will have my masters in Software engineering and this would be a cool project
 72 2015-08-04 13:34:02 <wumpus> well sure developer documentation is certainly welcome
 73 2015-08-04 13:34:54 <pouta> but to maintain that UML we have to add new rules
 74 2015-08-04 13:35:03 <pouta> when new code is added an UML must be added
 75 2015-08-04 13:35:05 <pouta> and so on
 76 2015-08-04 13:35:14 <pouta> or else it will be impossible
 77 2015-08-04 13:35:44 <wumpus> I'm afraid that will be impossible to enforce in practice, people contribute to this project voluntarily, there are of course some coding standard but we can't force people to follow an entire checklist
 78 2015-08-04 13:35:50 <StormDev> you can make a script to generate uml from headers
 79 2015-08-04 13:35:59 <pouta> Yes
 80 2015-08-04 13:36:01 <wumpus> yes - doxygen does that, sort of
 81 2015-08-04 13:36:22 <pouta> StormDev I know that is possible with Java, C++ I have no idea
 82 2015-08-04 13:36:36 <wumpus> pouta: https://dev.visucore.com/bitcoin/doxygen/
 83 2015-08-04 13:37:07 <wumpus> not exactly UML, but it may help with browsing the code and has call graphs and such
 84 2015-08-04 13:37:53 <pouta> yes, that is helpfull
 85 2015-08-04 13:38:39 <pouta> but we both know that a project like bitcoin will have eventually a full UML and design changes to keep it "professional".
 86 2015-08-04 13:38:52 <pouta> but as of right now that is not important
 87 2015-08-04 13:38:57 <wumpus> well, only if someone makes it and keeps it up to date
 88 2015-08-04 13:39:29 <wumpus> in practice UML is hardly used in open source dev
 89 2015-08-04 13:39:47 <StormDev> in pro dev too...
 90 2015-08-04 13:39:56 <StormDev> to
 91 2015-08-04 13:40:03 <wumpus> e.g. there is no UML for Linux as well - at least not maintained with the source code, there are tons of books about it tho
 92 2015-08-04 13:40:26 <wumpus> about the kernel architecture and design
 93 2015-08-04 13:40:39 <wumpus> not so much for bitcoin (but our project is tiny in comparison :-)
 94 2015-08-04 13:40:42 <pouta> I know, because the purpose of the UML is to keep the development agile
 95 2015-08-04 13:40:52 <pouta> and whats more agile then open source? ahha
 96 2015-08-04 13:41:25 <pouta> I'm just trying to figure out ways to help this massive project
 97 2015-08-04 13:41:51 <pouta> coding for work can be boring, angularJS is kinda cool but php :(
 98 2015-08-04 13:42:16 <wumpus> there's a page with developer documentation here, it is meant to be high level and does not focus on the implementation but may help understand things: https://bitcoin.org/en/developer-documentation
 99 2015-08-04 13:46:07 <pouta> So care to explain to me what kind of refractoring is normally accepted?
100 2015-08-04 13:53:32 <wumpus> assume: none at all, we really value if you try to contribute something that improves the user experience, performance, or testing coverage, but refactoring-for-refactoring is very low prio
101 2015-08-04 13:54:30 <wumpus> once you have been working with the source code with a long time it's easier to see what can or should be refactored, but I certainly don't recommend it as a beginner project
102 2015-08-04 13:55:01 <jtimon> pouta: I do a lot of refactorings and you just have to accept that they're very slow because reviwing those changes is rarely a priority (unless it's make it easier to do some actual change later and things like that)
103 2015-08-04 13:56:36 <pouta> wumpus: thank you very much for your time
104 2015-08-04 13:58:27 <wumpus> jtimon: yes you've been working with the source code much longer and even then it goes slow and difficultly.
105 2015-08-04 13:59:10 <pouta> so as beginner project: should I do unit testing?
106 2015-08-04 14:00:20 <wumpus> yes, adding tests is one of the most useful things you can do as beginner, and also a good way to learn the code... start here: https://github.com/bitcoin/bitcoin#automated-testing
107 2015-08-04 14:01:41 <pouta> So where can I find the unit test that are already done?
108 2015-08-04 14:02:00 <pouta> So I know where I can find untested code
109 2015-08-04 14:02:22 <wumpus> src/tests for low-level unit tests and qa/rpc-tests for high-level tests
110 2015-08-04 14:04:05 <pouta> wumpus: thanks again!!
111 2015-08-04 14:05:12 <jtimon> pouta: there's a lot of untested code, new tests are very good for the project and far more likely to be accepted faster than refactors
112 2015-08-04 14:38:53 <harding> The IRC logs on bitcoinstats are missing the logs for July 4th (and several nearby days).  Does anyone know of an alternative log source for those days?  (I have the logs locally; I'm looking for somewhere that allows me to link to a particular line.)
113 2015-08-04 14:45:17 <justanotheruser> github gist?
114 2015-08-04 14:46:51 <harding> justanotheruser: I can do that if I need to, but I was hoping there was already another log somewhere.  I'm pretty sure I've seen people link to alternative pages with the log, I just don't recall any of the domains.
115 2015-08-04 14:47:48 <justanotheruser> Sorry, I don't know of any. A few days ago I tried to find one on google using text from local logs to no avail :(
116 2015-08-04 14:48:30 <harding> justanotheruser: heh, I tried the same. :-(
117 2015-08-04 15:36:08 <mn3monic> hello
118 2015-08-04 16:12:33 <rodarmor> Is there a way to get the logs from a failed Travis build?
119 2015-08-04 16:22:25 <drazisil> rodarmor: click on the detail in the PR
120 2015-08-04 16:24:20 <rodarmor> drazisil: I can get the contents of stdout, like here https://travis-ci.org/bitcoin/bitcoin/jobs/73953019, but I'm looking for the contents of the logfile, i.e. what would be in .bitcoin/debug.log
121 2015-08-04 16:24:42 <anddam> hi, should Bitcoin-Qt on OS X prevent the system from sleeping while syncing?
122 2015-08-04 16:26:01 <anddam> I started sync like 8 hours ago with 2 weeks to sync, I left the mac and came back like half an hour ago to check the status and it had still two days to sync, but I think the system may have gone to sleep since now it's fully synced
123 2015-08-04 16:26:17 <wumpus> anddam: what's the question? should it or does it?
124 2015-08-04 16:28:03 <wumpus> anddam: from what I remember it does set a flag to avoid being sent to the background with low priority, but I'm not aware that it prevents the computer completely from going to sleep
125 2015-08-04 16:28:42 <wumpus> I suppose your OS has settings to control it at that level
126 2015-08-04 16:35:30 <wumpus> that other flag was 'app nap' https://github.com/bitcoin/bitcoin/pull/5041
127 2015-08-04 16:40:01 <anddam> wumpus: the question is if core wallet does on osx, IIRC it's up to each app to ask the system to prevent sleeping
128 2015-08-04 16:40:41 <anddam> and the time passed since this morning doesn't add up for the 2 weeks sync, considering last 2 days were completed in (less than) half an hour
129 2015-08-04 16:41:16 <wumpus> I don't think it has any code to do that, but there may be some metadata-flag I don't know...
130 2015-08-04 16:41:41 <anddam> I expected a flag in the option, this could be an interesting feature to implement
131 2015-08-04 16:41:58 <anddam> s/option/preferences panel
132 2015-08-04 16:42:29 <anddam> wumpus: are you on osx?
133 2015-08-04 16:43:10 <wumpus> no, I don't have any OSX computers
134 2015-08-04 16:43:42 <anddam> no offense
135 2015-08-04 16:43:46 <anddam> ;-)
136 2015-08-04 16:44:16 <wumpus> but if you implement that feature it's likely to be merged, at least in -qt, I don't think bitcoind should have more platform-specific code
137 2015-08-04 16:47:07 <wumpus> but for the GUI there's already a lot :)
138 2015-08-04 16:48:42 <anddam> ofc, I was thinking about the Gui
139 2015-08-04 16:48:53 <anddam> never used Qt tho'
140 2015-08-04 16:49:43 <anddam> are there build instructions I should read as primer?
141 2015-08-04 16:49:53 <anddam> or is it classic autotools?
142 2015-08-04 16:52:11 <wumpus> doc/build-osx.md
143 2015-08-04 16:52:40 <wumpus> it's classic autotools but you need the right dependencies
144 2015-08-04 16:55:37 <anddam> I'll just pull in the build-dependencies for bitcoin port
145 2015-08-04 16:57:35 <warren> anddam: macports?  you probably would be happier with homebrew
146 2015-08-04 16:57:41 <anddam> I wouldn't
147 2015-08-04 16:58:11 <anddam> I've been using and contributing to mp for years, I know it, I can bend it and I'm satisfied with what it does
148 2015-08-04 16:58:31 <anddam> and as much as I despise Tcl, homebrew is Ruby, so…
149 2015-08-04 19:38:12 <halitosis> bitcoin-cli 0.11  changed getrawmempool to return the transactions in unordered, correct?
150 2015-08-04 19:38:32 <halitosis> while 0.10 returned them in sorted order?
151 2015-08-04 19:38:36 <halitosis> (by hash)
152 2015-08-04 19:39:15 <wumpus> not on purpose, but it may be a by-effect of a change in data structure (from map to unordered_map)
153 2015-08-04 19:41:06 <halitosis> fair enough, not a big deal. I can sort client-side. Probably shouldn't have been relying on that property to do diffs anyway
154 2015-08-04 19:42:01 <ThomasV> estimatefee returns very different results on different nodes (max response can be 3 times the min response). what causes that?
155 2015-08-04 19:42:55 <halitosis> ^ I also experience that
156 2015-08-04 19:43:42 <ThomasV> (it does not seem to be related to bitcoind uptime)
157 2015-08-04 19:43:48 <Squidicuz> different amount of cached TX's in the various nodes?
158 2015-08-04 19:46:29 <wumpus> halitosis: right, it was never documented what the order should be
159 2015-08-04 19:47:37 <ThomasV> Squidicuz: you mean TX that the node sees confirmed, but were not in mempool?
160 2015-08-04 19:49:14 <halitosis> wumpus: One issue is the results *look* sorted, but I believe they are not: http://privatepaste.com/c41b6cb5de
161 2015-08-04 19:49:54 <halitosis> Like based on the last characters, it looks like there's some canonical order. But my script takes a crap wiht 0.11 so i'm assuming that there's not
162 2015-08-04 19:51:04 <wumpus> probably needs a mention in the RPC doc that the returned order is undefined
163 2015-08-04 19:53:37 <Squidicuz> ThomasV, it is based on the fees of recently mined transactions and what is in the nodes mempool. I don't recall exactly how it works, perhaps someone else knows better and could explain
164 2015-08-04 19:54:22 <ThomasV> Squidicuz: it should not be based on what is in the mempool, but on what has been in the mempool, no?
165 2015-08-04 19:54:58 <wumpus> it's based on what leaves the mempool
166 2015-08-04 19:55:21 <ThomasV> yeah, that makes more sense ^
167 2015-08-04 19:56:11 <ThomasV> the estimatefee values returned by different nodes seem to be clustered around some values
168 2015-08-04 19:56:14 <Squidicuz> so if the TX was never there, it wouldn't count as leaving.. and would change the estimate? or does it check the recently mined blocks
169 2015-08-04 19:56:40 <ThomasV> Squidicuz: yes, that would change the est
170 2015-08-04 19:57:13 <ThomasV> but it does not explain why I get a clustered distribution
171 2015-08-04 19:57:30 <Squidicuz> groups of nodes with default, or similiar relay/tx settings?
172 2015-08-04 19:57:48 <Squidicuz> they would have similiar TX in->out
173 2015-08-04 19:58:03 <morcos> halitosis: wumpus: the mempool is sorted, but i think with the change of uint256 from arith_uint256, the sort order is based on the bytes which are stored in little endian format
174 2015-08-04 19:58:05 <ThomasV> hmm, maybe, yes
175 2015-08-04 19:58:25 <morcos> actually i said that backwards
176 2015-08-04 19:58:29 <Squidicuz> ThomasV, versus a node with a more strict relay policy.
177 2015-08-04 19:58:41 <wumpus> morcos: right, I understand what you mean
178 2015-08-04 19:58:48 <morcos> it's printed as if its a little endian number, but in reality its just a bunch of bytes
179 2015-08-04 19:58:49 <ThomasV> Squidicuz: good point. I will try to check that
180 2015-08-04 19:58:57 <morcos> or something
181 2015-08-04 19:59:02 <halitosis> morcos: Yeah, eye-balling it looks like the results are sorted that way. Which then means my script is taking a crap for no good reason ><
182 2015-08-04 19:59:07 <halitosis> i'll just verify it's really sorted like that
183 2015-08-04 19:59:16 <Squidicuz> ThomasV, cool. good luck :)
184 2015-08-04 19:59:45 <morcos> ThomasV: you're talking about estimatefee on 0.11 nodes?
185 2015-08-04 20:00:02 <morcos> 0.11 nodes will return very different results from 0.10
186 2015-08-04 20:00:06 <ThomasV> morcos: on various nodes (electrum servers)
187 2015-08-04 20:00:16 <ThomasV> morcos: why?
188 2015-08-04 20:00:18 <morcos> also i don't think either will work properly if they're not up most of the time
189 2015-08-04 20:00:23 <morcos> the algorithm changed completely
190 2015-08-04 20:00:42 <ThomasV> is it described in the changelog?
191 2015-08-04 20:00:49 <morcos> i would expect 0.11 nodes that have been running for more than a week should return pretty consistent results
192 2015-08-04 20:01:04 <morcos> it is mentioned in the release notes yes
193 2015-08-04 20:01:04 <ThomasV> ok
194 2015-08-04 20:01:33 <morcos> however, i will say i'm not very happy with the estimates .11 nodes are returning ...  i think they are still considerably more meaningful than 0.10 nodes
195 2015-08-04 20:02:24 <morcos> but they're givign you a snapshot averaged over the last week or two, (half-life of 2.5 days) when in reality the recent history is much more relevant
196 2015-08-04 20:03:15 <ThomasV> so the half life is too long?
197 2015-08-04 20:03:31 <morcos> i've been working on trying to figure out the best way to improve it.  i think at the least it should be more conservative so you don't send txs that'll be stuck for a long time which has been happening during the recent spam attacks
198 2015-08-04 20:03:44 <morcos> well impossible to eliminate that, but reduce the time for which that happens
199 2015-08-04 20:04:15 <morcos> yes its too long, and the success threshold is too low (85%).
200 2015-08-04 20:04:25 <morcos> but there are tradeoffs
201 2015-08-04 20:04:52 <morcos> i think the clearest win is too increase the success threshold to 95% (except that just doesn't work for estimating 1)
202 2015-08-04 20:06:04 <morcos> wumpus: let me know if you ever have a timeline for a .11.1 release, bc this might be something nice to get in there for it..  it wouldn't be a big change, but its just somehow deciding what the "right" change is.
203 2015-08-04 20:06:36 <ThomasV> morcos: 2 is more reliable than 1 ?
204 2015-08-04 20:07:21 <morcos> historically speaking even the very highest fee transactions only had about a 90% chance of being included in the next block (maybe the miners hadn't reselected tx's since the tx came in)
205 2015-08-04 20:07:39 <morcos> so it makes estimatefee 1 subject to a lot of noise
206 2015-08-04 20:07:57 <morcos> so yeah, 2 is a lot better to use, we changed the default in core to 2
207 2015-08-04 20:08:17 <ThomasV> I see
208 2015-08-04 20:09:07 <wumpus> morcos: no current conceret plans for 0.11.1, but if you send in a pull and think it should be backported into the 0.11 branch just let me know
209 2015-08-04 20:09:44 <morcos> but if you're trying to put something together that will hold up in spam attacks, i'd either wait for 0.11.1 or hack around with the estimate code or add in some hard coded minimum
210 2015-08-04 20:10:04 <morcos> wumpus: do you have any thoughts of how this should work
211 2015-08-04 20:10:15 <wumpus> one of the mempool limiting patches should definitely go in
212 2015-08-04 20:10:19 <morcos> inherently fee estimation is kind of an art
213 2015-08-04 20:10:24 <ThomasV> morcos: so it'sprobably better to use factor*(estimatefee 2), instead of (estimatefee 1) ?
214 2015-08-04 20:11:08 <morcos> and i dont' want to go down the path of just tweaking constants each time
215 2015-08-04 20:11:16 <morcos> perhaps it should be more user configurable
216 2015-08-04 20:11:30 <wumpus> yes, it's a difficult problem
217 2015-08-04 20:11:31 <morcos> so that the community as a whole can come up with different values they like to use
218 2015-08-04 20:12:11 <wumpus> making it configurable only works if the configured parameters make sense to users
219 2015-08-04 20:12:20 <morcos> ThomasV: i'm hestitant to spit out a formula, but yeah maybe something liek that or max((ef 2) , (ef 3) + constant)
220 2015-08-04 20:13:00 <morcos> the idea behind that is that if it takes the same fee to get confirmed in 3 (or 4 or whatever) blocks then maybe you dont' have a whole lot of buffer
221 2015-08-04 20:13:33 <morcos> I will be making some improvement to core along those lines, i just have to figure out what
222 2015-08-04 20:14:19 <morcos> wumpus: ha, yeah i suppose...
223 2015-08-04 20:15:22 <morcos> the 2 main parameters make some sense...  whats the recent time period you want to consider (measured by halflife) and what percentage of txs do you require to be confirmed in your target (success rate)
224 2015-08-04 20:15:55 <morcos> the problem is the best answer is probably some small combination of things....
225 2015-08-04 20:16:54 <wumpus> time-based parameters and succes rate are explainable to users. Although I don't see many users tweaking them, still.
226 2015-08-04 20:17:35 <morcos> could be the defaults everyone uses
227 2015-08-04 20:17:38 <morcos> shoot
228 2015-08-04 20:18:12 <morcos> stupid client.  i was thinking that at least if its configurable, there would be more people than me who could easily try out different values.
229 2015-08-04 20:18:36 <Squidicuz> .-.
230 2015-08-04 20:18:45 <morcos> and maybe we'd more quickly find closer to the ideal defaults for people to use
231 2015-08-04 20:18:45 <Squidicuz> everyone loves to run defaults
232 2015-08-04 20:19:15 <morcos> people like ThomasV and others who've asked me about issues with fee estimation, could easily try things without having to recompile
233 2015-08-04 20:19:49 <wumpus> morcos: well I'm not against making the parameters configurable (eg through a --help-debug option)
234 2015-08-04 20:20:01 <Squidicuz> not having to recompile is nice
235 2015-08-04 20:20:01 <wumpus> it's good to be able to experiment without rebuilding, sure
236 2015-08-04 20:24:39 <morcos> yeah the success threshold should have been configurable from the beginning, you dont' even need to stop the program to change that, just call the function with a different value.
237 2015-08-04 20:38:39 <Lightsword> I’m seeing these slow GBT sockets calls on block changes(https://gist.github.com/jameshilliard/4730153ecdd213620c54) which seems to correlate with these messages in my debug.log https://gist.github.com/jameshilliard/292d5be5aad5f737c7a2 any idea what might be causing this?
238 2015-08-04 20:42:23 <wumpus> Lightsword: maybe a very large mempool?
239 2015-08-04 20:43:43 <Lightsword> wumpus, "pooledtx" : 46179,"currentblocksize" : 998994,"currentblocktx" : 532,
240 2015-08-04 20:44:29 <Lightsword> the socket delays seems to correlate with UpdateTip: new best in my debug.log
241 2015-08-04 20:44:37 <wumpus> that's reasonably large, yes
242 2015-08-04 20:45:24 <wumpus> updatetip simply means that a new block is coming in
243 2015-08-04 20:45:43 <Lightsword> wumpus, thats what I figured, does that happen on all block changes?
244 2015-08-04 20:45:43 <wumpus> and being processed and added to the best-chain data structure
245 2015-08-04 20:45:53 <wumpus> yes
246 2015-08-04 20:46:09 <wumpus> there will be a message like that in your log for every block # (more, in the case of reorgs)
247 2015-08-04 20:48:05 <Lightsword> wumpus, whats the currently recommended settings when running a pool? right now this is the relevant part of my bitcoin.conf https://gist.github.com/jameshilliard/55c392d79838c6227187
248 2015-08-04 20:48:08 <wumpus> so if that causes the delay, it is the validation itself that holds up RPC
249 2015-08-04 20:48:40 <wumpus> which is normal, but validating a block should be fast enough unless you have very slow hardware
250 2015-08-04 20:48:45 <Lightsword> wumpus, the validation of the old block or as part of creating the new block template?
251 2015-08-04 20:48:54 <Lightsword> this is run from a high end server
252 2015-08-04 20:49:04 <Lightsword> cpu load and ram usage is very low
253 2015-08-04 20:50:58 <wumpus> Lightsword: config seems fine to me; see https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md#transaction-flooding for settings you can use if your mempool is growing too large
254 2015-08-04 20:51:31 <Lightsword> wumpus, how would I know if my mempool is too large? are there issues other than running out of RAM?
255 2015-08-04 20:52:11 <wumpus> Lightsword: getblocktemplate becomes slow
256 2015-08-04 21:33:15 <rodarmor> Has anyone had success using an IDE for working on Core?
257 2015-08-04 21:39:09 <shurnormal> I'm not a regular on this, but sometimes I get OK kdevelop no matter what C/C++ project, when it does not want to segfault. There's the CLion promise too, but it's too much CMake centered yet. Why bother anyway since Vim grants more control than JetBrains?
258 2015-08-04 21:41:26 <rodarmor> I'm a pretty diehard vim/terminal user, but I figure I might as well try using an IDE, mostly for nice file browsing.
259 2015-08-04 21:42:11 <wumpus> opening and editing the files in an IDE should be easy, building can be a problem if it requires some specific build system other than autoconf
260 2015-08-04 21:42:53 <shurnormal> If you have the luck your KDevelop doesn't segfault, maybe fits you.
261 2015-08-04 21:43:09 <wumpus> I've used qt creator in the past
262 2015-08-04 21:43:20 <wumpus> but I'm fully over to vim for everything these days
263 2015-08-04 21:49:56 <rodarmor> Yeah, I think the truth is that I've gotten lazy, and I just need to invest some time improving my vim-based workflow.
264 2015-08-04 21:51:54 <Lightsword> so, to clarify what holds up GBT is the generation of the new block template and not the validation of the previous block right?
265 2015-08-04 21:54:05 <wumpus> Lightsword: it's unclear what is the case, but my guess would be the generation of a new block template
266 2015-08-04 21:54:27 <wumpus> Lightsword: you could check by restarting the node (and thus clearing the mempool), see if it becomes faster
267 2015-08-04 21:54:49 <Lightsword> its somewhat sporadic but seems to be worse when theres more transactions