< gmaxwell> I really wish there were an offline and tui github interface.
< gmaxwell> jnewbery: Did you intend to thumbs down 9715 without a comment?
< gmaxwell> (I only ask because maybe a comment got lost or you clicked the wrong button.)
< bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/dd163f578869...36f9d3ae6da4
< bitcoin-git> bitcoin/master c8cee26 Luke Dashjr: Qt/Intro: Update block chain size
< bitcoin-git> bitcoin/master 93ffba7 Luke Dashjr: Bugfix: Qt/Intro: Chain state needs to be stored even with the full blockchain
< bitcoin-git> bitcoin/master a9baa6d Luke Dashjr: Bugfix: Qt/Intro: Pruned nodes never require *more* space
< wumpus> should bitseed.xf2.org be removed from the seeds? re: https://github.com/bitcoin/bitcoin/issues/8861#issuecomment-278140201
< luke-jr> wumpus: dunno, but I would prefer if bug text wasn't updated so as to make it useless for understanding what the problem was :p
< wumpus> luke-jr: changed the title
< luke-jr> XD
< bitcoin-git> [bitcoin] laanwj opened pull request #9726: netbase: Do not print an error on connection timeouts through proxy (master...2017_02_intr_recv_error) https://github.com/bitcoin/bitcoin/pull/9726
< bitcoin-git> [bitcoin] laanwj opened pull request #9727: Remove fallbacks for boost_filesystem < v3 (master...2017_02_boostfs_flailbacks) https://github.com/bitcoin/bitcoin/pull/9727
< bitcoin-git> [bitcoin] NicolasDorier opened pull request #9728: Can create Watch Only HD wallet with -hdwatchonly (master...watchonlyhd) https://github.com/bitcoin/bitcoin/pull/9728
< bitcoin-git> [bitcoin] jonasschnelli opened pull request #9730: Remove bitseed.xf2.org form the dns seed list (master...2017/02/seeds) https://github.com/bitcoin/bitcoin/pull/9730
< jonasschnelli> wumpus: yes. Lets remove it.
< jonasschnelli> Try a couple of addrs from the bitseed.xf2.org DNS response...
< jonasschnelli> I could not get a single address that responsed on 8333
< brg444> https://github.com/bitcoin/bitcoin/pull/9441 is this set to make it into 0.14?
< Lauda> brg444 I see it marked for 0.14.0?
< brg444> yeah nvm :P
< bitcoin-git> [bitcoin] earonesty opened pull request #9731: Bitcoin Unlimited Pull Request (master...release) https://github.com/bitcoin/bitcoin/pull/9731
< bitcoin-git> [bitcoin] earonesty closed pull request #9731: Bitcoin Unlimited Pull Request (master...release) https://github.com/bitcoin/bitcoin/pull/9731
< instagibbs> I seem to always forget, but what's the best way to get a reference(or copy) of a CScript as a unsigned char*
< instagibbs> sigh, as soon as I ask.. .front() seems to do trick
< cfields> didn't we give it a .data() ?
< instagibbs> appears so in master, working on slightly older branch. good call.
< cfields> ah, ok
< sipa> instagibbs: you can't call front om an empty vector
< sipa> and if it isn't empty, &v[0] works fine
< instagibbs> what happens if I do call it on an empty vector?
< Chris_Stewart_5> index out of bounds?
< sipa> instagibbs: undefined
< sipa> Chris_Stewart_5: no, operator[] does not do bounds checking. you're simply only allowed to call it for indexes that exist
< wumpus> it's one of the wacky things about c++, but we shouldn't care now that c++11 added .data()
< wumpus> we used to have begin_ptr and end_ptr functions to go from a vector to a begin/end pointer and wrap the "if empty" logic, but that's no longer necessary with data()
< Chris_Stewart_5> wumpus: Yes, coming from jvm land this has been a little confusing for me. I'll have to read more about .data()
< cfields> Chris_Stewart_5: throw .at() in for even more fun :)
< instagibbs> sigh. The More You Know
< wumpus> yes it's bizarre
< MarcoFalke> meeting in 3 minutes I guess
< wumpus> yes
< sipa> ploink
< MarcoFalke> everyone too busy reviewing code
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Feb 9 19:01:39 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< jonasschnelli> hi
< wumpus> topic: 0.14, I guess
< jonasschnelli> What holds the rc1 back? The open PRs with 0.14 tag?
< wumpus> there are some net issues
< jonasschnelli> #9698
< gribble> https://github.com/bitcoin/bitcoin/issues/9698 | net: fix socket close race by theuni · Pull Request #9698 · bitcoin/bitcoin · GitHub
< wumpus> #9698 #9715 #9720
< gribble> https://github.com/bitcoin/bitcoin/issues/9698 | net: fix socket close race by theuni · Pull Request #9698 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/9715 | Disconnect peers which we do not receive VERACKs from within 60 sec by TheBlueMatt · Pull Request #9715 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/9720 | net: fix banning and disallow sending messages before receiving verack by theuni · Pull Request #9720 · bitcoin/bitcoin · GitHub
< wumpus> but I'm not sure that's all; cfields here?
< cfields> and the atomics, or did those go in this morning?
< cfields> #9708
< gribble> https://github.com/bitcoin/bitcoin/issues/9708 | Clean Up all known races/platform-specific UB by TheBlueMatt · Pull Request #9708 · bitcoin/bitcoin · GitHub
< wumpus> you mean the wallet update counter?
< wumpus> that went in, I don't know about any other atomic changes
< cfields> wumpus: ^^
< cfields> not strictly necessary for 0.14, but makes it much easier to test the others
< wumpus> ok will tag that too
< wumpus> anything else?
< cfields> sorry for the last minute issues. For back-story/context, BlueMatt began testing in helgrind, and came up with a list of possible races in the net code. I wrote a quick fuzz tool to try to hit some, and managed to do so in a few cases. Some are new issues, some are long-standing
< wumpus> well, better to catch these before the release than after atleast :)
< achow101> besides these net issues there's just the importmulti stuff left, yes?
< cfields> the above PRs address all known races in the net code. By fixing even the harmless ones, it allows us to start using tools as part of c-i to avoid introducing new ones
< sipa> do we want to update the static seed IP list for 0.14?
< jonasschnelli> That would probably be a good idea.
< wumpus> yes, we usually do that before a major release
< wumpus> I'll do that
< cfields> do defaultAssumeValid/nMinimumChainWork get bumps before rc1?
< bitcoin-git> [bitcoin] jnewbery opened pull request #9732: [Trivial] Remove nonsense #undef foreach (master...removeundefforeach) https://github.com/bitcoin/bitcoin/pull/9732
< wumpus> #action update hardcoded seeds
< sipa> we can update chainTxData (only used for progress estimation) for sure
< wumpus> ok, do we have a script or something for that? I wouldn't know how to do that
< MarcoFalke> I propose we do the bumps in the commit prior to branch off. thus we don't need to redo the work for the master branch
< MarcoFalke> sipa: Is is mentioned in release process.md?
< sipa> MarcoFalke: i believe not
< sipa> MarcoFalke: i'll write a script, and add it to contrib/ ?
< MarcoFalke> Add a note to release-process.md at least, so we don't forget about it in the future.
< sipa> yeah, that too
< MarcoFalke> If the script is only for maintainers, you can add it to the maintainer repo
< sipa> it was updated in #9472, which is very recent, so i don't think it needs much adjusting, but we should have a procedure for it
< MarcoFalke> I think it helps devs if the main repo is kept lean
< sipa> ok
< sipa> unsure what to do about defaultAssumeValid/nMinimumChainWork though
< gribble> https://github.com/bitcoin/bitcoin/issues/9472 | Disentangle progress estimation from checkpoints and update it by sipa · Pull Request #9472 · bitcoin/bitcoin · GitHub
< wumpus> yes it'd help to have the process described in any case
< gmaxwell> sipa: why unsure? there is a process documented in the relase instructions.
< gmaxwell> follow the process.
< MarcoFalke> sipa: We want those bumped as well, I guess. Would be nice to do assumevalid in a pull, so that people can review the hash.
< gmaxwell> (if the process there is somehow insufficent, -- PR's accepted.)
< sipa> gmaxwell: cool, i remember reviewing those release instructions even, just forgot about them
< gmaxwell> oh good. :P
< gmaxwell> There isn't a script but it's trivial enough that I didn't think one was needed. (it's basically 'call getblockchaininfo')
< sipa> yeah, chainTxData is a bit more complicated as it needs an estimate of the tx/s rate
< sipa> but i'll PR a release process update
< MarcoFalke> #action update release process for chainTxData
< gmaxwell> sipa: thats 'read two updatetip lines' ?
< wumpus> ideally it'd be automated with a script, especially as it's under "every minor release"
< gmaxwell> make a RPC that emits a patch. :P
< wumpus> if it's manual work, it's probably going to be skipped for most minor releases
< wumpus> heck, weforget to update the version numbers half the time :-)
< wumpus> anyhow, any other topics?
< sipa> well what else is on the 0.14 tagged list?
< sipa> is #9392 going to be fixed?
< gribble> https://github.com/bitcoin/bitcoin/issues/9392 | Wallet ancestor sanity-check ignores sigops · Issue #9392 · bitcoin/bitcoin · GitHub
< jonasschnelli> #9108
< gribble> https://github.com/bitcoin/bitcoin/issues/9108 | Use importmulti timestamp when importing watch only keys by ryanofsky · Pull Request #9108 · bitcoin/bitcoin · GitHub
< sipa> i don't think 9392 is very high priority
< gmaxwell> I don't think 9392 is interesting at all.
< wumpus> ok, let's untag it for 0.14 then, there's enough high priority stuff to worry about
< gmaxwell> it's not something our wallet can violate.
< gmaxwell> (I think, or if so it would be super fringe)
< wumpus> ... it isn't tagged for 0.14
< wumpus> oh MarcoFalke just did that
< wumpus> :D
< MarcoFalke> The other issues tagged for 0.14 have pulls open. I think this concludes the meeting
< achow101> does anything else need to be added to the release notes?
< gmaxwell> I haven't been following the wiki release notes. Hows that been going?
< wumpus> from what I remember all the things on the list were done
< gmaxwell> cool.
< achow101> I added a ton of stuff a couple of weeks ago
< wumpus> yes, awesome work achow101
< sipa> nice
< jonasschnelli> thanks achow101
< wumpus> I was planning on merging the release notes from the wiki just before the rc1 branch
< wumpus> or just after the 0.14 branch-off, in any case there's no reason to have them on master they'll be cleared there anyway
< MarcoFalke> you mean 0.14 branch or rc1 tag?
< wumpus> before the rc1 tag
< MarcoFalke> ok
< wumpus> or after the 0.14 branch
< wumpus> doesn't matter much :)
< achow101> there's only two things on the release notes todo that aren't checked off. I can't write them because I don't understand those topics :(
< sdaftuar> the release notes currently have a recommendation to run Bitcoin Knots, for miners wishing to retain "priority" sorting for mining. i don't think recommending other forks of the project is appropriate (as i've brought up in the past)
< sipa> sdaftuar: agree
< wumpus> I don't think that makes much sense either
< jonasschnelli> sdaftuar: definitively.
< gmaxwell> My concern is different:
< jtimon> wumpus: if they're cleared on master after the fact, yeah, it doesn't matter
< gmaxwell> I think it's fine to recommend a compatible fork for a feature we don't care to support. BUT I think we should not be recommending priority, I think it's bad for users of the network.
< wumpus> jtimon: master will end up with empty release notes to be filled in for 0.15
< sdaftuar> gmaxwell: my primary concern is that developers on this project have not reviewed other forks. secondarily, i agree with your concern that we should not be recommending priority
< gmaxwell> (also, if miners do want to do priority, the best way would be using the rpc and a prioriizing daemon... but see my part (2))
< wumpus> (and, after 0.14.0 final is released, with the 0.14.0.md in historical release notes)
< gmaxwell> Part of my answer to luke when he was complaining about priority is that if miners want priority (I think ~none do) they could just use knots. I think that might motivate that release note recommendation.
< gmaxwell> But me saying "you can use knots" is not the same as the project saying it
< sdaftuar> gmaxwell: yes, i think it's fine if you or luke individually make that recommendation
< wumpus> just doesn't make sense to recommend it in the release notes
< sdaftuar> well, "fine" :)
< wumpus> would marginally make sense if it was an experimental feature we were expecting to merge in later
< jtimon> wumpus: I see, I tend to prefer to put as much in master as possible (and if it makes sense), but in this case it really doesn't matter
< gmaxwell> I could make a post about 'I think you shouldn't use priority, I think ~no one does, but if you want-- there is knots' which might make luke happier. I wouldn't mind doing that personally.
< jtimon> it's release notes
< gmaxwell> in any case, +1 for removing that from release notes.
< achow101> it's gone
< jtimon> maybe just a question in a faq or something? "we don't recomment using prioirty, but if you miss it, there's knots at..."
< gmaxwell> jtimon: infrequently asked questions
< achow101> (jonasschnelli removed it)
< gmaxwell> never asked questions
< jtimon> gmaxwell: yeah, in some iaq.html then
< wumpus> ok, any other topics?
< wumpus> if not, let's close the meeting
< gmaxwell> I'm excited to get 0.14 out. It's got lots of great stuff. :)
< cfields> +1 :)
< sipa> indeed
< wumpus> me too, it should be close now, everyone review!: https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.14.0
< jtimon> yep, many optimizations and cleanups
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Feb 9 19:49:42 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< morcos> oops sorry, the snow distracted me from the meeting
< morcos> achow101: you said there are 2 unchecked off things, but are there other things that need to be in release notes
< morcos> i think i need to mention all my new minimum fees
< sipa> morcos: comment about that on #8455 ?
< gribble> https://github.com/bitcoin/bitcoin/issues/8455 | TODO for release notes 0.14.0 · Issue #8455 · bitcoin/bitcoin · GitHub
< morcos> i can do that, but what's my deadline?
< MarcoFalke> morcos: Probably when rc1 is tagged
< morcos> ok, i can probably do it tomorrow if not tonight
< achow101> morcos: add them to the list with links to relevant PRs
< achow101> do maintainer scripts have to by python scripts?
< sipa> achow101: no, but they have to be usable by the people that tend to run them :)
< sipa> (i would object to a visual basic program, for example)
< achow101> so bash would be fine
< sipa> oh, sure
< achow101> ok. I think I'm going to write a do-the-pre-release-things script which does the version increment, seed update, etc
< achow101> (because apparently we forget to do those)
< sipa> achow101: that would be nice
< BlueMatt> does anyone have a 0.14-testing branch anywhere?
< BlueMatt> (ie with all the 0.14-tagged things merged)
< cfields> BlueMatt: not an answer to your question, but another branch for you to look at: https://github.com/theuni/bitcoin/tree/2017-02-fix-copystats-races
< BlueMatt> cfields: what all is integrated there?
< cfields> BlueMatt: that adds threading annotations for most net vars, and verifies your race fixes
< BlueMatt> ahh
< BlueMatt> is the first a fix for more races?
< cfields> here are the outstanding ones it turned up: https://github.com/theuni/bitcoin/commit/d185ca0840f8107b2cf4307f51d703e849532928
< BlueMatt> ahh, not actual races because of ordering of Start/Stop with other things, but, yea, should fix
< cfields> yea. i don't think we actually need to worry about most of it
< cfields> the only one with any weight is the cs_filter
< cfields> that one's still actually racy
< BlueMatt> oh, I guess i never evicted in helgrind, yea
< cfields> it's fRelayTxes and pfilter
< BlueMatt> yea
< BlueMatt> oh pfilter too? ouch
< BlueMatt> oh, pfilter != NULL
< BlueMatt> not so bad
< BlueMatt> but, yea, race
< cfields> adding the lock there is kinda ugly, any better ideas?
< BlueMatt> cfields: I think the lock is fine? I mean it goes away two LOC later?
< cfields> BlueMatt: just that cs_filter is held with wide scope in net_processing, i'm concerned about the ordering
< BlueMatt> cfields: agreed, does clang do lockorder checking in its compile-time stuff?
< BlueMatt> (or can we make it?)
< sipa> yes
< cfields> yea, you can tell it that a lock is not allowed here
< cfields> playing with that now
< sipa> the definitions in src/threadsafety.h
< cfields> ACQUIRED_BEFORE(...) and ACQUIRED_AFTER(...) are currently unimplemented
< cfields> fantastic.
< BlueMatt> heh
< BlueMatt> does clang support them, though?
< cfields> that's from the clang docs
< BlueMatt> heh
< cfields> mm, nope. It's not smart enough to figure it out. The fact that cs_vNodes lives in CConnman and cs_filter lives in CNode is too much.
< luke-jr> can someone reopen #7339 please?
< gribble> https://github.com/bitcoin/bitcoin/issues/7339 | Support building without libevent by luke-jr · Pull Request #7339 · bitcoin/bitcoin · GitHub
< cfields> BlueMatt: how much do you hate this https://github.com/theuni/bitcoin/commit/c6a93bd5313297d7ec091988a46366cfc12fef3c ? rather just pile on more atomics instead?