1 2017-01-15 00:05:04	0|sipa|BlueMatt: probably less.. even 50ms on average, but if it happens while any other peer sends us anything, it's less also
  2 2017-01-15 00:05:10	0|sipa|anyway... very simple change
  3 2017-01-15 00:07:23	0|BlueMatt|sipa: yea, see comment on pr, its probably close to min(closest peer RTT, 100ms)
  4 2017-01-15 00:08:55	0|BlueMatt|note that if another peer sends you a message during validation it may not be enough to get the loop to do a full go-around
  5 2017-01-15 00:09:22	0|BlueMatt|oh, actually take that back, i suppose it is
  6 2017-01-15 00:09:37	0|BlueMatt|anyway, whatever, its a super trivial change that will make a difference sometimes
  7 2017-01-15 00:09:52	0|BlueMatt|IIRC morcos said something about having been testing +/- that change for a while, and i realized its not pr'ed anywhere
  8 2017-01-15 00:11:14	0|BlueMatt|ofc we should, later, remove that and move the whole block-announce logic from SendMessages into the UpdatedBlockTip callback
  9 2017-01-15 00:11:17	0|BlueMatt|but....for later
 10 2017-01-15 00:17:17	0|morcos|BlueMatt: ha, thats exactly the same as what i did except my commits were in the opposite order.  :)
 11 2017-01-15 00:17:57	0|BlueMatt|morcos: well github is sorting them in the wrong order :p
 12 2017-01-15 00:18:20	0|morcos|no i know.. my point was i didn't realize i needed to make it public
 13 2017-01-15 00:18:28	0|BlueMatt|oh, neither did I
 14 2017-01-15 00:18:40	0|BlueMatt|thats why github is displaying them as "wake" then "make public"
 15 2017-01-15 00:18:41	0|BlueMatt|:p
 16 2017-01-15 00:18:49	0|morcos|oh ha, and thats why they are sorted in that order
 17 2017-01-15 00:19:19	0|BlueMatt|yea, date-based
 18 2017-01-15 00:19:19	0|morcos|what are you worried about missing 0.14
 19 2017-01-15 00:19:23	0|morcos|i thought we were doing pretty good
 20 2017-01-15 00:19:31	0|morcos|i mean there are some bugs that still need fixing
 21 2017-01-15 00:19:59	0|morcos|i mean maybe bumpfee will miss it i guess.  but i won't cry...
 22 2017-01-15 00:20:02	0|BlueMatt|I'm not confident in the hd split one, and still feel like I need to do more review on bumpfee
 23 2017-01-15 00:20:16	0|BlueMatt|yea, I'm concerned about bumpfee and hd split
 24 2017-01-15 00:20:30	0|morcos|oh yeah..  the split one .. htat might be bad.. i keep thinking i'm going to review that, and then when i realize i have to read a BIP first i stop
 25 2017-01-15 00:21:02	0|BlueMatt|heh, i skipped the concept ack stage...figure sipa will tell us if its the wrong way to do it :p
 26 2017-01-15 00:21:17	0|BlueMatt|but I think I found some bugs in the implementation yesterday, so waiting on jonasschnelli to reappear :/
 27 2017-01-15 00:22:07	0|sipa|i still haven't looked at the split :(
 28 2017-01-15 01:27:52	0|achow101|have we figured out what's wrong with mingw on ubuntu 16.04?
 29 2017-01-15 01:30:42	0|BlueMatt|i thought i remembered wumpus saying something which sounded like he had debugged it back to a patch ubuntu applied to their gcc
 30 2017-01-15 02:36:51	0|gmaxwell|I really wish someone would encourage him to ditch the inflamitory titles.
 31 2017-01-15 02:37:44	0|sipa|?
 32 2017-01-15 02:37:45	0|gmaxwell|so far the ones I've looked at were not possible. Worth changing to make the code more robust in the face of future changes perhaps, but right now with the way our release notes work it's going to end up with a wall of things that sound serious but aren't and people are gonna wonder why we're not backporting them.
 33 2017-01-15 02:38:06	0|gmaxwell|sipa: the "Avoid null dereference" "Avoid divide by zero" and so on.
 34 2017-01-15 02:52:22	0|bitcoin-git|[13bitcoin] 15practicalswift closed pull request #9560: [rpc] Avoid possibility of NULL pointer dereference in getblocktemplate(...) (06master...06avoid-null-pointer-dereference-in-rpc-blockchain) 02https://github.com/bitcoin/bitcoin/pull/9560
 35 2017-01-15 02:56:35	0|luke-jr|gmaxwell: I'm not sure the average user considers them to be inflamitory at least
 36 2017-01-15 02:58:55	0|gmaxwell|When 0.13.2 came out I had some journalist ask me for info about the release and I was going through the release notes and realizing how not-useful many of our short entries are.. (my own too!).  In this case, if I saw a bunch of those I'd be worried about vulnerabilities.
 37 2017-01-15 02:59:12	0|gmaxwell|which isn't a correct worry at least for any of those PRs I've looked at so far.
 38 2017-01-15 02:59:42	0|gmaxwell|at least for technically advanced average users who have heard what kinds of names vulnerablities come under.
 39 2017-01-15 03:01:12	0|luke-jr|oh well, disarmed one that wasn't really even a bug
 40 2017-01-15 03:03:41	0|sipa|FWIW, ubsan would detect all of these potential issues that practicalswift just opened PRs for
 41 2017-01-15 03:04:27	0|sipa|so at least in none of the unit tests or rpc tests it gets triggered
 42 2017-01-15 03:10:40	0|gmaxwell|I think for a lot they're just provably not reachable now, but maybe the code would change again.
 43 2017-01-15 03:25:40	0|wumpus|BlueMatt: no, I never got to the bottom of it, latest known information is in https://github.com/bitcoin/bitcoin/issues/8732
 44 2017-01-15 03:27:03	0|wumpus|BlueMatt: well there's two issues really: the posix/non-posix mutex issue (c++11 compatibliity mingw) and the fstack-protector-all one
 45 2017-01-15 03:32:46	0|wumpus|gmaxwell: it's the pull request titles (not commit messages) that end up in the shortlog, if there's any PR titles that got merged for 0.14 that you find inflammatory please let me know, makes sense to change them before the list is generated
 46 2017-01-15 03:33:53	0|gmaxwell|oh interesting! I didn't realize that. well makes it easier to change!
 47 2017-01-15 03:34:11	0|luke-jr|☺
 48 2017-01-15 03:34:39	0|gmaxwell|Useful to think about them from the perspective of someone upgrading and trying to decide if which impact them.
 49 2017-01-15 03:34:58	0|gmaxwell|which isn't what I've historically thought about while setting PR titles/commit shortlogs.
 50 2017-01-15 03:35:22	0|gmaxwell|maybe other people have, most are okay. Some not as much.
 51 2017-01-15 03:36:23	0|wumpus|heh I tend to already edit issue titles that are absolute crap (like "update main.cpp")
 52 2017-01-15 03:40:46	0|wumpus|also the list in the release notes is a subset: e.g. small typo fixes, straightforward move-only without user impact I tend to drop. The list is so long that some probably slip by though. If e.g. a technical writer could spend some time with the release notes that'd be awesome.
 53 2017-01-15 03:41:28	0|wumpus|I think more important than the shortlist are the longer items though. We need to be doubly careful about those.
 54 2017-01-15 03:42:52	0|gmaxwell|blockstream can supply someone to help, and I also think just asking for more assistance will get us some. (maybe?) seems like something where our extended community has some more people who would like to help with that sort of thing.
 55 2017-01-15 03:43:09	0|wumpus|in the past that has never helped, at least :)
 56 2017-01-15 03:44:12	0|luke-jr|I've already written some release notes when I added some of these things in Knots; could copy those over
 57 2017-01-15 03:44:45	0|wumpus|yes that'd be useful luke-jr
 58 2017-01-15 03:45:33	0|luke-jr|probably won't get a chance until after I time-out on reviews Monday, but I'll try to remember then
 59 2017-01-15 03:46:09	0|wumpus|in any case I'll generate the first list and insert it into the release notes just before rc1 - otherwise there's too much diff noise and work to keep it up to date as a lot of merges still have to happen
 60 2017-01-15 03:46:35	0|wumpus|yes, it's not something to worry about now
 61 2017-01-15 03:48:58	0|wumpus|maybe using a collaborative editing site such as google docs would make sense for the release notes? It encourages more editing than having a document on the branch. Although we have to be careful who to give edit access then :)
 62 2017-01-15 03:49:29	0|sipa|perhaps for a first draft - unsure
 63 2017-01-15 03:49:30	0|wumpus|or a wiki page
 64 2017-01-15 03:49:43	0|wumpus|yes
 65 2017-01-15 03:49:44	0|gmaxwell|yea, would be fine to just use a page on the bitcoin wiki.
 66 2017-01-15 03:50:25	0|wumpus|it's a bit of a pity that mediawiki doesn't support markdown
 67 2017-01-15 03:50:53	0|gmaxwell|well we don't need to see the markup there and I don't think anything in markdown will break mediawiki
 68 2017-01-15 03:51:06	0|gmaxwell|in fact it would be fine to put it in <pre> tags.
 69 2017-01-15 03:51:14	0|wumpus|everything is set up for markdown-formatted release notes. Not that it makes a lot of difference, it's not like we use a lot of markup in the text usually.
 70 2017-01-15 03:51:20	0|wumpus|right, pre tags makes sense
 71 2017-01-15 03:52:14	0|MarcoFalke_publi|What about the GitHub wiki?
 72 2017-01-15 03:52:22	0|MarcoFalke_publi|I never tried it, though.
 73 2017-01-15 03:54:25	0|wumpus|good point, that one does use markdown. Though github wiki has very restriced access control IIRC, only those withrepo write permission can edit it
 74 2017-01-15 03:54:40	0|wumpus|(not 100% sure about that maybe it's a setting)
 75 2017-01-15 03:55:18	0|MarcoFalke_publi|Luke seems to be using it for the bips repo.
 76 2017-01-15 03:55:20	0|wumpus|but that would defeat the point if it is to get outside people involved
 77 2017-01-15 03:58:17	0|MarcoFalke_publi|You can enable it for any GitHub user: https://help.github.com/articles/changing-access-permissions-for-wikis/
 78 2017-01-15 03:58:23	0|sipa|wumpus: i think the issue to report things for release notes was a great idea
 79 2017-01-15 03:58:41	0|MarcoFalke_publi|Agree
 80 2017-01-15 03:58:44	0|sipa|there are so many things that seem to get forgotten when the notes have to be generated too quickly
 81 2017-01-15 03:59:03	0|wumpus|though even that may still be useful for us, if we prefer editing in the wiki to committing to git on the branch
 82 2017-01-15 03:59:23	0|wumpus|let's just try
 83 2017-01-15 03:59:39	0|achow101|what kind of stuff needs to be done for the release notes? I may be able to help
 84 2017-01-15 03:59:46	0|wumpus|MarcoFalke_publi: oh nice
 85 2017-01-15 04:00:15	0|gmaxwell|well I think wiki may just be best for an initial pass.. I felt kinda bad about that windows update PR, since basically I knew people were going to rewrite it in the PR... but I thought it better to do something.
 86 2017-01-15 04:00:16	0|wumpus|achow101: make sure it includes only user facing things, and that pull titles are not inflammatory/panic-arousing
 87 2017-01-15 04:00:36	0|wumpus|achow101: (and of course general English spelling and structure related editing etc)
 88 2017-01-15 04:01:02	0|wumpus|gmaxwell: yes the github format just isn't too great for editing documents
 89 2017-01-15 04:01:07	0|achow101|ok. I think I can help with that
 90 2017-01-15 04:01:12	0|gmaxwell|and also just generally informative...  focus should be on the impact/non-impact to users not the how. (often our commit messages and PR messages are very how oriented.)
 91 2017-01-15 04:01:53	0|MarcoFalke_publi|Include a wiki page with how to write the release notes :)
 92 2017-01-15 04:03:20	0|wumpus|shall I make a new repository for the wiki? that seems better for access control
 93 2017-01-15 04:05:22	0|gmaxwell|sure. I don't think we should intend to retain the history/work there.. should just be a scratchpad.
 94 2017-01-15 04:06:28	0|MarcoFalke_publi|https://github.com/bitcoin-core/bitcoin-devwiki/wiki
 95 2017-01-15 04:06:48	0|wumpus|its' just an experiment for now, let's not worry about retaining history and such, may nuke the whole thing if it doesn't work out :)
 96 2017-01-15 04:07:57	0|achow101|will it be open to everyone?
 97 2017-01-15 04:08:57	0|wumpus|achow101: don't think it hurts to try. If it's abused, we can always lock it down more
 98 2017-01-15 04:09:13	0|achow101|great. just don't tell reddit :)
 99 2017-01-15 04:11:41	0|luke-jr|wumpus: Google Docs does have a nice "suggest" feature
100 2017-01-15 04:12:27	0|luke-jr|wumpus: github wiki for bips at least seems to be editable by all?
101 2017-01-15 04:12:49	0|luke-jr|but personally I think GDocs is the better solution but whatever
102 2017-01-15 04:14:38	0|wumpus|luke-jr: yes, gdocs has some nice features as well
103 2017-01-15 04:17:01	0|achow101|are release notes written from the last major version or the last minor version
104 2017-01-15 04:17:14	0|wumpus|the last minor version of the last major version
105 2017-01-15 04:17:26	0|achow101|ok
106 2017-01-15 04:18:04	0|wumpus|so relative to 0.13.2 int this case unless there's another release on the 0.13 branch inthe meantime
107 2017-01-15 04:20:13	0|luke-jr|hmm, maybe we should have non-devs write our release notes for us :P
108 2017-01-15 04:21:07	0|luke-jr|for reference: https://github.com/bitcoinknots/bitcoin/blob/v0.13.2.knots20170102/doc/release-notes.md https://github.com/bitcoinknots/bitcoin/blob/45f61ea047b08dc18a2cee7f6d946c94de8dafcd/doc/release-notes.md https://github.com/bitcoinknots/bitcoin/blob/c372395f0d8b8b7dde63f6489e98e03264abe2d7/doc/release-notes.md
109 2017-01-15 04:21:26	0|luke-jr|in case any non-dev wants to start working on it ;)
110 2017-01-15 04:43:42	0|fanquake|practicalswift Any chance your idling in here under a different handle?
111 2017-01-15 04:57:15	0|gmaxwell|fanquake: you could send an email I guess.
112 2017-01-15 05:00:49	0|bitcoin-git|13bitcoin/06master 147094bf7 15Gregory Maxwell: Trim down the XP notice and say more about what we support....
113 2017-01-15 05:00:49	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/23281a4dc3af...4105cb6fd964
114 2017-01-15 05:00:50	0|bitcoin-git|13bitcoin/06master 144105cb6 15MarcoFalke: Merge #9550: Trim down the XP notice and say more about what we support....
115 2017-01-15 05:01:04	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9550: Trim down the XP notice and say more about what we support. (06master...06we_got_it_already) 02https://github.com/bitcoin/bitcoin/pull/9550
116 2017-01-15 05:01:17	0|gmaxwell|that as merged fast. need to make more doc changes. :P
117 2017-01-15 05:02:10	0|fanquake|gmaxwell Yea I might do that. Was just going to comment on the stream of new PRs. Would be nice if there were grouped together a bit more, rather than seperate for every change.
118 2017-01-15 05:03:05	0|gmaxwell|fanquake: Yea, good to encourage the contribution but making manage similar changes before the first goes in might result in many that need to be adjusted.
119 2017-01-15 05:05:05	0|fanquake|gmaxwell yep. Definitely don't want to turn away what looks like an interested new contributor. Just going to point out that the repo is already somewhat overwhelmed with PRs, and review is the bottleneck. Opening many trivial PRs also generates a bit of noise.
120 2017-01-15 05:05:29	0|MarcoFalke|"trivial" :P
121 2017-01-15 05:06:29	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #8889: Qt/ModalOverlay: Use theme tooltip colours (06master...06overlay_theme) 02https://github.com/bitcoin/bitcoin/pull/8889
122 2017-01-15 05:07:12	0|norotartagen|trivial!
123 2017-01-15 05:08:01	0|fanquake|Going to close 9263 now that 9531 has been merged. Any objections?
124 2017-01-15 05:11:29	0|sipa|#9263
125 2017-01-15 05:11:31	0|gribble|https://github.com/bitcoin/bitcoin/issues/9263 | release notes: Only free transactions are being removed, not priority. by luke-jr · Pull Request #9263 · bitcoin/bitcoin · GitHub
126 2017-01-15 05:14:05	0|luke-jr|fanquake: objection.
127 2017-01-15 05:14:09	0|luke-jr|9263 should be merged
128 2017-01-15 05:15:01	0|luke-jr|there is no consensus to remove priority, and doing so would be inappropriate abuse of position to force a specific policy on miners.
129 2017-01-15 05:15:37	0|luke-jr|it's also a small amount of well-isolated and harmless code
130 2017-01-15 05:20:38	0|gmaxwell|luke-jr: as far as I know you're the only person saying otherwise, and I think everyone else has expressed a lot of willingness to help improve the setpriority interface to make it unneeded. (including, in this release, saving the updates)
131 2017-01-15 05:21:10	0|gmaxwell|and I'm not aware of any current evidence suggesting that it plays a role in a non-trivial number of blocks getting mined today (or even any?)
132 2017-01-15 05:23:01	0|luke-jr|gmaxwell: the existence of objections is itself proof there is no consensus. the onus of evidence it is unused should be on those wishing to remove it (and there is in fact proof it is used on the PR comments).
133 2017-01-15 05:24:08	0|luke-jr|last time it came up, I went to the trouble to get proof it is used; doing so again would be at the very least difficult because the information to detect CPFP is not something available
134 2017-01-15 05:25:02	0|gmaxwell|luke-jr: you're trying to force people to continue to support and maintain functionality they don't care to support; it has a real cost. Alternatives have been provided, interest from actual users appears to be nearly zero.  And it is not a consensus feature at all.
135 2017-01-15 05:25:38	0|gmaxwell|If everyone acted like you do on this about things they care about very little would get done.
136 2017-01-15 05:28:07	0|luke-jr|it is 100 lines of isolated code that has virtually no maintenance cost. furthermore, I am a regular contributor and as such I'm not forcing anyone else to do the little work to maintain it. alternatives are overly and unnecessarily complex and create significantly more burden than simply leaving the code in as-is.
137 2017-01-15 05:28:25	0|gmaxwell|if you don't think maintaining it has a cost-- then I assume you'd just solve the disagreement by keeping it in knotts.
138 2017-01-15 05:28:47	0|gmaxwell|Every time someone else changes something in the system that possibly interacts with it, they have to consider it.
139 2017-01-15 05:29:05	0|gmaxwell|You can't deflect these costs except by doing all the work yourself.
140 2017-01-15 05:29:23	0|luke-jr|I'm not sure anyone but me is constantly nagged about removing things they support and people use..
141 2017-01-15 05:29:31	0|gmaxwell|also it hasn't been removed yet-- presumably once depricated it will get removed when it's actually in the way.
142 2017-01-15 05:30:02	0|gmaxwell|(we have things that have been marked depricated for years still not removed because there hasn't yet been good cause to do so.)
143 2017-01-15 05:30:04	0|luke-jr|I probably could just maintain it in Knots, though.
144 2017-01-15 05:30:33	0|gmaxwell|Good! certantly no one has any concern or objection with it being out there! its not at all incompatible.
145 2017-01-15 05:31:03	0|luke-jr|gmaxwell: perhaps a reasonable compromise could be found by removing "[removed] in the next major version", and leave it alone until it actually creates an issue?
146 2017-01-15 05:43:30	0|bitcoin-git|[13bitcoin] 15laanwj pushed 5 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/4105cb6fd964...01c4576a3914
147 2017-01-15 05:43:31	0|bitcoin-git|13bitcoin/06master 1402fcb29 15fanquake: [depends] Qt 5.7.1
148 2017-01-15 05:43:31	0|bitcoin-git|13bitcoin/06master 142b32dea 15Cory Fields: depends: use new variable layout for qt sdk
149 2017-01-15 05:43:32	0|bitcoin-git|13bitcoin/06master 14c37ea4d 15Cory Fields: depends: fix qt translations build...
150 2017-01-15 05:43:45	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9469: [depends] Qt 5.7.1 (06master...06depends-0-14-0-qt) 02https://github.com/bitcoin/bitcoin/pull/9469
151 2017-01-15 05:45:18	0|bitcoin-git|13bitcoin/06master 14e6111b2 15Matt Corallo: Make peer id logging consistent ("peer=%d" instead of "peer %d")
152 2017-01-15 05:45:18	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/01c4576a3914...f62bc10a607c
153 2017-01-15 05:45:19	0|bitcoin-git|13bitcoin/06master 14f62bc10 15Wladimir J. van der Laan: Merge #9486: Make peer=%d log prints consistent...
154 2017-01-15 05:45:31	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9486: Make peer=%d log prints consistent (06master...062017-01-peer-log-consistency) 02https://github.com/bitcoin/bitcoin/pull/9486
155 2017-01-15 05:57:38	0|luke-jr|sipa: BlueMatt: did you even look at the new PR changes? should I give up on a compromise and go back to the original?
156 2017-01-15 05:59:36	0|sipa|luke-jr: i did not notice you changed it; i'm fine with the text, can you also change the pr title?
157 2017-01-15 06:00:00	0|luke-jr|ok, updated
158 2017-01-15 06:46:51	0|achow101|I went through the release notes todo and added most of it to the release notes in the wiki
159 2017-01-15 06:47:15	0|achow101|of course it can and should be improved, but at least most of it is now there so it won't be forgotten
160 2017-01-15 09:50:42	0|BlueMatt|luke-jr: which pr?
161 2017-01-15 14:22:19	0|luke-jr|BlueMatt: 9263
162 2017-01-15 17:22:34	0|sipa|cfields: with --enable-debug we build with -O0... any reason not to use -Og (which enables certain warnings through better analysis, that the compiler would not find at -O0)
163 2017-01-15 17:23:02	0|cfields|sipa: iirc -Og was only added to clang recently
164 2017-01-15 17:23:28	0|cfields|but sure, we could check for it and use it instead, if it works
165 2017-01-15 17:25:08	0|sipa|cfields: it's been in gcc since 4.8, iirc the lowest version of gcc we support now
166 2017-01-15 17:25:23	0|cfields|sipa: https://github.com/llvm-mirror/clang/commit/14bfc9e99e6e6903b09480a22c153032be77ae4e
167 2017-01-15 17:25:45	0|sipa|ah, i see
168 2017-01-15 17:25:58	0|sipa|i thought we were claiming "it's only available since a recent version of cland"
169 2017-01-15 17:26:33	0|cfields|ah, no. just that it was gcc-only until very recently
170 2017-01-15 17:26:40	0|sipa|i see
171 2017-01-15 17:27:03	0|sipa|oh, and it's equal to -O1 in clang
172 2017-01-15 17:27:26	0|cfields|sounds useful though. Lots of things about running at -O0 is very useless.
173 2017-01-15 17:29:42	0|sipa|cfields, luke-jr, BlueMatt: -fsanitize=thread is useless as expected... i'm bombarded with warnings about races in BDB...
174 2017-01-15 17:30:07	0|cfields|sipa: within bdb itself?
175 2017-01-15 17:30:11	0|sipa|(unsure if it's our BDB wrapper or BDB itself)
176 2017-01-15 17:30:17	0|cfields|ok
177 2017-01-15 17:30:32	0|cfields|sipa: depends built with sanitize-thread too? or just bitcoin?
178 2017-01-15 17:30:43	0|sipa|just bitcoin, so far
179 2017-01-15 17:31:05	0|sipa|i'm already happy to be able to satisfy asan, lsan, and ubsan
180 2017-01-15 17:31:09	0|cfields|sipa: iirc when i messed with it, it appeared as though accounting was messed up if the depends weren't built with it too
181 2017-01-15 17:31:10	0|sipa|msan and tsan sound tricker
182 2017-01-15 17:31:13	0|sipa|*trickier
183 2017-01-15 17:32:42	0|cfields|sipa: er, --disable-wallet :)
184 2017-01-15 17:33:46	0|sipa|cfields: i can't run the rpc tests in that case
185 2017-01-15 17:34:08	0|cfields|ah, right
186 2017-01-15 17:44:59	0|bitcoin-git|13bitcoin/06master 14d4781ac 15Gregory Sanders: Set peers as HB peers upon full block validation
187 2017-01-15 17:44:59	0|bitcoin-git|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f62bc10a607c...8a445c5651ed
188 2017-01-15 17:45:00	0|bitcoin-git|13bitcoin/06master 148a445c5 15Pieter Wuille: Merge #9400: Set peers as HB peers upon full block validation...
189 2017-01-15 17:45:10	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #9400: Set peers as HB peers upon full block validation (06master...06maybesetfullblock) 02https://github.com/bitcoin/bitcoin/pull/9400
190 2017-01-15 18:20:33	0|bitcoin-git|[13bitcoin] 15practicalswift closed pull request #9559: [net] Avoid possibility of NULL pointer dereference in ProcessMessage(...) (06master...06avoid-null-pointer-deref-in-processmessage) 02https://github.com/bitcoin/bitcoin/pull/9559
191 2017-01-15 18:24:11	0|profall|Is there any good documentation someone can link me that covers everything I can put in bitcoin.conf and what it does.
192 2017-01-15 18:27:49	0|mol|profall, ask in #bitcoin
193 2017-01-15 18:27:55	0|profall|ok
194 2017-01-15 19:07:19	0|morcos|profall: also running bitcoind -help prints out all the command line options which are the same as what can be put in the config file...
195 2017-01-15 19:07:53	0|arubi|also also `git grep -E -h "HelpMessageOpt.*\-" | cut -d'"' -f2,4 --output-delimiter="     "`
196 2017-01-15 19:10:19	0|sipa|git grep GetArg
197 2017-01-15 19:11:01	0|arubi|-foo -bar -foo -bar
198 2017-01-15 19:24:24	0|profall|thank you morcos!
199 2017-01-15 21:20:35	0|jonasschnelli|BlueMatt, luke-jr: I pickup to work for #9294 tomorrow. Couldn't to to much during the weekend. @luke-jr: feel free to add a commit to the PR.
200 2017-01-15 21:20:38	0|gribble|https://github.com/bitcoin/bitcoin/issues/9294 | Use internal HD chain for change outputs (hd split) by jonasschnelli · Pull Request #9294 · bitcoin/bitcoin · GitHub