1 2017-04-14 00:42:31	0|gmaxwell|Anyone have AMD Ryzen yet? apparently they implement the intel SHA extensions.
  2 2017-04-14 02:45:32	0|warren|Yikes ... rescan is very slow.
  3 2017-04-14 03:16:05	0|bitcoin-git|[13bitcoin] 15wtogami opened pull request #10207: Clarify importprivkey help text ... example of blank label without rescan (06master...06importprivkey) 02https://github.com/bitcoin/bitcoin/pull/10207
  4 2017-04-14 03:26:53	0|kallewoof|I think the PR review request part of the weekly meetings is a bad idea. It risks alienating the contributors who aren't hard core enough to participate and/or who aren't in a compatible time zone. I also don't think I would ever ask for a review for anything as I wouldn't consider my PRs important enough to take anyone's time at a specific time.
  5 2017-04-14 03:28:39	0|kallewoof|At the same time it's a bit frustrating watching PRs just gather dust for no (to oneself) apparent reason. Maybe that's just me.
  6 2017-04-14 03:30:16	0|kallewoof|Meetings start 4 in the morning where I am, FWIW.
  7 2017-04-14 03:36:38	0|warren|kallewoof: you make a good point, although I don't have a good suggestion.  Asking for reviews during the meeting is not decision making.  It is merely humans asking other humans to take a look at something.  Perhaps folks here could volunteer to talk with you and others at other hours to better communication and coordination in other schedules.
  8 2017-04-14 03:41:17	0|kallewoof|I am a bit surprised that there's no better method to keep the ball rolling so to say. After the initial comment spree (if any) it sort of just sits there. If you're like me, who hates bugging people for no particular reason, that can be a long time. E.g. #9517 is over 3 months old and I don't even know if people want it merged.
  9 2017-04-14 03:41:19	0|gribble|https://github.com/bitcoin/bitcoin/issues/9517 | [refactor] Switched httpserver.cpp to use RAII wrapped libevents. by kallewoof · Pull Request #9517 · bitcoin/bitcoin · GitHub
 10 2017-04-14 03:41:46	0|kallewoof|And it's a very simple PR. +8 lines -16 lines.
 11 2017-04-14 03:57:24	0|gmaxwell|kallewoof: sometimes they get forgotten and you need to nag. It's suboptimal but there is often more in flight than we can really manage. squeaky wheel and all that.
 12 2017-04-14 04:00:13	0|gmaxwell|kallewoof: in any case, sorry about that I will test now.
 13 2017-04-14 04:01:03	0|gmaxwell|Recommended procedure is: (1) wait until we're not closing for a major release (e.g. now is fine), (2) nag.  (3) apologize for nagging by cross responding to other people's nags: end result everyone happy.
 14 2017-04-14 04:03:15	0|kallewoof|gmaxwell: Yeah, I can sort of grasp that this is the approach, but for a newcomer I think it's very intimidating. (Not necessarily speaking about myself there, though i do hate nagging.) It'd be a pity for a bright individual to lose their steam and go somewhere else because they are too scared to bug you guys. That's more of an issue here since everyone here is a damn genius.
 15 2017-04-14 04:03:59	0|kallewoof|Friendly geniuses, but that's not necessarily obvious to someone who hasn't spent a great deal of time watching you interact.
 16 2017-04-14 04:05:21	0|kallewoof|My approach so far has been to jump to e.g. page 5-6 in the PR list and just go from bottom and upwards. But I am not exactly the most qualified to review a lot of the stuff there. :)
 17 2017-04-14 04:07:20	0|gmaxwell|kallewoof: people do go and advocate for other PRs, which does rescue this case in some cases. But it happens at a much greater rate when they've taken some personal interest in the result; and so good cleanup work like the RAII wrapper takes a backseat because as good as it may be, it isn't sexy.
 18 2017-04-14 04:08:00	0|gmaxwell|It's certantly something we need to improve-- and you can help improve it by also advocating for other people. I dunno about you but I find it less intimidating to ask for other people than for myself.
 19 2017-04-14 04:09:13	0|kallewoof|That makes a lot of sense, yeah.
 20 2017-04-14 04:11:22	0|kallewoof|TBH I think part of the problem is that you aren't sure if what you are suggesting is desired or not. Getting a concept ACK from someone goes a long way and makes the wait less of an issue, at least in my book.
 21 2017-04-14 04:11:48	0|kallewoof|Or a concept NACK for that matter.
 22 2017-04-14 04:12:01	0|gmaxwell|kallewoof: ah, well in this case you got suggestions from wumpus that weren't a "don't do this", which was not a Concept NACK.
 23 2017-04-14 04:12:56	0|gmaxwell|Part of it is familarity with the codebase-- I would expect wumpus to be the person most opinionated with this code. (I believe he wrote all of it.)
 24 2017-04-14 04:13:01	0|gmaxwell|well almost all of it.
 25 2017-04-14 04:13:48	0|gmaxwell|if you don't already know its handy to run a git blame / git log on whatever your change and get an idea of who has been working on that part most recently, since they're most likely to have the most useful review and strongest opinions.
 26 2017-04-14 04:14:12	0|kallewoof|*nods* this is true, but even a code suggestion can be less than a concept ACK. "Merge desire opinions aside, you can improve this code by doing XYZ". That's how I interpret it usually. I wouldn't be surprised to get a concept NACK later.
 27 2017-04-14 04:14:18	0|kallewoof|Oh... I never thought of that, actually.
 28 2017-04-14 04:14:49	0|kallewoof|That might make it easier to nag as it's sort of a suggestion on top of their work..
 29 2017-04-14 04:15:07	0|gmaxwell|oh, I would not expect a person to suggest changes and then concept NACK for a simple patch. For a complex patch where the implications are unclear, perhaps.
 30 2017-04-14 04:15:27	0|kallewoof|*nods*
 31 2017-04-14 04:15:57	0|gmaxwell|Generally if people mildly dislike a change you'll get a thundering silence, not exactly useful feedback to you-- but often people would prefer to bite their tongue in case someone else likes it.
 32 2017-04-14 04:17:13	0|gmaxwell|Suggestions are an investment of resources into your change, in some sense they're better than an ACK in that an ACK can be a drive by review, while if someone makes suggesitons they've basically put themselves on the hook to explain the suggestions to you and collaborate. :)
 33 2017-04-14 04:18:39	0|kallewoof|Right. I've learned a tremendous amount since becoming a contributor. I wish I'd joined an OSS project much earlier. In that sense even a NACK can be appreciated and feel rewarding.
 34 2017-04-14 04:20:18	0|gmaxwell|I think the most important thing to learn is that-- at least once you're beyond a basic level of skill-- your real contribution is the attempt, it doesn't matter if the result ends up in the finished version or stays there, but we're all pushing towards an improved piece of software, and if we keep pushing we'll be successful, even though-- in fact, especially because-- not every change makes it
 35 2017-04-14 04:20:24	0|gmaxwell|in.
 36 2017-04-14 04:21:47	0|gmaxwell|now, ... trying to test your patch and I'm bombing out with a perplexing multiple definition error that looks like you missed an include guard. But it has an include guard.
 37 2017-04-14 04:22:05	0|kallewoof|I agree that that's exactly the right approach to take, and you've given me feedback that I think will help me advocate my own stuff or stuff I feel about by others. Maybe I'll make a PR to the contribution doc summarizing what you said, cause some of it was NOT obvious, at least not to me.
 38 2017-04-14 04:22:28	0|kallewoof|Weird. Testing.
 39 2017-04-14 04:22:47	0|gmaxwell|test/test_test_bitcoin-raii_event_tests.o:/home/gmaxwell/src/bitcoin/src/./support/events.h:30: first defined here
 40 2017-04-14 04:22:50	0|gmaxwell|libbitcoin_server.a(libbitcoin_server_a-httpserver.o): In function `obtain_event(event_base*, int, short, void (*)(int, short, void*), void*)':
 41 2017-04-14 04:22:53	0|gmaxwell|/home/gmaxwell/src/bitcoin/src/support/events.h:37: multiple definition of `obtain_event(event_base*, int, short, void (*)(int, short, void*), void*)'
 42 2017-04-14 04:23:18	0|gmaxwell|oh
 43 2017-04-14 04:23:41	0|gmaxwell|the test. missed that it was the test.
 44 2017-04-14 04:32:28	0|kallewoof|Weird. I'm not getting that compile error (on lubuntu).
 45 2017-04-14 04:33:49	0|gmaxwell|kallewoof: in any case, I went and made all the function definitions in that header static inline, it's fine then. AFAICT the duplicate symbol is real.
 46 2017-04-14 04:34:11	0|gmaxwell|May just be that your linker is handling it differently.
 47 2017-04-14 04:34:50	0|kallewoof|Yeah they should be static and/or inline for sure.
 48 2017-04-14 04:34:58	0|gmaxwell|or moved out of the header.
 49 2017-04-14 04:36:00	0|gmaxwell|(I tend to have relatively few optinions about these things, because I am not much of a C++ coder; and don't really have a sense of taste for such things beyond preferring almost everything to look like C, which is usually the wrong answer. :) )
 50 2017-04-14 04:38:03	0|gmaxwell|in any case seems to work for me, I'll ACK when you've updated to do something about the duplicate function definitions.
 51 2017-04-14 04:40:44	0|kallewoof|Thanks a lot :) I just pushed a commit that adds inline.
 52 2017-04-14 04:44:52	0|cfields|kallewoof: you on osx?
 53 2017-04-14 04:45:13	0|gmaxwell|kallewoof: obtain_event_base too.
 54 2017-04-14 04:45:28	0|kallewoof|cfields: Yep. I do have a linux box too though.
 55 2017-04-14 04:45:46	0|kallewoof|gmaxwell: Yeah, sorry. I force-pushed a squash fix of that one. Was hoping you wouldn't grab before I did.
 56 2017-04-14 04:46:00	0|cfields|kallewoof: the osx linker is very forgiving. too much so, imo.
 57 2017-04-14 04:46:07	0|NicolasDorier|kallewoof: Yeah, the solution to our time zone problem is called the ACK Begging. It works, just need to find the right balance to not get a kick in the butt while getting things committed.
 58 2017-04-14 04:46:16	0|kallewoof|cfields: I compiled fine under lubuntu too, though.
 59 2017-04-14 04:46:33	0|NicolasDorier|btcdrak taught me this technique. Now I think I surpassed the master.
 60 2017-04-14 04:46:47	0|cfields|ah
 61 2017-04-14 04:47:32	0|cfields|kallewoof: fyi, I've written a pretty full-featured c++ wrapper for libevent. Maybe we should collaborate a bit to avoid stepping on eachother.
 62 2017-04-14 04:48:05	0|kallewoof|cfields: That would be lovely. :)
 63 2017-04-14 04:48:42	0|cfields|kallewoof: i'm getting ready to libevent-ify the net code, and I'd really rather not litter it with c code. I think we're probably in agreement there :)
 64 2017-04-14 04:49:39	0|kallewoof|Isn't that what #9517 does already?
 65 2017-04-14 04:49:40	0|gribble|https://github.com/bitcoin/bitcoin/issues/9517 | [refactor] Switched httpserver.cpp to use RAII wrapped libevents. by kallewoof · Pull Request #9517 · bitcoin/bitcoin · GitHub
 66 2017-04-14 04:51:40	0|kallewoof|Oh wait, that's just the httpserver part.
 67 2017-04-14 04:51:52	0|cfields|kallewoof: yea, but it doesn't handle refcounting, std::function, etc. I'd much prefer more native looking callbacks and functors.
 68 2017-04-14 04:53:56	0|kallewoof|That sounds nice yeah. I'd love to help if there's anything I can do.
 69 2017-04-14 04:54:47	0|cfields|kallewoof: for ex, the bufferevent wrapper looks like this: https://0bin.net/paste/1tIvDfqrmUlS5DZU#2y7U59tfCueh+QfprDlMv+5XBjGm2wWceUeKX-PZrTz
 70 2017-04-14 04:54:49	0|gribble|https://github.com/bitcoin/bitcoin/issues/2 | Long-term, safe, store-of-value · Issue #2 · bitcoin/bitcoin · GitHub
 71 2017-04-14 04:55:06	0|cfields|(it's been a while since I've worked with it, I don't recall exactly what state it's in)
 72 2017-04-14 04:55:54	0|kallewoof|Oh, wow.
 73 2017-04-14 04:56:23	0|cfields|kallewoof: the goal would be to be able to cleanly work with events like: bufferevent.read_cb([](size_t bytes){printf("read %lu bytes\n", bytes);});
 74 2017-04-14 04:56:58	0|kallewoof|Looks pretty neat. Would this be a separate library? It looks like it would be.
 75 2017-04-14 04:57:35	0|cfields|it's intended to be a standalone wrapper, but included in our repo
 76 2017-04-14 04:58:57	0|cfields|kallewoof: anyway, that's the reason I haven't chimed in on your PRs. I'd like something a little different, but I don't like standing in the way of obvious improvements either.
 77 2017-04-14 05:00:25	0|kallewoof|cfields: I initially started writing something like that (less elegant) but wumpus suggested he wanted something more light weight. I think a fully featured wrapper might be useful, but it adds some amount of maintainer load in case libevent changes. But then again, I doubt libevent will change a whole lot ever, so I don't think it would be a prob.
 78 2017-04-14 05:01:40	0|cfields|kallewoof: yea, understandable. fwiw, I don't intend to wrap everything, just the stuff we use
 79 2017-04-14 05:02:06	0|kallewoof|Yeah, uh, s/fully featured//
 80 2017-04-14 05:02:11	0|cfields|kallewoof: the reason I ultimately decided on that route is I found my own code to be unreadble without it :(
 81 2017-04-14 05:03:05	0|cfields|kallewoof: anyway, I'm open to whatever is cleanest/simplest. Maybe minimal would be better. But we should collaborate either way :)
 82 2017-04-14 05:03:17	0|kallewoof|I admittedly haven't done a lot. I just fixed the stuff that had // TODO: RAII comments on them, in my never ending quest to find something that needs doing that I am capable of. :P
 83 2017-04-14 05:04:00	0|kallewoof|cfields: I would love to collaborate! :)
 84 2017-04-14 05:05:12	0|cfields|kallewoof: great, give me a few days and I'll push up what I have. Don't let me keep you from working on what you already have though, we can converge later
 85 2017-04-14 05:07:50	0|cfields|kallewoof: one of the most important things (imo) is tracking ownership by passing objects around. For example, if an event needs a pointer to its base, it should hold a reference and keep the base alive. Otherwise, it gets very difficult to guarantee that everything will tear down safely.
 86 2017-04-14 05:09:36	0|kallewoof|cfields: I noticed that too. I tried to do something clever but it kind of backfired and I simplified it. It ended up not being intuitive at all. (I think it was something like, a wrapper holding an object lost the object after a certain operation, but I can't remember.)
 87 2017-04-14 05:10:21	0|cfields|heh
 88 2017-04-14 05:11:57	0|cfields|in the example above, the CBufferEvent requires a CEventBase in its ctor. CEventBase contains a shared_ptr<event_base>. That way, the base lives at least as long as any bufferevents using it.
 89 2017-04-14 05:13:19	0|cfields|so there's no way to create a bufferevent without a valid base, and no way for the base to be deleted out from under a bufferevent.
 90 2017-04-14 05:13:52	0|kallewoof|In some cases the underlying libevent struct takes ownership of an argument, e.g. I believe the evhttp takes ownership of passed-in evhttp_requests. That is what got me.
 91 2017-04-14 05:14:27	0|kallewoof|Even with shared pointers, the request should sometimes be deleted (if not passed into evhttp) and sometimes not (if passed in).
 92 2017-04-14 05:15:53	0|cfields|ah yea, I remember seeing some wonky stuff in evhttp.
 93 2017-04-14 05:16:12	0|cfields|(I didn't wrap that)
 94 2017-04-14 05:17:14	0|kallewoof|cfields: This is the part, I was a bit off on the struct names, but: https://github.com/bitcoin/bitcoin/pull/9387/files#diff-321303fddcf725df060981d626a05df9R234
 95 2017-04-14 05:18:35	0|cfields|kallewoof: is it just evhttp_make_request that does that?
 96 2017-04-14 05:18:39	0|kallewoof|Or not... either way, an evhttp_request is stolen by an evhttp_request when calling evhttp_make_request().
 97 2017-04-14 05:18:48	0|cfields|or.. just certain functions?
 98 2017-04-14 05:18:59	0|kallewoof|Not sure. I think certain functions simply take ownership of stuff you pass in.
 99 2017-04-14 05:19:25	0|kallewoof|So far this is the only case I ran into.
100 2017-04-14 05:20:06	0|cfields|kallewoof: well that'd be easy enough to wrap: http.Request(const CConn& conn, CRequest&& req)
101 2017-04-14 05:20:40	0|cfields|I think those could be handled with move semantics reasonably enough?
102 2017-04-14 05:21:05	0|kallewoof|I'm not sure. I talked to wumpus about it. See e.g. https://github.com/bitcoin/bitcoin/pull/9387#issuecomment-268213151
103 2017-04-14 05:22:23	0|kallewoof|I think part of the problem with my approach was that it wasn't especially elegant, so there was no reason for its existence other than simply wrapping libevent into C++ish fluff. Having a more solid solution like what you're proposing is probably more meaningful.
104 2017-04-14 05:23:12	0|cfields|oh i see, it's conditional on what happens in different places
105 2017-04-14 05:23:36	0|cfields|sorry, I really shouldn't speak on the evhttp code, I'm not familiar enough with it.
106 2017-04-14 05:24:30	0|kallewoof|To be honest, neither am I. I just learned enough to make it work replacing the stuff that was there already.
107 2017-04-14 05:25:04	0|cfields|kallewoof: well I agree with trying to keep it as minimal as possible. I think there's some middle ground that maintains the api while adding protection and type/memory safety.
108 2017-04-14 05:25:44	0|cfields|kallewoof: sounds like a good approach if it gets the job done :)
109 2017-04-14 05:26:56	0|cfields|kallewoof: I'll ping you in the next few days. keep up the good work :)
110 2017-04-14 05:27:04	0|kallewoof|Looking forward to it! :)
111 2017-04-14 05:34:10	0|bitcoin-git|[13bitcoin] 15kallewoof closed pull request #9872: [qa] Multi-chain support in test framework (06master...06qa-multi-chain-support) 02https://github.com/bitcoin/bitcoin/pull/9872
112 2017-04-14 06:48:14	0|bitcoin-git|[13bitcoin] 15kallewoof opened pull request #10208: [wallet] Rescan abortability (06master...06rescan-abortability) 02https://github.com/bitcoin/bitcoin/pull/10208
113 2017-04-14 07:09:19	0|bitcoin-git|[13bitcoin] 15jonasschnelli closed pull request #10208: [wallet] Rescan abortability (06master...06rescan-abortability) 02https://github.com/bitcoin/bitcoin/pull/10208
114 2017-04-14 07:09:40	0|bitcoin-git|[13bitcoin] 15jonasschnelli reopened pull request #10208: [wallet] Rescan abortability (06master...06rescan-abortability) 02https://github.com/bitcoin/bitcoin/pull/10208
115 2017-04-14 07:38:58	0|jonasschnelli|Having a stalled shutdown on a node. It's on c7e73eafa139c29a38f73ab697e2e967a386908d (not a release)
116 2017-04-14 07:47:02	0|sipa|file an issue, give debug.log, ...
117 2017-04-14 07:57:44	0|jonasschnelli|sipa_ https://github.com/bitcoin/bitcoin/issues/10209
118 2017-04-14 07:59:05	0|jonasschnelli|Hmm.... I don't really understand why getaddrinfo on OSX does cache forever... https://github.com/bitcoin/bitcoin/blob/1a5aaabb8a3d67a039ad120bb5d8d418467cac4e/src/netbase.cpp#L104
119 2017-04-14 07:59:21	0|jonasschnelli|The result in OSX client always get the same result from the dnsseed,...
120 2017-04-14 07:59:45	0|jonasschnelli|Well,.. it's not very bad becuase you very likely have a peer that can response reasonable to a getaddr
121 2017-04-14 08:00:06	0|jonasschnelli|But still something thats unfortunate in "client-mode"
122 2017-04-14 08:16:34	0|bitcoin-git|13bitcoin/06master 14883154c 15John Newbery: [rpc] rename disconnectnode argument
123 2017-04-14 08:16:34	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/b7365f0545b1...f4db00f9a548
124 2017-04-14 08:16:35	0|bitcoin-git|13bitcoin/06master 14f4db00f 15Wladimir J. van der Laan: Merge #10204: [rpc] rename disconnectnode argument...
125 2017-04-14 08:16:58	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10204: [rpc] rename disconnectnode argument (06master...06rename_disconnect_node_argument) 02https://github.com/bitcoin/bitcoin/pull/10204
126 2017-04-14 08:26:13	0|wumpus|jonasschnelli: that's crappy. good thing we're going to stop getaddrinfo in favor of libevent after cfields's p2p changes
127 2017-04-14 08:26:40	0|wumpus|(e.g. libevent implements its own DNS resolving instead of using libc's)
128 2017-04-14 08:26:48	0|jonasschnelli|wumpus: What will be the substitute? I hope it won't be evutil_getaddrinfo
129 2017-04-14 08:27:11	0|wumpus|no, I don't think so
130 2017-04-14 08:27:17	0|wumpus|evutil_* is just a wrapper
131 2017-04-14 08:27:20	0|jonasschnelli|Yes. This makes sense.
132 2017-04-14 08:36:14	0|bitcoin-git|13bitcoin/060.14 143c79602 15John Newbery: [rpc] rename disconnectnode argument...
133 2017-04-14 08:36:14	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 060.14: 02https://github.com/bitcoin/bitcoin/compare/06909df179e7...30fa231011a6
134 2017-04-14 08:36:15	0|bitcoin-git|13bitcoin/060.14 1430fa231 15Cory Fields: net: define NodeId as an int64_t...
135 2017-04-14 08:36:33	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10205: [0.14] net: define NodeId as an int64_t (060.14...0610176-backport) 02https://github.com/bitcoin/bitcoin/pull/10205
136 2017-04-14 08:38:57	0|wumpus|did I forget anything for rc2? last chance
137 2017-04-14 09:36:47	0|btcdrak|wumpus: activate segwit ✓ 😁
138 2017-04-14 09:38:33	0|wumpus|😈
139 2017-04-14 10:22:50	0|wumpus|can we activate that before the world goes up in flames, pretty please
140 2017-04-14 10:35:19	0|bitcoin-git|13bitcoin/060.14 14348a717 15Wladimir J. van der Laan: qt: translations update pre-rc2
141 2017-04-14 10:35:19	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.14: 02https://github.com/bitcoin/bitcoin/commit/348a71701db4cb29a762c7d60aba34380ee1d403
142 2017-04-14 10:47:16	0|bitcoin-git|13bitcoin/060.14 1433fadc2 15Wladimir J. van der Laan: doc: Update release notes pre-rc2
143 2017-04-14 10:47:16	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.14: 02https://github.com/bitcoin/bitcoin/commit/33fadc20bae4828788d6d82c582c457adc6941e1
144 2017-04-14 10:51:20	0|wumpus|* [new tag]         v0.14.1rc2 -> v0.14.1rc2
145 2017-04-14 12:27:31	0|emucode|wumpus: core could perhaps include segwit, just as a command line (and gui?) option
146 2017-04-14 12:27:47	0|emucode|I mean, include UASF, BIP148, of segwit
147 2017-04-14 12:31:01	0|wumpus|UASF, in its current form at least, is under heavy discussion still
148 2017-04-14 12:33:50	0|wumpus|the current form has quite some risks while it activates, which wouldn't really be our prefered way of working, see the mailing list for example gmaxwell's writeup here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014152.html
149 2017-04-14 13:11:37	0|achow101|rc2? I thought we were doing final
150 2017-04-14 13:14:14	0|wumpus|meeting yesterday wasn't really conclusive on that, and the rc2 backported changes were deemed too important to leave out, also I forgot to do a translations update for rc1. Hopefully rc2 can be final...
151 2017-04-14 14:12:42	0|bitcoin-git|[13bitcoin] 15kallewoof opened pull request #10211: [doc] Contributor fixes & new "finding reviewers" section (06master...06contributor-finding-reviewers) 02https://github.com/bitcoin/bitcoin/pull/10211
152 2017-04-14 15:02:20	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #10212: Make sure parameter names in .cpp and .h files are in sync (06master...06make-doxygen-happy-by-using-consistent-parameter-names) 02https://github.com/bitcoin/bitcoin/pull/10212
153 2017-04-14 17:32:11	0|cfields|gitian builders: detached sigs for 0.14.1rc2 are up
154 2017-04-14 19:02:58	0|bitcoin-git|[13bitcoin] 15rawodb opened pull request #10214: Abortable rescans & rpc abortrescan command (06master...06pr/rpc_abort_rescan) 02https://github.com/bitcoin/bitcoin/pull/10214
155 2017-04-14 19:11:31	0|bitcoin-git|[13bitcoin] 15rawodb closed pull request #10214: Abortable rescans & rpc abortrescan command (06master...06pr/rpc_abort_rescan) 02https://github.com/bitcoin/bitcoin/pull/10214
156 2017-04-14 20:09:49	0|BlueMatt|jonasschnelli: hey
157 2017-04-14 20:23:25	0|bitcoin-git|[13bitcoin] 15KibbledJiveElkZoo closed pull request #10183: [RPC] Don't default rescan on private/public key imports. (06master...06rpc_rescan_fixes) 02https://github.com/bitcoin/bitcoin/pull/10183
158 2017-04-14 20:35:14	0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #10215: Check interruptNet during dnsseed lookups (06master...062017-04-dnsseed-break) 02https://github.com/bitcoin/bitcoin/pull/10215