1 2016-02-25T00:00:13  *** raedah has joined #bitcoin-core-dev
  2 2016-02-25T00:20:12  *** AaronvanW_ has joined #bitcoin-core-dev
  3 2016-02-25T00:30:46  *** wumpus has quit IRC
  4 2016-02-25T00:35:05  *** wumpus has joined #bitcoin-core-dev
  5 2016-02-25T00:40:17  *** danielsocials has joined #bitcoin-core-dev
  6 2016-02-25T00:44:14  *** danielsocials has quit IRC
  7 2016-02-25T00:44:23  *** danielsocials has joined #bitcoin-core-dev
  8 2016-02-25T00:47:25  *** randy-waterhouse has joined #bitcoin-core-dev
  9 2016-02-25T00:48:39  *** Thireus has joined #bitcoin-core-dev
 10 2016-02-25T00:48:52  *** danielsocials has quit IRC
 11 2016-02-25T01:04:10  *** Chris_Stewart_5 has quit IRC
 12 2016-02-25T01:09:38  <GitHub107> [bitcoin] promag closed pull request #6570: Add option to specify rescan starting timestamp to RPC import calls (master...feature/import-rescan-from-block-index) https://github.com/bitcoin/bitcoin/pull/6570
 13 2016-02-25T01:10:02  *** ghtdak has quit IRC
 14 2016-02-25T01:13:28  <GitHub184> [bitcoin] promag closed pull request #7498: Add createtransaction (master...feature/rpc-createtransaction) https://github.com/bitcoin/bitcoin/pull/7498
 15 2016-02-25T01:17:23  *** d9b4bef9 has quit IRC
 16 2016-02-25T01:18:27  *** justanotheruser has quit IRC
 17 2016-02-25T01:19:09  *** d9b4bef9 has joined #bitcoin-core-dev
 18 2016-02-25T01:24:17  *** justanotheruser has joined #bitcoin-core-dev
 19 2016-02-25T01:33:51  *** gevs has quit IRC
 20 2016-02-25T01:42:28  *** zooko has joined #bitcoin-core-dev
 21 2016-02-25T01:45:37  *** gevs has joined #bitcoin-core-dev
 22 2016-02-25T01:45:57  *** danielsocials has joined #bitcoin-core-dev
 23 2016-02-25T01:48:27  *** Ylbam has quit IRC
 24 2016-02-25T01:48:36  *** PaulCapestany has quit IRC
 25 2016-02-25T01:50:08  *** PaulCapestany has joined #bitcoin-core-dev
 26 2016-02-25T01:52:27  *** danielsocials has quit IRC
 27 2016-02-25T01:54:49  *** wallet42 has quit IRC
 28 2016-02-25T02:00:26  *** dermoth has quit IRC
 29 2016-02-25T02:00:56  *** dermoth has joined #bitcoin-core-dev
 30 2016-02-25T02:01:25  *** go1111111 has quit IRC
 31 2016-02-25T02:16:43  *** AaronvanW_ has quit IRC
 32 2016-02-25T02:17:13  *** go1111111 has joined #bitcoin-core-dev
 33 2016-02-25T02:32:45  *** justanotheruser has quit IRC
 34 2016-02-25T02:33:25  *** justanotheruser has joined #bitcoin-core-dev
 35 2016-02-25T02:34:59  *** gamersg has joined #bitcoin-core-dev
 36 2016-02-25T02:46:01  *** p15 has joined #bitcoin-core-dev
 37 2016-02-25T02:50:27  *** belcher has quit IRC
 38 2016-02-25T02:53:54  *** laurentmt has joined #bitcoin-core-dev
 39 2016-02-25T02:54:10  *** laurentmt has quit IRC
 40 2016-02-25T02:59:29  *** gevs has quit IRC
 41 2016-02-25T03:23:31  *** ghtdak has joined #bitcoin-core-dev
 42 2016-02-25T03:28:16  *** PaulCapestany has quit IRC
 43 2016-02-25T03:34:26  *** achow101 has joined #bitcoin-core-dev
 44 2016-02-25T03:49:18  *** achow101 has quit IRC
 45 2016-02-25T03:49:39  *** danielsocials has joined #bitcoin-core-dev
 46 2016-02-25T03:53:35  <GitHub23> [bitcoin] AliceWonderMiscreations closed pull request #7588: Sample RPM spec file for Bitcoin 0.12.0 (master...master) https://github.com/bitcoin/bitcoin/pull/7588
 47 2016-02-25T03:54:34  *** danielsocials has quit IRC
 48 2016-02-25T04:20:35  *** p15x has joined #bitcoin-core-dev
 49 2016-02-25T04:20:40  *** helo has quit IRC
 50 2016-02-25T04:21:09  *** helo has joined #bitcoin-core-dev
 51 2016-02-25T04:30:57  *** baldur has quit IRC
 52 2016-02-25T04:31:16  *** baldur has joined #bitcoin-core-dev
 53 2016-02-25T04:52:31  *** wallet42 has joined #bitcoin-core-dev
 54 2016-02-25T04:58:55  *** Don_John has quit IRC
 55 2016-02-25T05:38:29  *** p15x has quit IRC
 56 2016-02-25T05:52:32  *** danielsocials has joined #bitcoin-core-dev
 57 2016-02-25T05:57:18  *** xiangfu has quit IRC
 58 2016-02-25T05:59:07  *** xiangfu has joined #bitcoin-core-dev
 59 2016-02-25T05:59:31  *** danielsocials has quit IRC
 60 2016-02-25T06:02:02  *** midnightmagic has quit IRC
 61 2016-02-25T06:20:53  *** midnightmagic has joined #bitcoin-core-dev
 62 2016-02-25T06:54:08  *** goregrind has quit IRC
 63 2016-02-25T07:32:24  *** gamersg has quit IRC
 64 2016-02-25T07:33:01  *** Ylbam has joined #bitcoin-core-dev
 65 2016-02-25T07:56:29  *** danielsocials has joined #bitcoin-core-dev
 66 2016-02-25T07:59:26  *** BashCo has quit IRC
 67 2016-02-25T08:03:45  *** danielsocials has quit IRC
 68 2016-02-25T08:25:53  *** BashCo has joined #bitcoin-core-dev
 69 2016-02-25T08:32:10  *** chris2000 has joined #bitcoin-core-dev
 70 2016-02-25T08:32:52  *** xiangfu has quit IRC
 71 2016-02-25T08:34:50  *** xiangfu has joined #bitcoin-core-dev
 72 2016-02-25T08:40:59  *** fkhan has quit IRC
 73 2016-02-25T08:54:24  *** fkhan has joined #bitcoin-core-dev
 74 2016-02-25T09:01:11  *** danielsocials has joined #bitcoin-core-dev
 75 2016-02-25T09:07:01  *** danielsocials has quit IRC
 76 2016-02-25T09:16:51  *** MarcoFalke has joined #bitcoin-core-dev
 77 2016-02-25T09:27:15  *** AaronvanW_ has joined #bitcoin-core-dev
 78 2016-02-25T09:48:22  *** go1111111 has quit IRC
 79 2016-02-25T10:00:32  *** go1111111 has joined #bitcoin-core-dev
 80 2016-02-25T10:01:02  *** MarcoFalke has quit IRC
 81 2016-02-25T10:07:53  *** wallet42 has quit IRC
 82 2016-02-25T10:14:39  *** zooko has quit IRC
 83 2016-02-25T10:29:43  *** randy-waterhouse has quit IRC
 84 2016-02-25T10:47:51  *** MarcoFalke has joined #bitcoin-core-dev
 85 2016-02-25T10:49:29  *** xiangfu has quit IRC
 86 2016-02-25T10:51:33  *** xiangfu has joined #bitcoin-core-dev
 87 2016-02-25T11:04:20  *** danielsocials has joined #bitcoin-core-dev
 88 2016-02-25T11:16:56  *** MarcoFalke has quit IRC
 89 2016-02-25T11:20:48  *** danielsocials has quit IRC
 90 2016-02-25T11:36:03  <GitHub199> [bitcoin] luke-jr closed pull request #7529: Bugfix: Rename descendantfees to descendantmodfees (master...bugfix_descendantfees) https://github.com/bitcoin/bitcoin/pull/7529
 91 2016-02-25T11:48:34  *** xiangfu has quit IRC
 92 2016-02-25T12:36:51  *** dermoth_ has joined #bitcoin-core-dev
 93 2016-02-25T12:37:17  *** dermoth has quit IRC
 94 2016-02-25T12:37:19  *** dermoth_ is now known as dermoth
 95 2016-02-25T12:40:22  *** MarcoFalke has joined #bitcoin-core-dev
 96 2016-02-25T12:41:38  *** p15x has joined #bitcoin-core-dev
 97 2016-02-25T12:47:04  *** Thireus has quit IRC
 98 2016-02-25T12:47:10  *** Thireus1 has joined #bitcoin-core-dev
 99 2016-02-25T12:48:06  *** Thireus has joined #bitcoin-core-dev
100 2016-02-25T12:51:43  *** Thireus1 has quit IRC
101 2016-02-25T12:55:12  *** MarcoFalke has quit IRC
102 2016-02-25T12:56:02  *** wallet42 has joined #bitcoin-core-dev
103 2016-02-25T13:01:53  *** dermoth_ has joined #bitcoin-core-dev
104 2016-02-25T13:02:00  *** dermoth has quit IRC
105 2016-02-25T13:02:21  *** dermoth_ is now known as dermoth
106 2016-02-25T13:02:30  *** laurentmt has joined #bitcoin-core-dev
107 2016-02-25T13:15:52  *** Kexkey has joined #bitcoin-core-dev
108 2016-02-25T13:16:58  *** gevs has joined #bitcoin-core-dev
109 2016-02-25T13:17:23  *** danielsocials has joined #bitcoin-core-dev
110 2016-02-25T13:20:37  *** zooko has joined #bitcoin-core-dev
111 2016-02-25T13:22:09  *** danielsocials has quit IRC
112 2016-02-25T13:32:24  *** xiangfu has joined #bitcoin-core-dev
113 2016-02-25T13:35:08  *** Kexkey has quit IRC
114 2016-02-25T13:58:56  *** MarcoFalke has joined #bitcoin-core-dev
115 2016-02-25T14:00:29  *** p15 has quit IRC
116 2016-02-25T14:01:22  *** p15x has quit IRC
117 2016-02-25T14:02:54  *** p15x has joined #bitcoin-core-dev
118 2016-02-25T14:03:19  *** Chris_Stewart_5 has joined #bitcoin-core-dev
119 2016-02-25T14:10:46  *** Chris_Stewart_5 has quit IRC
120 2016-02-25T14:13:42  *** wallet42 has quit IRC
121 2016-02-25T14:19:13  *** danielsocials has joined #bitcoin-core-dev
122 2016-02-25T14:25:15  *** MarcoFalke has quit IRC
123 2016-02-25T14:25:39  *** danielsocials has quit IRC
124 2016-02-25T14:44:09  *** zooko has quit IRC
125 2016-02-25T15:12:15  *** p15x has quit IRC
126 2016-02-25T15:22:29  *** danielsocials has joined #bitcoin-core-dev
127 2016-02-25T15:31:11  *** zooko has joined #bitcoin-core-dev
128 2016-02-25T15:32:51  *** MarcoFalke has joined #bitcoin-core-dev
129 2016-02-25T15:33:30  *** murch has joined #bitcoin-core-dev
130 2016-02-25T15:34:57  *** danielsocials has quit IRC
131 2016-02-25T15:53:01  *** zooko has quit IRC
132 2016-02-25T15:53:51  * Luke-Jr prods cfields to fix the OSX SDK from Travis..
133 2016-02-25T16:12:25  *** xiangfu has quit IRC
134 2016-02-25T16:16:39  *** zooko has joined #bitcoin-core-dev
135 2016-02-25T16:18:49  <btcdrak> Luje-Jr: what's wrong with it?
136 2016-02-25T16:19:41  *** treehug88 has joined #bitcoin-core-dev
137 2016-02-25T16:21:37  <Luke-Jr> btcdrak: it's Forbidden as usual
138 2016-02-25T16:23:24  *** cheese_ has joined #bitcoin-core-dev
139 2016-02-25T16:23:56  <btcdrak> link?
140 2016-02-25T16:24:15  <btcdrak> oh the SDK, yeah.
141 2016-02-25T16:25:57  *** Cheeseo has quit IRC
142 2016-02-25T16:26:58  *** BashCo has quit IRC
143 2016-02-25T16:32:16  *** danielsocials has joined #bitcoin-core-dev
144 2016-02-25T16:34:10  *** Chris_Stewart_5 has joined #bitcoin-core-dev
145 2016-02-25T16:35:57  *** Thireus has quit IRC
146 2016-02-25T16:38:04  *** danielsocials has quit IRC
147 2016-02-25T16:41:10  *** Thireus has joined #bitcoin-core-dev
148 2016-02-25T16:42:25  *** dermoth has quit IRC
149 2016-02-25T16:47:08  *** BashCo has joined #bitcoin-core-dev
150 2016-02-25T16:47:17  *** Don_John has joined #bitcoin-core-dev
151 2016-02-25T16:48:06  *** Thireus1 has joined #bitcoin-core-dev
152 2016-02-25T16:48:06  *** Thireus has quit IRC
153 2016-02-25T16:55:37  *** Thireus has joined #bitcoin-core-dev
154 2016-02-25T16:55:43  *** gevs has quit IRC
155 2016-02-25T16:56:34  *** Thireus1 has quit IRC
156 2016-02-25T17:08:29  *** Thireus1 has joined #bitcoin-core-dev
157 2016-02-25T17:09:23  *** Thireus has quit IRC
158 2016-02-25T17:10:10  *** Thireus has joined #bitcoin-core-dev
159 2016-02-25T17:13:07  *** Thireus1 has quit IRC
160 2016-02-25T17:19:35  <GitHub178> [bitcoin] morcos opened pull request #7598: Refactor CreateNewBlock to be a method of the BlockAssembler class (master...BlockAssembler) https://github.com/bitcoin/bitcoin/pull/7598
161 2016-02-25T17:25:28  *** laurentmt has quit IRC
162 2016-02-25T17:29:52  *** gevs has joined #bitcoin-core-dev
163 2016-02-25T17:29:52  *** gevs has joined #bitcoin-core-dev
164 2016-02-25T17:34:46  *** cj has quit IRC
165 2016-02-25T17:37:16  *** lightningbot has joined #bitcoin-core-dev
166 2016-02-25T17:41:00  *** jon3ss has joined #bitcoin-core-dev
167 2016-02-25T17:43:26  *** jon3ss has quit IRC
168 2016-02-25T17:44:09  *** Chris_Stewart_5 has quit IRC
169 2016-02-25T17:44:25  *** danielsocials has quit IRC
170 2016-02-25T17:50:46  *** skyraider_ has joined #bitcoin-core-dev
171 2016-02-25T17:52:45  *** cj has joined #bitcoin-core-dev
172 2016-02-25T17:53:39  *** zooko has quit IRC
173 2016-02-25T18:04:43  *** raedah has quit IRC
174 2016-02-25T18:05:10  *** raedah has joined #bitcoin-core-dev
175 2016-02-25T18:06:14  *** wallet42 has joined #bitcoin-core-dev
176 2016-02-25T18:08:38  *** murch has quit IRC
177 2016-02-25T18:13:38  *** Thireus1 has joined #bitcoin-core-dev
178 2016-02-25T18:14:39  *** Thireus has quit IRC
179 2016-02-25T18:14:58  *** Thireus has joined #bitcoin-core-dev
180 2016-02-25T18:18:13  *** Thireus1 has quit IRC
181 2016-02-25T18:26:28  *** cj has quit IRC
182 2016-02-25T18:28:24  *** cj has joined #bitcoin-core-dev
183 2016-02-25T18:30:26  *** AtashiCon has quit IRC
184 2016-02-25T18:30:45  *** AtashiCon has joined #bitcoin-core-dev
185 2016-02-25T18:40:35  *** raedah has quit IRC
186 2016-02-25T18:43:49  <cfields> Luke-Jr: just grepped the logs and guessed on a range based on what was failing. fingers crossed, should work now.
187 2016-02-25T18:50:31  *** zooko has joined #bitcoin-core-dev
188 2016-02-25T18:54:12  *** raedah has joined #bitcoin-core-dev
189 2016-02-25T18:58:38  *** achow101 has joined #bitcoin-core-dev
190 2016-02-25T19:01:14  <gmaxwell> #startmeeting
191 2016-02-25T19:01:14  <lightningbot> Meeting started Thu Feb 25 19:01:14 2016 UTC.  The chair is gmaxwell. Information about MeetBot at http://wiki.debian.org/MeetBot.
192 2016-02-25T19:01:14  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
193 2016-02-25T19:01:35  <gmaxwell> Hello. Welcome to today's meeting (bot is broken in #bitcoin-dev. Topics?
194 2016-02-25T19:02:08  <morcos> Did anyone review 7187 as per last weeks action item?
195 2016-02-25T19:02:14  <morcos> We need punishments
196 2016-02-25T19:02:29  <petertodd> morcos: heh, you're making me glad I was on a plane :)
197 2016-02-25T19:02:30  <btcdrak> I got stuck in traffic, honest
198 2016-02-25T19:02:41  *** zooko has quit IRC
199 2016-02-25T19:03:02  *** proslogion has joined #bitcoin-core-dev
200 2016-02-25T19:03:05  <morcos> Actually to make a topic out of it, lets gameplan a 68/112/113 rollout
201 2016-02-25T19:03:10  <gmaxwell> morcos: we'll end up with people showing up every other meeting it seems. I also wasn't in last week.
202 2016-02-25T19:03:18  <gmaxwell> #topic  68/112/113 rollout
203 2016-02-25T19:03:18  <btcdrak> +1 morcos
204 2016-02-25T19:03:37  <petertodd> so, rollout is made more complex by a non-trivial amount of hashing power nVersion voting for classic
205 2016-02-25T19:03:54  <jonasschnelli> could a bip 68/112/113 softfork be a timestopper for SW?
206 2016-02-25T19:04:09  <gmaxwell> This... again. :(
207 2016-02-25T19:04:11  <morcos> sorry btcdrak i haven't checked recently, but it seemed to me that the soft fork logic was relatively easy to review (except for gmaxwells concern), but that we still needed more extensive testing
208 2016-02-25T19:04:14  <petertodd> jonasschnelli: what do you mean by 'timestopper'?
209 2016-02-25T19:04:17  <btcdrak> Yes. I have written an ISM rollout in https://github.com/bitcoin/bitcoin/pull/7561 but we may need to consider BIP9 now
210 2016-02-25T19:04:21  <sdaftuar> has anyone reviewed either of the new versionbits proposals? (i haven't)
211 2016-02-25T19:04:33  <jonasschnelli> timestopper: I guess we can't run two SF at the same time.
212 2016-02-25T19:04:38  <morcos> yes, that should be action item for next week.
213 2016-02-25T19:05:01  <btcdrak> sipa started a BIP9 implementation in https://github.com/bitcoin/bitcoin/pull/7575
214 2016-02-25T19:05:02  <gmaxwell> jonasschnelli: I don't think so; at least we can roll multiple ISM sofforks at once so long as they are strictly additive. No one that I'm aware of is clamoring againsst 68/112/113.
215 2016-02-25T19:05:12  <petertodd> gmaxwell: fwiw I asked f2pool and bitmain to use coinbase to allow hashers to show support rather than nVersion
216 2016-02-25T19:05:37  <petertodd> gmaxwell: 68/112/113 were briefly discussed in HK, with no objections, fwiw
217 2016-02-25T19:05:40  <gmaxwell> I am pretty fond of sipa's BIP9 implementation.
218 2016-02-25T19:05:46  <btcdrak> I've been working on converting the tests in #7561 to work with versionbits so we have both options. But I have a couple of technical nits I'd like to discuss
219 2016-02-25T19:06:52  <morcos> I think it would be the wiser move technically and politically to do BIP9 first if we don't think the delay is too long.  It's kind of the whole point of the thign.
220 2016-02-25T19:06:52  <btcdrak> BIP68 obviously requires v2 transactions, which currently dont relay. So we need to bump the relay policy. the question is do we go for sf enforcement first, and then bump the policy or do we change the relay policy with the sf deployment?
221 2016-02-25T19:07:08  <gmaxwell> petertodd: it's hard to be sure, it may be that it only becomes a constructed political hot potato once merged as we've seen for at least one other thing. But we can't plan based on my cyncicism. Maybe a last call to the mailing list would be useful.  "We're thinking about moving this into deployment, what if any complaints remain?"
222 2016-02-25T19:07:29  <petertodd> btcdrak: I think changing the relay policy in the release that supports it is fine - that's basically what we did with CLTV after all
223 2016-02-25T19:07:36  <morcos> gmaxwell: yes thats my point exactly, i think much less likely to have complaints if we are doing it via bip9
224 2016-02-25T19:07:48  <petertodd> btcdrak: just don't bump the default tx version number yet!
225 2016-02-25T19:07:55  <btcdrak> We also have a sort of chicken and egg situation for changing the default tx version, so I proposed this https://github.com/btcdrak/bitcoin/commit/957d59043b1eb3a2525eae6cae6a2a15b2eab401 so it can be done in two steps
226 2016-02-25T19:08:18  <petertodd> btcdrak: looks good
227 2016-02-25T19:08:37  *** zooko has joined #bitcoin-core-dev
228 2016-02-25T19:08:50  <morcos> two steps seems logical, and bumping the default isn't particularly important while we don't have wallet code for sending BIP68 locked txs anyway right?
229 2016-02-25T19:08:52  <btcdrak> Unless miners were change their signalling, I think we should go for BIP9 this time. It shouldnt take too long to convert the RPC tests over to sipa's PR.
230 2016-02-25T19:09:01  <gmaxwell> I haven't spoken to the BTCD folks in a bit, they've provided useful feedback on protocol changes in the past. I'll take an action to go talk to them about 9/68/112/113.
231 2016-02-25T19:09:14  <btcdrak> I'm building a patch based on #7575
232 2016-02-25T19:09:36  <CodeShark> I personally dislike adding these constants to the CTransaction class
233 2016-02-25T19:09:37  <jonasschnelli> #action talk to BTCD folk about bips 9/68/112/113
234 2016-02-25T19:10:02  <btcdrak> maybe also action review 7575?
235 2016-02-25T19:10:15  <gmaxwell> Should we send a last call-ish like message about 68/112/113 ?
236 2016-02-25T19:10:27  <CodeShark> CTransaction should be relay policy independent as well as consensus independent
237 2016-02-25T19:10:28  <petertodd> gmaxwell: ack
238 2016-02-25T19:10:30  <btcdrak> gmaxwell: in what way?
239 2016-02-25T19:10:53  <gmaxwell> btcdrak: "We're thinkin about moving these to deployment. Speak now or be mocked when you complain later."
240 2016-02-25T19:10:53  <morcos> CodeShark: are you referring to BIP68 stuff.  (I mostly agree, but we merged that already)
241 2016-02-25T19:10:54  <petertodd> CodeShark: I think that's a reasonable concern
242 2016-02-25T19:10:59  <sdaftuar> gmaxwell: ack
243 2016-02-25T19:11:10  <btcdrak> gmaxwell: yes that would be great. I had been contemplating this.
244 2016-02-25T19:11:26  <gmaxwell> #action Send email re-68/112/113 deployment.
245 2016-02-25T19:11:27  *** Thireus1 has joined #bitcoin-core-dev
246 2016-02-25T19:11:30  <petertodd> gmaxwell: probably worth mentioning that we're considering version bits due to classic conflicts
247 2016-02-25T19:11:40  <morcos> Who is taking that action item
248 2016-02-25T19:11:46  <sipa> hi, i'm on bad internet in barbados
249 2016-02-25T19:12:08  <gmaxwell> I could do it but I'm not ideal; not super up to date on the history there.
250 2016-02-25T19:12:10  <morcos> petertodd: i think we should not mention that, lets just see if we can get bip 9 ready quickly and then say we're doing it
251 2016-02-25T19:12:16  <CodeShark> sipa: what's the status on bip 9?
252 2016-02-25T19:12:46  <petertodd> morcos: eh, that's reasonable if we think we're close
253 2016-02-25T19:13:02  <sipa> CodeShark: i started working on some other changes to the bip (disambiguate some things, add a state transition diagram, and add start time)
254 2016-02-25T19:13:03  <jonasschnelli> morcos: do you want to take the action-item for email re-68/112/113 deployment?
255 2016-02-25T19:13:17  <morcos> sure unless btcdrak wants it
256 2016-02-25T19:13:31  <btcdrak> morcos: I'll pass :)
257 2016-02-25T19:13:34  <sipa> CodeShark: but not submitted yet
258 2016-02-25T19:13:48  <jonasschnelli> morocs has "a white vest".
259 2016-02-25T19:14:02  <btcdrak> sipa: is #7575 not up to date?
260 2016-02-25T19:14:12  <jonasschnelli> 7575 was updated today
261 2016-02-25T19:14:16  <sipa> btcdrak: is that my pr?
262 2016-02-25T19:14:19  <gmaxwell> jonasschnelli: all the better to show the gunshot wounds.
263 2016-02-25T19:14:26  <jonasschnelli> gmaxwell... haha
264 2016-02-25T19:14:28  <sipa> btcdrak: it impkements a start time, which is not in bip9
265 2016-02-25T19:14:52  *** Thireus has quit IRC
266 2016-02-25T19:14:56  <btcdrak> sipa: oh, _that_ is why my RPC tests did not work....
267 2016-02-25T19:14:58  <morcos> uhh
268 2016-02-25T19:14:58  <sipa> btcdrak: and i had to make some interoretation as bip9 is ambiguous about what hapoens when both transitiin to failed and lockedin happen simultaneously
269 2016-02-25T19:15:04  <gmaxwell> We had previously discussed a start time esp with the debacle that happened with CLTV being used by 1/4 to 1/3 of the hashpower before any released software supported it.
270 2016-02-25T19:15:09  <btcdrak> sipa: I was going bananas
271 2016-02-25T19:15:27  <sipa> sorry for typing, in a bumpy car
272 2016-02-25T19:15:42  <CodeShark> argh...I added and removed a start time several times to the bip :p
273 2016-02-25T19:15:52  <sipa> CodeShark: i know, sorry
274 2016-02-25T19:16:06  <sipa> i believe we need one, but i want some other explanations on the bip too
275 2016-02-25T19:16:07  <btcdrak> sipa: I agree with starttime, prefer it.
276 2016-02-25T19:16:22  <sipa> there are different ways to do it
277 2016-02-25T19:16:46  <morcos> sipa: so to be clear, is your bip 9 pr (7575) where you want it to be?  if so i think that should be primary action item for everyone else to review and feedback
278 2016-02-25T19:16:58  <gmaxwell> I can't imagine doin BIP9 without a start time. Rusty was opposed on principle, I think, but expirence trumps.
279 2016-02-25T19:17:00  <btcdrak> sipa: so I'll have to mock time for the RPC test
280 2016-02-25T19:17:11  <petertodd> gmaxwell: by start time, you mean minimum possible activation data right?
281 2016-02-25T19:17:13  <morcos> btcdrak can simultaneously work on getting the 68/112/113 ready to use it
282 2016-02-25T19:17:19  <petertodd> gmaxwell: or grace period post-activation?
283 2016-02-25T19:17:20  <sdaftuar> fyi 7575 is still failing travis, haven't dived in to see what is wrong
284 2016-02-25T19:17:24  <gmaxwell> morcos: people reviewing should keep in mind that intentional discrepency with the BIP at the moment.
285 2016-02-25T19:17:28  <morcos> we need both of those and 7187 merged for backport
286 2016-02-25T19:17:36  <morcos> gmaxwell: noted.  :)
287 2016-02-25T19:17:49  <CodeShark> https://github.com/bitcoin/bips/pull/219 didn't even get merged over this whole starttime crap :(
288 2016-02-25T19:18:03  <gmaxwell> petertodd: former, in what the PR implements there is a time where the bit in the header becomes defined as counting for the soft-fork.
289 2016-02-25T19:18:07  <CodeShark> Which wasn't even the main point of that PR
290 2016-02-25T19:18:13  <btcdrak> morcos: yeah it's basically done, modulo converting the RPC tests from my ISM PR.
291 2016-02-25T19:18:34  <petertodd> gmaxwell: right, any idea on how many months after final release that should be?
292 2016-02-25T19:18:46  <sipa> btcdrak: starttime is blocktime based, not real time; you don't need mocktime
293 2016-02-25T19:19:10  <sipa> morcos: 7575 is where i want it to be, but the logic should also go in bip9
294 2016-02-25T19:19:31  <gmaxwell> petertodd: I think it's OKAY for it to be relatively near the release. considering that we've survived with an effectively negative start time.
295 2016-02-25T19:19:43  <sipa> CodeSharki'll have a look at your pr to the bip again
296 2016-02-25T19:19:55  <petertodd> gmaxwell: ok, so maybe 1-2 months?
297 2016-02-25T19:20:11  <btcdrak> our roadmap FAQ tentatively pencilled BIP68,112,113 for March.
298 2016-02-25T19:20:14  <sipa> sdaftuar: if tests still fails, the pr is certainly not where it should be regarding tests
299 2016-02-25T19:20:31  <morcos> petertodd: i'm not following, you think you shouldn't be able to start soft fork activation for 1-2 months after code release?
300 2016-02-25T19:20:53  <morcos> why not? at 95% miner threshold and with innocous soft forks, it should be ok to do it sooner.
301 2016-02-25T19:20:56  <CodeShark> We need to start getting into the habit of publishing less optimistic schedules ;)
302 2016-02-25T19:21:14  <morcos> maybe something a bit more invasive (like segwit) then you could put a couple 1000 block delay
303 2016-02-25T19:21:15  <gmaxwell> morcos: ideally nodes are updated first, though it's not strictly needed.
304 2016-02-25T19:21:15  <petertodd> morcos: yes, that's gmaxwell's argument, to give non-miners some time to upgrade their nodes (even in a soft-fork that's a good thing)
305 2016-02-25T19:21:26  <btcdrak> morcos: we want to avoid the situation we had with CLTV where f2pool were mining v4 blocks before we'd actually released the code.
306 2016-02-25T19:21:26  <gmaxwell> morcos: because you want them rejecting any blocks from that 5% that are not valid.
307 2016-02-25T19:21:35  <CodeShark> However long you think anything could reasonably take, double it for public expectations
308 2016-02-25T19:21:45  <petertodd> morcos: one argument for it, is it can be done in about one line of code - cheap protection
309 2016-02-25T19:22:13  <petertodd> CodeShark: yeah, so a practical problem, is you'd be changing unit tests right up until the last minute pre-release
310 2016-02-25T19:22:35  <petertodd> CodeShark: a grace period - if it could be implemented easily enough - is better in that regard as it's defined from after the point at which the fork activates
311 2016-02-25T19:22:50  <morcos> petertodd: i'm mostly just thinking about making changes take even longer..  and also perhaps losing attention focused on what's happening...   oh maybe i'm misunderstanding.  you could signal for it immediately, but it couldn't activate until start time
312 2016-02-25T19:22:53  <petertodd> CodeShark: less important if the minimum start time is far into the future, but 1-2 months isn't
313 2016-02-25T19:22:54  <morcos> that might be good
314 2016-02-25T19:23:04  <petertodd> morcos: yeah, 100% ok to signal immediately
315 2016-02-25T19:23:05  <btcdrak> petertodd: I think we get the PR into a mergable state, once agreed (and decided on deployment of code), we can set the start date for a reasonable amount of time into the future.
316 2016-02-25T19:23:38  <petertodd> btcdrak: well, so long as we can co-ordinate that with the bitcoin core release schedule - which admittedly is much easier if we continue to do that in minor version releases
317 2016-02-25T19:23:51  <btcdrak> petertodd: exactly.
318 2016-02-25T19:24:15  <petertodd> alright, ack 1-2 month min start time
319 2016-02-25T19:25:30  <btcdrak> wumpus: I would caution any merging consensus refactoring PRs until we get the sf code emerged. It will make backporting to 0.12 easier and easier to verify (basically an easy cherrypick).
320 2016-02-25T19:26:28  <petertodd> btcdrak: I suggest we buy jtimom a time machine so he can do his refactors in the past :)
321 2016-02-25T19:26:40  <petertodd> *jtimon
322 2016-02-25T19:28:52  <gmaxwell> Any other topics? (we can discuss BIP9 more out of meeting and maybe when sipa has better connectivity?
323 2016-02-25T19:29:04  <sipa> i'm going afk now; i'll look at bip9 and 7575 and tests next week
324 2016-02-25T19:30:02  <petertodd> I'm working on a tech writeup re: HK
325 2016-02-25T19:30:46  <warren> FYI: probably need to be ready to analyze and act on https://mta.openssl.org/pipermail/openssl-announce/2016-February/000063.html if necessary
326 2016-02-25T19:31:35  <petertodd> warren: interesting!
327 2016-02-25T19:31:38  <gmaxwell> #topic openssl drama again
328 2016-02-25T19:31:54  <gmaxwell> our response needs to get openssl out of the software to the greatest extent possible. It's already out of consensus, it's close to out of bitcoind.
329 2016-02-25T19:32:37  <gmaxwell> The only thing we don't have an answer for is payment protocol, and the feedback I'm getting is that PP is virtually unused esp in core. We could consider making PP off by default and have a setting in the UI to enable it.
330 2016-02-25T19:32:54  <petertodd> gmaxwell: and fortunately, PP isn't consensus critical, which helps a bit
331 2016-02-25T19:33:04  <morcos> oh so i don't need to ever bother figuring out what PP is?
332 2016-02-25T19:33:10  <petertodd> morcos: payment protocol
333 2016-02-25T19:33:16  <gmaxwell> petertodd: still means we need to roll emergency updates for serious openssl vulnerabilties.
334 2016-02-25T19:33:27  <morcos> i just mean i haven't looked at the code
335 2016-02-25T19:33:43  <warren> Does anyone use rpcssl?
336 2016-02-25T19:33:44  *** jtimon has joined #bitcoin-core-dev
337 2016-02-25T19:33:46  <petertodd> gmaxwell: interesting question re: PP - does the average install of Bitcoin Core's qt wallet actually let people click on a PP link and have their wallet pop up? if not, strongly suggests it isn't being used much
338 2016-02-25T19:33:49  <gmaxwell> It's written in QT, uses QT for HTTP.
339 2016-02-25T19:33:52  <gmaxwell> warren: thats gone.
340 2016-02-25T19:33:56  <warren> oh good
341 2016-02-25T19:34:22  <gmaxwell> petertodd: I know nothing about windows packaging. I did believe we installed a URL handler.
342 2016-02-25T19:35:24  <gmaxwell> If PP continues in the long run it should be process seperated at least, I tried to do this before (and also to make it useful from cli/rpc) but the implementation was such that it didn't lend itself to that.
343 2016-02-25T19:35:24  <petertodd> gmaxwell: we can always do a release where you need a command line flag to enable it and see if anyone notices :)
344 2016-02-25T19:35:56  <gmaxwell> petertodd: thats kind of what I was thinking with the GUI option too "If you've turned this on, please report to..."
345 2016-02-25T19:36:32  <petertodd> also, PP w/o multisig has somewhat dubious advantages right now, and even with multisig I'm not sure there are any wallets that really do it well
346 2016-02-25T19:37:16  <petertodd> more likely that PP will have worse CA verification than your browser, which benefits from the massive amount of work done to make SSL secure in the face of bad cert authorities
347 2016-02-25T19:38:15  <CodeShark> PP is dumb
348 2016-02-25T19:38:50  <petertodd> CodeShark: eh, it goes in the right direction, it's just not so useful in the current environment
349 2016-02-25T19:39:36  <CodeShark> silly to try to specify it when so many more fundamental things still aren't solved ;)
350 2016-02-25T19:39:56  <petertodd> CodeShark: in the far future I'd be surprised if we aren't using something like PP for all txs, probably on a mandatory basis (but I assume treechains will eventually happen!)
351 2016-02-25T19:40:02  <gmaxwell> Okay any other topics?
352 2016-02-25T19:41:02  <gmaxwell> Otherwise, I'm going to call the end.
353 2016-02-25T19:41:15  <petertodd> ack
354 2016-02-25T19:41:18  <gmaxwell> #endmeeting
355 2016-02-25T19:41:18  <lightningbot> Meeting ended Thu Feb 25 19:41:18 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
356 2016-02-25T19:41:18  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-02-25-19.01.html
357 2016-02-25T19:41:18  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-02-25-19.01.txt
358 2016-02-25T19:41:18  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-02-25-19.01.log.html
359 2016-02-25T19:41:21  <gmaxwell> thanks everyone.
360 2016-02-25T19:41:25  <btcdrak> thank you!
361 2016-02-25T19:41:28  <paveljanik> Let's celebrate #400000 :-)
362 2016-02-25T19:41:37  <jonasschnelli> \o/
363 2016-02-25T19:41:44  <morcos> and hope we make it to 500000
364 2016-02-25T19:41:57  <sdaftuar> if we're lucky we'll get lots of 500000's
365 2016-02-25T19:42:02  <petertodd> paveljanik: why? why not celibrate an important number like 524288?
366 2016-02-25T19:42:05  <btcdrak> LOL
367 2016-02-25T19:42:18  <paveljanik> sdaftuar, ;-)
368 2016-02-25T19:42:36  <paveljanik> sdaftuar, so many to choose from :-)
369 2016-02-25T19:43:30  <petertodd> paveljanik: I'm also partial to 0x6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000
370 2016-02-25T19:44:13  <paveljanik> sdaftuar, maybe we can patch UI to help user to select from all #500000s ;-)
371 2016-02-25T19:45:59  *** achow101 has quit IRC
372 2016-02-25T19:48:35  <sdaftuar> paveljanik: :)
373 2016-02-25T19:51:05  *** belcher has joined #bitcoin-core-dev
374 2016-02-25T19:52:09  <CodeShark> petertodd: my comment regarding PP is not to be understood to mean such layers aren't necessary...but that I think such specification is premature
375 2016-02-25T19:53:23  <CodeShark> It's sorta like trying to specify ssl before we've even specified tcp
376 2016-02-25T20:07:27  <zooko> Does the payment protocol use Bitcoin private (signing) keys?
377 2016-02-25T20:07:56  <jtimon> petertodd: lol, actually you guys need the time machine to review my code in the past, most of what's in https://github.com/jtimon/bitcoin/tree/libconsensus-p3 / https://github.com/jtimon/bitcoin/tree/jt I had coded in some way or another for long (although I constantly rewrite history to try to have the "most mergeable things" as the first commits)
378 2016-02-25T20:09:52  <jtimon> btcdrak: fwiw all my consensus PRs merged since 0.12 's fork are already backported (with anything that would make the rebase less clean) in https://github.com/jtimon/bitcoin/tree/backports-0.12 in case they were necessary for backporting SF functionality
379 2016-02-25T20:10:17  <btcdrak> jtimon: great.
380 2016-02-25T20:11:29  <sipa> zooko: no
381 2016-02-25T20:11:36  <sipa> it uses ssl :(
382 2016-02-25T20:12:37  <zooko> Great, so no matter how badly screwed up this new openssl announcement is, openssl isn't being given the opportunity to touch Bitcoin signing keys.
383 2016-02-25T20:12:41  <zooko> In current Bitcoin core.
384 2016-02-25T20:13:06  <zooko> Although I fully agree that "No openssl anywhere near our codebase" is a desirable goal.
385 2016-02-25T20:14:17  <paveljanik> zooko, who created them then? ;-)
386 2016-02-25T20:17:08  <jtimon> CodeShark: when I first reviewed your BIP9 implementation I first complained aboutthe start time but then reading the code more was convinced that it could actually simplify the implementation, after implementing it myself, I realized it does not simplify things, but it's just a couple of extra lines for a very reaonable feature (specially needed if we are ever going to use versionbits for hardfork deployment as recommended by
387 2016-02-25T20:17:08  <jtimon> bip99 anyway)
388 2016-02-25T20:17:42  <jtimon> I feel sorry for you that it wasn't incorporated to spec at the time
389 2016-02-25T20:19:40  <jtimon> sipa starttime is block.nTime based? we're using median time for the timeout
390 2016-02-25T20:20:39  *** treehug88 has quit IRC
391 2016-02-25T20:22:26  <sipa> jtimon: yes, mediantimepast
392 2016-02-25T20:22:45  <sipa> jtimon: i mean it is not based on the real clock time, it deoends on the block chain only
393 2016-02-25T20:23:57  <btcdrak> I can't believe I missed the start time detail
394 2016-02-25T20:25:34  *** zooko has quit IRC
395 2016-02-25T20:26:31  <jtimon> btw, my wip bip9 implementation is #7566 I started before sipa but got distracted maximizing its libconsensus friendly-ness and...sipa codes faster than me
396 2016-02-25T20:27:18  <jtimon> in any case, it seems we're both copying a little bit of code from one another since we found out we were both working on it
397 2016-02-25T20:48:13  <GitHub136> [bitcoin] sdaftuar opened pull request #7600: [WIP] Mining: Select transactions using feerate-with-ancestors (master...ancestor-mining) https://github.com/bitcoin/bitcoin/pull/7600
398 2016-02-25T20:50:25  *** Guyver2 has joined #bitcoin-core-dev
399 2016-02-25T20:52:10  <instagibbs> what's the correct way to flush the wallet db? I'm "zapping" individual transactions and internal accounting doesn't realize this until I shut down and start back up.
400 2016-02-25T20:53:23  <jonasschnelli> instagibbs: hmm... could be a bud. Can you explain how you do a "zapping"?
401 2016-02-25T20:53:27  <jonasschnelli> bug
402 2016-02-25T20:53:36  <sipa> instagibbs: what do you mean by flush?
403 2016-02-25T20:54:40  <GitHub141> [bitcoin] ebfull opened pull request #7601: [WIP] HTLC implementation in the wallet (master...zkcp) https://github.com/bitcoin/bitcoin/pull/7601
404 2016-02-25T20:55:22  <instagibbs> jonasschnelli, I'm rolling my own, which is probably why it's my fault. I'm calling EraseTx.
405 2016-02-25T20:55:58  <instagibbs> i run my code, check listunspent/listreceivedbyX, transactions are still there. If I shut down, start back up, they're gone.
406 2016-02-25T20:56:23  <jonasschnelli> call `void CWallet::MarkDirty()`=
407 2016-02-25T20:56:29  <jonasschnelli> s/=/?
408 2016-02-25T20:56:31  <instagibbs> ah the whole wallet?
409 2016-02-25T20:56:33  <instagibbs> makes sense
410 2016-02-25T20:57:02  <jonasschnelli> hmm... but you can't marke the erased wtx as dirty. :)... not sure if it works.
411 2016-02-25T20:57:20  <instagibbs> heh, ill test
412 2016-02-25T20:57:34  <sipa> if you erase a tx, you need to dirty all the transactions that it's spending coins from
413 2016-02-25T20:57:46  <jonasschnelli> Wait... you only call EraseTx?!
414 2016-02-25T20:57:53  <jonasschnelli> You also need to remove it from the in memory map
415 2016-02-25T20:58:12  <instagibbs> that could definitely explain it yes
416 2016-02-25T20:58:16  <sipa> the mempool?
417 2016-02-25T20:58:20  <jonasschnelli> no... :)
418 2016-02-25T20:58:30  <jonasschnelli> mapWallet
419 2016-02-25T20:58:39  <jonasschnelli> <const uint256, CWalletTx>
420 2016-02-25T20:58:47  <sipa> i was assuming that that's exactly what EraseTx does
421 2016-02-25T20:58:54  <instagibbs> nope from the wallet itself
422 2016-02-25T20:59:03  <instagibbs> ZapWalletTxns calls it on aLL THE THINGS
423 2016-02-25T20:59:05  <sipa> oh, from the database?
424 2016-02-25T20:59:12  <sipa> the database has no effect on runtime
425 2016-02-25T20:59:15  <jonasschnelli> probably you should do: 1. remove from mapWallet, 2. remove from DB (eraseTx), mark whole wallet as dirty
426 2016-02-25T20:59:20  <sipa> we only read from it at startup
427 2016-02-25T20:59:25  <instagibbs> i see ok cool
428 2016-02-25T20:59:27  <instagibbs> so yeah
429 2016-02-25T20:59:29  <instagibbs> map
430 2016-02-25T20:59:34  <instagibbs> thanks jonasschnelli i think that'll do it
431 2016-02-25T20:59:46  <jonasschnelli> And PR your work. We need a runtime zap wallet tx functionality!
432 2016-02-25T20:59:51  <instagibbs> I know!
433 2016-02-25T21:00:00  <instagibbs> belcher was bitching about it in pruned mode :)
434 2016-02-25T21:00:13  <instagibbs> and i coded the reverse(importprunedfunds), so figured i should do it
435 2016-02-25T21:00:25  <belcher> to clarify, i was not bitching
436 2016-02-25T21:00:35  <jonasschnelli> yes. You probably can't zap in prune because of missing rescan functionality
437 2016-02-25T21:00:44  <jonasschnelli> belcher: lol
438 2016-02-25T21:00:46  <instagibbs> ;)
439 2016-02-25T21:01:32  <instagibbs> jonasschnelli, right, you can't do that zap, so im making no-rescan equiv
440 2016-02-25T21:02:30  <jonasschnelli> instagibbs: also keep an eye on the "abandontransaction" RPC function
441 2016-02-25T21:02:57  <jonasschnelli> Could be saver for most usecases then just zapping.
442 2016-02-25T21:22:09  *** drnet has joined #bitcoin-core-dev
443 2016-02-25T21:32:57  *** Guyver2 has quit IRC
444 2016-02-25T21:34:15  *** drnet has quit IRC
445 2016-02-25T21:41:59  <GitHub22> [bitcoin] instagibbs opened pull request #7602: [WIP] [RPC] Add call zaptransaction to delete transaction from wallet (master...zaponetx) https://github.com/bitcoin/bitcoin/pull/7602
446 2016-02-25T21:43:09  *** danielsocials has joined #bitcoin-core-dev
447 2016-02-25T21:48:03  *** danielsocials has quit IRC
448 2016-02-25T21:49:40  <jtimon> sipa btcdrak I was going to comment on https://github.com/sipa/bitcoin/commit/99f66325e83f8da3b5dfe38cad4f5fdc60bca05a#commitcomment-16313065 but I thought IRC could be more appropriate:
449 2016-02-25T21:49:40  <jtimon> See my other comment bike-shedding the enumerator.
450 2016-02-25T21:49:40  <jtimon> I think it makes a lot of sense that BIP68 and BIP112 are deployed together (in fact, I would have been happy if they had been a single BIP), but I'm not so sure about BIP113.
451 2016-02-25T21:49:40  <jtimon> @petertodd mentioned that BIP68 required more testing and that's why I went with BIP113 in my implementation (although I'm happy to change it to something else and that will probably mean less code in my PR).
452 2016-02-25T21:49:40  <jtimon> Assuming BIP9 was reviewed, tested and ready for merge, what would be the BIPs from this 3 that are ready to be deployed right now (modulo backports)?
453 2016-02-25T21:49:42  <jtimon> 
454 2016-02-25T21:53:13  <jtimon> BIP113 is ready, right? or do we plan to wait some more time of it being deployed as relay policy ?
455 2016-02-25T21:55:12  <midnightmagic> I really like this, from the OpenSSL team: "You can not pay us to get security patches in advance."
456 2016-02-25T21:55:17  <midnightmagic> good for them.
457 2016-02-25T21:56:40  *** zooko has joined #bitcoin-core-dev
458 2016-02-25T22:01:26  *** jujumax has joined #bitcoin-core-dev
459 2016-02-25T22:04:33  *** AaronvanW_ has quit IRC
460 2016-02-25T22:12:18  *** Expanse has joined #bitcoin-core-dev
461 2016-02-25T22:30:16  *** MarcoFalke has quit IRC
462 2016-02-25T22:51:34  *** Thireus1 has quit IRC
463 2016-02-25T22:52:33  *** Thireus has joined #bitcoin-core-dev
464 2016-02-25T23:03:41  *** laurentmt has joined #bitcoin-core-dev
465 2016-02-25T23:17:07  *** Chris_Stewart_5 has joined #bitcoin-core-dev
466 2016-02-25T23:28:31  *** AaronvanW has joined #bitcoin-core-dev
467 2016-02-25T23:28:32  *** AaronvanW has quit IRC
468 2016-02-25T23:28:32  *** AaronvanW has joined #bitcoin-core-dev
469 2016-02-25T23:29:37  *** randy-waterhouse has joined #bitcoin-core-dev
470 2016-02-25T23:40:23  <jtimon> sipa sorry for the bunch of comments in #7575, I edited some of them to make clear they are not very important
471 2016-02-25T23:40:24  <jtimon> the difference between my implementation and yours that worries me the most is https://github.com/bitcoin/bitcoin/pull/7575/files#r54179238
472 2016-02-25T23:41:34  <gmaxwell> midnightmagic: the last time they did one of these timed code dumps they also had run the code through a reformat so it was impossible to easily tell what they changed.
473 2016-02-25T23:44:33  *** danielsocials has joined #bitcoin-core-dev
474 2016-02-25T23:47:33  <jtimon> one test case comes to mind that my explain my point better: my implementation should be fine if you have if you schedule 3 different deployments for the same bit on the same date (or in three consecutive days), even if each of them takes 3 months to be deployed (the other ones will just wait)
475 2016-02-25T23:48:20  <jtimon> sipa I believe your implementation would currently fail that test (assuming the test is properly implemented)
476 2016-02-25T23:49:33  <jtimon> I'm not sure I'm explaining myself...
477 2016-02-25T23:54:12  <jtimon> but sipa is probably busy, so, never mind, I will maintain the "can queue new deployments on utilized bits without knowing when the previous started deployments on that bit will be activated" feature in mind for now, even if I still don't see a clean wait of making that feature with nicely separating the warning code (while still reusing a lot of code) like you've done
478 2016-02-25T23:57:29  *** danielsocials has quit IRC
479 2016-02-25T23:57:33  <jtimon> in the meantime, I think I will decouple my PR from BIP113 (I don't know why #7565 is currently failing in travis anyway, but doesn't inspire confidence) and use BIP112 as example as well
480 2016-02-25T23:59:41  <jtimon> I guess I should also decouple it from the two first commits in #7563 as well to make it easier to review and compare with #7575