< 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
< 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.
< 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?
< 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?
< 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. :)