12017-01-15T00:05:03  <sipa> BlueMatt: probably less.. even 50ms on average, but if it happens while any other peer sends us anything, it's less also
  22017-01-15T00:05:09  <sipa> anyway... very simple change
  32017-01-15T00:07:22  <BlueMatt> sipa: yea, see comment on pr, its probably close to min(closest peer RTT, 100ms)
  42017-01-15T00:08:53  <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
  52017-01-15T00:09:21  <BlueMatt> oh, actually take that back, i suppose it is
  62017-01-15T00:09:36  <BlueMatt> anyway, whatever, its a super trivial change that will make a difference sometimes
  72017-01-15T00:09:50  <BlueMatt> IIRC morcos said something about having been testing +/- that change for a while, and i realized its not pr'ed anywhere
  82017-01-15T00:11:13  <BlueMatt> ofc we should, later, remove that and move the whole block-announce logic from SendMessages into the UpdatedBlockTip callback
  92017-01-15T00:11:16  <BlueMatt> but....for later
 102017-01-15T00:17:16  <morcos> BlueMatt: ha, thats exactly the same as what i did except my commits were in the opposite order.  :)
 112017-01-15T00:17:55  <BlueMatt> morcos: well github is sorting them in the wrong order :p
 122017-01-15T00:18:19  <morcos> no i know.. my point was i didn't realize i needed to make it public
 132017-01-15T00:18:26  <BlueMatt> oh, neither did I
 142017-01-15T00:18:38  <BlueMatt> thats why github is displaying them as "wake" then "make public"
 152017-01-15T00:18:39  <BlueMatt> :p
 162017-01-15T00:18:48  <morcos> oh ha, and thats why they are sorted in that order
 172017-01-15T00:19:18  <morcos> what are you worried about missing 0.14
 182017-01-15T00:19:18  <BlueMatt> yea, date-based
 192017-01-15T00:19:22  <morcos> i thought we were doing pretty good
 202017-01-15T00:19:30  <morcos> i mean there are some bugs that still need fixing
 212017-01-15T00:19:57  <morcos> i mean maybe bumpfee will miss it i guess.  but i won't cry...
 222017-01-15T00:20:01  <BlueMatt> I'm not confident in the hd split one, and still feel like I need to do more review on bumpfee
 232017-01-15T00:20:15  <BlueMatt> yea, I'm concerned about bumpfee and hd split
 242017-01-15T00:20:28  <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
 252017-01-15T00:21:01  <BlueMatt> heh, i skipped the concept ack stage...figure sipa will tell us if its the wrong way to do it :p
 262017-01-15T00:21:16  <BlueMatt> but I think I found some bugs in the implementation yesterday, so waiting on jonasschnelli to reappear :/
 272017-01-15T00:22:05  <sipa> i still haven't looked at the split :(
 282017-01-15T00:46:25  *** xinxi has joined #bitcoin-core-dev
 292017-01-15T00:51:15  *** To7 has joined #bitcoin-core-dev
 302017-01-15T00:53:39  *** xinxi has quit IRC
 312017-01-15T01:18:59  *** Netmage has quit IRC
 322017-01-15T01:19:42  *** Netmage has joined #bitcoin-core-dev
 332017-01-15T01:27:50  <achow101> have we figured out what's wrong with mingw on ubuntu 16.04?
 342017-01-15T01:30:40  <BlueMatt> i thought i remembered wumpus saying something which sounded like he had debugged it back to a patch ubuntu applied to their gcc
 352017-01-15T01:47:29  *** Ylbam has quit IRC
 362017-01-15T01:49:53  *** PRab_ has joined #bitcoin-core-dev
 372017-01-15T01:50:41  *** xinxi has joined #bitcoin-core-dev
 382017-01-15T01:51:15  *** PRab has quit IRC
 392017-01-15T01:51:26  *** PRab_ is now known as PRab
 402017-01-15T01:58:15  *** xinxi has quit IRC
 412017-01-15T02:02:52  *** xinxi has joined #bitcoin-core-dev
 422017-01-15T02:31:22  *** xinxi has quit IRC
 432017-01-15T02:36:49  <gmaxwell> I really wish someone would encourage him to ditch the inflamitory titles.
 442017-01-15T02:37:43  <sipa> ?
 452017-01-15T02:37:43  <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.
 462017-01-15T02:38:05  <gmaxwell> sipa: the "Avoid null dereference" "Avoid divide by zero" and so on.
 472017-01-15T02:43:49  *** xinxi has joined #bitcoin-core-dev
 482017-01-15T02:52:21  <bitcoin-git> [bitcoin] practicalswift closed pull request #9560: [rpc] Avoid possibility of NULL pointer dereference in getblocktemplate(...) (master...avoid-null-pointer-dereference-in-rpc-blockchain) https://github.com/bitcoin/bitcoin/pull/9560
 492017-01-15T02:56:34  <luke-jr> gmaxwell: I'm not sure the average user considers them to be inflamitory at least
 502017-01-15T02:58:54  <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.
 512017-01-15T02:59:10  <gmaxwell> which isn't a correct worry at least for any of those PRs I've looked at so far.
 522017-01-15T02:59:40  <gmaxwell> at least for technically advanced average users who have heard what kinds of names vulnerablities come under.
 532017-01-15T03:01:11  <luke-jr> oh well, disarmed one that wasn't really even a bug
 542017-01-15T03:03:39  <sipa> FWIW, ubsan would detect all of these potential issues that practicalswift just opened PRs for
 552017-01-15T03:04:25  <sipa> so at least in none of the unit tests or rpc tests it gets triggered
 562017-01-15T03:10:39  <gmaxwell> I think for a lot they're just provably not reachable now, but maybe the code would change again.
 572017-01-15T03:21:01  *** Alopex has quit IRC
 582017-01-15T03:22:07  *** Alopex has joined #bitcoin-core-dev
 592017-01-15T03:25:39  <wumpus> BlueMatt: no, I never got to the bottom of it, latest known information is in https://github.com/bitcoin/bitcoin/issues/8732
 602017-01-15T03:27:01  <wumpus> BlueMatt: well there's two issues really: the posix/non-posix mutex issue (c++11 compatibliity mingw) and the fstack-protector-all one
 612017-01-15T03:32:45  <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
 622017-01-15T03:33:51  <gmaxwell> oh interesting! I didn't realize that. well makes it easier to change!
 632017-01-15T03:34:10  <luke-jr> ☺
 642017-01-15T03:34:38  <gmaxwell> Useful to think about them from the perspective of someone upgrading and trying to decide if which impact them.
 652017-01-15T03:34:57  <gmaxwell> which isn't what I've historically thought about while setting PR titles/commit shortlogs.
 662017-01-15T03:35:20  <gmaxwell> maybe other people have, most are okay. Some not as much.
 672017-01-15T03:36:21  <wumpus> heh I tend to already edit issue titles that are absolute crap (like "update main.cpp")
 682017-01-15T03:37:50  *** xiangfu has quit IRC
 692017-01-15T03:39:12  *** xiangfu has joined #bitcoin-core-dev
 702017-01-15T03:40:45  <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.
 712017-01-15T03:41:27  <wumpus> I think more important than the shortlist are the longer items though. We need to be doubly careful about those.
 722017-01-15T03:42:51  <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.
 732017-01-15T03:43:07  <wumpus> in the past that has never helped, at least :)
 742017-01-15T03:44:10  <luke-jr> I've already written some release notes when I added some of these things in Knots; could copy those over
 752017-01-15T03:44:44  <wumpus> yes that'd be useful luke-jr
 762017-01-15T03:45:32  <luke-jr> probably won't get a chance until after I time-out on reviews Monday, but I'll try to remember then
 772017-01-15T03:46:07  <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
 782017-01-15T03:46:33  <wumpus> yes, it's not something to worry about now
 792017-01-15T03:48:56  <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 :)
 802017-01-15T03:49:28  <sipa> perhaps for a first draft - unsure
 812017-01-15T03:49:29  <wumpus> or a wiki page
 822017-01-15T03:49:41  <wumpus> yes
 832017-01-15T03:49:43  <gmaxwell> yea, would be fine to just use a page on the bitcoin wiki.
 842017-01-15T03:50:24  <wumpus> it's a bit of a pity that mediawiki doesn't support markdown
 852017-01-15T03:50:52  <gmaxwell> well we don't need to see the markup there and I don't think anything in markdown will break mediawiki
 862017-01-15T03:51:04  <gmaxwell> in fact it would be fine to put it in <pre> tags.
 872017-01-15T03:51:13  <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.
 882017-01-15T03:51:19  <wumpus> right, pre tags makes sense
 892017-01-15T03:51:53  *** MarcoFalke_publi has joined #bitcoin-core-dev
 902017-01-15T03:52:00  *** windsok has quit IRC
 912017-01-15T03:52:13  <MarcoFalke_publi> What about the GitHub wiki?
 922017-01-15T03:52:20  <MarcoFalke_publi> I never tried it, though.
 932017-01-15T03:53:04  *** Victorsueca has joined #bitcoin-core-dev
 942017-01-15T03:54:24  <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
 952017-01-15T03:54:38  <wumpus> (not 100% sure about that maybe it's a setting)
 962017-01-15T03:55:17  <MarcoFalke_publi> Luke seems to be using it for the bips repo.
 972017-01-15T03:55:18  <wumpus> but that would defeat the point if it is to get outside people involved
 982017-01-15T03:55:47  *** Victor_sueca has quit IRC
 992017-01-15T03:58:16  <MarcoFalke_publi> You can enable it for any GitHub user: https://help.github.com/articles/changing-access-permissions-for-wikis/
1002017-01-15T03:58:22  <sipa> wumpus: i think the issue to report things for release notes was a great idea
1012017-01-15T03:58:40  <MarcoFalke_publi> Agree
1022017-01-15T03:58:43  <sipa> there are so many things that seem to get forgotten when the notes have to be generated too quickly
1032017-01-15T03:59:01  <wumpus> though even that may still be useful for us, if we prefer editing in the wiki to committing to git on the branch
1042017-01-15T03:59:22  <wumpus> let's just try
1052017-01-15T03:59:38  <achow101> what kind of stuff needs to be done for the release notes? I may be able to help
1062017-01-15T03:59:44  <wumpus> MarcoFalke_publi: oh nice
1072017-01-15T04:00:13  <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.
1082017-01-15T04:00:15  <wumpus> achow101: make sure it includes only user facing things, and that pull titles are not inflammatory/panic-arousing
1092017-01-15T04:00:34  <wumpus> achow101: (and of course general English spelling and structure related editing etc)
1102017-01-15T04:01:01  <wumpus> gmaxwell: yes the github format just isn't too great for editing documents
1112017-01-15T04:01:06  <achow101> ok. I think I can help with that
1122017-01-15T04:01:10  <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.)
1132017-01-15T04:01:51  <MarcoFalke_publi> Include a wiki page with how to write the release notes :)
1142017-01-15T04:03:18  <wumpus> shall I make a new repository for the wiki? that seems better for access control
1152017-01-15T04:05:21  <gmaxwell> sure. I don't think we should intend to retain the history/work there.. should just be a scratchpad.
1162017-01-15T04:06:27  <MarcoFalke_publi> https://github.com/bitcoin-core/bitcoin-devwiki/wiki
1172017-01-15T04:06:46  <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 :)
1182017-01-15T04:07:55  <achow101> will it be open to everyone?
1192017-01-15T04:08:55  <wumpus> achow101: don't think it hurts to try. If it's abused, we can always lock it down more
1202017-01-15T04:09:12  <achow101> great. just don't tell reddit :)
1212017-01-15T04:11:40  <luke-jr> wumpus: Google Docs does have a nice "suggest" feature
1222017-01-15T04:12:26  <luke-jr> wumpus: github wiki for bips at least seems to be editable by all?
1232017-01-15T04:12:47  <luke-jr> but personally I think GDocs is the better solution but whatever
1242017-01-15T04:14:09  *** xinxi has quit IRC
1252017-01-15T04:14:36  <wumpus> luke-jr: yes, gdocs has some nice features as well
1262017-01-15T04:15:21  *** windsok has joined #bitcoin-core-dev
1272017-01-15T04:16:12  *** chris2000 has joined #bitcoin-core-dev
1282017-01-15T04:16:59  <achow101> are release notes written from the last major version or the last minor version
1292017-01-15T04:17:13  <wumpus> the last minor version of the last major version
1302017-01-15T04:17:24  <achow101> ok
1312017-01-15T04:18:03  <wumpus> so relative to 0.13.2 int this case unless there's another release on the 0.13 branch inthe meantime
1322017-01-15T04:19:00  *** chris200_ has quit IRC
1332017-01-15T04:20:11  <luke-jr> hmm, maybe we should have non-devs write our release notes for us :P
1342017-01-15T04:21:06  <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
1352017-01-15T04:21:25  <luke-jr> in case any non-dev wants to start working on it ;)
1362017-01-15T04:23:43  *** xinxi has joined #bitcoin-core-dev
1372017-01-15T04:26:20  *** MarcoFalke_publi has quit IRC
1382017-01-15T04:34:07  *** shesek has joined #bitcoin-core-dev
1392017-01-15T04:39:58  *** fanquake has joined #bitcoin-core-dev
1402017-01-15T04:43:40  <fanquake> practicalswift Any chance your idling in here under a different handle?
1412017-01-15T04:51:57  *** MarcoFalke has joined #bitcoin-core-dev
1422017-01-15T04:57:13  <gmaxwell> fanquake: you could send an email I guess.
1432017-01-15T05:00:48  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/23281a4dc3af...4105cb6fd964
1442017-01-15T05:00:48  <bitcoin-git> bitcoin/master 7094bf7 Gregory Maxwell: Trim down the XP notice and say more about what we support....
1452017-01-15T05:00:49  <bitcoin-git> bitcoin/master 4105cb6 MarcoFalke: Merge #9550: Trim down the XP notice and say more about what we support....
1462017-01-15T05:01:03  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9550: Trim down the XP notice and say more about what we support. (master...we_got_it_already) https://github.com/bitcoin/bitcoin/pull/9550
1472017-01-15T05:01:15  <gmaxwell> that as merged fast. need to make more doc changes. :P
1482017-01-15T05:02:08  <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.
1492017-01-15T05:03:04  <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.
1502017-01-15T05:05:04  <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.
1512017-01-15T05:05:28  <MarcoFalke> "trivial" :P
1522017-01-15T05:06:27  <bitcoin-git> [bitcoin] fanquake closed pull request #8889: Qt/ModalOverlay: Use theme tooltip colours (master...overlay_theme) https://github.com/bitcoin/bitcoin/pull/8889
1532017-01-15T05:07:11  <norotartagen> trivial!
1542017-01-15T05:08:00  <fanquake> Going to close 9263 now that 9531 has been merged. Any objections?
1552017-01-15T05:11:28  <sipa> #9263
1562017-01-15T05:11:30  <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
1572017-01-15T05:14:04  <luke-jr> fanquake: objection.
1582017-01-15T05:14:08  <luke-jr> 9263 should be merged
1592017-01-15T05:15:00  <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.
1602017-01-15T05:15:34  *** MarcoFalke has quit IRC
1612017-01-15T05:15:35  <luke-jr> it's also a small amount of well-isolated and harmless code
1622017-01-15T05:15:42  *** droark has quit IRC
1632017-01-15T05:20:37  <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)
1642017-01-15T05:21:09  <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?)
1652017-01-15T05:23:00  <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).
1662017-01-15T05:24:07  <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
1672017-01-15T05:25:00  <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.
1682017-01-15T05:25:36  <gmaxwell> If everyone acted like you do on this about things they care about very little would get done.
1692017-01-15T05:28:05  <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.
1702017-01-15T05:28:23  <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.
1712017-01-15T05:28:45  <gmaxwell> Every time someone else changes something in the system that possibly interacts with it, they have to consider it.
1722017-01-15T05:28:49  *** xinxi has quit IRC
1732017-01-15T05:29:03  <gmaxwell> You can't deflect these costs except by doing all the work yourself.
1742017-01-15T05:29:21  <luke-jr> I'm not sure anyone but me is constantly nagged about removing things they support and people use..
1752017-01-15T05:29:29  <gmaxwell> also it hasn't been removed yet-- presumably once depricated it will get removed when it's actually in the way.
1762017-01-15T05:30:00  <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.)
1772017-01-15T05:30:02  <luke-jr> I probably could just maintain it in Knots, though.
1782017-01-15T05:30:32  <gmaxwell> Good! certantly no one has any concern or objection with it being out there! its not at all incompatible.
1792017-01-15T05:30:56  * gmaxwell goes to bed
1802017-01-15T05:31:01  <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?
1812017-01-15T05:43:29  <bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/4105cb6fd964...01c4576a3914
1822017-01-15T05:43:30  <bitcoin-git> bitcoin/master 02fcb29 fanquake: [depends] Qt 5.7.1
1832017-01-15T05:43:30  <bitcoin-git> bitcoin/master 2b32dea Cory Fields: depends: use new variable layout for qt sdk
1842017-01-15T05:43:31  <bitcoin-git> bitcoin/master c37ea4d Cory Fields: depends: fix qt translations build...
1852017-01-15T05:43:44  <bitcoin-git> [bitcoin] laanwj closed pull request #9469: [depends] Qt 5.7.1 (master...depends-0-14-0-qt) https://github.com/bitcoin/bitcoin/pull/9469
1862017-01-15T05:45:16  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/01c4576a3914...f62bc10a607c
1872017-01-15T05:45:16  <bitcoin-git> bitcoin/master e6111b2 Matt Corallo: Make peer id logging consistent ("peer=%d" instead of "peer %d")
1882017-01-15T05:45:17  <bitcoin-git> bitcoin/master f62bc10 Wladimir J. van der Laan: Merge #9486: Make peer=%d log prints consistent...
1892017-01-15T05:45:30  <bitcoin-git> [bitcoin] laanwj closed pull request #9486: Make peer=%d log prints consistent (master...2017-01-peer-log-consistency) https://github.com/bitcoin/bitcoin/pull/9486
1902017-01-15T05:45:46  *** xinxi has joined #bitcoin-core-dev
1912017-01-15T05:57:37  <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?
1922017-01-15T05:59:34  <sipa> luke-jr: i did not notice you changed it; i'm fine with the text, can you also change the pr title?
1932017-01-15T05:59:59  <luke-jr> ok, updated
1942017-01-15T06:15:42  *** xinxi has quit IRC
1952017-01-15T06:33:26  *** Alopex has quit IRC
1962017-01-15T06:34:31  *** Alopex has joined #bitcoin-core-dev
1972017-01-15T06:46:50  <achow101> I went through the release notes todo and added most of it to the release notes in the wiki
1982017-01-15T06:47:14  <achow101> of course it can and should be improved, but at least most of it is now there so it won't be forgotten
1992017-01-15T07:00:08  *** dermoth has quit IRC
2002017-01-15T07:01:09  *** dermoth has joined #bitcoin-core-dev
2012017-01-15T07:07:07  *** Alopex has quit IRC
2022017-01-15T07:08:12  *** Alopex has joined #bitcoin-core-dev
2032017-01-15T07:16:08  *** xinxi has joined #bitcoin-core-dev
2042017-01-15T07:20:41  *** xinxi has quit IRC
2052017-01-15T07:26:12  *** Alopex has quit IRC
2062017-01-15T07:27:17  *** Alopex has joined #bitcoin-core-dev
2072017-01-15T07:34:43  *** xinxi has joined #bitcoin-core-dev
2082017-01-15T08:57:30  *** fanquake has quit IRC
2092017-01-15T08:58:38  *** Evel-Knievel has quit IRC
2102017-01-15T09:05:08  *** fanquake has joined #bitcoin-core-dev
2112017-01-15T09:50:40  <BlueMatt> luke-jr: which pr?
2122017-01-15T10:24:33  *** xinxi has quit IRC
2132017-01-15T11:01:45  *** mol has joined #bitcoin-core-dev
2142017-01-15T11:03:13  *** Guyver2 has joined #bitcoin-core-dev
2152017-01-15T11:04:35  *** moli_ has quit IRC
2162017-01-15T11:27:17  *** str4d has joined #bitcoin-core-dev
2172017-01-15T11:27:59  *** Ylbam has joined #bitcoin-core-dev
2182017-01-15T11:35:59  *** xinxi has joined #bitcoin-core-dev
2192017-01-15T11:39:59  *** fanquake has quit IRC
2202017-01-15T11:40:23  *** xinxi has quit IRC
2212017-01-15T11:52:49  *** xinxi has joined #bitcoin-core-dev
2222017-01-15T12:17:38  *** Evel-Knievel has joined #bitcoin-core-dev
2232017-01-15T12:27:18  *** Saucery has joined #bitcoin-core-dev
2242017-01-15T12:30:38  *** Saucery has quit IRC
2252017-01-15T12:36:41  *** MarcoFalke has joined #bitcoin-core-dev
2262017-01-15T13:25:17  *** Netmage has quit IRC
2272017-01-15T13:27:24  *** Netmage has joined #bitcoin-core-dev
2282017-01-15T13:29:13  *** waxwing has joined #bitcoin-core-dev
2292017-01-15T14:22:18  <luke-jr> BlueMatt: 9263
2302017-01-15T14:36:36  *** Aleph0 has quit IRC
2312017-01-15T14:37:22  *** Aleph0 has joined #bitcoin-core-dev
2322017-01-15T14:53:33  *** xinxi has quit IRC
2332017-01-15T14:55:46  *** xinxi has joined #bitcoin-core-dev
2342017-01-15T14:57:37  *** MarcoFalke has quit IRC
2352017-01-15T15:21:22  *** Guyver2 has quit IRC
2362017-01-15T15:40:41  *** chris2000 has quit IRC
2372017-01-15T15:57:23  *** waxwing has quit IRC
2382017-01-15T16:06:11  *** str4d has quit IRC
2392017-01-15T16:28:48  *** Soligor has quit IRC
2402017-01-15T16:38:21  *** Soligor has joined #bitcoin-core-dev
2412017-01-15T17:22:33  <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)
2422017-01-15T17:23:01  <cfields> sipa: iirc -Og was only added to clang recently
2432017-01-15T17:23:26  <cfields> but sure, we could check for it and use it instead, if it works
2442017-01-15T17:25:06  <sipa> cfields: it's been in gcc since 4.8, iirc the lowest version of gcc we support now
2452017-01-15T17:25:21  <cfields> sipa: https://github.com/llvm-mirror/clang/commit/14bfc9e99e6e6903b09480a22c153032be77ae4e
2462017-01-15T17:25:44  <sipa> ah, i see
2472017-01-15T17:25:56  <sipa> i thought we were claiming "it's only available since a recent version of cland"
2482017-01-15T17:26:32  <cfields> ah, no. just that it was gcc-only until very recently
2492017-01-15T17:26:38  <sipa> i see
2502017-01-15T17:27:01  <sipa> oh, and it's equal to -O1 in clang
2512017-01-15T17:27:24  <cfields> sounds useful though. Lots of things about running at -O0 is very useless.
2522017-01-15T17:29:41  <sipa> cfields, luke-jr, BlueMatt: -fsanitize=thread is useless as expected... i'm bombarded with warnings about races in BDB...
2532017-01-15T17:30:06  <cfields> sipa: within bdb itself?
2542017-01-15T17:30:09  <sipa> (unsure if it's our BDB wrapper or BDB itself)
2552017-01-15T17:30:15  <cfields> ok
2562017-01-15T17:30:30  <cfields> sipa: depends built with sanitize-thread too? or just bitcoin?
2572017-01-15T17:30:41  <sipa> just bitcoin, so far
2582017-01-15T17:31:04  <sipa> i'm already happy to be able to satisfy asan, lsan, and ubsan
2592017-01-15T17:31:07  <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
2602017-01-15T17:31:09  <sipa> msan and tsan sound tricker
2612017-01-15T17:31:12  <sipa> *trickier
2622017-01-15T17:32:41  <cfields> sipa: er, --disable-wallet :)
2632017-01-15T17:33:45  <sipa> cfields: i can't run the rpc tests in that case
2642017-01-15T17:34:07  <cfields> ah, right
2652017-01-15T17:44:57  <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f62bc10a607c...8a445c5651ed
2662017-01-15T17:44:58  <bitcoin-git> bitcoin/master d4781ac Gregory Sanders: Set peers as HB peers upon full block validation
2672017-01-15T17:44:58  <bitcoin-git> bitcoin/master 8a445c5 Pieter Wuille: Merge #9400: Set peers as HB peers upon full block validation...
2682017-01-15T17:45:09  <bitcoin-git> [bitcoin] sipa closed pull request #9400: Set peers as HB peers upon full block validation (master...maybesetfullblock) https://github.com/bitcoin/bitcoin/pull/9400
2692017-01-15T17:50:48  *** str4d has joined #bitcoin-core-dev
2702017-01-15T18:05:26  *** fresn3ll has joined #bitcoin-core-dev
2712017-01-15T18:14:07  *** fresn3ll has quit IRC
2722017-01-15T18:20:31  <bitcoin-git> [bitcoin] practicalswift closed pull request #9559: [net] Avoid possibility of NULL pointer dereference in ProcessMessage(...) (master...avoid-null-pointer-deref-in-processmessage) https://github.com/bitcoin/bitcoin/pull/9559
2732017-01-15T18:22:59  *** Chris_Stewart_5 has quit IRC
2742017-01-15T18:24:09  <profall> Is there any good documentation someone can link me that covers everything I can put in bitcoin.conf and what it does.
2752017-01-15T18:27:48  <mol> profall, ask in #bitcoin
2762017-01-15T18:27:53  <profall> ok
2772017-01-15T18:30:35  *** str4d has quit IRC
2782017-01-15T18:39:51  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2792017-01-15T18:54:38  *** laurentmt has joined #bitcoin-core-dev
2802017-01-15T19:05:24  *** Chris_Stewart_5 has quit IRC
2812017-01-15T19:05:51  *** xiangfu has quit IRC
2822017-01-15T19:06:12  *** laurentmt has quit IRC
2832017-01-15T19:06:13  *** xiangfu has joined #bitcoin-core-dev
2842017-01-15T19:07:17  <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...
2852017-01-15T19:07:52  <arubi> also also `git grep -E -h "HelpMessageOpt.*\-" | cut -d'"' -f2,4 --output-delimiter="     "`
2862017-01-15T19:09:58  *** str4d has joined #bitcoin-core-dev
2872017-01-15T19:10:18  <sipa> git grep GetArg
2882017-01-15T19:10:59  <arubi> -foo -bar -foo -bar
2892017-01-15T19:24:23  <profall> thank you morcos!
2902017-01-15T19:32:37  *** xiangfu has quit IRC
2912017-01-15T19:35:41  *** justanotheruser has joined #bitcoin-core-dev
2922017-01-15T19:37:52  *** justan0theruser has quit IRC
2932017-01-15T19:38:09  *** Netmage has quit IRC
2942017-01-15T19:38:23  *** xiangfu has joined #bitcoin-core-dev
2952017-01-15T20:36:27  *** xinxi has quit IRC
2962017-01-15T20:36:56  *** xinxi has joined #bitcoin-core-dev
2972017-01-15T20:41:24  *** xinxi has quit IRC
2982017-01-15T20:50:43  *** chjj has quit IRC
2992017-01-15T20:50:43  *** chjj has joined #bitcoin-core-dev
3002017-01-15T21:03:12  *** BashCo has quit IRC
3012017-01-15T21:20:34  <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.
3022017-01-15T21:20:36  <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
3032017-01-15T21:24:33  *** BashCo has joined #bitcoin-core-dev
3042017-01-15T21:32:49  *** stench has joined #bitcoin-core-dev
3052017-01-15T21:38:15  *** xinxi has joined #bitcoin-core-dev
3062017-01-15T21:42:38  *** BitBully has joined #bitcoin-core-dev
3072017-01-15T21:42:42  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3082017-01-15T21:43:11  *** xbtc21e has joined #bitcoin-core-dev
3092017-01-15T21:44:53  *** xinxi has quit IRC
3102017-01-15T21:46:53  *** Chris_Stewart_5 has quit IRC
3112017-01-15T21:48:43  *** BitBully has quit IRC
3122017-01-15T21:55:59  *** BashCo has quit IRC
3132017-01-15T21:56:04  *** BashCo_ has joined #bitcoin-core-dev
3142017-01-15T21:59:25  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3152017-01-15T22:13:58  *** baldur has quit IRC
3162017-01-15T22:16:26  *** xbtc21e has quit IRC
3172017-01-15T22:27:04  *** baldur has joined #bitcoin-core-dev
3182017-01-15T22:39:52  *** AaronvanW has joined #bitcoin-core-dev
3192017-01-15T22:39:52  *** AaronvanW has joined #bitcoin-core-dev
3202017-01-15T22:41:30  *** xinxi has joined #bitcoin-core-dev
3212017-01-15T22:43:49  *** str4d has quit IRC
3222017-01-15T22:47:41  *** xinxi has quit IRC
3232017-01-15T23:18:18  *** wasi has quit IRC
3242017-01-15T23:21:27  *** arubi has quit IRC
3252017-01-15T23:22:13  *** wasi has joined #bitcoin-core-dev
3262017-01-15T23:24:32  *** arubi has joined #bitcoin-core-dev
3272017-01-15T23:34:48  *** Saucery has joined #bitcoin-core-dev
3282017-01-15T23:44:47  *** xinxi has joined #bitcoin-core-dev
3292017-01-15T23:52:23  *** xinxi has quit IRC