1 2017-10-12 00:04:15	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #11488: Codeai fixes: remove dead code, prevent possible division by zero. (06master...06codeai-fixes) 02https://github.com/bitcoin/bitcoin/pull/11488
  2 2017-10-12 00:04:57	0|fanquake|I guess their AI didn't bother checking the open pull requests..
  3 2017-10-12 00:16:22	0|esotericnonsense|`CodeAi suggests` is hilarious
  4 2017-10-12 00:20:06	0|sipa|they're pretty good suggestions
  5 2017-10-12 00:35:07	0|esotericnonsense|fanquake: you really missed a trick with the response. 'fanquake suggests an issue is raised on the CodeAi github regarding ...' :p
  6 2017-10-12 00:36:24	0|TD-Linux|I'm impressed that none of them were false positives
  7 2017-10-12 00:36:58	0|sipa|TD-Linux: perhaps they're human-filtered?
  8 2017-10-12 00:39:44	0|fanquake|sipa If you're are doing some review, could you check #11073 ?
  9 2017-10-12 00:39:46	0|gribble|https://github.com/bitcoin/bitcoin/issues/11073 | Remove dead store in ecdsa_signature_parse_der_lax. by BitonicEelis · Pull Request #11073 · bitcoin/bitcoin · GitHub
 10 2017-10-12 02:13:40	0|bigtimmyc|hello
 11 2017-10-12 02:14:26	0|bigtimmyc|looking for some advice fellas
 12 2017-10-12 02:16:25	0|sipa|you're generally better off on #bitcoin, but without asking a question it's hard to know
 13 2017-10-12 02:17:18	0|bigtimmyc|just looking for general starter advice for development
 14 2017-10-12 02:17:22	0|bigtimmyc|should I go to #bitcoin?
 15 2017-10-12 02:18:07	0|bigtimmyc|just a little confused with how to get started
 16 2017-10-12 02:20:06	0|wxss|bigtimmyc: this channel is for development of the Bitcoin Core client, you may want to try #bitcoin for starting advice
 17 2017-10-12 02:20:37	0|bigtimmyc|sounds good, thanks
 18 2017-10-12 02:20:42	0|bigtimmyc|JOIN #bitcoin
 19 2017-10-12 02:20:44	0|bigtimmyc|fuck
 20 2017-10-12 02:20:48	0|sipa|almost!
 21 2017-10-12 03:21:00	0|BlueMatt|someone wanna close #11481? he's asking why there are two tx sizes (hint: segwit.....)
 22 2017-10-12 03:21:01	0|gribble|https://github.com/bitcoin/bitcoin/issues/11481 | Different size and same transaction · Issue #11481 · bitcoin/bitcoin · GitHub
 23 2017-10-12 04:44:55	0|bitcoin-git|[13bitcoin] 15kallewoof opened pull request #11489: [wallet] sendtoaddress style argument (06master...06201709_segwitwallet2_sendtoaddress) 02https://github.com/bitcoin/bitcoin/pull/11489
 24 2017-10-12 07:01:39	0|bitcoin-git|[13bitcoin] 15justicz closed pull request #11201: [WIP] [RPC] Add verifyrawtransaction RPC (06master...06maxj_add_verify_tx_rpc) 02https://github.com/bitcoin/bitcoin/pull/11201
 25 2017-10-12 11:40:42	0|bitcoin-git|13bitcoin/06master 1455509f1 15practicalswift: Document assumptions that are being made to avoid division by zero
 26 2017-10-12 11:40:42	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/892809309c1b...a865b38bf332
 27 2017-10-12 11:40:43	0|bitcoin-git|13bitcoin/06master 14a865b38 15Wladimir J. van der Laan: Merge #11133: Document assumptions that are being made to avoid division by zero...
 28 2017-10-12 11:41:13	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11133: Document assumptions that are being made to avoid division by zero (06master...06div0) 02https://github.com/bitcoin/bitcoin/pull/11133
 29 2017-10-12 11:41:38	0|bitcoin-git|13bitcoin/06master 14bfebc0b 15Eelis: Remove dead store in ecdsa_signature_parse_der_lax....
 30 2017-10-12 11:41:38	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/a865b38bf332...3bb77ebee6e3
 31 2017-10-12 11:41:39	0|bitcoin-git|13bitcoin/06master 143bb77eb 15Wladimir J. van der Laan: Merge #11073: Remove dead store in ecdsa_signature_parse_der_lax....
 32 2017-10-12 11:42:05	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11073: Remove dead store in ecdsa_signature_parse_der_lax. (06master...06deadstore) 02https://github.com/bitcoin/bitcoin/pull/11073
 33 2017-10-12 12:55:07	0|bitcoin-git|[13bitcoin] 15laanwj pushed 7 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/3bb77ebee6e3...f74459dba6de
 34 2017-10-12 12:55:08	0|bitcoin-git|13bitcoin/06master 14e02007a 15Russell Yanofsky: Limit AuthServiceProxyWrapper.__getattr__ wrapping...
 35 2017-10-12 12:55:08	0|bitcoin-git|13bitcoin/06master 14edafc71 15Russell Yanofsky: Fix uninitialized URI in batch RPC requests...
 36 2017-10-12 12:55:09	0|bitcoin-git|13bitcoin/06master 149f67646 15Russell Yanofsky: Make AuthServiceProxy._batch method usable...
 37 2017-10-12 12:55:39	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11277: Fix uninitialized URI in batch RPC requests (06master...06pr/mb) 02https://github.com/bitcoin/bitcoin/pull/11277
 38 2017-10-12 14:22:37	0|wumpus|github has something new apparently
 39 2017-10-12 14:22:38	0|wumpus|Label issues and pull requests for new contributors
 40 2017-10-12 14:22:38	0|wumpus|Now, GitHub will help potential first-time contributors discover issues labeled with help wanted or good first issue
 41 2017-10-12 14:24:18	0|wumpus|a good idea, though I don't like that we have to add labels in exactly their syntax (and probably capitalization) now
 42 2017-10-12 14:30:52	0|Sentineo|yeah I saw that, but the idea is certainly nice
 43 2017-10-12 14:38:22	0|wumpus|maybe rename "Easy to implement" to "good first issue"? it's the same idea after all
 44 2017-10-12 14:38:44	0|wumpus|was introduced for the same reason
 45 2017-10-12 14:39:42	0|Sentineo|well easy to implement is relative :) easy for who?
 46 2017-10-12 14:52:13	0|wumpus|it only makes sense as a label if it's broadly true
 47 2017-10-12 14:54:14	0|Sentineo|indeed
 48 2017-10-12 14:54:22	0|wumpus|everything might be easy to implement for a single person with matching super-specialized knowledge
 49 2017-10-12 14:55:18	0|wumpus|we can add an "easy to implement for sipa" label and add it to all issues *ducks*
 50 2017-10-12 14:58:38	0|sdaftuar|+1
 51 2017-10-12 15:11:25	0|midnightmagic|+1
 52 2017-10-12 15:19:25	0|Sentineo|:D
 53 2017-10-12 16:42:24	0|promag|sipa: in case you missed https://github.com/bitcoin/bitcoin/pull/11221/files#r143359150
 54 2017-10-12 18:26:12	0|mess110|hi, I am trying to work on https://github.com/bitcoin/bitcoin/issues/7734 and I wanted to ask for advice
 55 2017-10-12 18:26:24	0|mess110|I added the icon on the GUI, designed the icon for proxy/no proxy (still needs work, but I got this), you can see my progress here:
 56 2017-10-12 18:26:38	0|mess110|https://github.com/bitcoin/bitcoin/compare/master...mess110:add_proxy_icon?expand=1
 57 2017-10-12 18:26:44	0|mess110|I am stuck figuring out if I need to show the icon enabled or disabled depending if a proxy/tor proxy is used.
 58 2017-10-12 18:26:52	0|mess110|I can look into settings, but I don't think that is a complete solution because it doesn't handle command line options.
 59 2017-10-12 18:26:58	0|mess110|I tried itterating over proxies here: https://github.com/bitcoin/bitcoin/compare/master...mess110:add_proxy_icon?expand=1#diff-0db7dd184df07a48c307ccc182021a68R266
 60 2017-10-12 18:27:04	0|mess110|but I always get not connected, even with tor browser running locally, so I was wondering if someone could give me some advice, thanks in advance
 61 2017-10-12 18:40:47	0|luke-jr|I guess there's a question of what conditions the icon should be lit; Tor *only*, or Tor at all?
 62 2017-10-12 18:41:17	0|sipa|how do we know you're proxying through tor?
 63 2017-10-12 18:42:47	0|wumpus|in the case of torcontrol automatically using tor it's easy
 64 2017-10-12 18:42:58	0|wumpus|for an arbitrary socks5 proxy it's harder to say
 65 2017-10-12 18:43:12	0|mess110|the way I see it: no proxy icon not lit. other proxy proxy icon lit. tor proxy different icon
 66 2017-10-12 18:43:57	0|wumpus|maybe easier to do would be a proxy icon
 67 2017-10-12 18:44:03	0|wumpus|then later on worry about tor detection
 68 2017-10-12 18:44:13	0|wumpus|(say, in a followup PR)
 69 2017-10-12 18:44:22	0|sipa|there is -tor, but that's about configuring a proxy for tor connections
 70 2017-10-12 18:44:25	0|mess110|ok, but would checking the settings be enough?
 71 2017-10-12 18:44:34	0|sipa|mess110: no
 72 2017-10-12 18:44:49	0|wumpus|you should check the same thing getnetworkinfo checks
 73 2017-10-12 18:44:50	0|sipa|in normal circumstances you'd just use -proxy
 74 2017-10-12 18:45:04	0|wumpus|it has the information, per network, whether a proxy is used
 75 2017-10-12 18:45:48	0|luke-jr|our node needs to know if it has a Tor address to advertise..
 76 2017-10-12 18:45:48	0|wumpus|I'd say show the icon only if all networks use a proxy, becaues that's usually what the user wants to be informed of ("is everything I do proxied")
 77 2017-10-12 18:46:12	0|luke-jr|so there should never be a question whether Tor is setup or not
 78 2017-10-12 18:46:18	0|wumpus|luke-jr: yeah advertising the onion is what torcontrol does, let's focus on proxy first, tor later
 79 2017-10-12 18:47:01	0|luke-jr|"are we binding any non-localhost ports?"
 80 2017-10-12 18:47:05	0|wumpus|if a proxy is used for everything *and* that is the tor proxy, it could show a special tor icon, but that's easier to do
 81 2017-10-12 18:47:17	0|wumpus|eh harder
 82 2017-10-12 18:47:25	0|wumpus|this is not really about binding
 83 2017-10-12 18:47:37	0|wumpus|proxy is foremost about outgoing connections
 84 2017-10-12 18:47:40	0|mess110|sipa: I am using the GUI to set tor proxy and restarting the client. there is a chance I am not actually connected though a proxy because I am doing similar things like getnetworkinfo
 85 2017-10-12 18:47:49	0|wumpus|though you could check the listening too...
 86 2017-10-12 18:48:15	0|wumpus|if you set a proxy in the GUI, it will use a proxy next restart
 87 2017-10-12 18:48:17	0|luke-jr|wumpus: I'm not sure why users would care only about outgoing connections?
 88 2017-10-12 18:48:27	0|wumpus|luke-jr: because that's the only ones that go through a proxy
 89 2017-10-12 18:48:40	0|luke-jr|we broadcast transactions on incoming connections too
 90 2017-10-12 18:48:55	0|luke-jr|presumably the icon is desired to get a feel for privacy level
 91 2017-10-12 18:48:56	0|wumpus|sure, but if you provide -proxy at least it disables incoming connections
 92 2017-10-12 18:50:25	0|luke-jr|IMO, we should have 3 states: public, proxy (no non-local inbound connections accepted; outbound via proxy), and tor (no non-local inbound connections accepted; Tor hidden service address configured [and known to be working?])
 93 2017-10-12 18:50:49	0|wumpus|yeah that sounds ok
 94 2017-10-12 18:51:44	0|mess110|luke-jr: thats my long term plan now. will focus on detecting public/proxy in my first PR
 95 2017-10-12 18:52:17	0|mess110|and thx, I got confirmation that getnetworkinfo is what I should look at
 96 2017-10-12 18:52:31	0|luke-jr|yeah, that's probably a good example to go from
 97 2017-10-12 19:00:05	0|sipa|WOOSH
 98 2017-10-12 19:00:14	0|achow101|meeting?
 99 2017-10-12 19:00:26	0|Chris_Stewart_5|and HERE WE GO.
100 2017-10-12 19:00:56	0|gmaxwell|wumpus
101 2017-10-12 19:01:07	0|jonasschnelli|hi
102 2017-10-12 19:02:12	0|achow101|hi
103 2017-10-12 19:02:17	0|wumpus|#startmeeting
104 2017-10-12 19:02:18	0|lightningbot|Meeting started Thu Oct 12 19:02:17 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
105 2017-10-12 19:02:18	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
106 2017-10-12 19:02:22	0|luke-jr|before we officially start, does anyone mind if I collapse the fixups in #11383 ?
107 2017-10-12 19:02:25	0|gribble|https://github.com/bitcoin/bitcoin/issues/11383 | Basic Multiwallet GUI support by luke-jr · Pull Request #11383 · bitcoin/bitcoin · GitHub
108 2017-10-12 19:02:41	0|wumpus|#bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101
109 2017-10-12 19:02:48	0|kanzure|hi.
110 2017-10-12 19:03:03	0|cfields|hi
111 2017-10-12 19:03:27	0|wumpus|luke-jr: probably best to do that just before merge
112 2017-10-12 19:03:35	0|BlueMatt|suggested topics: backdating segwit/p2sh
113 2017-10-12 19:03:38	0|BlueMatt|suggested topics: segwit wallet
114 2017-10-12 19:03:51	0|BlueMatt|suggested topics: pre-2x release (possibly with no segwit wallet)?
115 2017-10-12 19:04:06	0|wumpus|#topic Backdating segwit/p2sh (BlueMatt)
116 2017-10-12 19:04:16	0|sdaftuar|i guess matt wants me to talk about this one
117 2017-10-12 19:04:33	0|jl2012|hi
118 2017-10-12 19:04:56	0|meshcollider|Hello
119 2017-10-12 19:05:18	0|gmaxwell|I am pro backdating but wasn't sure how we should handle the rollback and replay. Rolling back the whole chain would be unfortunate. :P
120 2017-10-12 19:05:21	0|sdaftuar|in thinking about p2sh and segwit, they both have the property that it doesn't make sense to ever accept blocks that violate those rules
121 2017-10-12 19:05:42	0|sdaftuar|in the case of p2sh, there was only one historical block that violated SCRIPT_VERIFY_P2SH
122 2017-10-12 19:05:48	0|jl2012|I think backdating segwit is not trivial because the inclusion of witness commitment pre-fork
123 2017-10-12 19:05:57	0|sdaftuar|in the case of segwit, no blocks have ever violated the segwit scritp flag SCRIPT_VERIFY_WITNESS
124 2017-10-12 19:06:14	0|gmaxwell|jl2012: I thought all the prefork ones were valid.
125 2017-10-12 19:06:16	0|sdaftuar|but of course, the witness commitment validation rules don't really work for backdating
126 2017-10-12 19:06:28	0|sdaftuar|gmaxwell: i don't think that is true, though i didn't verify myself
127 2017-10-12 19:06:28	0|wumpus|backdating to when? to the beginning of the chain?
128 2017-10-12 19:06:31	0|sdaftuar|wumpus: yes
129 2017-10-12 19:06:43	0|cfields|jl2012: i checked the pre-activation commitments on mainnet and found them to all be valid
130 2017-10-12 19:06:43	0|wumpus|interesting
131 2017-10-12 19:06:49	0|BlueMatt|gmaxwell: somehow i thought many of them were invalid
132 2017-10-12 19:06:52	0|BlueMatt|oh!
133 2017-10-12 19:06:53	0|jl2012|gmaxwell: not exactly, because of lack of the 0000.....0000 coinbase witness
134 2017-10-12 19:06:54	0|sdaftuar|cfields: oh!
135 2017-10-12 19:06:55	0|achow101|isn't segwit only backdateable to p2sh activation at earliest?
136 2017-10-12 19:07:03	0|gmaxwell|I think in general its cleanest when we can backdate softforks to the start.
137 2017-10-12 19:07:09	0|BlueMatt|achow101: we're talking about backdating p2sh as well (with one exception)
138 2017-10-12 19:07:16	0|sdaftuar|yes it would take some work to manufacture the witness nonces as jl2012 points out
139 2017-10-12 19:07:28	0|sipa|what is the advantage over just hardcoding a height for segwit and p2sh start?
140 2017-10-12 19:07:31	0|sdaftuar|but if it is really true that none were invalid, that might change the way i look at it
141 2017-10-12 19:07:46	0|wumpus|sipa: no need to handle the non-segwit case for initial validation anymore ,I guess
142 2017-10-12 19:07:49	0|BlueMatt|sipa: it is a very nice property (imo) that you will *never* accept any chain with invalid segwit/p2sh spends
143 2017-10-12 19:07:57	0|BlueMatt|irrespective of reorgs
144 2017-10-12 19:08:04	0|jl2012|sdaftuar: and for some blocks that was very close to 1MB, adding the coinbase witness will make it over 4M weight
145 2017-10-12 19:08:24	0|sipa|BlueMatt: sure, but i'm not sure that weighs up against the complication of adding exceptions, make-pretending to have coinbase witnesses nonces, ...
146 2017-10-12 19:08:29	0|gmaxwell|it also simplifies reasoning about further changes, e.g. what happens if someone forks early during IBD and feeds us a chain with things we assumed were impossible.
147 2017-10-12 19:08:43	0|BlueMatt|in any case, I believe sdaftuar's suggestion was to backdate SCRIPT_VERIFY_WITNESS/P2SH, but dissallow witnesses in blocks pre-activation, effectively disabling segwit
148 2017-10-12 19:08:47	0|sdaftuar|gmaxwell: yeah that's basically the reason i started thinking abotu this
149 2017-10-12 19:08:52	0|sipa|BlueMatt: ugh
150 2017-10-12 19:08:54	0|sdaftuar|but i don't feel strongly either way
151 2017-10-12 19:08:58	0|BlueMatt|sipa: you can skip the witness nonce part
152 2017-10-12 19:09:16	0|luke-jr|jl2012: are any of those blocks *also* with the commitment?
153 2017-10-12 19:09:21	0|sipa|that's effectively splitting the segwit logic into 2 deployments, with one always active?
154 2017-10-12 19:09:23	0|gmaxwell|I don't feel strongly about it except the general principle that it's better to backdate wheverever possible.
155 2017-10-12 19:09:36	0|BlueMatt|sipa: well I would call that splitting it into one deployment and one consensus rule
156 2017-10-12 19:09:37	0|BlueMatt|but ok
157 2017-10-12 19:09:41	0|morcos|well an always active deployment is kind of not a deployment
158 2017-10-12 19:09:43	0|morcos|right
159 2017-10-12 19:09:46	0|sdaftuar|sipa: the branch i have splits the witness commitment rule from the script verification rule, basically
160 2017-10-12 19:09:54	0|sipa|BlueMatt: so you're not getting rid of the deployment overhead
161 2017-10-12 19:09:57	0|sdaftuar|i was not sure it was an improvement
162 2017-10-12 19:10:16	0|BlueMatt|sipa: indeed, it does not significantly simplify, it (mostly) just adds a very nice property
163 2017-10-12 19:10:28	0|BlueMatt|(and, as gmaxwell points out, may simplify future fork logic)
164 2017-10-12 19:10:37	0|sipa|i understand the advantage of making a consensus rule always active, allowing you to get rid of some logic
165 2017-10-12 19:10:43	0|jl2012|luke-jr: I guess so, especially from f2pool. They mine exactly 1MB block quite frequently
166 2017-10-12 19:10:44	0|sdaftuar|jl2012: that weight issue is a good point
167 2017-10-12 19:10:48	0|sipa|but it doesn't seem that's really possible here without further complication
168 2017-10-12 19:11:00	0|BlueMatt|I dont think its adding significant new complication
169 2017-10-12 19:11:02	0|gmaxwell|Not just simplfy but reduce the incidence where the community makes design errors due to reasoning from current rules without realizing they don't apply in IBD.
170 2017-10-12 19:11:29	0|gmaxwell|but what sipa says, I don't think backdating is worth non-trivial extra complexity.
171 2017-10-12 19:11:33	0|luke-jr|what's the downside to allowing witness in pre-activation blocks?
172 2017-10-12 19:11:48	0|sipa|luke-jr: makes my head hurt
173 2017-10-12 19:12:07	0|gmaxwell|luke-jr: that we'll make changes in the future based on an assumption that they're never there.
174 2017-10-12 19:12:28	0|BlueMatt|sipa: I'm looking at https://github.com/sdaftuar/bitcoin/compare/2649d1690ce9458aa344a8ccfb1fa8548b2ac57c...2017-09-p2sh-segwit-from-genesis
175 2017-10-12 19:12:52	0|gmaxwell|We also don't have to decide this forever now, we could e.g. set it to activate at the real height now, and then later adjust it further back.
176 2017-10-12 19:12:54	0|morcos|sipa: i just really hate the attack scenarios that involve feeding alternate chains that eventually get reorged out but possibly with poor consequences...  perhaps this is not a problem with segwit, but perhaps it is... say your wallet loses money in an unexpected way or something?
177 2017-10-12 19:13:15	0|sipa|BlueMatt: that doesn't look too bad, i guess
178 2017-10-12 19:13:26	0|sipa|but i need to think about it
179 2017-10-12 19:13:39	0|BlueMatt|sipa: yes, sorry, should have shared the code since we're arguing based on different understandings...anyway, something to think about, I dont think I feel *that* strongly, but I am vaguely in favor
180 2017-10-12 19:13:41	0|sdaftuar|if this is worth discussion, i can open a PR
181 2017-10-12 19:13:50	0|sdaftuar|i wasn't sure whether to move this forward
182 2017-10-12 19:14:08	0|sipa|but in regards to the next topic, do we want all that in 0.15.1?
183 2017-10-12 19:14:21	0|morcos|no, i don't
184 2017-10-12 19:14:25	0|BlueMatt|i dont think so?
185 2017-10-12 19:14:25	0|sdaftuar|i don't think this so either
186 2017-10-12 19:14:30	0|sipa|okay
187 2017-10-12 19:14:33	0|wumpus|would be kind of hurried IMO
188 2017-10-12 19:14:37	0|BlueMatt|very
189 2017-10-12 19:14:39	0|gmaxwell|It would be really nice if 0.15.1 were out before the B2X split, but we're on the thin edge of that now I think.
190 2017-10-12 19:14:43	0|wumpus|also let's not increase the scope of 0.15.1
191 2017-10-12 19:14:47	0|BlueMatt|ok, so #action sdaftuar opens pr? next topic?
192 2017-10-12 19:14:47	0|sipa|so this is unrelated to #11389
193 2017-10-12 19:14:49	0|gribble|https://github.com/bitcoin/bitcoin/issues/11389 | Support having SegWit always active in regtest by sipa · Pull Request #11389 · bitcoin/bitcoin · GitHub
194 2017-10-12 19:14:52	0|wumpus|#topic segwit wallet
195 2017-10-12 19:15:20	0|achow101|if we want 0.15.1 out before B2X, it probably needs to go into rc's within the next week
196 2017-10-12 19:15:28	0|jonasschnelli|For the GUI, I'm working on a Bech32 error pointer (red underlines where errors appear)
197 2017-10-12 19:15:30	0|sipa|achow101: seems unreasonable
198 2017-10-12 19:15:35	0|sipa|i first want to get 11389 in, but there seems to be some discussion about the right approach
199 2017-10-12 19:15:36	0|BlueMatt|(which probably means no segwit wallet)
200 2017-10-12 19:15:52	0|wumpus|0.15.0.2? :p
201 2017-10-12 19:15:56	0|BlueMatt|yea, that
202 2017-10-12 19:16:04	0|sipa|or 0.15.1 without segwit wallet, 0.15.2 with
203 2017-10-12 19:16:14	0|wumpus|we'll just do minor-minor releases until we have the damn segwit wallet :)
204 2017-10-12 19:16:19	0|BlueMatt|yea, numbers...isnt someone in charge of those so I dont have to think about them?
205 2017-10-12 19:16:19	0|sipa|haha
206 2017-10-12 19:16:24	0|jnewbery|I think #11389 is related to Suhas's suggested change, no?
207 2017-10-12 19:16:26	0|gribble|https://github.com/bitcoin/bitcoin/issues/11389 | Support having SegWit always active in regtest by sipa · Pull Request #11389 · bitcoin/bitcoin · GitHub
208 2017-10-12 19:16:38	0|gmaxwell|well, RC by then at least would be good if not out...
209 2017-10-12 19:16:53	0|BlueMatt|sipa: wait, so you want to have segwit always active in regtest for segwit wallet, or what am I misunderstanding about the need for segwit-regtest for 0.15.1?
210 2017-10-12 19:16:59	0|sipa|BlueMatt: yes
211 2017-10-12 19:17:17	0|sipa|adapting the tests to deal with segwit activation halfway through them is a giant pain
212 2017-10-12 19:17:24	0|wumpus|so if we'd do 0.15.1 without segwit wallet, is there anything that still needs to go in? or can we tag rc1 after the meeting?
213 2017-10-12 19:17:27	0|BlueMatt|test_framework().activate_segwit() ?
214 2017-10-12 19:17:31	0|morcos|as much as i really want to concentrate on segwit wallet
215 2017-10-12 19:17:39	0|sipa|jnewbery: i was starting to respond to you, but to the last point "We already have control to make a BIP9 deployment active at a certain height in regtest using -vbparams. What advantages do you see for making a deployment buried instead of just activated at a height?" -> -vbparams doesn't permit having segwit active before block 432
216 2017-10-12 19:17:51	0|achow101|what's the point of doing 0.15.1 without segwit wallet?
217 2017-10-12 19:17:51	0|morcos|i think practically speaking we should focus on what would be good to have before 2X
218 2017-10-12 19:17:56	0|wumpus|I'm not sure what is the rationale for doing 0.15.1, are there important bugfixes that we need to get out?
219 2017-10-12 19:17:57	0|morcos|and we should do that withotu segwit wallet
220 2017-10-12 19:18:14	0|BlueMatt|wumpus: mostly I want https://github.com/bitcoin/bitcoin/pull/11487/commits/09cf35122a219217f841e4e4f7847386eb0b0b8a pre-b2x
221 2017-10-12 19:18:19	0|achow101|what needs to be done before 2X then?
222 2017-10-12 19:18:21	0|BlueMatt|but dunno if thats a realistic goal (it probably isnt)
223 2017-10-12 19:18:21	0|morcos|wumpus: there are a few edge cases with invalid chains that might cause for annoying behavior
224 2017-10-12 19:18:55	0|wumpus|I mean MarcoFalke backported a lot of things, that's nice to have in #11447
225 2017-10-12 19:18:57	0|gribble|https://github.com/bitcoin/bitcoin/issues/11447 | 0.15.1: Backports by MarcoFalke · Pull Request #11447 · bitcoin/bitcoin · GitHub
226 2017-10-12 19:19:47	0|wumpus|BlueMatt: so 11487 should get 0.15.1 tag?
227 2017-10-12 19:19:58	0|BlueMatt|its not critical, but having edge cases that you may see if you're offline during the fork and suddenly you accept blocks that are on the 2x chain (if they're <4m weight and more work and within our pruning window) thats kinda annoying
228 2017-10-12 19:20:00	0|wumpus|or really just that commit?
229 2017-10-12 19:20:03	0|gmaxwell|Just for the record I think it is terrible that we're effectively being forced to delay segwit wallet due to this nonsense.
230 2017-10-12 19:20:11	0|wumpus|if so, please open a separate PR for that
231 2017-10-12 19:20:15	0|BlueMatt|wumpus: the rest of that pr is just test changes and other tiny things
232 2017-10-12 19:20:30	0|wumpus|gmaxwell: yes, me to, I'd personally prefer not to change our plans for them
233 2017-10-12 19:20:31	0|gmaxwell|(even if we don't bump around the versions for it, the fact that people are spending time on these other things creates delays)
234 2017-10-12 19:21:01	0|wumpus|but if we need robustness changes now, better to do it
235 2017-10-12 19:21:05	0|meshcollider|And add to high priority for review?
236 2017-10-12 19:21:14	0|wumpus|yes, and remove the rest probably
237 2017-10-12 19:21:17	0|gmaxwell|In any case, so far I haven't seen PRs that we need in advance merged yet, if there were some in, I would support doing a release with them.
238 2017-10-12 19:21:41	0|gmaxwell|It's hard to anticipate what we'll need a month in advance...
239 2017-10-12 19:22:05	0|BlueMatt|wumpus: again, I dont think its a "need", but its open for discussion
240 2017-10-12 19:22:07	0|wumpus|if we want to do rc1 start of next week we'll really need to hurry
241 2017-10-12 19:22:11	0|gmaxwell|esp because B2X has already changed their behavior to undermine our protections in the past... :-/
242 2017-10-12 19:22:18	0|BlueMatt|its really gross that we may accept/store blocks on a chain we know is invalid
243 2017-10-12 19:22:25	0|BlueMatt|but its not gonna do anything but use a bit more disk
244 2017-10-12 19:22:32	0|gmaxwell|Yes, okay, that is a concern.
245 2017-10-12 19:23:00	0|meshcollider|#11446 probably won't make it either will it
246 2017-10-12 19:23:02	0|gribble|https://github.com/bitcoin/bitcoin/issues/11446 | [WIP] Bad block interrogation by achow101 · Pull Request #11446 · bitcoin/bitcoin · GitHub
247 2017-10-12 19:23:02	0|wumpus|yes that's kind of gross
248 2017-10-12 19:23:29	0|gmaxwell|meshcollider: well thats the sort of thing we're talking about right now.
249 2017-10-12 19:23:49	0|achow101|I think 11446 would be necessary for a pre-B2X release so that we kick all peers that give us invalid blocks, not just the first
250 2017-10-12 19:23:57	0|gmaxwell|basically to do these things we'll need to more or less drop working on SW wallet for a moment, get those things, and RC them. ASAP.
251 2017-10-12 19:24:18	0|achow101|and/or maybe #10593
252 2017-10-12 19:24:20	0|gribble|https://github.com/bitcoin/bitcoin/issues/10593 | Relax punishment for peers relaying invalid blocks and headers by luke-jr · Pull Request #10593 · bitcoin/bitcoin · GitHub
253 2017-10-12 19:24:23	0|meshcollider|Yeah a release including both of those would be worth it if they're ready for merge in time
254 2017-10-12 19:24:50	0|gmaxwell|misleading PR title. :P
255 2017-10-12 19:25:03	0|wumpus|ok tagged both of them for 0.15.1
256 2017-10-12 19:25:49	0|wumpus|will move the rest that's tagged with 0.15.1 and unmerged to 0.15.2 when we actually decide to do the release
257 2017-10-12 19:25:51	0|sdaftuar|fyi i have one more pr that is along these same lines that i will be opening shortly... basically trying to implement some of the outbound peer protection we talked abotu last week's meeting
258 2017-10-12 19:26:21	0|gmaxwell|sdaftuar: I'll put some time into helping review that. (though I'll be in the air much of the weekend...)
259 2017-10-12 19:26:27	0|sdaftuar|awesome, thanks
260 2017-10-12 19:26:28	0|cfields|sorry, i had to run out for a min.... Lots of people are expecting 0.15.1 as the release that enables more segwit wallet functionality. Releasing without that will be very confusing to lots of people. Is there any reason not to call it 0.15.0.2 ?
261 2017-10-12 19:26:53	0|sipa|no opinion on versioning
262 2017-10-12 19:26:58	0|luke-jr|gmaxwell: how is it misleading?
263 2017-10-12 19:26:59	0|jonasschnelli|agree with cfields
264 2017-10-12 19:27:07	0|jnewbery|+1 for 0.15.0.2
265 2017-10-12 19:27:08	0|cfields|It's just that they've been told over and ove to wait for 0.15.1...
266 2017-10-12 19:27:09	0|meshcollider|Agree with cfields as well
267 2017-10-12 19:27:10	0|jl2012|ack 0.15.0.2
268 2017-10-12 19:27:20	0|wumpus|no opinion on how to call it either, 0.15.0.2 was really a joke though, usually we do minor-mimor versions only for tiny changes
269 2017-10-12 19:27:32	0|gmaxwell|I'd prefer to call 0.15.1 the one with segwit wallet just due to comms reasons.
270 2017-10-12 19:27:41	0|luke-jr|personally, I'd prefer to move segwitwallet to 0.16, but it's numbers so who cares
271 2017-10-12 19:27:55	0|wumpus|anyhow if everyone wants 0.15.0.2 , we'll have 0.15.0.2
272 2017-10-12 19:27:56	0|luke-jr|comms reasons probably outweigh any reason to move it
273 2017-10-12 19:27:58	0|meshcollider|Or look at #9653 now and throw everyone into confusion ;)
274 2017-10-12 19:27:59	0|gribble|https://github.com/bitcoin/bitcoin/issues/9653 | Versioning convention for Bitcoin Core · Issue #9653 · bitcoin/bitcoin · GitHub
275 2017-10-12 19:28:04	0|wumpus|yes, agree with that
276 2017-10-12 19:28:08	0|gmaxwell|(comms reasons is that there are a billionity messages on the internet saying 0.15.1 has segwit wallet)
277 2017-10-12 19:28:11	0|wumpus|we've kind of promised segwit wallet in 0.15.1
278 2017-10-12 19:28:17	0|cfields|right
279 2017-10-12 19:28:28	0|achow101|what if we did segwit wallet this weekend? *ducks*
280 2017-10-12 19:28:36	0|luke-jr|let's go with 0.15.½ :P
281 2017-10-12 19:28:45	0|wumpus|achow101: if we did that, we'ld not get around to the ultra-high-priority ones that warrant releasing now
282 2017-10-12 19:28:46	0|meshcollider|Lol
283 2017-10-12 19:28:49	0|gmaxwell|so obviously we release 0.15.3  ... and then 0.15.1 after it...
284 2017-10-12 19:28:56	0|wumpus|luke-jr: hehe floating point version numbers
285 2017-10-12 19:29:15	0|wumpus|luke-jr: eh I mean fractions
286 2017-10-12 19:29:23	0|meshcollider|0.15.0.../.1
287 2017-10-12 19:29:37	0|cfields|gmaxwell: starting to sound like gcc. Obviously gcc 8.0 is the beta :p
288 2017-10-12 19:30:03	0|gmaxwell|0.15.A
289 2017-10-12 19:30:19	0|wumpus|ok, so 0.15.0.2 it is, will create a milestone and change the tags
290 2017-10-12 19:30:24	0|gmaxwell|in any case, lets worry about that when we're actually ready to release; I think we understand the tradeoffs.
291 2017-10-12 19:30:34	0|gmaxwell|sounds good to me
292 2017-10-12 19:30:42	0|cfields|sorry for the late chime-in
293 2017-10-12 19:32:18	0|wumpus|yeah no problem, I guess we covered both "segwit wallet" and "pre-2x release"  - any other topics?
294 2017-10-12 19:32:38	0|morcos|So not clear to me if we've decided
295 2017-10-12 19:32:51	0|morcos|Are we doing a pre-2X release or trying to at least
296 2017-10-12 19:33:11	0|wumpus|my impression is that we're going to try
297 2017-10-12 19:33:15	0|morcos|It would be helpful to note if we're clearly prioritizing that and putting them on high-priority-for-review
298 2017-10-12 19:33:21	0|wumpus|https://github.com/bitcoin/bitcoin/milestone/32
299 2017-10-12 19:33:40	0|wumpus|yes, they should be (and anything else should go for nwo)
300 2017-10-12 19:33:50	0|gmaxwell|it sounds like we're going to try...
301 2017-10-12 19:34:25	0|gmaxwell|also keep in mind that there is value in having protections in master, even if they're not in a release... a small percentage of nodes in the network being protected can help improve stability for everyone.
302 2017-10-12 19:35:11	0|morcos|achow101: can you please update title and description for #11446
303 2017-10-12 19:35:13	0|gribble|https://github.com/bitcoin/bitcoin/issues/11446 | [WIP] Bad block interrogation by achow101 · Pull Request #11446 · bitcoin/bitcoin · GitHub
304 2017-10-12 19:35:17	0|achow101|morcos: hehe sure
305 2017-10-12 19:35:50	0|morcos|And do you think we don't need #10593 if we have 11446?
306 2017-10-12 19:35:53	0|gribble|https://github.com/bitcoin/bitcoin/issues/10593 | Relax punishment for peers relaying invalid blocks and headers by luke-jr · Pull Request #10593 · bitcoin/bitcoin · GitHub
307 2017-10-12 19:35:57	0|gmaxwell|in any case, based on CST prices, I think we should focus on protections that help in the case that we have disguised B2X peers and they're getting no blocks at all (Because they've rejected the bitcoin chain).
308 2017-10-12 19:36:19	0|achow101|morcos: #10953 does something mostly different
309 2017-10-12 19:36:22	0|gribble|https://github.com/bitcoin/bitcoin/issues/10953 | [Refactor] Combine scriptPubKey and amount as CTxOut in CScriptCheck by jl2012 · Pull Request #10953 · bitcoin/bitcoin · GitHub
310 2017-10-12 19:36:35	0|sipa|wrong pr number?
311 2017-10-12 19:36:45	0|achow101|oops 10593
312 2017-10-12 19:36:45	0|morcos|593, see above
313 2017-10-12 19:36:53	0|gmaxwell|#10593
314 2017-10-12 19:36:55	0|gribble|https://github.com/bitcoin/bitcoin/issues/10593 | Relax punishment for peers relaying invalid blocks and headers by luke-jr · Pull Request #10593 · bitcoin/bitcoin · GitHub
315 2017-10-12 19:37:00	0|morcos|in 593 you say it does the same as 11446
316 2017-10-12 19:37:01	0|wumpus|https://github.com/bitcoin/bitcoin/projects/8 updated
317 2017-10-12 19:37:24	0|achow101|I suggested it because luke-jr that it would do about the same thing plus some more, but I noticed that it doesn't really
318 2017-10-12 19:37:25	0|morcos|basically i'm just trying to get concept acks here on what we're going for
319 2017-10-12 19:37:32	0|morcos|ok
320 2017-10-12 19:37:44	0|achow101|see https://github.com/bitcoin/bitcoin/pull/10593#issuecomment-334946691
321 2017-10-12 19:38:06	0|achow101|I thought luke-jr might change it to include what 11446 does
322 2017-10-12 19:38:39	0|BlueMatt|gmaxwell: yes, regarding b2x peers that have less hashpower and are disguised, I believe thats what sdaftuar is working on
323 2017-10-12 19:38:50	0|gmaxwell|BlueMatt: great, okay!
324 2017-10-12 19:38:59	0|morcos|OK Can someone motivate 10593 for me
325 2017-10-12 19:39:20	0|morcos|I mean not really motivate, but explain why it is important before 2X
326 2017-10-12 19:39:37	0|luke-jr|It's more important before the next softfork, not so much before 2X, AFAIK
327 2017-10-12 19:39:49	0|morcos|ok, that was my reading...
328 2017-10-12 19:39:57	0|luke-jr|(if 2X would accept a reorg, it'd be useful, but 2X doesn't)
329 2017-10-12 19:40:17	0|gmaxwell|I thought it also added disconnects on invalids that we currently don't have?
330 2017-10-12 19:40:17	0|luke-jr|oh, if 2X users want to switch to Bitcoin, it might be useful for them
331 2017-10-12 19:40:34	0|gmaxwell|luke-jr: because it turns some bans into disconnects?
332 2017-10-12 19:40:38	0|luke-jr|gmaxwell: right
333 2017-10-12 19:40:38	0|morcos|can we perhaps remove that from high priority and concentrate on the pre-2X things... (hmm, good point i suppose)
334 2017-10-12 19:40:47	0|luke-jr|gmaxwell: IIRC, the disconnect-on-merely-invalid is achow101's PR
335 2017-10-12 19:41:39	0|achow101|gmaxwell: it turns bans into disconnects, which includes the ban on the first time we see an invalid block
336 2017-10-12 19:43:27	0|gmaxwell|I think that in and of itself is less critical.
337 2017-10-12 19:43:49	0|luke-jr|so I guess 10593 is a nice-to-have before 2X, but not a must-have
338 2017-10-12 19:43:51	0|luke-jr|?
339 2017-10-12 19:43:58	0|achow101|luke-jr: agreed
340 2017-10-12 19:44:25	0|morcos|that sounds right to me
341 2017-10-12 19:44:38	0|gmaxwell|sounds reasonable to me.
342 2017-10-12 19:45:10	0|wumpus|so 10593 is less-than-higher-priority-for-review? :p
343 2017-10-12 19:45:23	0|sdaftuar|slightly-higher-priority-for-review
344 2017-10-12 19:45:26	0|sipa|elevated-priority
345 2017-10-12 19:45:49	0|morcos|or as we used to do it in Core:  14275131000
346 2017-10-12 19:46:10	0|sipa|$ date --date "@14275131000"
347 2017-10-12 19:46:10	0|sipa|Thu May 12 03:10:00 PDT 2422
348 2017-10-12 19:46:31	0|achow101|???
349 2017-10-12 19:46:41	0|morcos|heh, i made up the number b/c i was lazy, but there were number ranges.. one was for medium-high priority
350 2017-10-12 19:46:55	0|BlueMatt|lol, ok, so did we ever discuss segwit wallet?
351 2017-10-12 19:47:02	0|BlueMatt|sorry, I kinda derailed things :(
352 2017-10-12 19:47:08	0|sipa|apparently we discussed it being less priority
353 2017-10-12 19:47:12	0|sipa|or something
354 2017-10-12 19:47:13	0|wumpus|TIL that date command line can convert unix timestamps, thanks sipa
355 2017-10-12 19:47:25	0|BlueMatt|noooooo :(
356 2017-10-12 19:47:26	0|sipa|wumpus: also, date "+%s"
357 2017-10-12 19:47:32	0|morcos|how did you do that otherwise?
358 2017-10-12 19:47:33	0|gmaxwell|57599999
359 2017-10-12 19:47:47	0|BlueMatt|wumpus: oh, another hint, when reading git logs, it is useful to have a vim keybinding to call that command so you can see when it happened :p
360 2017-10-12 19:47:47	0|morcos|thanks gmax
361 2017-10-12 19:47:57	0|wumpus|morcos: time.ctime(n) or time.localtime(n) in python
362 2017-10-12 19:48:02	0|gmaxwell|morcos: python is pretty useful for date math.
363 2017-10-12 19:48:12	0|sipa|BlueMatt: i will work on describing the alternatives for segwit wallet support, and some thoughts on wallet/ismine in 0.16
364 2017-10-12 19:48:20	0|sipa|BlueMatt: but blocker is the always-segwit-active
365 2017-10-12 19:48:26	0|gmaxwell|e.g. script I use for IBD benchmarking uses python to difference bitcoin log dates.
366 2017-10-12 19:48:27	0|wumpus|gmaxwell: exactly
367 2017-10-12 19:48:32	0|sipa|so review/discussion can focus on that for now, i think
368 2017-10-12 19:49:04	0|BlueMatt|sipa: well, at least personally, I'm also fine with taking the always-active-segwit pr and then reverting it if we decide we want something more like jl2012's on master, isnt a big changeset either way
369 2017-10-12 19:49:11	0|BlueMatt|so I'm not sure I'd call it a "blocker" in that sense.....
370 2017-10-12 19:49:17	0|sipa|fair
371 2017-10-12 19:51:09	0|wumpus|any other topics?
372 2017-10-12 19:51:45	0|BlueMatt|#action activate segwit
373 2017-10-12 19:51:54	0|wumpus|luke-jr: well at least your entire SSD won't be full with one git checkout, as with the linux kernel :-)
374 2017-10-12 19:52:12	0|wumpus|activate segwit in 1970
375 2017-10-12 19:52:14	0|luke-jr|wumpus: git-show of a tag is taking me a full minute here :/
376 2017-10-12 19:52:28	0|BlueMatt|luke-jr: is that on a 10-year-old sd card?!
377 2017-10-12 19:52:32	0|gmaxwell|1
378 2017-10-12 19:52:32	0|gmaxwell|$ git grep -i delorean | wc -l
379 2017-10-12 19:52:37	0|sipa|BlueMatt: it's on core memory
380 2017-10-12 19:52:38	0|wumpus|luke-jr: git show? that just retrieves an object, that's slow even for a mechanical hd
381 2017-10-12 19:52:39	0|cfields|BlueMatt: pretty sure we did that in a previous meeting. Though we could do it again and make it 2x activations...
382 2017-10-12 19:52:40	0|luke-jr|BlueMatt: fairly newish 5400 RPM magnetic drive
383 2017-10-12 19:52:53	0|luke-jr|wumpus: it does many many MB of reading for some reason
384 2017-10-12 19:53:01	0|wumpus|git log can be kind of slow here, especially when showing branches (as I have about 800 local branches), but show is super quick
385 2017-10-12 19:53:03	0|BlueMatt|5400 RPM? eww
386 2017-10-12 19:53:08	0|jonasschnelli|:-)
387 2017-10-12 19:53:20	0|luke-jr|wumpus: I suspect part of the cause is that I never prune my git repo
388 2017-10-12 19:53:42	0|wumpus|luke-jr: can you prune a git repo?
389 2017-10-12 19:53:47	0|wumpus|(or do you mean gc?)
390 2017-10-12 19:53:48	0|sipa|git gc
391 2017-10-12 19:54:00	0|wumpus|I interpreted that literally, like converting it to a shallow repo
392 2017-10-12 19:54:10	0|sipa|git prune also exists, just removes unreachable objects
393 2017-10-12 19:54:20	0|sipa|gc does that + compacting storage
394 2017-10-12 19:54:26	0|luke-jr|wumpus: gc
395 2017-10-12 19:54:35	0|sipa|shallow repo is something else
396 2017-10-12 19:54:38	0|wumpus|git gc --aggresive  --force --prune=all
397 2017-10-12 19:54:42	0|luke-jr|my gc is configured to only compress :P
398 2017-10-12 19:54:46	0|sipa|why?
399 2017-10-12 19:55:02	0|luke-jr|so I can git-show any object hash from any point in time, even if it's long-dead
400 2017-10-12 19:55:22	0|CryptAxe|luke-jr I do 2 ssds in raid 0 + rsync backup to disk and it works great
401 2017-10-12 19:55:23	0|luke-jr|.git is only 1.1 GB, surprisingly
402 2017-10-12 19:55:28	0|sipa|perhaps you can split up your repo in an archive version + working version
403 2017-10-12 19:55:47	0|luke-jr|sipa: well, I'm hoping simply moving it to SSD will be good enough XD
404 2017-10-12 19:55:52	0|BlueMatt|#topic optimal git workflows for Core memory users
405 2017-10-12 19:55:52	0|sipa|seems this meeting is out of topics?
406 2017-10-12 19:56:03	0|sipa|#link https://en.wikipedia.org/wiki/Magnetic-core_memory
407 2017-10-12 19:56:48	0|luke-jr|wumpus: you suggested waiting to squash fixups into multiwallet until it's about to be merged; but jnewbery is asking for a rebase.. :x
408 2017-10-12 19:57:09	0|wumpus|when I started using worktrees I've moved everything to work from a single .git tree (with seaprate checkouts for some branches), but a seperate archive and working copy sounds pretty good
409 2017-10-12 19:57:11	0|sipa|if you need a rebase anyway, i generally don't care about squashing fixups
410 2017-10-12 19:57:28	0|wumpus|mercury delay line memory ftw
411 2017-10-12 19:57:48	0|wumpus|luke-jr: yes in that case feel free to squash
412 2017-10-12 19:58:11	0|luke-jr|k, *done*
413 2017-10-12 19:58:40	0|wumpus|#endmeeting
414 2017-10-12 19:58:41	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-10-12-19.02.log.html
415 2017-10-12 19:58:41	0|lightningbot|Meeting ended Thu Oct 12 19:58:39 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
416 2017-10-12 19:58:41	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-10-12-19.02.html
417 2017-10-12 19:58:41	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-10-12-19.02.txt
418 2017-10-12 20:01:43	0|wumpus|btw the meetings hasn't been updated since june https://bitcoincore.org/en/meetings/, anyone know what happened to G1lius?
419 2017-10-12 20:03:11	0|gmaxwell|I've seen him posting on reddit, I assume he's just been busy.
420 2017-10-12 20:03:14	0|wumpus|he's had no github activity at all since :/
421 2017-10-12 20:03:15	0|wumpus|okay
422 2017-10-12 20:04:06	0|karelb|wumpus: yeah I wanted to ask this too, I wanted to read some recent summaries
423 2017-10-12 20:04:29	0|wumpus|good to know he's alive and kicking on reddit at least :)
424 2017-10-12 20:04:47	0|wumpus|if he's too busy we can try to find another volunteer
425 2017-10-12 20:05:17	0|achow101|I can see if someone at my school's cryptocurrency club is interested in doing that
426 2017-10-12 20:05:30	0|wumpus|achow101: cool, thanks
427 2017-10-12 20:05:40	0|achow101|or we could ask harding :)
428 2017-10-12 20:05:53	0|wumpus|it doesn't have to be as extensive as he did, but the basic info such as a link to the irc log and big bullet points would be nice
429 2017-10-12 20:06:14	0|wumpus|what G1lius did was really great though
430 2017-10-12 20:06:41	0|wumpus|harding is probably too busy too
431 2017-10-12 21:06:24	0|bitcoin-git|[13bitcoin] 15sdaftuar opened pull request #11490: Disconnect from outbound peers with bad headers chains (06master...062017-10-outbound-peers-good-chain) 02https://github.com/bitcoin/bitcoin/pull/11490
432 2017-10-12 21:09:54	0|sdaftuar|wumpus: ^ this is the PR i had in mind as a consideration for 0.15.0.2
433 2017-10-12 21:13:05	0|wumpus|ok, will tag
434 2017-10-12 21:24:40	0|bitcoin-git|[13bitcoin] 15mess110 opened pull request #11491: [gui] Add proxy icon in statusbar (06master...06add_proxy_icon) 02https://github.com/bitcoin/bitcoin/pull/11491
435 2017-10-12 21:56:19	0|bitcoin-git|[13bitcoin] 15laanwj pushed 6 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f74459dba6de...470c730e3fa9
436 2017-10-12 21:56:20	0|bitcoin-git|13bitcoin/06master 1455224af 15practicalswift: Remove redundant NULL checks after new
437 2017-10-12 21:56:20	0|bitcoin-git|13bitcoin/06master 147466991 15practicalswift: Remove redundant check (!ecc is always true)
438 2017-10-12 21:56:21	0|bitcoin-git|13bitcoin/06master 14b5fb339 15practicalswift: Remove duplicate uriParts.size() > 0 check
439 2017-10-12 21:56:44	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10898: Fix invalid checks (NULL checks after dereference, redundant checks, etc.) (06master...06invalid-logic) 02https://github.com/bitcoin/bitcoin/pull/10898
440 2017-10-12 22:20:54	0|promag|jnewbery: https://github.com/bitcoin/bitcoin/pull/11472#issuecomment-336280787 same PR or new?
441 2017-10-12 22:22:24	0|harding|achow101, wumpus: I'll poke G1lius and see what's up with the meeting notes.
442 2017-10-12 22:22:45	0|bitcoin-git|[13bitcoin] 15promag opened pull request #11492: Fix leak in CDB constructor (06master...062017-10-cdb-constructor-leak) 02https://github.com/bitcoin/bitcoin/pull/11492
443 2017-10-12 22:35:18	0|bitcoin-git|13bitcoin/06master 148c2f4b8 15Jeremy Rubin: Expose more parallelism with relaxed atomics (suggested in #9938). Fix a test to check the exclusive or of two properties rather than just or.
444 2017-10-12 22:35:18	0|bitcoin-git|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/470c730e3fa9...424be0330514
445 2017-10-12 22:35:19	0|bitcoin-git|13bitcoin/06master 14424be03 15Pieter Wuille: Merge #10099: Slightly Improve Unit Tests for Checkqueue...
446 2017-10-12 22:35:28	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #10099: Slightly Improve Unit Tests for Checkqueue (06master...06speedup-checkqueue-tests) 02https://github.com/bitcoin/bitcoin/pull/10099
447 2017-10-12 22:36:10	0|promag|Is ryanofsky around?
448 2017-10-12 22:36:24	0|ryanofsky|hi
449 2017-10-12 22:36:42	0|promag|see my comment in 11492
450 2017-10-12 22:36:52	0|promag|do you think I should squash?
451 2017-10-12 22:36:59	0|promag|ty
452 2017-10-12 22:39:33	0|ryanofsky|slight preference for keeping two commits, and updating message on second commit so it is more clearly a bugfix not just a refactoring
453 2017-10-12 22:39:57	0|promag|ok, thanks