1 2016-09-15T00:10:11  *** Alopex has quit IRC
  2 2016-09-15T00:11:16  *** Alopex has joined #bitcoin-core-dev
  3 2016-09-15T00:18:05  *** PatBoy has quit IRC
  4 2016-09-15T00:20:25  *** PatBoy has joined #bitcoin-core-dev
  5 2016-09-15T00:28:03  *** achow101_ has joined #bitcoin-core-dev
  6 2016-09-15T00:28:31  *** achow101_ has quit IRC
  7 2016-09-15T00:48:32  *** sdaftuar has joined #bitcoin-core-dev
  8 2016-09-15T00:57:24  *** btcdrak has quit IRC
  9 2016-09-15T00:58:04  <achow101> I'm experimenting with the review thing. Can someone go to https://github.com/achow101/ProtectedBranchTest/pull/3 and submit an "Approve" review?
 10 2016-09-15T00:59:35  <sdaftuar> achow101: done
 11 2016-09-15T01:00:08  <achow101> thanks. something's not working...
 12 2016-09-15T01:00:12  <sdaftuar> yeah i saw :)
 13 2016-09-15T01:01:02  <sdaftuar> does it need to be approved by someone with write privs maybe?
 14 2016-09-15T01:01:44  <achow101> I don't know. I can't approve it since I wrote it. I'll try with the other account.
 15 2016-09-15T01:03:22  <achow101> oh yeah. That was totally it.
 16 2016-09-15T01:06:54  *** Ylbam has quit IRC
 17 2016-09-15T01:08:26  <achow101> Interesting that the status checks are still pending.
 18 2016-09-15T01:11:11  *** Magma has joined #bitcoin-core-dev
 19 2016-09-15T01:15:03  *** nibor has quit IRC
 20 2016-09-15T01:19:11  *** Chris_Stewart_5 has quit IRC
 21 2016-09-15T01:40:04  <rebroad> is the -dropmessagestest code still needed in main.cpp? It's not even mentioned as a command line option in init.cpp
 22 2016-09-15T01:41:03  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 23 2016-09-15T01:41:49  <rebroad> oh... sorry, it is
 24 2016-09-15T01:46:23  *** [Author] has quit IRC
 25 2016-09-15T01:58:20  <rebroad> ok, so I am wondering... develoeprs seem to complain when I either raise too many pull requests or raise a pull request with too many changes.. so it seems the complain is about the amount of development I am doing, so my thnking is that this is implying I should be working on other thnigs, code review perhaps? In what areas is it that the complaint might be indication that I am not contributing enough?
 26 2016-09-15T02:00:32  <achow101> I've mostly figured out how the review thing works, and it could benefit us.
 27 2016-09-15T02:00:54  <achow101> So comments through the review thing are just general comments on the whole thing, kind of useless. You can still do line notes though and that is good
 28 2016-09-15T02:01:41  <achow101> approving cannot be done commit by commit but rather by the full diff at the time of review.
 29 2016-09-15T02:04:10  <achow101> requesting changes seems like it will revoke a previous approval
 30 2016-09-15T02:04:58  <dcousens> achow101: you can't edit comments interestingly when posting an 'approval'
 31 2016-09-15T02:05:19  <achow101> And lastly branches can be setup with protections to require an approve from a committer, pass status checks (travis), and prevent administrators from merging regardless
 32 2016-09-15T02:05:56  <achow101> also the submitter can't approve or request changes in his own PR (duh)
 33 2016-09-15T02:06:22  <GitHub54> [bitcoin] rebroad opened pull request #8734: Send NOTFOUND when we don't have the block data. (master...NotfoundIfPruned) https://github.com/bitcoin/bitcoin/pull/8734
 34 2016-09-15T02:07:33  <achow101> dcousens: right. so any comments done with the review thing can't be edited
 35 2016-09-15T02:07:40  <rebroad> achow101, all sounds good!
 36 2016-09-15T02:08:17  *** luke-jr has quit IRC
 37 2016-09-15T02:08:30  *** dermoth has quit IRC
 38 2016-09-15T02:09:06  <achow101> I think the best thing about this is that it can be set so that a PR submitted by a committer must have another committer review it before it can be merged
 39 2016-09-15T02:09:20  <achow101> just in case someone gets hacked
 40 2016-09-15T02:11:26  <dcousens> achow101: eh,  they already have multiple processes in place... trusting github further isn't really necessary
 41 2016-09-15T02:12:35  <dcousens> achow101: RE privileges to approve, you don't need any see https://github.com/bitcoin/bitcoin/pull/8723#pullrequestreview-82853
 42 2016-09-15T02:13:31  <dcousens> I honestly don't see this being any better than the current ACK' system
 43 2016-09-15T02:15:18  <achow101> anyone can approve, but only certain people's approvals (the committers) will allow a PR to be merged when the branch is protected
 44 2016-09-15T02:16:25  <achow101> If you look at the one I linked earlier, you can see the message there about an "approved review" which apparantly must come from someone with write access
 45 2016-09-15T02:38:06  *** Alopex has quit IRC
 46 2016-09-15T02:39:11  *** Alopex has joined #bitcoin-core-dev
 47 2016-09-15T02:48:56  *** luke-jr has joined #bitcoin-core-dev
 48 2016-09-15T03:05:29  *** Chris_Stewart_5 has quit IRC
 49 2016-09-15T03:14:11  *** Alopex has quit IRC
 50 2016-09-15T03:15:17  *** Alopex has joined #bitcoin-core-dev
 51 2016-09-15T03:25:02  *** Alopex has quit IRC
 52 2016-09-15T03:26:07  *** Alopex has joined #bitcoin-core-dev
 53 2016-09-15T03:46:31  *** Giszmo has quit IRC
 54 2016-09-15T03:51:01  *** Alopex has quit IRC
 55 2016-09-15T03:51:29  *** dgenr8 has quit IRC
 56 2016-09-15T03:51:43  *** Soligor has quit IRC
 57 2016-09-15T03:52:06  *** Alopex has joined #bitcoin-core-dev
 58 2016-09-15T03:55:43  *** dgenr8 has joined #bitcoin-core-dev
 59 2016-09-15T04:02:02  *** Alopex has quit IRC
 60 2016-09-15T04:03:07  *** Alopex has joined #bitcoin-core-dev
 61 2016-09-15T04:15:17  *** Alopex has quit IRC
 62 2016-09-15T04:16:22  *** Alopex has joined #bitcoin-core-dev
 63 2016-09-15T04:37:05  *** timothy has quit IRC
 64 2016-09-15T04:37:08  *** drizztbsd has joined #bitcoin-core-dev
 65 2016-09-15T04:37:41  *** drizztbsd is now known as timothy
 66 2016-09-15T05:02:03  *** rebroad has quit IRC
 67 2016-09-15T05:18:32  *** Ylbam has joined #bitcoin-core-dev
 68 2016-09-15T05:28:31  *** [Author] has joined #bitcoin-core-dev
 69 2016-09-15T05:42:55  *** timothy has quit IRC
 70 2016-09-15T05:42:58  *** drizztbsd has joined #bitcoin-core-dev
 71 2016-09-15T05:43:31  *** drizztbsd is now known as timothy
 72 2016-09-15T05:50:11  *** Alopex has quit IRC
 73 2016-09-15T05:51:16  *** Alopex has joined #bitcoin-core-dev
 74 2016-09-15T06:00:21  *** drizztbsd has joined #bitcoin-core-dev
 75 2016-09-15T06:00:22  *** timothy has quit IRC
 76 2016-09-15T06:00:51  *** drizztbsd is now known as timothy
 77 2016-09-15T06:22:11  *** Alopex has quit IRC
 78 2016-09-15T06:22:57  <jonasschnelli> I guess thats also a new Githup thing: you can later change the base branch of a pull request
 79 2016-09-15T06:23:16  *** Alopex has joined #bitcoin-core-dev
 80 2016-09-15T06:31:56  *** rebroad has joined #bitcoin-core-dev
 81 2016-09-15T06:33:15  *** mol has quit IRC
 82 2016-09-15T06:41:14  *** rebroad_ has joined #bitcoin-core-dev
 83 2016-09-15T06:44:19  *** rebroad has quit IRC
 84 2016-09-15T06:48:17  <cfields_> wumpus: wip mingw toolchain: https://github.com/theuni/bitcoin/commit/6cc40455c96f8820a35f745fb03466bcdc8d9919
 85 2016-09-15T06:49:54  <cfields_> wumpus: lots of work remains. But, mingw depends build fully, and bitcoin build breaks with the same threading problems that have been reported, so it's enough to help with testing/debugging.
 86 2016-09-15T06:50:55  <cfields_> will continue with it tomorrow.
 87 2016-09-15T06:51:03  <jonasschnelli> nice cfields_ !
 88 2016-09-15T06:51:49  <cfields_> jonasschnelli: heh, not really. It's at the "it's a bloodbath, but it builds" stage of development :)
 89 2016-09-15T06:54:35  *** lahwran has joined #bitcoin-core-dev
 90 2016-09-15T07:08:41  *** jl2012 has quit IRC
 91 2016-09-15T07:10:19  *** jl2012 has joined #bitcoin-core-dev
 92 2016-09-15T07:15:12  *** btcdrak has joined #bitcoin-core-dev
 93 2016-09-15T07:16:49  *** btcdrak has quit IRC
 94 2016-09-15T07:17:12  *** btcdrak has joined #bitcoin-core-dev
 95 2016-09-15T07:20:56  *** Guyver2 has joined #bitcoin-core-dev
 96 2016-09-15T07:47:40  *** cdecker has joined #bitcoin-core-dev
 97 2016-09-15T08:04:16  *** Soligor has joined #bitcoin-core-dev
 98 2016-09-15T08:10:03  *** cdecker has quit IRC
 99 2016-09-15T08:18:32  *** MarcoFalke has joined #bitcoin-core-dev
100 2016-09-15T08:20:13  *** Lauda has quit IRC
101 2016-09-15T08:33:54  *** Lauda has joined #bitcoin-core-dev
102 2016-09-15T08:48:46  *** mol has joined #bitcoin-core-dev
103 2016-09-15T08:55:21  *** Guyver2 has quit IRC
104 2016-09-15T09:11:09  *** timothy has quit IRC
105 2016-09-15T09:11:13  *** drizztbsd has joined #bitcoin-core-dev
106 2016-09-15T09:11:24  <GitHub156> [bitcoin] jonasschnelli opened pull request #8735: [Wallet] add option for a custom extended master privat key (xpriv) (master...2016/09/hd_set_seed) https://github.com/bitcoin/bitcoin/pull/8735
107 2016-09-15T09:11:46  *** drizztbsd is now known as timothy
108 2016-09-15T09:41:54  *** jannes has joined #bitcoin-core-dev
109 2016-09-15T09:44:55  *** rebroad_ has quit IRC
110 2016-09-15T09:49:51  <dcousens> wumpus: oh, I wanted to mention.  And all other things aside.  A small RPC cache works wonders for reducing some of the performance issues with high loads (10-20 mb)
111 2016-09-15T10:08:09  *** laurentmt has joined #bitcoin-core-dev
112 2016-09-15T10:10:19  <GitHub24> [bitcoin] wjx opened pull request #8736: base58: Improve DecodeBase58 performance. (master...speedup-decodebase58) https://github.com/bitcoin/bitcoin/pull/8736
113 2016-09-15T10:13:25  *** laurentmt has quit IRC
114 2016-09-15T10:14:24  *** timothy has quit IRC
115 2016-09-15T10:14:26  *** drizztbsd has joined #bitcoin-core-dev
116 2016-09-15T10:14:59  *** drizztbsd is now known as timothy
117 2016-09-15T10:42:50  <GitHub86> [bitcoin] paveljanik opened pull request #8737: Trivial: UndoReadFromDisk works on undo files (rev), not on block files. (master...20160915_Undo_error_message_fix) https://github.com/bitcoin/bitcoin/pull/8737
118 2016-09-15T10:52:55  *** rebroad_ has joined #bitcoin-core-dev
119 2016-09-15T10:57:27  *** laurentmt has joined #bitcoin-core-dev
120 2016-09-15T10:58:12  *** laurentmt has quit IRC
121 2016-09-15T11:30:11  *** paveljanik has quit IRC
122 2016-09-15T11:51:14  *** cryptapus has joined #bitcoin-core-dev
123 2016-09-15T11:51:14  *** cryptapus has joined #bitcoin-core-dev
124 2016-09-15T12:11:54  *** Giszmo has joined #bitcoin-core-dev
125 2016-09-15T12:12:20  *** paveljanik has joined #bitcoin-core-dev
126 2016-09-15T12:12:21  *** paveljanik has joined #bitcoin-core-dev
127 2016-09-15T12:21:39  *** laurentmt has joined #bitcoin-core-dev
128 2016-09-15T12:21:42  *** laurentmt has quit IRC
129 2016-09-15T12:25:13  *** timothy has quit IRC
130 2016-09-15T12:26:25  *** timothy has joined #bitcoin-core-dev
131 2016-09-15T12:35:53  *** Chris_Stewart_5 has joined #bitcoin-core-dev
132 2016-09-15T12:47:51  *** dcousens has quit IRC
133 2016-09-15T12:49:33  *** dcousens has joined #bitcoin-core-dev
134 2016-09-15T12:51:05  *** Chris_Stewart_5 has quit IRC
135 2016-09-15T12:54:49  *** Chris_Stewart_5 has joined #bitcoin-core-dev
136 2016-09-15T12:54:55  *** kadoban has joined #bitcoin-core-dev
137 2016-09-15T12:56:45  *** kadoban has quit IRC
138 2016-09-15T12:57:11  *** kadoban has joined #bitcoin-core-dev
139 2016-09-15T13:38:15  *** cryptapus has quit IRC
140 2016-09-15T13:39:32  *** MarcoFalke has left #bitcoin-core-dev
141 2016-09-15T13:41:28  *** paveljanik has quit IRC
142 2016-09-15T13:43:32  *** dcousens has quit IRC
143 2016-09-15T13:47:08  *** laurentmt has joined #bitcoin-core-dev
144 2016-09-15T13:47:47  *** laurentmt has quit IRC
145 2016-09-15T13:49:16  *** paveljanik has joined #bitcoin-core-dev
146 2016-09-15T13:51:15  *** cryptapus has joined #bitcoin-core-dev
147 2016-09-15T13:51:15  *** cryptapus has joined #bitcoin-core-dev
148 2016-09-15T14:09:04  *** ganger has joined #bitcoin-core-dev
149 2016-09-15T14:22:22  *** laurentmt has joined #bitcoin-core-dev
150 2016-09-15T14:27:31  *** wjx has quit IRC
151 2016-09-15T14:27:51  *** laurentmt has quit IRC
152 2016-09-15T14:44:37  <GitHub111> [bitcoin] rebroad closed pull request #8729: More granular debug (master...MoreGranularDebug6) https://github.com/bitcoin/bitcoin/pull/8729
153 2016-09-15T14:46:49  *** ganger has quit IRC
154 2016-09-15T15:02:03  *** Chris_Stewart_5 has quit IRC
155 2016-09-15T15:05:01  *** cryptapus has quit IRC
156 2016-09-15T15:10:36  *** cryptapus has joined #bitcoin-core-dev
157 2016-09-15T15:10:36  *** cryptapus has joined #bitcoin-core-dev
158 2016-09-15T15:14:14  *** e4xit_ has joined #bitcoin-core-dev
159 2016-09-15T15:16:58  *** e4xit has quit IRC
160 2016-09-15T15:16:58  *** e4xit_ is now known as e4xit
161 2016-09-15T15:17:33  *** Chris_Stewart_5 has joined #bitcoin-core-dev
162 2016-09-15T15:36:42  *** laurentmt has joined #bitcoin-core-dev
163 2016-09-15T15:41:18  *** laurentmt has quit IRC
164 2016-09-15T16:02:47  <phantomcircuit> jonasschnelli: poke 8696 updated to address nits
165 2016-09-15T16:06:17  *** laurentmt has joined #bitcoin-core-dev
166 2016-09-15T16:08:52  *** laurentmt has quit IRC
167 2016-09-15T16:32:31  *** cryptapus has quit IRC
168 2016-09-15T16:32:31  *** cryptapus_ has joined #bitcoin-core-dev
169 2016-09-15T16:40:15  <GitHub112> [bitcoin] sdaftuar opened pull request #8739: [qa] Fix broken sendcmpct test in p2p-compactblocks.py (master...fix-cb-test) https://github.com/bitcoin/bitcoin/pull/8739
170 2016-09-15T16:40:51  *** laurentmt has joined #bitcoin-core-dev
171 2016-09-15T16:40:52  *** laurentmt has quit IRC
172 2016-09-15T16:49:26  *** cryptapus_ is now known as cryptapus
173 2016-09-15T17:04:23  *** jannes has quit IRC
174 2016-09-15T17:10:41  *** cryptapus has quit IRC
175 2016-09-15T17:26:50  *** echonaut1 has quit IRC
176 2016-09-15T17:27:04  *** echonaut has joined #bitcoin-core-dev
177 2016-09-15T17:37:30  *** Giszmo has quit IRC
178 2016-09-15T17:56:08  *** Giszmo has joined #bitcoin-core-dev
179 2016-09-15T18:29:41  *** cryptapus has joined #bitcoin-core-dev
180 2016-09-15T18:29:41  *** cryptapus has joined #bitcoin-core-dev
181 2016-09-15T18:42:08  *** achow101 has left #bitcoin-core-dev
182 2016-09-15T18:42:23  *** achow101 has joined #bitcoin-core-dev
183 2016-09-15T18:48:43  *** MarcoFalke has joined #bitcoin-core-dev
184 2016-09-15T18:52:29  <paveljanik> wumpus, jonasschnelli: here is a rough QT -Wshadow commit (https://github.com/paveljanik/bitcoin/commit/f9d00d7e624a6760a099ca61caca25d7982844d1). I'd like to hear what you like or dislike about such changes or what to do in some other way.
185 2016-09-15T18:54:00  <paveljanik> E.g. using member initializers instead in some places etc.
186 2016-09-15T18:54:06  <jonasschnelli> phantomcircuit: newline nits: https://github.com/bitcoin/bitcoin/pull/8696/files#diff-b2bb174788c7409b671c46ccc86034bdR2518
187 2016-09-15T18:54:37  <jonasschnelli> phantomcircuit: I prefere modeIn instead of _mode
188 2016-09-15T18:54:42  <jonasschnelli> But consider it as nit
189 2016-09-15T18:54:57  <paveljanik> for ~qt we already agreed on _...
190 2016-09-15T18:55:12  <jonasschnelli> Okay. Fair enought.
191 2016-09-15T18:55:14  <jonasschnelli> _ look always after instance vars IMO
192 2016-09-15T18:55:29  <jonasschnelli> But maybe because of my Obj-C past
193 2016-09-15T18:56:04  <jonasschnelli> phantomcircuit: But the change-set looks good!
194 2016-09-15T18:56:12  <jonasschnelli> ah. meant paveljanik
195 2016-09-15T18:56:31  <paveljanik> it is a bit huge :-(
196 2016-09-15T18:57:01  <paveljanik> and there are still two other issues, but they are more serialization related than qt/
197 2016-09-15T18:57:48  <paveljanik> and I do not like how I solved this-> stuff because it can be a lot nicer.
198 2016-09-15T18:58:04  <jonasschnelli> Maybe split it into parts? But I don't care. I'm happy to merge it at once. Its fairly reviewable.
199 2016-09-15T18:59:16  <paveljanik> this itself is a part ;-)
200 2016-09-15T18:59:52  <cfields_> jonasschnelli: completely agree, but i didn't want to create noise :)
201 2016-09-15T18:59:53  <jonasschnelli> Ah. Okay then. :)
202 2016-09-15T19:00:00  <sipa> DING
203 2016-09-15T19:00:04  *** cdecker has joined #bitcoin-core-dev
204 2016-09-15T19:00:08  <jonasschnelli> meeting?
205 2016-09-15T19:00:08  <petertodd> pong
206 2016-09-15T19:00:09  <cfields_> (about _foo being member)
207 2016-09-15T19:00:11  <gmaxwell> #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
208 2016-09-15T19:00:13  <kanzure> greetz.
209 2016-09-15T19:00:13  <paveljanik> peng
210 2016-09-15T19:00:24  <sdaftuar> hi
211 2016-09-15T19:00:39  <jonasschnelli> cfields_, paveljanik: do we already make use of _var instead of varIn?
212 2016-09-15T19:00:56  <cfields_> jonasschnelli: yea, in the PRs that are already in
213 2016-09-15T19:01:08  *** cryptapus has quit IRC
214 2016-09-15T19:01:18  *** andytoshi has joined #bitcoin-core-dev
215 2016-09-15T19:01:19  <jonasschnelli> #startmeeting
216 2016-09-15T19:01:19  <lightningbot> Meeting started Thu Sep 15 19:01:19 2016 UTC.  The chair is jonasschnelli. Information about MeetBot at http://wiki.debian.org/MeetBot.
217 2016-09-15T19:01:19  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
218 2016-09-15T19:01:28  <jonasschnelli> topic proposals?
219 2016-09-15T19:01:46  <MarcoFalke> proposed short topic: EOL 0.11
220 2016-09-15T19:02:11  <jonasschnelli> #topic EOL 0.11
221 2016-09-15T19:02:18  <cfields_> I'll only be around for ~30 min before I have to head out.
222 2016-09-15T19:02:29  <MarcoFalke> #link https://github.com/bitcoin-core/bitcoincore.org/pull/211
223 2016-09-15T19:02:37  <wumpus> if we're following the same schedule as usual, 0.11 was EOL at the moment 0.13 was released
224 2016-09-15T19:02:47  <sipa> except critical fixes?
225 2016-09-15T19:02:50  <jonasschnelli> agree with wumpus
226 2016-09-15T19:03:02  <MarcoFalke> it is about critical fixes
227 2016-09-15T19:03:03  <wumpus> security problems may be an exception
228 2016-09-15T19:03:22  <MarcoFalke> We should set a date when we no longer fix critial issues
229 2016-09-15T19:03:29  <gmaxwell> I thought 0.11 was EOL when 0.13 was released, except for whatever exceptions we decide...
230 2016-09-15T19:03:33  <jeremyrubin> nheren
231 2016-09-15T19:03:33  <wumpus> but usually no new executables will be built, just simple backports
232 2016-09-15T19:03:35  <sipa> gmaxwell: agree
233 2016-09-15T19:03:53  <petertodd> ack EOL; you can always run 0.11 behind a 0.13 node if you need too
234 2016-09-15T19:03:59  <sipa> so we need to get https://bitcoincore.org/en/lifecycle/ updated?
235 2016-09-15T19:04:07  <kanzure> i think the concern was that 0.11 was not marked as EOL, not that it wasn't considered EOL.
236 2016-09-15T19:04:09  <MarcoFalke> Jup, note that I already changed maintenance end to 2016-08-23
237 2016-09-15T19:04:18  <wumpus> yes the bitcoin.org page needs to be updated
238 2016-09-15T19:04:31  <wumpus> +Core
239 2016-09-15T19:04:38  <achow101> If 0.11 is EOL, then what about 0.10?
240 2016-09-15T19:04:48  <sipa> ah, so 0.11 is not EOL but maintenance end
241 2016-09-15T19:04:59  <sipa> EOL means not even security critical backports
242 2016-09-15T19:05:04  <sipa> according to that website
243 2016-09-15T19:05:07  <gmaxwell> achow101: it was unmaintained as of january or so.
244 2016-09-15T19:05:28  <achow101> gmaxwell: but it is still marked as receiving critical updates on bitcoincore.org
245 2016-09-15T19:05:33  <jonasschnelli> According to bitcoincore.org 0.10 has EOL in 2017
246 2016-09-15T19:05:35  <sipa> but 0.10 should be EOL at 2016-08-23
247 2016-09-15T19:05:40  <morcos> it seems to me that ending security critical backports depends not just on how old the release is but on how many people are still using it
248 2016-09-15T19:05:50  <gmaxwell> what morcos says.
249 2016-09-15T19:05:54  <wumpus> and how difficult it is to backport/test
250 2016-09-15T19:06:00  <morcos> ha ha, of course!
251 2016-09-15T19:06:08  <wumpus> I mean if it's just updating a dependency library like upnp...
252 2016-09-15T19:06:17  <gmaxwell> the reality is that it has nothing to do with dates. We're not actively seeking to maintain these versions but will do what it takes to protect the ecosystem.
253 2016-09-15T19:06:19  <sipa> sure, but the reason for having a clearly stated policy is so that people can make informed decisions about what to run
254 2016-09-15T19:06:26  <MarcoFalke> ^
255 2016-09-15T19:06:47  <wumpus> I think this will always be a discussion people can't really agree on
256 2016-09-15T19:06:48  <MarcoFalke> We should communicate the EOL in advance
257 2016-09-15T19:06:51  <luke-jr> frankly 0.12 seems like EOL before 0.14 at this rate
258 2016-09-15T19:06:56  <petertodd> gmaxwell: setting expectations also can help protect the ecosystem
259 2016-09-15T19:07:07  <gmaxwell> We also continue to see no feedback from parties that would prefer to use a 0.old.next over a 0.new.hottness. :)
260 2016-09-15T19:07:08  *** cryptapus has joined #bitcoin-core-dev
261 2016-09-15T19:07:16  * jonasschnelli still count 569 0.10.x peers with status "good" on his seeder
262 2016-09-15T19:07:19  <morcos> agreed with all, but i'm saying we should be supplementing our discussion with #'s of nodes running 0.10, 0.11
263 2016-09-15T19:07:23  <sipa> i wish we had more insight in users' needs... that there would be requests of the form "wait! no! i can't upgrade to 0.12 yet for reason X, but we really need updated for now"
264 2016-09-15T19:07:24  <wumpus> in practice it's indeed not about dates, but if someone cares about using/maintainging it
265 2016-09-15T19:07:27  <BlueMatt> am I the only one who wasnt aware of that page? I mean I dont think a strict N-monghts schedule really works, so we'd need to all be thinking about it/aware of it, at least, to make it reasonable
266 2016-09-15T19:07:28  <wumpus> it seems to be 0 people
267 2016-09-15T19:07:29  <gmaxwell> Which supports the view that effort spent supporting older versions is of negative value.
268 2016-09-15T19:07:45  <luke-jr> wumpus: maintaining it is not practical without testing/usage
269 2016-09-15T19:07:51  <petertodd> morcos: so many nodes are run because users "want to contribute" - I wouldn't read too much into that number. Equally, a lot of nodes are likely spy-nodes...
270 2016-09-15T19:07:57  <wumpus> luke-jr: right it's a chicken egg problem
271 2016-09-15T19:08:00  <sipa> wumpus: that's a fair characterization of reality, but perhaps that page should reflect that
272 2016-09-15T19:08:02  <kanzure> BlueMatt: i think it's something like "people should be following the mailing lists and announcement mailing lists and the webpage, although apparently the webpage is out of sync with reality for the moment"
273 2016-09-15T19:08:41  *** cdecker has quit IRC
274 2016-09-15T19:08:45  <wumpus> yes, updating the webpage to reflect reality would make sense
275 2016-09-15T19:08:46  <BlueMatt> kanzure: hmm? people shouldnt have to follow the ml to find out if their node is EOL...we should have some kind of information for users, but devs have to be aware that it exists for it to be accurate :p
276 2016-09-15T19:08:50  <gmaxwell> If we were being completely pragmatic we would probably say that we only support the very latest thing put out at all.-- this is all that I can tell people are upgrading to. But I think that is a bad principle and the fact that the only thing people upgrade to is the latest thing is an aspect of industry immaturity which will hopefully go away.
277 2016-09-15T19:08:56  <luke-jr> wumpus: I maintained old versions back to 0.4 for years with no indication of real usage or feedback - the first few got some testing, but after a while it never made it past RC
278 2016-09-15T19:09:43  <petertodd> fwiw I've never gotten any feedback from python-bitcoinlib users complaining about non-backwards-compatible changes
279 2016-09-15T19:09:43  <luke-jr> IMO we *should* have longer support, but it just doesn't seem feasible with softforks
280 2016-09-15T19:09:47  <wumpus> the point of creating that webpage was to have an easier available place where release maintenance status was available, but yes if it runs out of date with reality then at some point it's only confusing
281 2016-09-15T19:09:50  * BlueMatt wishes there was an "ask the community" button for this kind of thing....
282 2016-09-15T19:10:06  <petertodd> BlueMatt: too bad we got rid of the alert system... /ducks
283 2016-09-15T19:10:19  <kanzure> wumpus: probably a good fix would be to have a checklist for releases, and add EOL webpage updates to that checklist.
284 2016-09-15T19:10:21  <wumpus> and it should reflect how things are, not how we think ideally they should be
285 2016-09-15T19:10:28  <sipa> we could make node software automatically show a warning X months after being released...
286 2016-09-15T19:10:37  <luke-jr> kanzure: we do have release-process.md
287 2016-09-15T19:10:43  <kanzure> well is it in there?
288 2016-09-15T19:10:50  <luke-jr> sipa: +1
289 2016-09-15T19:10:54  <wumpus> kanzure: there's one in the release process, but there is already so much stuff there. I don't thin kthe assumption should be that the same person does all that
290 2016-09-15T19:10:56  *** cdecker has joined #bitcoin-core-dev
291 2016-09-15T19:11:06  <kanzure> "EOL" not found in that doc, nor variations of it.
292 2016-09-15T19:11:07  <petertodd> sipa: signal does that actually - they forgot the timer expired once and scared a bunch of people
293 2016-09-15T19:11:26  <kanzure> wumpus: sure, sure, perhaps it's multiple people. but a checklist can still be helpful regardless of number of people that use it.
294 2016-09-15T19:11:29  <BlueMatt> petertodd: is that automated? heh, yea, maybe
295 2016-09-15T19:11:48  <achow101> has anyone actually tried asking the community? like posting on reddit, bitcointalk, etc.
296 2016-09-15T19:12:08  <luke-jr> petertodd: if we stagnate for 12 months, something else is wrong
297 2016-09-15T19:12:19  <wumpus> I think we should first document how things are clearly on the site, and only then worry about maybe changing it
298 2016-09-15T19:12:25  <btcdrak> oh sorry I am late
299 2016-09-15T19:12:31  <jonasschnelli> The problem is probably not what the community want, its more what the team is capable of delivering
300 2016-09-15T19:12:36  <gmaxwell> achow101: we've posted asking for feedback on older versions many times in the past, and also called for testing on old support backups.
301 2016-09-15T19:12:37  <wumpus> exactly jonasschnelli
302 2016-09-15T19:12:58  <jonasschnelli> Its an OSS, if people want longer EOL, they should contribute
303 2016-09-15T19:13:19  <gmaxwell> I've also gone 1:1 to several companies. Mostly we've recieved complete silence. scanning the network (and watching inbounds) also shows that adoption of point releases after a new major is out is basically non-existant.
304 2016-09-15T19:13:20  <wumpus> as I've said before I have nothing against maintaining old releases if someone really commits to that
305 2016-09-15T19:13:24  <sipa> that's fair... we're only so many people, and review for backports is a significant burden
306 2016-09-15T19:13:25  <luke-jr> I'm happy to go back to maintaining stable versions longer if people will actually use it (and can't upgrade)
307 2016-09-15T19:13:31  <gmaxwell> jonasschnelli: or at least speak up.
308 2016-09-15T19:13:31  <wumpus> but I've never seen much interest, so reality is, it doesn't
309 2016-09-15T19:13:38  <kanzure> i don't know what to think about re: automatic warnings after timelapse.   as long a there's some good reason to think it' dissimilar from automatic updates, i suppose..
310 2016-09-15T19:13:54  <jonasschnelli> gmaxwell: right.
311 2016-09-15T19:13:55  <wumpus> kanzure: I don't know what to think about it either
312 2016-09-15T19:13:58  <kanzure> didn't mean to impose on wumpus with the checklist suggestion
313 2016-09-15T19:14:09  <luke-jr> maybe update EOL page, and mention the lack of usage as the reason, suggesting if people want it, they should get in touch
314 2016-09-15T19:14:17  <jonasschnelli> Luke-Jr: +1
315 2016-09-15T19:14:20  <BlueMatt> ok, so lets post something on the ml or so that says "We're gonna stop doing this, but would very much love to hear if anyone actually wants it" and then link to that from reddit/emails/twitter/whatever
316 2016-09-15T19:14:27  <BlueMatt> yea, that
317 2016-09-15T19:14:29  <gmaxwell> stop doing what?
318 2016-09-15T19:14:32  <gmaxwell> I am really confused.
319 2016-09-15T19:14:37  <BlueMatt> stop supporting backports
320 2016-09-15T19:14:42  <BlueMatt> beyond like one or two versions, maybe
321 2016-09-15T19:14:46  <wumpus> kanzure: I really don't like time-locks in programs. Though this would just be a warning I guess... but it could be intimidating
322 2016-09-15T19:14:46  <gmaxwell> We have a stated policy, we maintain one major version behind.
323 2016-09-15T19:14:47  <luke-jr> gmaxwell: stop promising backports we aren't really doing anyway
324 2016-09-15T19:14:55  <gmaxwell> BlueMatt: we already did that, like, a yea ago.
325 2016-09-15T19:14:58  <jonasschnelli> stop doing sound negative... something more like "...we are concentrating ressources on X"
326 2016-09-15T19:15:01  <gmaxwell> year*
327 2016-09-15T19:15:06  <sipa> BlueMatt: "beyond one version" is exactly what the page says
328 2016-09-15T19:15:07  <BlueMatt> s/one or two versions/one or so point releases/
329 2016-09-15T19:15:15  <luke-jr> wumpus: might be good to make the time limit fuzzy, so not everyone gets hit at the same time
330 2016-09-15T19:15:17  <btcdrak> Seems there's a lot of discussion here which was _already)_ covered in previous meetings and is detailed in the Lifecycle document https://bitcoincore.org/en/lifecycle/ tldr maintenance and EOL are two different things.
331 2016-09-15T19:15:22  <luke-jr> perhaps 1 year from when it was installed?
332 2016-09-15T19:15:25  <gmaxwell> what btcdrak says
333 2016-09-15T19:15:28  <BlueMatt> sipa: gmaxwell to be fair, the website doesnt say that
334 2016-09-15T19:15:36  <wumpus> well then add it to the website!
335 2016-09-15T19:15:42  <wumpus> everyone can submit pulls there you know
336 2016-09-15T19:15:45  <btcdrak> I suggest people re-read the Lifecycle page after the meeting :)
337 2016-09-15T19:15:57  <wumpus> we can spend an hour discussing what should be added to the website, or just add it
338 2016-09-15T19:16:03  <jonasschnelli> #action update Lifecycle page on bitcoincore.org
339 2016-09-15T19:16:04  <Chris_Stewart_5> ^
340 2016-09-15T19:16:08  <kanzure> luke-jr: cool idea. fuzzy random noise time-delay notifications.  (hopefully nobody proposes "intentionally low performance over time until someone thinks to get a new version")
341 2016-09-15T19:16:10  <BlueMatt> ok, next topic
342 2016-09-15T19:16:30  <gmaxwell> BlueMatt: read the "Maintance period" section on the site, I think it's completely clear.
343 2016-09-15T19:16:32  <wumpus> any other topics?
344 2016-09-15T19:16:48  <jonasschnelli> #into hackdays in milan: http://coredev.tech/nextmeeting_tmp.html
345 2016-09-15T19:16:56  <wumpus> 0.14 release schedule maybe
346 2016-09-15T19:17:00  <jonasschnelli> Its a temporary page.. not public yet. But feel free to register
347 2016-09-15T19:17:19  <wumpus> I've posted a proposal for the 0.14 release schedule here: https://github.com/bitcoin/bitcoin/issues/8719
348 2016-09-15T19:17:29  <jonasschnelli> #topic 0.14 release schedule
349 2016-09-15T19:17:34  <MarcoFalke> sounds fine
350 2016-09-15T19:17:44  <sipa> yes, sounds good
351 2016-09-15T19:17:49  <jonasschnelli> yes. fine for me
352 2016-09-15T19:18:00  <btcdrak> looks good to me
353 2016-09-15T19:18:06  <BlueMatt> yea, looks good now
354 2016-09-15T19:18:06  <wumpus> I'll mail it around on the mailing lists if there are no issues with it
355 2016-09-15T19:18:08  <CodeShark> +1
356 2016-09-15T19:18:12  <wumpus> ok great!
357 2016-09-15T19:18:15  <kanzure> jonasschnelli: you have a typo in your form ("your are")
358 2016-09-15T19:18:33  <morcos> wumpus: my only thought is 0.13.1 release is a bit of a heavy lift, and depending on when that happens, it may seem like 0.14.0 is coming up quite quickly...  but i don't feel strongly about it
359 2016-09-15T19:18:34  <jonasschnelli> kanzure: ill give you edit right. :)
360 2016-09-15T19:18:56  <wumpus> morcos: it's already a month later compared to 0.12 was this year
361 2016-09-15T19:19:13  <MarcoFalke> No worries. I am sure the will be last-minute blockers for 0.14.0
362 2016-09-15T19:19:14  <wumpus> morcos: postponsing major releases for minor releases makes very little sense I think
363 2016-09-15T19:19:51  <morcos> wumpus: yeah i was only pointing out that 0.13.1 is not minor in a lot of ways..  but if others are fine with it, i don't object
364 2016-09-15T19:19:51  <wumpus> 0.14 will have lots of new features, 0.13.1 will not
365 2016-09-15T19:20:09  <wumpus> morcos: I agree with that
366 2016-09-15T19:20:26  <luke-jr> ? 0.13.1 should only be fixes + softfork
367 2016-09-15T19:20:33  <btcdrak> yes.
368 2016-09-15T19:20:33  <wumpus> luke-jr: it is
369 2016-09-15T19:20:38  <morcos> anyway, seems not its a widely shared concern, so lets stick with the schedule
370 2016-09-15T19:20:45  <gmaxwell> having a short gap between releases would be a good problem to have. :)
371 2016-09-15T19:20:53  <BlueMatt> yup
372 2016-09-15T19:20:55  <jonasschnelli> #topic 0.13.1 release
373 2016-09-15T19:21:00  <wumpus> it's a minor release strictly, just a lot of code changes, so you can jokingly call it 'major'
374 2016-09-15T19:21:14  <btcdrak> Here are the remaining PRs and issues for 0.13.1 https://github.com/bitcoin/bitcoin/milestone/22
375 2016-09-15T19:21:22  <btcdrak> #link https://github.com/bitcoin/bitcoin/milestone/22
376 2016-09-15T19:21:42  <sdaftuar> i wanted to suggest that we consider dropping some of those PRs from the 0.13.1 milestone
377 2016-09-15T19:21:54  <btcdrak> sdaftuar which in particular?
378 2016-09-15T19:21:55  <wumpus> sdaftuar: specific suggestions?
379 2016-09-15T19:22:15  <BlueMatt> nulldummy as softfork?
380 2016-09-15T19:22:16  <sdaftuar> 8654 is one
381 2016-09-15T19:22:20  <kanzure> was there a mempool issue still open for 0.13.1.. don't see it listed there.
382 2016-09-15T19:22:24  <BlueMatt> I figure I'd get yelled at, but I'm not convinced
383 2016-09-15T19:22:25  <CodeShark> Is the mempool dos thing still urgent?
384 2016-09-15T19:22:27  <kanzure> ah there it is.
385 2016-09-15T19:22:27  <sdaftuar> that's a performance optimization that i think is not urgent
386 2016-09-15T19:22:35  <kanzure> (8279)
387 2016-09-15T19:22:39  <btcdrak> I recall sipa saying #8635 may not be essential for 0.13.1
388 2016-09-15T19:22:46  <luke-jr> I reviewed a few merged fixes and commented on a few that they should be backported. Did someone with tagging access get to tag those?
389 2016-09-15T19:23:13  <jonasschnelli> Luke-Jr: I'll have a look
390 2016-09-15T19:23:16  <MarcoFalke> luke-jr: I think I did
391 2016-09-15T19:23:22  <jl2012> i think #8635 may be dropped for 0.13.1
392 2016-09-15T19:23:36  <sipa> agree
393 2016-09-15T19:23:44  <jonasschnelli> jl2012: what do you think about https://github.com/bitcoin/bitcoin/pull/8654?
394 2016-09-15T19:23:46  <btcdrak> ok let's untag it
395 2016-09-15T19:23:56  <sipa> i'd like to see 8654 in
396 2016-09-15T19:23:57  <btcdrak> *untag 8635
397 2016-09-15T19:24:09  <luke-jr> ACK dropping 8635 for 0.13.1
398 2016-09-15T19:24:20  <btcdrak> I guess the big blocker is #8393 compact blocks.
399 2016-09-15T19:24:21  <jonasschnelli> untagged
400 2016-09-15T19:24:45  <wumpus> #decision dropped #8635 for 0.13.1
401 2016-09-15T19:24:51  <luke-jr> jonasschnelli: if that's strictly an optimisation, it should wait for 0.14
402 2016-09-15T19:25:12  <jonasschnelli> sipa: why did you want to see 8654 in 0.13.1?
403 2016-09-15T19:25:15  <wumpus> luke-jr: depends on whether it's an optimisation or an 'optimisation' (e.g. - DoS fix)
404 2016-09-15T19:25:22  <gmaxwell> btcdrak: thats ... working fine for me, but we probably need to do a bit more organized testing. sdaftuar was updating some tests for it.
405 2016-09-15T19:25:27  <luke-jr> wumpus: right, hence "if" ☺
406 2016-09-15T19:25:49  <btcdrak> gmaxwell: well it's fine to merge afaik, but there was some discussion about the BIP text which is blocking it afaik
407 2016-09-15T19:26:06  <btcdrak> I think #8636 is ok to merge.
408 2016-09-15T19:26:37  <wumpus> that has a lot of ACKs
409 2016-09-15T19:26:40  <michagogo> Hi
410 2016-09-15T19:26:48  <wumpus> #action merge #8636
411 2016-09-15T19:26:53  <wumpus> michagogo: hey!
412 2016-09-15T19:27:00  <gmaxwell> Can someone make a list of all PR's merged for master that are not in 0.13 so we can check to make sure we haven't missed any that need backport?
413 2016-09-15T19:27:10  * BlueMatt isnt a huge fan of 8636 in 0.13.1
414 2016-09-15T19:27:11  <morcos> oh i was going to vote against 8636 as well
415 2016-09-15T19:27:25  <morcos> i haven't reviewed it and don't necessarily have any concrete concerns
416 2016-09-15T19:27:29  <wumpus> gmaxwell: all that still need backport should have the 'needs backport' tag
417 2016-09-15T19:27:35  <wumpus> https://github.com/bitcoin/bitcoin/labels/Needs%20backport
418 2016-09-15T19:27:42  <BlueMatt> its just more stuff for segwit that could easily fit in another softfork
419 2016-09-15T19:27:46  <michagogo> Sorry, not too around -- was with my grandmother (my grandfather passed away on Sunday), and now shopping with the family.
420 2016-09-15T19:27:48  <gmaxwell> assuming they got tagged.
421 2016-09-15T19:27:53  <BlueMatt> better to push any more complication further
422 2016-09-15T19:27:54  <luke-jr> gmaxwell: I did, but I may have missed some. (minor ones I didn't comment on, and have a local list I can backport myself)
423 2016-09-15T19:27:55  <wumpus> (including what is already merged)
424 2016-09-15T19:27:56  <morcos> but just seems it possibly hasn't been thought about enough to know there isn't a hidden risk like jl2012 found low-s
425 2016-09-15T19:28:08  <gmaxwell> it's an istandardness rule
426 2016-09-15T19:28:11  * michagogo wonders if zu will become the new 11
427 2016-09-15T19:28:20  <btcdrak> morcos: it's already a standard rule
428 2016-09-15T19:28:21  <gmaxwell> oh you're talkign about nulldummy sorry.
429 2016-09-15T19:28:47  <BlueMatt> gmaxwell: yea, sorry, nulldummy...I'm more ok with adding standard rules for things we want to softfork out soon
430 2016-09-15T19:28:53  <wumpus> michagogo:  hah, luckily the C parser doesn't accept it as number
431 2016-09-15T19:29:20  <wumpus> otherwise some magic constants should be defined as zuzuzuzu, especially on windows
432 2016-09-15T19:29:56  <jl2012> #8499 actually somehow depends on nulldummy softfork
433 2016-09-15T19:29:58  <luke-jr> #define zu 11
434 2016-09-15T19:30:08  <luke-jr> fixed C parser
435 2016-09-15T19:30:20  <jl2012> it still works, just can't protect CHECKMULTISIG
436 2016-09-15T19:30:20  <morcos> re: nulldummy, ok so if we think its got sufficient technical review, and we also think its technical enough it doesn't need more community discussion (for instance never appears in chain?) then ok wiht me
437 2016-09-15T19:30:41  <sipa> i think the risk for nulldummy is very low
438 2016-09-15T19:30:46  <petertodd> nulldummy is very, very simple
439 2016-09-15T19:30:51  <jl2012> since without a softfork, we can't DoS ban a peer sending us a violating transaction
440 2016-09-15T19:31:16  <sipa> jl2012: well we can't generally do that anyway
441 2016-09-15T19:31:32  <sipa> an attacker node can always pretend to be an old version
442 2016-09-15T19:31:37  <jl2012> for segwit tx we could
443 2016-09-15T19:31:39  <gmaxwell> we could for Sw things however, as it doesn't have transisiton issue.
444 2016-09-15T19:31:39  <cfields_> crap, gtg. wumpus: not a meeting topic, but I noticed that the libevent unit tests fail for the zu case. We should consider running unit tests for deps somewhere.
445 2016-09-15T19:31:44  <cfields_> bbl
446 2016-09-15T19:31:44  <jl2012> 8499 is for segwit only
447 2016-09-15T19:31:48  <luke-jr> sipa: if it's bundled with segwit I think we can?
448 2016-09-15T19:31:56  <gmaxwell> But we could ban without the softfork in such a case too.
449 2016-09-15T19:32:02  <sipa> luke-jr: an old node can always pretend to be pre-segwit
450 2016-09-15T19:32:11  <gmaxwell> There is no need to link those behaviors though we have previously.
451 2016-09-15T19:32:13  <wumpus> cfields_: yes did you see https://github.com/bitcoin/bitcoin/pull/8730?
452 2016-09-15T19:32:22  <luke-jr> but then it won't have witness data at all
453 2016-09-15T19:32:30  *** Guyver2 has joined #bitcoin-core-dev
454 2016-09-15T19:32:40  <wumpus> cfields_: running libevent tests would make some sense, yes, although we'd first need a travis run on ubuntu 16.04
455 2016-09-15T19:32:46  <sipa> luke-jr: so? it's an attacker node. it just won't send segwit txn
456 2016-09-15T19:32:54  <cfields_> wumpus: yes, I'm still making my way through that problem.
457 2016-09-15T19:32:55  <sipa> it can make up all its transactions
458 2016-09-15T19:33:00  <gmaxwell> in any case, I only think that its urgent to at least have these behaviors non-standard.
459 2016-09-15T19:33:01  <cfields_> wumpus: indeed, it was just a general thought
460 2016-09-15T19:33:21  <luke-jr> sipa: afaik the proposal is to ban Nulldummy-violating sw txns
461 2016-09-15T19:33:37  <sipa> luke-jr: to ban nulldummy-violation sw *peers*
462 2016-09-15T19:33:50  <sipa> so an attacker will just not be an sw peer
463 2016-09-15T19:33:53  <wumpus> cfields_: at least that one's easy to fix, the -stack-protector-all problem is more worrying
464 2016-09-15T19:34:21  <wumpus> cfields_: anyhw better to speak of this outside the meeting some time
465 2016-09-15T19:34:24  <jl2012> sipa: I think it's to ban segwit-nulldummy-violation peers
466 2016-09-15T19:34:37  <sipa> jl2012: ok
467 2016-09-15T19:34:39  <morcos> too many conversations
468 2016-09-15T19:34:41  <sipa> same thing
469 2016-09-15T19:34:43  <sipa> morcos: agree
470 2016-09-15T19:34:47  <luke-jr> well, whether it's useful or not is another matter - maybe it isn't
471 2016-09-15T19:34:49  <sipa> what is the topic?
472 2016-09-15T19:34:55  <jonasschnelli> 0.13.1
473 2016-09-15T19:34:57  <morcos> in summary i'm happy to let you guys decide what should go into 0.13.1 and what shouldn't, as i have been a bit out of the loop
474 2016-09-15T19:34:59  <jonasschnelli> (nulldummy)
475 2016-09-15T19:35:03  <wumpus> 0.13.1 still
476 2016-09-15T19:35:13  <morcos> however i just want to raise the concern that maybe we're putting a lot of things in very quickly at the end
477 2016-09-15T19:35:18  <gmaxwell> welcome back
478 2016-09-15T19:35:18  <morcos> and that should cause us to be nervous
479 2016-09-15T19:35:22  <sipa> i think nulldummy is very low risk, but also not very useful
480 2016-09-15T19:35:23  <gmaxwell> :)
481 2016-09-15T19:35:39  <morcos> when already the segwit activation is going to be a lot to pay attention to
482 2016-09-15T19:35:42  <BlueMatt> 0.13.1 - various things...I think morcos, sdaftuar and I generally arent a fan of all these policy and various things coming in last minute before 0.13.1, but, I think we've all been out of the loop so maybe they have more review than we think
483 2016-09-15T19:35:44  <sipa> it should happen at some point, and perhaps doing it together with segwit is easier
484 2016-09-15T19:35:51  <btcdrak> morcos: in all fairness, these PRs have been worked on over quite a long time.. they arent out of the blue.
485 2016-09-15T19:36:01  <BlueMatt> maybe nulldummy is ok, but still, so many things happening at the same time is a review burden and complicates things further
486 2016-09-15T19:36:02  <btcdrak> you need to sync up on the conversations / background of them
487 2016-09-15T19:36:03  <sipa> BlueMatt: yes, i don't like that either, but i think we just discovered many things to improve
488 2016-09-15T19:36:06  <BlueMatt> when segwit is already complicated
489 2016-09-15T19:36:13  <BlueMatt> sipa: ok, lets do it in a later sf
490 2016-09-15T19:36:13  <BlueMatt> ?
491 2016-09-15T19:36:26  <BlueMatt> i mean sf-able things, that is
492 2016-09-15T19:36:38  <gmaxwell> it's unclear whats being discussed now.
493 2016-09-15T19:36:39  <BlueMatt> and maybe if policy isnt as restrictive as we'd like in 0.13.1, thats ok
494 2016-09-15T19:36:42  <sipa> nulldummy sf
495 2016-09-15T19:37:29  <btcdrak> the only sf is nulldummy, the rest is just policy standardness.
496 2016-09-15T19:37:36  <jonasschnelli> Didn't we had this discussion already and where mostly for including nulldummy sf together with SW in 0.13.1?
497 2016-09-15T19:37:40  <gmaxwell> bluematt is talking about many, if the discussion is limited to nulldummy whatever.
498 2016-09-15T19:38:01  <gmaxwell> But the policy changes are more important.
499 2016-09-15T19:38:03  <wumpus> yes I think trying to stash a lot of changes into 0.13.1 has caused some delays already, at the least we shouldn't be adding anything else now and focus on what is there getting in
500 2016-09-15T19:38:10  <gmaxwell> jonasschnelli: yes, we did.
501 2016-09-15T19:38:30  <luke-jr> IMO nulldummy isn't worth all the time we're spending disucssing it now.
502 2016-09-15T19:38:41  <jonasschnelli> https://bitcoincore.org/en/meetings/2016/09/01/#nulldummy-and-lows-softfork-proposals
503 2016-09-15T19:38:47  <Chris_Stewart_5> Do we have a tentative release date for 0.13.1 or feature freeze?
504 2016-09-15T19:38:53  <gmaxwell> wumpus: that isn't what happened. We had specific necessary to fix issues related to SW specific moderate risk denial of service attacks, and the path to fixing them spun off a number of sub isues along the way.
505 2016-09-15T19:38:55  <wumpus> if you discover any other nice improvements they can wait until next version, unless it's critical to deployment of segwit
506 2016-09-15T19:38:57  <jonasschnelli> cfields_: no
507 2016-09-15T19:39:01  <jonasschnelli> Chris_Stewart_5: no
508 2016-09-15T19:39:15  <gmaxwell> It's a little frustrating to loop rediscussing the same things over again. Makes the meetings feel like a waste of time, FWIW.
509 2016-09-15T19:39:21  <wumpus> gmaxwell: agreed
510 2016-09-15T19:39:30  <wumpus> there are a lot of repeated topics lately
511 2016-09-15T19:39:31  <jonasschnelli> agree with gmaxwell
512 2016-09-15T19:39:50  <jonasschnelli> (which is mostly a sign of not made decistions)
513 2016-09-15T19:39:50  <wumpus> e.g. people that have been out of the loop then bring up something that was discussed a meeting or a few meetings ago
514 2016-09-15T19:39:56  <wumpus> meetings are not there to bring you up to speed
515 2016-09-15T19:40:18  <btcdrak> we publish meeting summaries, people should be reading them :-p
516 2016-09-15T19:40:26  <wumpus> the logs and minutes are available, and summaries are made and published on the site
517 2016-09-15T19:40:41  <gmaxwell> okay, thats enough probably. :) people get the point.
518 2016-09-15T19:40:44  <wumpus> and you can always ask about things outside the meeting
519 2016-09-15T19:40:57  <gmaxwell> (I am glad to not be alone!)
520 2016-09-15T19:40:58  <BlueMatt> wumpus: IIRC there are folks complaining now who were in favor of it, as there are now 5 related issues that are coming up.....8634, eg, was not previously discussed and is in the same veign
521 2016-09-15T19:41:03  <BlueMatt> maybe that should be the next topic
522 2016-09-15T19:41:41  <BlueMatt> otherwise, someone can propose a different topic :)
523 2016-09-15T19:41:47  <wumpus> BlueMatt: yes, I'm not saying it should be impossible to reconsider things discussed in previous meetings if convinng new reasons come up! just that repeating the same discussions with the same outcomes is not constructive
524 2016-09-15T19:41:49  <gmaxwell> BlueMatt: thats fine, things can be rediscussed again, but instead of repeating the discussion we should focus on whats changed or whats disagreed with.. a diff rather than a redo.
525 2016-09-15T19:41:58  <btcdrak> We need some more ACKs on #8634 and #8499 and #8526
526 2016-09-15T19:42:04  <wumpus> yes
527 2016-09-15T19:42:12  <wumpus> #action review #8634 and #8499 and #8526
528 2016-09-15T19:42:42  <sipa> it's not clear what is being discussed. if we're talking about nulldummy sf, i think there is little risk, but little benefit. it was discussed before however, and unless people strongly feel that everything being done is too much, then this is something that can be reconsidered. please don't start reconsidering everything. there are good reasons and they were discussed before
529 2016-09-15T19:42:43  <btcdrak> then the compact block/BIP thing needs to be finalised so we can merge the compact block pull #8393
530 2016-09-15T19:43:04  <BlueMatt> sipa: eg, btcdrak just pointed out three prs...two of which i think are optional in 0.13.1
531 2016-09-15T19:43:06  <BlueMatt> as is nulldummy
532 2016-09-15T19:43:24  <BlueMatt> now we're in a position where we have a at least 3 prs that are "optional", at least one or two has been previously agreed upon
533 2016-09-15T19:43:33  <wumpus> nulldummy softwork has been discussed zillions of times in the meeting, everytime the sentiment was slightly in favor of doing it because it has very little risk
534 2016-09-15T19:43:34  <btcdrak> sipa: it's been well reviewed, and run on testnet for 4 weeks already.
535 2016-09-15T19:43:41  <BlueMatt> but we want to get this thing out the door without spreading ourselves thin over too much review
536 2016-09-15T19:43:49  <wumpus> and by now it has lots of testing and review too
537 2016-09-15T19:43:51  <btcdrak> can we move on?
538 2016-09-15T19:43:51  <sipa> so let's just stick to it
539 2016-09-15T19:43:58  <wumpus> so if you want to reconsider it have a very good reason
540 2016-09-15T19:44:04  <wumpus> not just 'I personally don't like it very much'
541 2016-09-15T19:44:07  <BlueMatt> btcdrak: "run on testnet for 4 weeks" is the opposite of "good testing"
542 2016-09-15T19:44:08  <gmaxwell> fwiw, all of my testing lately has been with most of this stack applied.
543 2016-09-15T19:44:26  <btcdrak> BlueMatt: it's completely trivial, come on.
544 2016-09-15T19:44:47  <wumpus> topc nulldummy is over now
545 2016-09-15T19:44:50  <btcdrak> Is there any thing I can do regarding CB, I'm sort of confused about what is holding it up?
546 2016-09-15T19:44:55  <wumpus> other topic proposals?
547 2016-09-15T19:45:00  <sipa> segwit cb?
548 2016-09-15T19:45:05  <btcdrak> yes please
549 2016-09-15T19:45:14  <wumpus> #topic segwit cb
550 2016-09-15T19:45:18  <gmaxwell> yes, I'm also unsure what else is required. I have been testing.
551 2016-09-15T19:45:24  <sipa> gmaxwell: the latest version?
552 2016-09-15T19:45:30  <sdaftuar> i'm working on testing.  i foudn a bunch of problems with the test unfortunately :(
553 2016-09-15T19:45:31  <sipa> (as of a few days ago)
554 2016-09-15T19:45:47  <BlueMatt> it was updated a few days ago, afaik only sdaftuar has looked at it since
555 2016-09-15T19:45:48  *** cdecker has quit IRC
556 2016-09-15T19:45:54  <sipa> i did
557 2016-09-15T19:45:57  <morcos> i like the concept of the latest version, and looked at the code.  but unfortunately i have to review CB in the first place before i can review the pull, so thats what i'm doing
558 2016-09-15T19:46:04  <BlueMatt> and sdaftuar is now rewriting the testers for it, so not much to talk about aside from people should look at it?
559 2016-09-15T19:46:09  <gmaxwell> sipa: as of a week ago? I could check.
560 2016-09-15T19:46:34  <morcos> not to say you need to wait for my review of course
561 2016-09-15T19:46:35  <sipa> gmaxwell: 2 days ago
562 2016-09-15T19:47:55  <BlueMatt> next topic?
563 2016-09-15T19:48:12  <gmaxwell> (Fwiw, more segwit traffic on testnet would make live testing of that PR more useful)
564 2016-09-15T19:48:27  <luke-jr> gmaxwell: where did you guys go btw?
565 2016-09-15T19:48:35  <gmaxwell> luke-jr: to the photo room.
566 2016-09-15T19:48:37  <btcdrak> gmaxwell: roasbeef is preparing to produce some load in the next day
567 2016-09-15T19:48:56  <gmaxwell> btcdrak: okay, I'll try to get things updated to the latest first.
568 2016-09-15T19:49:53  *** laurentmt has joined #bitcoin-core-dev
569 2016-09-15T19:49:58  <jonasschnelli> any other topics?
570 2016-09-15T19:50:10  <sipa> specifically it would be useful to test connections between 0.13-with-segwit-activation-removed testnet nodes with #8393
571 2016-09-15T19:50:24  <sdaftuar> sipa: i'm also working on doing that in regtest, fyi
572 2016-09-15T19:50:32  <sipa> awesome
573 2016-09-15T19:50:34  <btcdrak> great
574 2016-09-15T19:50:40  <gmaxwell> sipa: okay, I'll make sure that I run with that too.
575 2016-09-15T19:50:52  <sipa> thanks
576 2016-09-15T19:51:37  <luke-jr> would be handy to have some regular segwit spam on testnet in general IMO
577 2016-09-15T19:51:56  <btcdrak> luke-jr: it's coming, roasbeef is setting something up
578 2016-09-15T19:52:08  *** laurentmt has quit IRC
579 2016-09-15T19:53:02  <btcdrak> *silence*
580 2016-09-15T19:53:41  <jonasschnelli> #endmeeting
581 2016-09-15T19:53:41  <lightningbot> Meeting ended Thu Sep 15 19:53:41 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
582 2016-09-15T19:53:41  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-15-19.01.html
583 2016-09-15T19:53:41  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-15-19.01.txt
584 2016-09-15T19:53:41  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-15-19.01.log.html
585 2016-09-15T19:55:49  * btcdrak looks around
586 2016-09-15T19:56:03  <btcdrak> I think I entered the twilight zone
587 2016-09-15T19:56:04  * sipa hands btcdrak a handful of crickets
588 2016-09-15T19:56:12  <btcdrak> XD
589 2016-09-15T19:56:48  * petertodd hands btcdrak a cricket of handfuls
590 2016-09-15T19:56:49  <jonasschnelli> Well,... everyone went reviewing the 0.13.1 PRs
591 2016-09-15T19:57:14  * btcdrak beer
592 2016-09-15T19:57:20  <petertodd> jonasschnelli: and I released OpenTimestamps earlier today, and have been up all night :) https://petertodd.org/2016/opentimestamps-announcement
593 2016-09-15T19:57:31  <jonasschnelli> Saw that! Nice job btw!
594 2016-09-15T19:57:38  * sipa hands petertodd a giveful of btcdraks
595 2016-09-15T19:57:39  <petertodd> thanks!
596 2016-09-15T19:58:02  <petertodd> jonasschnelli: gonna (hopefully!) have a blog post tomorrow morning about the git commit timestamping it does as well
597 2016-09-15T19:58:40  <petertodd> sipa: "hands.... hands everywhere...."
598 2016-09-15T19:58:51  <jonasschnelli> petertodd: Yes. I think a "non-technical" description of the possibilities would be nice
599 2016-09-15T19:59:30  <petertodd> jonasschnelli: I've actually written up (most) of that post already: https://github.com/opentimestamps/opentimestamps-client/blob/master/doc/git-integration.md
600 2016-09-15T19:59:59  <petertodd> jonasschnelli: a step-by-step example of a case where you could use it (e.g. sipa's key compromise) would be good though
601 2016-09-15T20:01:12  <jonasschnelli> petertodd: your git sig time-stamping is very clever...
602 2016-09-15T20:02:33  <petertodd> jonasschnelli: yeah, that's a fun hack! I noticed it was possible awhile back, and made a demo of a PGP-signed git commit with signatures from Isis Lovecruft and myself on one commit :)
603 2016-09-15T20:02:48  <petertodd> jonasschnelli: unfortunately, github shows those sigs as "unverified", but that's a minor problem
604 2016-09-15T20:03:12  <jonasschnelli> Yes. The github-verified icon is nice. But does not prove anything. :)
605 2016-09-15T20:03:27  <roasbeef> re testnet segwit spam: would help if we could get more segwit enabled hashpower on testnet and to get those currently mining to limit by max weight (4mil) instead of stripped size
606 2016-09-15T20:03:44  <petertodd> jonasschnelli: well, if you trust github...
607 2016-09-15T20:03:48  <roasbeef> err I mean regular size
608 2016-09-15T20:04:43  <sipa> jonasschnelli: sure it does. as long as you trust github and the companies hosting their hardware.
609 2016-09-15T20:04:46  <sipa> if.
610 2016-09-15T20:04:52  <jonasschnelli> kanzure: I gave you edit right on https://docs.google.com/forms/d/1HbJecbEN62r8sL2H0nBjlznmJEa1VDCR_FWC76-qEvo/edit
611 2016-09-15T20:04:57  <jonasschnelli> Thanks for fixing the typos. :)
612 2016-09-15T20:05:03  <kanzure> oh.
613 2016-09-15T20:05:43  <jonasschnelli> sipa: Yes. And probably trust all your browser plugins. :)
614 2016-09-15T20:06:13  <jonasschnelli> I guess github.com does not include any third-party CDN-ish CSS/JS files..
615 2016-09-15T20:06:15  <sipa> yes, and you c library, X server, kernel, cpu, motherboard manufacturer, delivery company, ...
616 2016-09-15T20:06:23  <jonasschnelli> okay. stop. :)
617 2016-09-15T20:07:31  <btcdrak> roasbeef: will pass it on
618 2016-09-15T20:07:38  <sipa> (but admittedly, the browser is the easiest target of all of those)
619 2016-09-15T20:07:48  <luke-jr> sipa: ping
620 2016-09-15T20:08:05  <sipa> luke-jr: pung
621 2016-09-15T20:17:51  *** cdecker has joined #bitcoin-core-dev
622 2016-09-15T20:39:45  *** aalex has quit IRC
623 2016-09-15T20:40:41  *** cdecker has quit IRC
624 2016-09-15T20:47:45  *** aalex has joined #bitcoin-core-dev
625 2016-09-15T20:50:40  <phantomcircuit> jonasschnelli: just the newline?
626 2016-09-15T21:18:06  *** cryptapus has quit IRC
627 2016-09-15T21:48:03  *** lightningbot has joined #bitcoin-core-dev
628 2016-09-15T21:48:18  *** sipa has joined #bitcoin-core-dev
629 2016-09-15T21:48:53  *** helo has joined #bitcoin-core-dev
630 2016-09-15T21:50:20  *** mappum has joined #bitcoin-core-dev
631 2016-09-15T21:50:26  *** mjdecour has joined #bitcoin-core-dev
632 2016-09-15T21:51:34  *** CyrusV has joined #bitcoin-core-dev
633 2016-09-15T21:51:55  *** lesderid has joined #bitcoin-core-dev
634 2016-09-15T21:51:59  *** Lightsword has joined #bitcoin-core-dev
635 2016-09-15T21:52:05  *** TD-Linux has joined #bitcoin-core-dev
636 2016-09-15T21:52:18  *** GreenIsMyPepper has joined #bitcoin-core-dev
637 2016-09-15T21:52:40  *** jonasschnelli has joined #bitcoin-core-dev
638 2016-09-15T21:54:12  *** cdecker has joined #bitcoin-core-dev
639 2016-09-15T21:55:11  *** aalex has quit IRC
640 2016-09-15T22:00:55  <gmaxwell> would it be unreasonable for us to keep a bitcoin-core keyring file that has the pgp keys of all the regulars around here in it?
641 2016-09-15T22:09:15  *** cdecker has quit IRC
642 2016-09-15T22:15:29  *** MarcoFalke has left #bitcoin-core-dev
643 2016-09-15T22:20:05  <BlueMatt> argh ffs...can we all agree to not use github's fancy new review mode thing? it seems to be breaking github's emails as they are no longer threaded together for a single issue...hopefully they can fix in a day or two but they really broke my bitcoin-email workflow :(
644 2016-09-15T22:20:25  <BlueMatt> damn github and their not always working perfectly :(
645 2016-09-15T22:20:41  <BlueMatt> gmaxwell: https://github.com/bitcoin/bitcoin/tree/master/contrib/gitian-keys
646 2016-09-15T22:20:45  <BlueMatt> we already have that :)
647 2016-09-15T22:21:14  <gmaxwell> thats gitian, and doesn't include things like morcos' key.
648 2016-09-15T22:21:38  <midnightmagic> mine's not in there either.
649 2016-09-15T22:21:39  <BlueMatt> it doesnt include morcos' key because he had +/- never used it until a few days ago...
650 2016-09-15T22:21:46  <BlueMatt> I had to push his to the keyserver for him :(
651 2016-09-15T22:22:07  <BlueMatt> gmaxwell: but, I dont see why we shouldnt just include everyone there, whether the folder is renamed from gitian or not :)
652 2016-09-15T22:22:15  <gmaxwell> right.
653 2016-09-15T22:22:56  <btcdrak> seems about right.
654 2016-09-15T22:23:47  <BlueMatt> oh, it doesnt have you there, gmaxwell :'(
655 2016-09-15T22:24:01  *** jnewbery has joined #bitcoin-core-dev
656 2016-09-15T22:28:46  <luke-jr> BlueMatt: is there an issue for this on GitHub?
657 2016-09-15T22:28:47  *** cdecker has joined #bitcoin-core-dev
658 2016-09-15T22:29:16  <BlueMatt> luke-jr: dunno, I emailed their support@ alias that has been responsive to me in the past
659 2016-09-15T22:30:45  *** jnewbery has quit IRC
660 2016-09-15T23:03:56  *** Chris_Stewart_5 has quit IRC
661 2016-09-15T23:18:00  *** Chris_Stewart_5 has joined #bitcoin-core-dev
662 2016-09-15T23:19:31  *** Guyver2 has quit IRC
663 2016-09-15T23:37:49  *** adiabat has quit IRC
664 2016-09-15T23:55:38  *** cdecker has quit IRC