< sipa>
BlueMatt: probably less.. even 50ms on average, but if it happens while any other peer sends us anything, it's less also
< sipa>
anyway... very simple change
< BlueMatt>
sipa: yea, see comment on pr, its probably close to min(closest peer RTT, 100ms)
< 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
< BlueMatt>
oh, actually take that back, i suppose it is
< BlueMatt>
anyway, whatever, its a super trivial change that will make a difference sometimes
< BlueMatt>
IIRC morcos said something about having been testing +/- that change for a while, and i realized its not pr'ed anywhere
< BlueMatt>
ofc we should, later, remove that and move the whole block-announce logic from SendMessages into the UpdatedBlockTip callback
< BlueMatt>
but....for later
< morcos>
BlueMatt: ha, thats exactly the same as what i did except my commits were in the opposite order. :)
< BlueMatt>
morcos: well github is sorting them in the wrong order :p
< morcos>
no i know.. my point was i didn't realize i needed to make it public
< BlueMatt>
oh, neither did I
< BlueMatt>
thats why github is displaying them as "wake" then "make public"
< BlueMatt>
:p
< morcos>
oh ha, and thats why they are sorted in that order
< morcos>
what are you worried about missing 0.14
< BlueMatt>
yea, date-based
< morcos>
i thought we were doing pretty good
< morcos>
i mean there are some bugs that still need fixing
< morcos>
i mean maybe bumpfee will miss it i guess. but i won't cry...
< BlueMatt>
I'm not confident in the hd split one, and still feel like I need to do more review on bumpfee
< BlueMatt>
yea, I'm concerned about bumpfee and hd split
< 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
< BlueMatt>
heh, i skipped the concept ack stage...figure sipa will tell us if its the wrong way to do it :p
< BlueMatt>
but I think I found some bugs in the implementation yesterday, so waiting on jonasschnelli to reappear :/
< sipa>
i still haven't looked at the split :(
< achow101>
have we figured out what's wrong with mingw on ubuntu 16.04?
< BlueMatt>
i thought i remembered wumpus saying something which sounded like he had debugged it back to a patch ubuntu applied to their gcc
< gmaxwell>
I really wish someone would encourage him to ditch the inflamitory titles.
< sipa>
?
< 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.
< gmaxwell>
sipa: the "Avoid null dereference" "Avoid divide by zero" and so on.
< 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
< luke-jr>
gmaxwell: I'm not sure the average user considers them to be inflamitory at least
< 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.
< gmaxwell>
which isn't a correct worry at least for any of those PRs I've looked at so far.
< gmaxwell>
at least for technically advanced average users who have heard what kinds of names vulnerablities come under.
< luke-jr>
oh well, disarmed one that wasn't really even a bug
< sipa>
FWIW, ubsan would detect all of these potential issues that practicalswift just opened PRs for
< sipa>
so at least in none of the unit tests or rpc tests it gets triggered
< gmaxwell>
I think for a lot they're just provably not reachable now, but maybe the code would change again.
< wumpus>
BlueMatt: well there's two issues really: the posix/non-posix mutex issue (c++11 compatibliity mingw) and the fstack-protector-all one
< 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
< gmaxwell>
oh interesting! I didn't realize that. well makes it easier to change!
< luke-jr>
☺
< gmaxwell>
Useful to think about them from the perspective of someone upgrading and trying to decide if which impact them.
< gmaxwell>
which isn't what I've historically thought about while setting PR titles/commit shortlogs.
< gmaxwell>
maybe other people have, most are okay. Some not as much.
< wumpus>
heh I tend to already edit issue titles that are absolute crap (like "update main.cpp")
< 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.
< wumpus>
I think more important than the shortlist are the longer items though. We need to be doubly careful about those.
< 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.
< wumpus>
in the past that has never helped, at least :)
< luke-jr>
I've already written some release notes when I added some of these things in Knots; could copy those over
< wumpus>
yes that'd be useful luke-jr
< luke-jr>
probably won't get a chance until after I time-out on reviews Monday, but I'll try to remember then
< 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
< wumpus>
yes, it's not something to worry about now
< 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 :)
< sipa>
perhaps for a first draft - unsure
< wumpus>
or a wiki page
< wumpus>
yes
< gmaxwell>
yea, would be fine to just use a page on the bitcoin wiki.
< wumpus>
it's a bit of a pity that mediawiki doesn't support markdown
< gmaxwell>
well we don't need to see the markup there and I don't think anything in markdown will break mediawiki
< gmaxwell>
in fact it would be fine to put it in <pre> tags.
< 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.
< wumpus>
right, pre tags makes sense
< MarcoFalke_publi>
What about the GitHub wiki?
< MarcoFalke_publi>
I never tried it, though.
< 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
< wumpus>
(not 100% sure about that maybe it's a setting)
< MarcoFalke_publi>
Luke seems to be using it for the bips repo.
< wumpus>
but that would defeat the point if it is to get outside people involved
< sipa>
wumpus: i think the issue to report things for release notes was a great idea
< MarcoFalke_publi>
Agree
< sipa>
there are so many things that seem to get forgotten when the notes have to be generated too quickly
< wumpus>
though even that may still be useful for us, if we prefer editing in the wiki to committing to git on the branch
< wumpus>
let's just try
< achow101>
what kind of stuff needs to be done for the release notes? I may be able to help
< wumpus>
MarcoFalke_publi: oh nice
< 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.
< wumpus>
achow101: make sure it includes only user facing things, and that pull titles are not inflammatory/panic-arousing
< wumpus>
achow101: (and of course general English spelling and structure related editing etc)
< wumpus>
gmaxwell: yes the github format just isn't too great for editing documents
< achow101>
ok. I think I can help with that
< 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.)
< MarcoFalke_publi>
Include a wiki page with how to write the release notes :)
< wumpus>
shall I make a new repository for the wiki? that seems better for access control
< gmaxwell>
sure. I don't think we should intend to retain the history/work there.. should just be a scratchpad.
< bitcoin-git>
bitcoin/master 7094bf7 Gregory Maxwell: Trim down the XP notice and say more about what we support....
< bitcoin-git>
bitcoin/master 4105cb6 MarcoFalke: Merge #9550: Trim down the XP notice and say more about what we support....
< 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
< gmaxwell>
that as merged fast. need to make more doc changes. :P
< 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.
< 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.
< 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.
< fanquake>
Going to close 9263 now that 9531 has been merged. Any objections?
< sipa>
#9263
< 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
< luke-jr>
fanquake: objection.
< luke-jr>
9263 should be merged
< 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.
< luke-jr>
it's also a small amount of well-isolated and harmless code
< 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)
< 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?)
< 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).
< 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
< 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.
< gmaxwell>
If everyone acted like you do on this about things they care about very little would get done.
< 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.
< 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.
< gmaxwell>
Every time someone else changes something in the system that possibly interacts with it, they have to consider it.
< gmaxwell>
You can't deflect these costs except by doing all the work yourself.
< luke-jr>
I'm not sure anyone but me is constantly nagged about removing things they support and people use..
< gmaxwell>
also it hasn't been removed yet-- presumably once depricated it will get removed when it's actually in the way.
< 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.)
< luke-jr>
I probably could just maintain it in Knots, though.
< gmaxwell>
Good! certantly no one has any concern or objection with it being out there! its not at all incompatible.
< * gmaxwell>
goes to bed
< 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?
< bitcoin-git>
bitcoin/master e6111b2 Matt Corallo: Make peer id logging consistent ("peer=%d" instead of "peer %d")
< bitcoin-git>
bitcoin/master f62bc10 Wladimir J. van der Laan: Merge #9486: Make peer=%d log prints consistent...
< 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
< 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?
< sipa>
luke-jr: i did not notice you changed it; i'm fine with the text, can you also change the pr title?
< luke-jr>
ok, updated
< achow101>
I went through the release notes todo and added most of it to the release notes in the wiki
< achow101>
of course it can and should be improved, but at least most of it is now there so it won't be forgotten
< BlueMatt>
luke-jr: which pr?
< luke-jr>
BlueMatt: 9263
< 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)
< cfields>
sipa: iirc -Og was only added to clang recently
< cfields>
but sure, we could check for it and use it instead, if it works
< sipa>
cfields: it's been in gcc since 4.8, iirc the lowest version of gcc we support now
< bitcoin-git>
bitcoin/master d4781ac Gregory Sanders: Set peers as HB peers upon full block validation
< bitcoin-git>
bitcoin/master 8a445c5 Pieter Wuille: Merge #9400: Set peers as HB peers upon full block validation...
< 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
< 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
< profall>
Is there any good documentation someone can link me that covers everything I can put in bitcoin.conf and what it does.
< mol>
profall, ask in #bitcoin
< profall>
ok
< 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...
< arubi>
also also `git grep -E -h "HelpMessageOpt.*\-" | cut -d'"' -f2,4 --output-delimiter=" "`
< sipa>
git grep GetArg
< arubi>
-foo -bar -foo -bar
< profall>
thank you morcos!
< 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.