1 2016-03-10T00:15:56  *** zooko has joined #bitcoin-core-dev
  2 2016-03-10T00:25:11  *** ghtdak has joined #bitcoin-core-dev
  3 2016-03-10T00:34:22  *** arowser has quit IRC
  4 2016-03-10T00:34:53  *** arowser has joined #bitcoin-core-dev
  5 2016-03-10T00:38:54  *** Don_John has joined #bitcoin-core-dev
  6 2016-03-10T00:43:56  *** anchow101 has joined #bitcoin-core-dev
  7 2016-03-10T00:44:36  *** frankenmint has joined #bitcoin-core-dev
  8 2016-03-10T00:45:07  *** Arnavion has quit IRC
  9 2016-03-10T00:45:11  *** Arnavion3 has joined #bitcoin-core-dev
 10 2016-03-10T00:45:15  *** Arnavion3 is now known as Arnavion
 11 2016-03-10T00:45:43  *** jl2012_ has joined #bitcoin-core-dev
 12 2016-03-10T00:45:43  *** ibrightly_ has joined #bitcoin-core-dev
 13 2016-03-10T00:49:08  *** Alopex has quit IRC
 14 2016-03-10T00:49:08  *** jl2012 has quit IRC
 15 2016-03-10T00:49:08  *** ibrightly has quit IRC
 16 2016-03-10T00:49:08  *** aknix has quit IRC
 17 2016-03-10T00:49:08  *** achow101 has quit IRC
 18 2016-03-10T00:49:08  *** cfields has quit IRC
 19 2016-03-10T00:49:09  *** cfields_ has joined #bitcoin-core-dev
 20 2016-03-10T00:49:10  *** jl2012_ is now known as jl2012
 21 2016-03-10T00:49:16  *** ibrightly_ is now known as ibrightly
 22 2016-03-10T00:50:39  *** aknix has joined #bitcoin-core-dev
 23 2016-03-10T00:54:09  *** Alopex has joined #bitcoin-core-dev
 24 2016-03-10T01:12:10  *** Don_John has joined #bitcoin-core-dev
 25 2016-03-10T01:17:31  *** Arnavion has quit IRC
 26 2016-03-10T01:17:40  *** Arnavion has joined #bitcoin-core-dev
 27 2016-03-10T01:19:59  *** grassass has quit IRC
 28 2016-03-10T01:22:22  *** fengling has joined #bitcoin-core-dev
 29 2016-03-10T01:35:41  *** zooko has quit IRC
 30 2016-03-10T02:00:58  *** Ylbam has quit IRC
 31 2016-03-10T02:12:48  *** Giszmo has quit IRC
 32 2016-03-10T02:12:55  *** Giszmo has joined #bitcoin-core-dev
 33 2016-03-10T02:32:24  *** belcher has quit IRC
 34 2016-03-10T02:44:22  *** zooko has joined #bitcoin-core-dev
 35 2016-03-10T02:45:09  *** justanotheruser has quit IRC
 36 2016-03-10T02:46:30  *** justanotheruser has joined #bitcoin-core-dev
 37 2016-03-10T02:58:49  *** zooko has quit IRC
 38 2016-03-10T03:00:09  *** wallet42 has joined #bitcoin-core-dev
 39 2016-03-10T03:21:28  *** murr4y has quit IRC
 40 2016-03-10T03:21:58  *** AtashiCon has quit IRC
 41 2016-03-10T03:23:14  *** murr4y has joined #bitcoin-core-dev
 42 2016-03-10T03:23:22  *** p15 has joined #bitcoin-core-dev
 43 2016-03-10T03:26:37  *** frankenmint has quit IRC
 44 2016-03-10T03:27:14  *** p15 has quit IRC
 45 2016-03-10T03:27:27  *** p15 has joined #bitcoin-core-dev
 46 2016-03-10T03:33:01  *** Alopex has quit IRC
 47 2016-03-10T03:34:06  *** Alopex has joined #bitcoin-core-dev
 48 2016-03-10T03:37:16  *** anchow101 has quit IRC
 49 2016-03-10T03:43:14  *** mrkent has joined #bitcoin-core-dev
 50 2016-03-10T03:55:55  <GitHub50> [bitcoin] jtimon opened pull request #7665: Contrib: Introduce script to tag compiled binaries for convenience (py) (master...0.12.99-contrib-tag) https://github.com/bitcoin/bitcoin/pull/7665
 51 2016-03-10T04:12:43  *** frankenmint has joined #bitcoin-core-dev
 52 2016-03-10T04:14:20  *** AtashiCon has joined #bitcoin-core-dev
 53 2016-03-10T04:14:29  *** AtashiCon has quit IRC
 54 2016-03-10T04:20:20  *** AtashiCon has joined #bitcoin-core-dev
 55 2016-03-10T04:32:49  *** murr4y has quit IRC
 56 2016-03-10T04:43:33  *** Cory has quit IRC
 57 2016-03-10T04:43:34  *** Chris_Stewart_5 has quit IRC
 58 2016-03-10T04:44:41  *** Pasha has joined #bitcoin-core-dev
 59 2016-03-10T04:51:34  *** Pasha is now known as Cory
 60 2016-03-10T04:52:51  *** nkuttler has quit IRC
 61 2016-03-10T04:55:21  *** mrkent has quit IRC
 62 2016-03-10T04:58:02  *** Alopex has quit IRC
 63 2016-03-10T04:59:07  *** Alopex has joined #bitcoin-core-dev
 64 2016-03-10T04:59:39  *** nkuttler has joined #bitcoin-core-dev
 65 2016-03-10T05:18:56  *** Giszmo has quit IRC
 66 2016-03-10T05:30:40  *** randy-waterhouse has joined #bitcoin-core-dev
 67 2016-03-10T05:40:26  *** cfields_ has quit IRC
 68 2016-03-10T05:40:27  *** anttea has quit IRC
 69 2016-03-10T05:40:27  *** Guest15994 has quit IRC
 70 2016-03-10T05:46:11  *** cfields_ has joined #bitcoin-core-dev
 71 2016-03-10T05:46:12  *** anttea has joined #bitcoin-core-dev
 72 2016-03-10T05:46:12  *** Guest15994 has joined #bitcoin-core-dev
 73 2016-03-10T05:51:23  *** rubensayshi has quit IRC
 74 2016-03-10T05:51:53  *** rubensayshi has joined #bitcoin-core-dev
 75 2016-03-10T05:58:32  *** fengling has quit IRC
 76 2016-03-10T06:00:18  *** fengling has joined #bitcoin-core-dev
 77 2016-03-10T06:02:58  *** cfields_ has quit IRC
 78 2016-03-10T06:02:58  *** anttea has quit IRC
 79 2016-03-10T06:02:59  *** Guest15994 has quit IRC
 80 2016-03-10T06:03:02  *** Alopex has quit IRC
 81 2016-03-10T06:04:07  *** Alopex has joined #bitcoin-core-dev
 82 2016-03-10T06:08:40  *** cfields_ has joined #bitcoin-core-dev
 83 2016-03-10T06:08:40  *** anttea has joined #bitcoin-core-dev
 84 2016-03-10T06:08:40  *** Guest15994 has joined #bitcoin-core-dev
 85 2016-03-10T06:36:21  *** murr4y has joined #bitcoin-core-dev
 86 2016-03-10T07:06:55  *** Tasoshi has quit IRC
 87 2016-03-10T07:16:41  *** hybridsole has quit IRC
 88 2016-03-10T07:32:01  *** Thireus has quit IRC
 89 2016-03-10T07:38:48  *** Don_John has quit IRC
 90 2016-03-10T07:45:37  *** arowser has quit IRC
 91 2016-03-10T07:45:59  *** arowser has joined #bitcoin-core-dev
 92 2016-03-10T07:53:45  *** BashCo has quit IRC
 93 2016-03-10T07:57:08  *** Thireus has joined #bitcoin-core-dev
 94 2016-03-10T07:58:24  *** Ylbam has joined #bitcoin-core-dev
 95 2016-03-10T08:24:40  *** BashCo has joined #bitcoin-core-dev
 96 2016-03-10T08:35:44  *** ibrightly has quit IRC
 97 2016-03-10T08:36:06  *** zmanian__ has quit IRC
 98 2016-03-10T08:36:13  *** binns has quit IRC
 99 2016-03-10T08:36:15  *** CodeShark has quit IRC
100 2016-03-10T08:36:39  *** NicolasDorier has quit IRC
101 2016-03-10T08:36:39  *** eragmus has quit IRC
102 2016-03-10T08:39:12  *** ibrightly has joined #bitcoin-core-dev
103 2016-03-10T08:41:13  *** zmanian__ has joined #bitcoin-core-dev
104 2016-03-10T08:41:16  *** NicolasDorier has joined #bitcoin-core-dev
105 2016-03-10T08:45:35  *** eragmus has joined #bitcoin-core-dev
106 2016-03-10T08:48:53  *** CodeShark has joined #bitcoin-core-dev
107 2016-03-10T08:50:03  *** binns has joined #bitcoin-core-dev
108 2016-03-10T09:02:30  *** frankenmint has quit IRC
109 2016-03-10T09:06:57  *** jannes has joined #bitcoin-core-dev
110 2016-03-10T09:07:51  *** chris2000 has joined #bitcoin-core-dev
111 2016-03-10T09:17:39  *** Guyver2 has joined #bitcoin-core-dev
112 2016-03-10T09:20:26  *** fredrin has quit IRC
113 2016-03-10T09:32:33  *** fredrin has joined #bitcoin-core-dev
114 2016-03-10T09:40:00  *** wallet42 has quit IRC
115 2016-03-10T09:50:27  *** MarcoFalke has joined #bitcoin-core-dev
116 2016-03-10T09:53:15  *** jtimon has quit IRC
117 2016-03-10T10:01:23  *** Tasoshi has joined #bitcoin-core-dev
118 2016-03-10T10:05:04  <GitHub191> [bitcoin] MarcoFalke opened pull request #7666: [0.12.1] Fix doc and output for rpcauth (0.12...Mf1603-012fixdocrpcauth) https://github.com/bitcoin/bitcoin/pull/7666
119 2016-03-10T10:07:55  *** randy-waterhouse has quit IRC
120 2016-03-10T10:48:57  <go1111111> so, wumpus commented on PR 7635 with "utACK after squash". As the PR author does this mean I should make another PR with the changes all squashed into one commit? or will whoever merges it squash them and I take no more action? (this is my first non-trivial PR)
121 2016-03-10T10:50:08  <MarcoFalke> git checkout docs4; git log -1
122 2016-03-10T10:50:17  *** AaronvanW has joined #bitcoin-core-dev
123 2016-03-10T10:50:24  <jonasschnelli> go1111111: squash and force push on the same branch/PR
124 2016-03-10T10:50:32  <MarcoFalke> You should not see you last commit 429
125 2016-03-10T10:50:54  <jonasschnelli> I do that with git rebase -i HEAD~X (X needs to be replace with >= amount of commits)
126 2016-03-10T10:50:59  <MarcoFalke> git rebase --interactive ed067f722a244a31809eab633fbe316028a6f80b~
127 2016-03-10T10:51:17  <MarcoFalke> and then select `f` or `s`
128 2016-03-10T10:51:21  <go1111111> ok, will do. thank you
129 2016-03-10T10:51:50  <MarcoFalke> finally git push $origin docs4 -f
130 2016-03-10T10:52:58  <go1111111> random github newb question: in the comments on that PR I referred to another branch in my repo (zmq3). it seemed like github then automatically included that branch in the PR also. which seems dangerous if I want to refer to a branch without including it. is my interpretation of how github handles that correct?
131 2016-03-10T10:53:23  <go1111111> i couldn't find that behavior documented
132 2016-03-10T10:57:14  <MarcoFalke> no, should not happen
133 2016-03-10T10:57:42  <MarcoFalke> maybe you fiddled locally with it.
134 2016-03-10T10:57:49  <MarcoFalke> Try git branch -v
135 2016-03-10T10:57:59  <MarcoFalke> to see what your branches look like locally
136 2016-03-10T11:00:13  <go1111111> ok, thanks.
137 2016-03-10T11:50:40  *** shesek has joined #bitcoin-core-dev
138 2016-03-10T12:05:18  *** p15 has quit IRC
139 2016-03-10T12:14:16  *** p15x has joined #bitcoin-core-dev
140 2016-03-10T12:14:49  *** laurentmt has joined #bitcoin-core-dev
141 2016-03-10T12:14:55  *** fredrin has quit IRC
142 2016-03-10T12:16:23  *** fredrin has joined #bitcoin-core-dev
143 2016-03-10T12:22:03  *** fredrin has quit IRC
144 2016-03-10T12:28:06  *** fredrin has joined #bitcoin-core-dev
145 2016-03-10T12:31:10  *** laurentmt has quit IRC
146 2016-03-10T12:36:27  *** blkdb has quit IRC
147 2016-03-10T12:36:34  *** arowser has quit IRC
148 2016-03-10T12:36:58  *** arowser has joined #bitcoin-core-dev
149 2016-03-10T12:37:39  *** blkdb has joined #bitcoin-core-dev
150 2016-03-10T12:45:24  *** afk11 has quit IRC
151 2016-03-10T12:46:09  *** afk11 has joined #bitcoin-core-dev
152 2016-03-10T12:46:39  *** afk11_ has joined #bitcoin-core-dev
153 2016-03-10T12:48:12  *** afk11 has quit IRC
154 2016-03-10T12:48:13  *** afk11_ has quit IRC
155 2016-03-10T12:50:50  *** afk11 has joined #bitcoin-core-dev
156 2016-03-10T12:51:20  *** afk11_ has joined #bitcoin-core-dev
157 2016-03-10T12:54:26  *** AtashiCon has quit IRC
158 2016-03-10T12:54:33  *** AtashiCon has joined #bitcoin-core-dev
159 2016-03-10T12:55:30  *** nkuttler has quit IRC
160 2016-03-10T12:55:44  *** nkuttler has joined #bitcoin-core-dev
161 2016-03-10T13:03:19  *** cj has quit IRC
162 2016-03-10T13:05:10  *** cj has joined #bitcoin-core-dev
163 2016-03-10T13:05:26  *** afk11_ has quit IRC
164 2016-03-10T13:05:26  *** afk11 has quit IRC
165 2016-03-10T13:15:04  *** fredrin has quit IRC
166 2016-03-10T13:21:51  *** afk11 has joined #bitcoin-core-dev
167 2016-03-10T13:22:22  *** afk11_ has joined #bitcoin-core-dev
168 2016-03-10T13:24:46  *** cj has quit IRC
169 2016-03-10T13:25:49  *** afk11_ has quit IRC
170 2016-03-10T13:25:49  *** afk11 has quit IRC
171 2016-03-10T13:27:32  *** fredrin has joined #bitcoin-core-dev
172 2016-03-10T13:30:05  *** Giszmo has joined #bitcoin-core-dev
173 2016-03-10T13:33:40  *** cj has joined #bitcoin-core-dev
174 2016-03-10T13:37:49  *** MarcoFalke has quit IRC
175 2016-03-10T13:41:49  *** cj has quit IRC
176 2016-03-10T13:49:13  *** hybridsole has joined #bitcoin-core-dev
177 2016-03-10T13:59:02  *** Chris_Stewart_5 has joined #bitcoin-core-dev
178 2016-03-10T14:00:49  *** p15x has quit IRC
179 2016-03-10T14:05:35  <wumpus> go1111111: should be no reason to make a new pull request  - rather not - if you need help with git just let me know
180 2016-03-10T14:06:20  <wumpus> I've listed the steps in various PRs scattered over the place, probably would make sense to add it to some developer faw
181 2016-03-10T14:06:22  <wumpus> faq
182 2016-03-10T14:11:03  *** Chris_Stewart_5 has quit IRC
183 2016-03-10T14:17:14  *** afk11 has joined #bitcoin-core-dev
184 2016-03-10T14:17:44  *** afk11_ has joined #bitcoin-core-dev
185 2016-03-10T14:18:42  *** afk11 has quit IRC
186 2016-03-10T14:18:43  *** afk11_ has quit IRC
187 2016-03-10T14:19:15  *** afk11 has joined #bitcoin-core-dev
188 2016-03-10T14:19:45  *** afk11_ has joined #bitcoin-core-dev
189 2016-03-10T14:22:09  *** afk11 has quit IRC
190 2016-03-10T14:22:45  *** afk11 has joined #bitcoin-core-dev
191 2016-03-10T14:26:48  *** afk11_ has quit IRC
192 2016-03-10T14:26:49  *** afk11 has quit IRC
193 2016-03-10T14:27:21  *** afk11 has joined #bitcoin-core-dev
194 2016-03-10T14:30:13  *** afk11 has quit IRC
195 2016-03-10T14:31:06  *** afk11 has joined #bitcoin-core-dev
196 2016-03-10T14:31:47  *** afk11 has quit IRC
197 2016-03-10T14:32:19  *** afk11 has joined #bitcoin-core-dev
198 2016-03-10T14:39:41  *** afk11 has quit IRC
199 2016-03-10T14:41:19  *** afk11 has joined #bitcoin-core-dev
200 2016-03-10T14:48:31  *** afk11 has quit IRC
201 2016-03-10T15:19:04  *** laurentmt has joined #bitcoin-core-dev
202 2016-03-10T15:29:49  *** zooko has joined #bitcoin-core-dev
203 2016-03-10T15:45:02  *** laurentmt has quit IRC
204 2016-03-10T15:49:51  *** fredrin has quit IRC
205 2016-03-10T15:50:47  *** afk11 has joined #bitcoin-core-dev
206 2016-03-10T15:50:51  *** fredrin has joined #bitcoin-core-dev
207 2016-03-10T15:55:15  *** fredrin has quit IRC
208 2016-03-10T15:57:20  *** fredrin has joined #bitcoin-core-dev
209 2016-03-10T16:10:34  *** Thireus has quit IRC
210 2016-03-10T16:20:36  *** laurentmt has joined #bitcoin-core-dev
211 2016-03-10T16:21:48  *** jtimon has joined #bitcoin-core-dev
212 2016-03-10T16:21:50  *** laurentmt has quit IRC
213 2016-03-10T16:25:47  *** BashCo has quit IRC
214 2016-03-10T16:27:52  *** laurentmt has joined #bitcoin-core-dev
215 2016-03-10T16:28:10  *** laurentmt has quit IRC
216 2016-03-10T16:38:27  *** hybridsole has quit IRC
217 2016-03-10T16:41:12  *** hybridsole has joined #bitcoin-core-dev
218 2016-03-10T16:52:13  *** wallet42 has joined #bitcoin-core-dev
219 2016-03-10T16:52:15  *** BashCo has joined #bitcoin-core-dev
220 2016-03-10T16:56:24  *** wallet42 has quit IRC
221 2016-03-10T17:05:34  *** rubensayshi has quit IRC
222 2016-03-10T17:08:45  *** Don_John has joined #bitcoin-core-dev
223 2016-03-10T17:14:09  *** achow101 has joined #bitcoin-core-dev
224 2016-03-10T17:14:29  *** Don_John has quit IRC
225 2016-03-10T17:15:06  <morcos> btcdrak: ok. i got sucked in.  i'm writing rpc/p2p tests for 68/112/113.
226 2016-03-10T17:16:27  <morcos> i'm basically taking one of your tests that tests the activation logic and modifying to try many variations of different txs before and after soft fork activates and make sure they are accepted/rejected appropriately
227 2016-03-10T17:18:18  *** rubensayshi has joined #bitcoin-core-dev
228 2016-03-10T17:19:19  *** Don_John has joined #bitcoin-core-dev
229 2016-03-10T17:38:49  *** wallet42 has joined #bitcoin-core-dev
230 2016-03-10T17:39:14  *** Thireus has joined #bitcoin-core-dev
231 2016-03-10T17:44:11  *** laurentmt has joined #bitcoin-core-dev
232 2016-03-10T17:44:21  *** laurentmt has quit IRC
233 2016-03-10T17:49:15  *** shesek has quit IRC
234 2016-03-10T17:50:29  *** Don_John has quit IRC
235 2016-03-10T17:52:24  *** Don_John has joined #bitcoin-core-dev
236 2016-03-10T17:53:39  <btcdrak> morcos: we can never have enough test :)
237 2016-03-10T17:58:02  <morcos> btcdrak: well i was letting you know in case someone else was working on them
238 2016-03-10T17:58:19  <morcos> but as far as i know we don't have any other than the unit tests so far right?
239 2016-03-10T17:58:33  *** gribble has quit IRC
240 2016-03-10T18:02:44  *** shesek has joined #bitcoin-core-dev
241 2016-03-10T18:09:31  <sipa> morcos: awesome, thanks
242 2016-03-10T18:09:55  <sipa> so what is the current state of the pull request against my bip9 pr?
243 2016-03-10T18:10:52  <sipa> i agree with you that it makes sense to have separate tests for "50% of the past N blocks have a version we don't know", and one for "an unknowm versionbits deployment is lockedin/activated"
244 2016-03-10T18:11:52  <morcos> sipa: hmm, i guess thats up to you
245 2016-03-10T18:12:09  <sipa> though the latter one should be permanent i think... if you happened to be offline during the window in which it activated, you won't ever know itherwise
246 2016-03-10T18:12:25  <morcos> what do you mean by permanent?
247 2016-03-10T18:12:30  <sipa> that was a downside we get from bit flags that expire: they are not visible forever
248 2016-03-10T18:12:53  <morcos> i guess its not clear to me how these alerts work
249 2016-03-10T18:13:02  <morcos> if you're not using QT, there is no permanent way is there?
250 2016-03-10T18:13:04  <sipa> if any vb deployment ever activated in your currently active blockchain, you get a warning
251 2016-03-10T18:13:06  *** laurentmt has joined #bitcoin-core-dev
252 2016-03-10T18:13:25  <sipa> eh, no clue what qt does
253 2016-03-10T18:13:33  <morcos> so right now that strMiscWarning isn't displayed in the errors field
254 2016-03-10T18:13:38  <morcos> i don't think
255 2016-03-10T18:13:48  <sipa> hmm?
256 2016-03-10T18:14:08  <morcos> so the errors that are printed in getInfo won't include this
257 2016-03-10T18:14:11  <morcos> i think
258 2016-03-10T18:14:14  <morcos> even for ISM soft forks
259 2016-03-10T18:14:23  *** skyraider has joined #bitcoin-core-dev
260 2016-03-10T18:14:25  <morcos> the only way you see it is if you look at your debug log
261 2016-03-10T18:14:33  <morcos> or if you're using QT or the -alertnotify script
262 2016-03-10T18:14:49  <sipa> what?
263 2016-03-10T18:14:52  <sipa> really?
264 2016-03-10T18:15:00  <morcos> maybe?
265 2016-03-10T18:15:08  <sipa> well, i have no counterevidence
266 2016-03-10T18:15:32  *** laurentmt has quit IRC
267 2016-03-10T18:15:39  <sipa> so i think that needs investigating
268 2016-03-10T18:15:49  <morcos> maybe i taket hat back
269 2016-03-10T18:15:52  <morcos> sorry, let me see
270 2016-03-10T18:16:59  <morcos> yeah i think thats right
271 2016-03-10T18:17:09  <morcos> look at GetWarnngs in main.cpp
272 2016-03-10T18:17:23  <morcos> strRPC isn't updated by strMiscWarning
273 2016-03-10T18:17:35  <sipa>  heh
274 2016-03-10T18:17:46  <sipa> that variable name does not even look familiar to me
275 2016-03-10T18:17:54  *** frankenmint has joined #bitcoin-core-dev
276 2016-03-10T18:18:58  <morcos> i also find it a bit disturbing that one warning can wipe out another
277 2016-03-10T18:19:37  <sipa> i doubt i have ever looked at that code
278 2016-03-10T18:20:40  <morcos> so for instance if PartitionCheck causes "abnormally high number of blocks" that wipes out your warning that a soft fork has activated
279 2016-03-10T18:20:58  <morcos> and even in the ISM code, that warning only happens once
280 2016-03-10T18:24:09  <morcos> so....  i'm going to quietly slink away and go back to my test writing...
281 2016-03-10T18:24:34  *** zooko has quit IRC
282 2016-03-10T18:26:20  <sipa> we should probably concatenate all warnings...
283 2016-03-10T18:26:27  <sipa> and have a boolean for "serious" or so
284 2016-03-10T18:26:59  <sipa> that can make RPCs fail or the GUI show bigger animated themed warning boxes
285 2016-03-10T18:27:08  <morcos> yeah i think the quick and dirty way is to have separate variables though for each of the warnings
286 2016-03-10T18:27:25  <morcos> b/c some occur repeatedly or can get cleared out or whatever
287 2016-03-10T18:27:39  <morcos> and then the display mechanism can check each one and do the right thing?
288 2016-03-10T18:27:58  <sipa> yeah
289 2016-03-10T18:28:55  <morcos> i guess it wouldn't be that hard to just have a set of strings, and then you can clear them to
290 2016-03-10T18:28:56  <sipa> anyway, the point i was trying to make (and which is independent of the warning presentation problem) is that imho a versionbits deployment from anywhere in your past should remain visible (but probably should not be considered serious)
291 2016-03-10T18:29:21  <morcos> wait, an unknown one should not be considered serious?
292 2016-03-10T18:30:31  <gmaxwell> Meeting in half an hour, everyone should think back to all the great topics we ran out of time for last week and have them ready for the agenda this time.
293 2016-03-10T18:31:43  <morcos> sipa: i suppose what we could do is everytime you start the node we rescan for unknown deployments from the beginning (which would speak to using a real cache)..  b/c otherwise there is a risk that you shutdown your old node and when you restart it you've lost the warning, is that what you meant?
294 2016-03-10T18:32:00  <sipa> morcos: i think that the presence of an unknown softfork should not be treated as something serious
295 2016-03-10T18:32:18  <sipa> morcos: or just have a versionbits cache per bit for warnings
296 2016-03-10T18:32:24  <sipa> without special logic
297 2016-03-10T18:32:39  <morcos> sipa: yes thats what i meant by speaking to using a real cache
298 2016-03-10T18:32:48  <morcos> perhaps its worth the 300k extra memory
299 2016-03-10T18:32:58  <morcos> but why isn't it serious?
300 2016-03-10T18:33:04  *** jgarzik has quit IRC
301 2016-03-10T18:33:06  <morcos> i think it should be considered quite serious
302 2016-03-10T18:33:23  <morcos> we have in the past, we told you your node was obsolete and you must upgrade
303 2016-03-10T18:33:42  <morcos> there is no way to know whether the soft fork was relatively benign or not
304 2016-03-10T18:34:08  <morcos> but if we give the information on the bit/activation height, then it should be easy for people to look up that soft fork, and decide for themselves whether they care
305 2016-03-10T18:34:29  <morcos> but to suhas's point, thats why its important to be able to warn on the same bit more than once?
306 2016-03-10T18:35:51  <sipa> hmm
307 2016-03-10T18:35:59  <sipa> maybe i misunderstood the code
308 2016-03-10T18:36:15  <sipa> it seemed to me that it would not catch historical deployments
309 2016-03-10T18:37:33  <morcos> my code will catch historical deployments but only once
310 2016-03-10T18:37:47  <morcos> i mean once per each deployment, will catch multiple on the same bit
311 2016-03-10T18:37:55  *** gribble has joined #bitcoin-core-dev
312 2016-03-10T18:41:42  *** frankenmint has quit IRC
313 2016-03-10T18:49:49  *** kangx_ has joined #bitcoin-core-dev
314 2016-03-10T18:50:57  *** mrkent has joined #bitcoin-core-dev
315 2016-03-10T18:52:24  <morcos> so sipa, i think if it were me, i'd just change my PR to run on start up on the entire blockchain, instead of actually populating a cache that is mostly usless and whose only effect is to obscure multiple deployments on the same bit
316 2016-03-10T18:53:46  *** laurentmt has joined #bitcoin-core-dev
317 2016-03-10T18:54:25  *** zooko has joined #bitcoin-core-dev
318 2016-03-10T18:55:37  *** jcorgan has joined #bitcoin-core-dev
319 2016-03-10T18:55:49  <sipa> ok
320 2016-03-10T18:56:51  <gmaxwell> sipa: morcos: sdaftuar: petertodd: btcdrak: wumpus: cfields_: jonasschnelli: phantomcircuit: BlueMatt: jtimon: CodeShark: NicolasDorier: paveljanik:  meetin in 4 minutes.
321 2016-03-10T18:56:58  <jonasschnelli> here!
322 2016-03-10T18:56:58  <BlueMatt> ahhhhhh
323 2016-03-10T18:57:00  <BlueMatt> taggggggg
324 2016-03-10T18:57:05  <btcdrak> present!
325 2016-03-10T18:57:27  <wumpus> yep
326 2016-03-10T18:57:37  <sipa> here
327 2016-03-10T18:57:46  <warren> here
328 2016-03-10T18:57:48  <morcos> sipa: so do you want me to make changes?
329 2016-03-10T18:57:54  <btcdrak> it's like being in school again :)
330 2016-03-10T18:58:26  <sipa> morcos: go ahead
331 2016-03-10T18:58:34  <jcorgan> not invited but still here :-)
332 2016-03-10T18:58:34  <gmaxwell> (sorry to ping, but we've had slow starts and time shortfalls recently)
333 2016-03-10T18:59:46  *** frankenmint has joined #bitcoin-core-dev
334 2016-03-10T18:59:59  <wumpus> #startmeeting
335 2016-03-10T18:59:59  <lightningbot> Meeting started Thu Mar 10 18:59:59 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
336 2016-03-10T18:59:59  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
337 2016-03-10T19:00:03  <wumpus> topics?
338 2016-03-10T19:00:23  <evoskuil> here
339 2016-03-10T19:01:05  <morcos> we have a list of remaining segwit items that were written on whiteboard at MIT...  should we assign those?
340 2016-03-10T19:01:16  <wumpus> sure
341 2016-03-10T19:01:18  * sipa hides
342 2016-03-10T19:01:24  *** mm_1 has quit IRC
343 2016-03-10T19:01:25  * btcdrak locked the door
344 2016-03-10T19:01:44  <wumpus> #topic remaining segwit items
345 2016-03-10T19:01:56  <jonasschnelli> I'm happy to help,... probably in the wallet section.
346 2016-03-10T19:02:05  <morcos> seems to me it would nice to buckle down and prioritize  BIP 9,  BIPs 68,112,113  ,   segwit.   i mean i think we are all working on those things, but there is still more to do on all of them
347 2016-03-10T19:02:06  <sipa> my plan was to rebase segwit on top of bip9, add the rewind logic to continie after post-softfork uograde, and do a new testnet
348 2016-03-10T19:02:10  <sipa> eh, new segnet
349 2016-03-10T19:02:21  <btcdrak> great
350 2016-03-10T19:02:33  <CodeShark> when do you think to deploy the new testnet?
351 2016-03-10T19:02:40  <sdaftuar> we also need to discuss standardness rules
352 2016-03-10T19:02:50  <sdaftuar> (or rather, propose and discuss)
353 2016-03-10T19:02:55  <warren> What was decided for safety on the edge of the rule change in case of reorg?
354 2016-03-10T19:03:45  <morcos> I think my suggestion would be to push that problem to wallet users
355 2016-03-10T19:03:49  <sdaftuar> warren: i believe we decided to advise wallet authors to wait some time after segwit activates before using
356 2016-03-10T19:03:51  <sipa> one possibility is not enabling relay/mempool logic for segwit transactions until 2 period after activatation
357 2016-03-10T19:03:56  <morcos> yes authors i meant
358 2016-03-10T19:04:04  <gmaxwell> warren: I don't understand the context of your question.  Generall new soft fork rules should not be used immediately.
359 2016-03-10T19:04:14  <sipa> another is to just be cautious and nit enable the functionality in wallets until a post segwit release
360 2016-03-10T19:04:15  <sdaftuar> gmaxwell: this one is more dangerous than usual though
361 2016-03-10T19:04:24  <gmaxwell> sdaftuar: it's just like p2sh.
362 2016-03-10T19:04:29  <warren> OK, that seems adequate enough.
363 2016-03-10T19:04:42  <CodeShark> I'm not that concerned about edge case reorg situations
364 2016-03-10T19:04:55  <morcos> gmaxwell: its a bit riskier than p2sh...  don't need a preimage
365 2016-03-10T19:04:55  <sipa> it's not situation*s*
366 2016-03-10T19:05:08  <gmaxwell> in core I would recommend that we would switch to using segwit as default in a subsiquent release after the SF activates.
367 2016-03-10T19:05:40  <jonasschnelli> so have it ready and auto-use it whiteout creating another release?
368 2016-03-10T19:06:00  <morcos> so in any case, i think we just advise wallet authors to wait some minimum amount of time after activation to send segwit txs.. they are already going to have to put in some code to wait until it activates
369 2016-03-10T19:06:00  <jonasschnelli> *without
370 2016-03-10T19:06:01  <CodeShark> either wait until next release - or wait a few blocks after activation before enabling it in wallet
371 2016-03-10T19:06:11  <sipa> ok
372 2016-03-10T19:06:43  <jonasschnelli> auto-enable in in the wallet after 95%?
373 2016-03-10T19:06:47  <gmaxwell> no.
374 2016-03-10T19:06:57  <btcdrak> I think better to wait a release code afterwards
375 2016-03-10T19:06:58  <sipa> not even at 100%
376 2016-03-10T19:07:19  <jonasschnelli> Okay. Then do it over the release-cycle..
377 2016-03-10T19:07:31  <gmaxwell> I recommend using a release. Automatic behavior is not needed here. Also-- it's a pretty big behavioral change to use it, e.g. you'd be issuing other address styles in response.
378 2016-03-10T19:07:43  <jonasschnelli> Agree.
379 2016-03-10T19:07:48  <morcos> also we haven't written that code yet anyway
380 2016-03-10T19:07:52  <sipa> that is an open question
381 2016-03-10T19:07:53  <jonasschnelli> I just think there is a hight incentive to use it (fees)
382 2016-03-10T19:07:54  <CodeShark> this is something that can be decided once segwit has already been deployed and is awaiting activation
383 2016-03-10T19:07:56  <gmaxwell> having that triggered by invisible-to-the-user network behavior isn't reat.
384 2016-03-10T19:08:16  <gmaxwell> great*
385 2016-03-10T19:08:31  <sipa> i wish we had an address style for segwit part of the standard :(
386 2016-03-10T19:08:39  *** frankenmint has quit IRC
387 2016-03-10T19:09:10  <gmaxwell> sipa: no you don't. Deploying a new address style takes forever. :P what you wish for is a magic wand.
388 2016-03-10T19:09:15  <btcdrak> sipa I thought we did? BIP142?
389 2016-03-10T19:09:37  <CodeShark> btcdrak: we haven't been pushing it because of concerns regarding scary "new addresses"
390 2016-03-10T19:09:41  <jonasschnelli> P2WPKH?
391 2016-03-10T19:09:53  <sipa> i think we have more buy-in from wallet authors about segwit now, than p2sh had at the timr
392 2016-03-10T19:09:54  <morcos> i think we should do that though, otherwise everyone is going to embed them in p2sh which is kind of silly
393 2016-03-10T19:10:11  *** frankenmint has joined #bitcoin-core-dev
394 2016-03-10T19:10:22  <CodeShark> p2sh was almost entirely under the radar as far as the community at large
395 2016-03-10T19:10:24  <gmaxwell> also, continued use of base58 is awful. I am going to refuse to discuss address encodings with anyone who hasn't read an address to me over the phone. :)
396 2016-03-10T19:10:48  <btcdrak> CodeShark: I would suggest brining it back. There's no problem.
397 2016-03-10T19:10:57  <gmaxwell> CodeShark: thats not the case; besides there is a material difference in the sheer mass of code that must be updated. Besides why is this being discussed there.
398 2016-03-10T19:11:02  <CodeShark> btcdrak: there sort of is a problem still...
399 2016-03-10T19:11:06  <gmaxwell> btcdrak: I oppose it in the strongest possible terms.
400 2016-03-10T19:11:08  <CodeShark> both internal and external
401 2016-03-10T19:11:22  <btcdrak> CodeShark: you can change you mind :)
402 2016-03-10T19:11:33  <CodeShark> internally some people hate base58, externally some people are still grandstanding with the "segwit is too hard" crap
403 2016-03-10T19:11:56  <BlueMatt> gmaxwell: there is certain value in user expectations of things that look like base58
404 2016-03-10T19:12:13  <CodeShark> I think it's a battle not worth fighting right now
405 2016-03-10T19:12:18  <jonasschnelli> +1
406 2016-03-10T19:12:22  <btcdrak> +1
407 2016-03-10T19:12:24  <morcos> gmaxwell: whats your number
408 2016-03-10T19:12:29  <jonasschnelli> haha
409 2016-03-10T19:12:31  <gmaxwell> BlueMatt: You are on subject-matter-ignore until you call me and successfully read me a base58 address.  :)
410 2016-03-10T19:13:04  <sipa> i would really like to have some psegwit afdressddress as part of the "package"
411 2016-03-10T19:13:10  <gmaxwell> morcos: PM :P
412 2016-03-10T19:13:40  <BlueMatt> gmaxwell: I'm not suggesting I'm necessarily in support of base58 addresses, but my point is that it is not up to us here to figure out addressing for segwit...that is something WALLETS need to be involved in...people who actually have some ux experience, which does not exist here
413 2016-03-10T19:14:16  <morcos> gmaxwell: BlueMatt says "..."
414 2016-03-10T19:14:17  <gmaxwell> yes indeed. but thats also why taking on a new address type at the same time is not a good idea, it would get in the way of that kind of collaboration.
415 2016-03-10T19:14:22  <gmaxwell> hahha
416 2016-03-10T19:14:30  <BlueMatt> agreed
417 2016-03-10T19:14:30  <sipa> do you think so?
418 2016-03-10T19:14:37  <sipa> i think it's the opposite
419 2016-03-10T19:14:46  <BlueMatt> I think the idea of pushing off address types for segwit for broader feedback is a good thing
420 2016-03-10T19:14:47  <Luke-Jr> sipa: that was a lot of backspaces.
421 2016-03-10T19:15:07  <CodeShark> good UI design wouldn't even burden users with having to deal with copy/pasting cryptographic keys
422 2016-03-10T19:15:20  <CodeShark> but that's an entirely separate discussion
423 2016-03-10T19:15:28  <Luke-Jr> FWIW, I've been thinking of implementing the payment protocol better in Core
424 2016-03-10T19:15:37  <Luke-Jr> including the new BIP 75 stuff
425 2016-03-10T19:15:39  <jonasschnelli> We are far away from designing the UX... this is a topic we can talk about in 2-3 years.
426 2016-03-10T19:16:04  *** zooko has quit IRC
427 2016-03-10T19:16:33  <sipa> :)
428 2016-03-10T19:16:42  <sipa> ok, let's postpone that address discussion
429 2016-03-10T19:16:42  <jonasschnelli> But sipa: is the P2WPKH address type not okay?,.. addresses like "p2xtZoXeX5X8BP8JfFhQK2nD3emtjch7UeFm"?
430 2016-03-10T19:16:53  <sipa> jonasschnelli: you mean bip142?
431 2016-03-10T19:17:08  <jonasschnelli> Yes. Easy to handle by existing wallets?
432 2016-03-10T19:17:17  <BlueMatt> jonasschnelli: ACK
433 2016-03-10T19:17:24  <gmaxwell> sipa was raising the concern that if something weren't done sooner we'd be left stuck with 80 bit security forever, I reminded him in PM that we have an upcoming checksig improvement to reduce transaction sizes by 30% which would be a nice time to do a new address type too. :)
434 2016-03-10T19:17:42  <wumpus> would be good to have concrete proposals for address formats ,say as BIPs
435 2016-03-10T19:17:50  <CodeShark> we'll have plenty of opportunities to introduce new stuff in the future
436 2016-03-10T19:18:00  <CodeShark> right now we should focus on the path of least resistance
437 2016-03-10T19:18:14  <sipa> the reason against incorporating bip142 is people yelling "see! sehwit needs new address types! everyone has to upgrade! not backward compatible!"
438 2016-03-10T19:18:17  <gmaxwell> The amount going on right now is too great to be able to afford forced seralization.
439 2016-03-10T19:18:27  <CodeShark> eventually my hope is we'll actually have a competent ecosystem that can actually do tech
440 2016-03-10T19:18:36  <CodeShark> but for now we must deal with what we have
441 2016-03-10T19:18:40  <morcos> Yeah I think it would make a lot of sense to release just the P2WPKH address
442 2016-03-10T19:18:44  <Luke-Jr> sipa: we could add sending support, and discourage anyone from using it to receive for now
443 2016-03-10T19:18:45  <jonasschnelli> sipa: You could still uses it over P2SH... but we don't live for the critics.
444 2016-03-10T19:18:56  <morcos> sipa: don't you think everyone is going to say that even more if we don't have address types
445 2016-03-10T19:19:12  <sipa> i don't know
446 2016-03-10T19:19:20  <sipa> i'm an engineer, not a marketer
447 2016-03-10T19:19:31  <jonasschnelli> +1 for P2WPKH bip142
448 2016-03-10T19:19:43  <wumpus> shouldn't be expected from you to act as marketeer sipa
449 2016-03-10T19:19:47  <wumpus> you have enough on your plate
450 2016-03-10T19:19:51  <sipa> next topic?
451 2016-03-10T19:19:59  <CodeShark> yes please
452 2016-03-10T19:20:07  <wumpus> suggestions?
453 2016-03-10T19:20:23  <Luke-Jr> (I don't see value in p2wpkh, but let's move on)
454 2016-03-10T19:21:14  <wumpus> ok, if not, that was a quick meeting
455 2016-03-10T19:21:28  <gmaxwell> there were many things last week that got cut off.
456 2016-03-10T19:21:29  <wumpus> (I'm still too tired and jetlaggy to contribute much now)
457 2016-03-10T19:21:38  <jonasschnelli> If no one has something important... what do you think about my approach of IBD with a pregenerated signed UTXOset?
458 2016-03-10T19:21:57  <btcdrak> Can I ask people to review the backport PRs for BIP68 and 112? They were straight cherry-picks into 0.12 but they do need a couple eyes on them.
459 2016-03-10T19:22:10  <morcos> jonasschnelli: i think thats a bad idea
460 2016-03-10T19:22:11  <Luke-Jr> jonasschnelli: sounds like a waste of time at best, to be frank. :x
461 2016-03-10T19:22:21  *** droark has joined #bitcoin-core-dev
462 2016-03-10T19:22:23  <wumpus> #action review backport PRs for BIP68 and 112
463 2016-03-10T19:22:33  <morcos> jonasschnelli: core devs (or anybody for that matter) should not be authorizing the state of the ledger at any time
464 2016-03-10T19:22:40  <wumpus> #topic IBD with a pregenerated signed UTXOse
465 2016-03-10T19:22:52  <wumpus> it's risky, it brings trust into the system
466 2016-03-10T19:22:56  <Luke-Jr> much prefer to see SPV mode until IBD completes
467 2016-03-10T19:23:15  <jonasschnelli> Luke-Jr: Yes. Agree.
468 2016-03-10T19:23:19  <wumpus> who would you trust to sign something like that?
469 2016-03-10T19:23:30  <sipa> Bob.
470 2016-03-10T19:23:32  <jonasschnelli> Just thought we might want to reduce the amount of block-serving even more.
471 2016-03-10T19:23:36  <wumpus> yes, definitely Bob
472 2016-03-10T19:23:38  <Luke-Jr> XD
473 2016-03-10T19:23:52  <jonasschnelli> wumpus: could be signed by the same users/devs who are signing the gitian builds.
474 2016-03-10T19:24:00  <sipa> jonasschnelli: that's not reducing block serving; it's changing the trust model instead
475 2016-03-10T19:24:22  <jonasschnelli> I agree. It does change the trust model.
476 2016-03-10T19:24:24  <wumpus> jonasschnelli: hmm don't put too much on their shoulders
477 2016-03-10T19:24:27  <CodeShark> without TXO commitments it's unfixable
478 2016-03-10T19:24:31  <CodeShark> :p
479 2016-03-10T19:24:35  <morcos> if we go back to the backport question, we also need to backport all these SF's to 0.11 is that correct?
480 2016-03-10T19:24:54  *** shawnmaten has joined #bitcoin-core-dev
481 2016-03-10T19:24:55  <jonasschnelli> Okay... so. Then let me not implement it. :)
482 2016-03-10T19:25:01  <wumpus> yea, UTXO commitments would make this somewhat more realistic, although it'd still reduce the overall trust model to SPV
483 2016-03-10T19:25:21  <wumpus> jonasschnelli: yes, better not for now I think
484 2016-03-10T19:25:28  <wumpus> #topic backports to 0.11
485 2016-03-10T19:25:30  *** cocoBTC has joined #bitcoin-core-dev
486 2016-03-10T19:25:33  <gmaxwell> morcos: I was thinking about this this morning. The normal release cadance would have us do so, I believe.
487 2016-03-10T19:25:42  <jonasschnelli> SPV during IBD and a throttled(CPU) IBD is the better approach.
488 2016-03-10T19:26:03  <wumpus> jonasschnelli: yes, definitely those would be good to have
489 2016-03-10T19:26:07  <Luke-Jr> how practical is it to backport to 0.10?
490 2016-03-10T19:26:14  <warren> why 0.10?
491 2016-03-10T19:26:20  <wumpus> topic is backport to 0.11 Luke-Jr :p
492 2016-03-10T19:26:20  <sipa> 0.10 and 0.11 are close
493 2016-03-10T19:26:22  <morcos> 0.10?  i'd hoped you guys would be willing to skip 0.11
494 2016-03-10T19:26:29  <sipa> but agree; just 0.11
495 2016-03-10T19:26:32  <btcdrak> morcos: I would skip 0.11
496 2016-03-10T19:26:38  <sipa> we have a published release schedule, no?
497 2016-03-10T19:26:51  <wumpus> I think backporting to 0.11 is fairly necessary, that's only one release back
498 2016-03-10T19:26:51  <Luke-Jr> sipa: of guaranteed support, not limited-to
499 2016-03-10T19:27:07  <Luke-Jr> 0.11 is necessary; 0.10 would be ideal
500 2016-03-10T19:27:09  <morcos> wumpus: i suppose, i'm worried about how well tested these major changes will be
501 2016-03-10T19:27:20  <sipa> master, 0.12, 0.11
502 2016-03-10T19:27:21  <Luke-Jr> but I'll deal with 0.10 later I guess
503 2016-03-10T19:27:24  <jonasschnelli> 0.10 is not necessary... we once agree in supporting only two major versions.
504 2016-03-10T19:27:28  <btcdrak> sipa: our lifecycle doc is at https://bitcoincore.org/en/lifecycle/
505 2016-03-10T19:28:00  <Luke-Jr> jonasschnelli: it was never agreed to drop support for older ones, only to not promise support for them; but that's on me for 0.10 I think
506 2016-03-10T19:28:05  <wumpus> morcos: it's a challenge, but I think you can't get around it, some people won't be ready yet to upgrade to 0.12
507 2016-03-10T19:28:06  <btcdrak> the backports to 0.12 are trivial, but 0.11 will be a little more annoying, especially for BIP68 I believe
508 2016-03-10T19:29:03  <morcos> btcdrak: we should just backport them kind of altogether right?
509 2016-03-10T19:29:10  <btcdrak> btw the backports for BIP68,112 are #7543 and #7544, I forgot to mention the numbers earlier
510 2016-03-10T19:29:14  <morcos> i suppose they don't overlap that much
511 2016-03-10T19:29:31  <morcos> i think i can make sure BIP68 for 0.11 backports properly
512 2016-03-10T19:30:02  <btcdrak> morcos: you'd be the best person to backport BIP68 to 0.11.
513 2016-03-10T19:30:10  <morcos> i will take the approach of not keeping the mempool consistent and checking sequence values in the mining code, which will probably not make much of an effect on the already absurdly slow mining code
514 2016-03-10T19:30:30  <morcos> thats why 7187 was separate, that won't be backported to 0.11
515 2016-03-10T19:30:42  <btcdrak> morcos: plenty miners have upgraded to 0.12 fwiw
516 2016-03-10T19:30:51  <btcdrak> well pools*
517 2016-03-10T19:31:26  <morcos> ok. i'll work on that
518 2016-03-10T19:31:33  <wumpus> the other path would be to wait for 0.13, then only backport to 0.12, but then you'll have to wait 6 months :p
519 2016-03-10T19:31:50  <Luke-Jr> >_<
520 2016-03-10T19:31:55  <btcdrak> wumpus: nice joke there :-P
521 2016-03-10T19:31:58  <wumpus> well not exactly 6 anymore but ok...
522 2016-03-10T19:32:14  <wumpus> I don't think it's realistic no
523 2016-03-10T19:32:39  <sipa> i think we can do 9/68/112/113 soon
524 2016-03-10T19:32:49  <wumpus> aim for 0.13 would be july
525 2016-03-10T19:33:04  <morcos> sipa: agreed!
526 2016-03-10T19:33:14  <wumpus> sipa: I hope so!
527 2016-03-10T19:33:16  <btcdrak> sipa: I also believe so. 68/112/113 are done from my side, morcos wants to add more RPC tests which is fine.
528 2016-03-10T19:33:22  <morcos> did you ever reply to my comment on block version = 4
529 2016-03-10T19:33:29  <morcos> btcdrak: there are NONE!
530 2016-03-10T19:33:43  <CodeShark> any plans to remove the default version crap out of primitives?
531 2016-03-10T19:33:50  <btcdrak> morcos: yes there are. same standard as for BIP65
532 2016-03-10T19:33:54  <sipa> CodeShark: yes, see bip9
533 2016-03-10T19:34:12  <sipa> morcos: it was needed in combination with the warning logic
534 2016-03-10T19:34:18  <btcdrak> morcos: see #7648
535 2016-03-10T19:34:20  <sipa> it may not be needed anymore with imoroved logic
536 2016-03-10T19:34:22  *** d_t has joined #bitcoin-core-dev
537 2016-03-10T19:34:36  <morcos> btcdrak: i saw, and i agree, BIP65 made it out withotu adequate tests
538 2016-03-10T19:35:05  <sdaftuar> sipa: right now #7575 will revert back to version 4 blocks after the first soft fork activates, if no other soft forks are in the queue
539 2016-03-10T19:35:06  <jonasschnelli> bip65 had rpc tests from petertodd?!
540 2016-03-10T19:35:13  <sdaftuar> i assume that is unintentional?
541 2016-03-10T19:35:18  <btcdrak> morcos: I would disagree they were not adaquet, you can always have more sure.
542 2016-03-10T19:35:26  <btcdrak> bip65 had RPC tests.
543 2016-03-10T19:35:29  <sipa> sdaftuar: that seems correct to mr
544 2016-03-10T19:35:39  <sdaftuar> oh, i didn't realize that!
545 2016-03-10T19:35:50  <morcos> sipa: huh?  correct as in you wanted that?
546 2016-03-10T19:36:03  <sipa> the old version is used to indicate "no versionbits"
547 2016-03-10T19:36:04  <btcdrak> bip68/112/113 have the p2p RPC tests in #7648
548 2016-03-10T19:36:30  <sipa> morcos: yes, otherwise the version is ambiguous based on what software miners use, ignoring deploymemts
549 2016-03-10T19:36:37  <sipa> which the warning logic can't deal with
550 2016-03-10T19:36:55  <sipa> it must be absolute "these deployments -> this nVersion"
551 2016-03-10T19:37:05  <morcos> sipa: all prior soft forks required minors to upgrade
552 2016-03-10T19:37:14  <sipa> miners :p
553 2016-03-10T19:37:19  <btcdrak> lol
554 2016-03-10T19:37:25  <CodeShark> minors can always get a fake ID
555 2016-03-10T19:37:27  <morcos> sipa: what i would like to do is with this first soft fork, require nVersion > 4
556 2016-03-10T19:37:44  <sipa> why?
557 2016-03-10T19:37:50  <btcdrak> morcos: why?
558 2016-03-10T19:37:51  <morcos> then we can warn on anything that is not 001...  unless it is <=4 which we know are invalid
559 2016-03-10T19:38:00  <morcos> that seems consistent with how we've done other soft forks
560 2016-03-10T19:38:10  <morcos> there is an expected version number, unknown differences are warned on
561 2016-03-10T19:38:23  *** GreenIsMyPepper has joined #bitcoin-core-dev
562 2016-03-10T19:38:24  <gmaxwell> so old software versions warn.
563 2016-03-10T19:38:34  <gmaxwell> and continue warning.
564 2016-03-10T19:38:35  *** Adiabat has joined #bitcoin-core-dev
565 2016-03-10T19:38:50  <morcos> gmaxwell: yes, old software versions are incapable of noticing transient changes
566 2016-03-10T19:39:06  <morcos> thats why we need to rework alerts/warning to correctly identify them now
567 2016-03-10T19:39:25  <morcos> in fact if you turned off a 0.12 node for a couple months
568 2016-03-10T19:39:34  <morcos> and then turned it back on after all these SF's activated
569 2016-03-10T19:39:36  <morcos> you would have no idea
570 2016-03-10T19:39:43  <morcos> even if you looked at your debug logs
571 2016-03-10T19:39:49  <morcos> b/c the warning logic doesn't run in IBD
572 2016-03-10T19:40:08  <morcos> i feel like that makes it a requirement that we permanently increase the version number
573 2016-03-10T19:40:24  <sdaftuar> agreed
574 2016-03-10T19:40:51  <sipa> wth are you talking about?
575 2016-03-10T19:40:56  <morcos> who?
576 2016-03-10T19:41:01  <CodeShark> I don't follow
577 2016-03-10T19:41:03  <morcos> me?  which part?
578 2016-03-10T19:41:09  <sipa> versionbits is deterministic based on the chain histotu
579 2016-03-10T19:41:18  <morcos> yes 0.12 doesn't have version bits
580 2016-03-10T19:41:20  <morcos> 0.12.0
581 2016-03-10T19:41:25  <CodeShark> after versionbits deployment, all block versions would be > 4
582 2016-03-10T19:41:26  <sipa> ah
583 2016-03-10T19:41:28  <gmaxwell> sipa: he's talking about software which doesn't have versionbits.
584 2016-03-10T19:41:32  <sipa> oh, now i get it
585 2016-03-10T19:41:37  <sipa> sorry
586 2016-03-10T19:41:43  <morcos> CodeShark: thats what i'm trying to say, thats not how its written
587 2016-03-10T19:42:17  <sipa> so increase to 5 after the first vb deployment?
588 2016-03-10T19:42:23  <morcos> no no no
589 2016-03-10T19:42:23  <sdaftuar> why not increase to 001...?
590 2016-03-10T19:42:24  <morcos> not 5
591 2016-03-10T19:42:33  <sdaftuar> consensus rule is >= 5 i guess
592 2016-03-10T19:42:39  <morcos> just > 4, but you expect to see 001
593 2016-03-10T19:43:03  <sipa> consensus >=4, but by default set 001...000....?
594 2016-03-10T19:43:16  <morcos> >4
595 2016-03-10T19:43:18  <morcos> yes
596 2016-03-10T19:43:57  <jonasschnelli> morcos: but you should see it in the debug log? https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2464
597 2016-03-10T19:44:13  <jonasschnelli> Agree that we should also warn in IDB (but low prio IMO).
598 2016-03-10T19:44:14  <sdaftuar> jonasschnelli: that code doesn't run during initialblockdownload
599 2016-03-10T19:44:35  <morcos> the assumption is if you see something that starts with 001 you think you know whats happening and you're unknown activation detector can alert you with specific information
600 2016-03-10T19:44:51  <jonasschnelli> Then lets improve that and BP.
601 2016-03-10T19:44:55  <morcos> and if you see soemthing that doesn't start with 001  such as a 5  or  a 110...
602 2016-03-10T19:45:07  <morcos> jonasschnelli: thats what we're doing , but we can't retroactively change old code
603 2016-03-10T19:45:29  <CodeShark> 110... would be treated as negative, no? because for some reason signed types were used
604 2016-03-10T19:45:31  <morcos> then you assume that someone is doing something you really don't understand
605 2016-03-10T19:45:38  <jonasschnelli> Yes. Sure... we might not be capable of warning for the next SF.
606 2016-03-10T19:45:41  <morcos> CodeShark: sure i mean 010
607 2016-03-10T19:45:54  <btcdrak> morcos: there is already 011 on the network too
608 2016-03-10T19:46:24  <morcos> btcdrak: exactly, and we should be warning about that (and we are now) b/c its changes our software doesn't understand
609 2016-03-10T19:46:35  <btcdrak> right
610 2016-03-10T19:46:38  <morcos> and if > 50/100 blocks then we turn that warning into an alert
611 2016-03-10T19:47:26  *** molz has joined #bitcoin-core-dev
612 2016-03-10T19:47:55  <jonasschnelli> Agree. But that raises also the question how to deploy an alert... debug.log? Yes. No.
613 2016-03-10T19:48:08  <morcos> jonasschnelli: see scroll back before meeting
614 2016-03-10T19:48:29  * jonasschnelli has only a 500 lines scrollback >_<
615 2016-03-10T19:48:53  <morcos> sipa: so agreed that we should increase version number?  should i make a new BIP for that?  and we'll just soft fork it in at same time, or add to existing BIP
616 2016-03-10T19:49:25  <sipa> morcos: consensus or not?
617 2016-03-10T19:49:53  <morcos> sipa: consensus rule that nVersion must be >= 5.
618 2016-03-10T19:50:25  <sipa> morcos: why consensus?
619 2016-03-10T19:50:31  <btcdrak> morcos: confused
620 2016-03-10T19:51:00  <CodeShark> before or after versionbits activation?
621 2016-03-10T19:51:02  <CodeShark> still don't follow
622 2016-03-10T19:51:03  <morcos> sipa: well i suppose it doesn't have to be a consensus rule...
623 2016-03-10T19:51:11  <morcos> CodeShark: with the first SF that activates
624 2016-03-10T19:51:17  *** moli has quit IRC
625 2016-03-10T19:51:30  <morcos> sipa: but i think its more clear to me that it doesn't have problems if it is a consensus rule
626 2016-03-10T19:51:36  <morcos> b/c thats how the other ones worked
627 2016-03-10T19:51:44  <gmaxwell> making it consensus would cause gratitious orphaning, which we were generally trying to avoid in the design of segwit.
628 2016-03-10T19:51:54  <morcos> gmaxwell: this will be before segwit
629 2016-03-10T19:52:04  <sipa> i prefer not introducing new consensus logic, especially when the only argument for it is better guarantees for warnings
630 2016-03-10T19:52:33  <morcos> sipa: yes thats the only difference i see.  is that now we somehow can't warn on version = 4 blocks
631 2016-03-10T19:52:58  <sipa> and if it's not consnesus, we can say bip9 miners without active rollouts use 001000...
632 2016-03-10T19:53:38  <gmaxwell> I like 001000 in that it would encourage visualization tools to parse the bitfield instead of just displaying an integer.
633 2016-03-10T19:53:43  <btcdrak> yes
634 2016-03-10T19:53:50  <morcos> sipa: if its not a consensus rule, you can't be SURE that old nodes will be warned that the rules have changed... perhaps thats not worth worrying about
635 2016-03-10T19:54:27  <sipa> miners can already cause total network forks
636 2016-03-10T19:54:28  <btcdrak> That was my initial understanding that the new version would be 00100..0 when no sfs are being deployed
637 2016-03-10T19:54:28  <morcos> its just cleaner to me
638 2016-03-10T19:54:38  <sipa> are we worried that they can bypass a warning mechanism?
639 2016-03-10T19:54:50  <btcdrak> sipa: no
640 2016-03-10T19:56:09  *** mm_1 has joined #bitcoin-core-dev
641 2016-03-10T19:56:51  <morcos> sipa: ok i guess. i'm ok with not making it a consensus rule..  but just seems weird to me...  i feel like we're transitioning from an old system to a new system, and the transition should conform to the old system
642 2016-03-10T19:57:09  <gmaxwell> Lets wrap the metting now and talk more about warning after. Unless there are any other subject to squeek in at the end?
643 2016-03-10T19:57:10  <wumpus> meeting: 3 minutes to go
644 2016-03-10T19:57:17  <morcos> but as long as we make the default 00100  then i think its just theoretical concerns
645 2016-03-10T19:57:21  <sipa> yeah
646 2016-03-10T19:58:17  <wumpus> #endmeeting
647 2016-03-10T19:58:17  <lightningbot> Meeting ended Thu Mar 10 19:58:17 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
648 2016-03-10T19:58:17  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-10-18.59.html
649 2016-03-10T19:58:17  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-10-18.59.txt
650 2016-03-10T19:58:17  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-10-18.59.log.html
651 2016-03-10T19:59:27  <kanzure> #action review scrollback
652 2016-03-10T19:59:39  <sipa> haha
653 2016-03-10T19:59:39  <btcdrak> haha
654 2016-03-10T19:59:55  <btcdrak> that was a really long meeting...
655 2016-03-10T19:59:56  <gmaxwell> sipa: So a concern I raised on the PR is that I'd like nodes to stop mining (e.g. error on GBT results) after a SW upgrade happens. The issue I'm trying to address is say the network successfully upgrades, and then a couple huge pools reboot and end up on pre softfork code-- e.g. bootscripts start the wrong versions; things run happily for a while, but then someone mines an invalid transaction a
656 2016-03-10T20:00:01  <gmaxwell> nd then a huge amount of hashpower begins a fork.  Nversion progression previously prevented this, but at the expense of creating gratitious orphans around the switchover time.
657 2016-03-10T20:00:33  <morcos> gmaxwell: i was wondering about that, but do miners change their version number outside of bitcoind anyway?
658 2016-03-10T20:01:07  <gmaxwell> morcos: in the past some mining hardware had hardcoded versions numbers, but I think the last couple softforks probably shook out a fair amount of that.
659 2016-03-10T20:01:33  <sipa> we hope...
660 2016-03-10T20:01:35  <morcos> gmaxwell: so this is another reason to make >= 5 a consensus rule
661 2016-03-10T20:01:42  <Luke-Jr> morcos: they set it outside bitcoind generally
662 2016-03-10T20:01:44  <morcos> if you don't you can't fix that problem for 0.12.0 miners
663 2016-03-10T20:01:57  <sipa> how does that help?
664 2016-03-10T20:02:21  <gmaxwell> sipa: the idea is that post SW miners would do the voluntarily shut off unless overridden.
665 2016-03-10T20:03:09  <morcos> sipa: well i don't know.  i took gmaxwell's scenario at face value.. but maybe it doesn't make sense.  i guess the difference is whether you find out right away or not?
666 2016-03-10T20:03:34  <gmaxwell> It's a difference in the size of the fork; and who takes the risks.
667 2016-03-10T20:03:37  <morcos> gmaxwell: are you specficially talking about SW script upgrades?  or do you mean BIP 9 soft forks?
668 2016-03-10T20:03:52  <gmaxwell> BIP9 softforks.
669 2016-03-10T20:04:25  <morcos> gmaxwell: can you explain a bit why the fork size would be bigger?
670 2016-03-10T20:04:26  <sipa> if the vereion number is set outside of bitcoim core, then logic there won't help
671 2016-03-10T20:04:47  <sipa> you just need logic that stops GBT in case the vb warning logic triggered
672 2016-03-10T20:04:53  *** shawnmaten has left #bitcoin-core-dev
673 2016-03-10T20:05:21  <morcos> that seems a bit risky to me to automatically stop GBT
674 2016-03-10T20:05:34  <gmaxwell> morcos: Because only an exceptional circumstance would begin such a fork, it might happen months or years after the change, with no one paying attention.
675 2016-03-10T20:05:40  <morcos> i mean i guess it does take 95% of miners to cause a fake trigger
676 2016-03-10T20:06:20  <gmaxwell> morcos: the existing warning stuff is stupid, boarderline broken-- which is why I was suggesting it only for BIP9 activation.
677 2016-03-10T20:07:05  <jonasschnelli> Is https://github.com/sipa/bitcoin/tree/segwit still the most recent segnet working tree?
678 2016-03-10T20:07:30  <jonasschnelli> BTW: how changes the https://github.com/bitcoin icon? Nice one!
679 2016-03-10T20:07:40  <jonasschnelli> *who
680 2016-03-10T20:07:47  <jonasschnelli> *changed (damit)
681 2016-03-10T20:07:57  <gmaxwell> morcos: the idea that the network in bulk could silently regress rules (though detectable by the nodes themselves) concerns me; but I don't know how much of a pratical concern it should be.
682 2016-03-10T20:09:06  <morcos> gmaxwell: the fact that nVersion is set outside bitcoind is disturbing, but imagine 1% of miners don't upgrade to versionbits and the 68/112/113 soft fork
683 2016-03-10T20:09:49  <morcos> they will happily mine version 4 blocks for months until they accidentally mine an invalid BIP68 tx, and then all the SPV miners will just build off them
684 2016-03-10T20:10:00  <morcos> as opposed to htat thing happening right away if the nVersion had to increase
685 2016-03-10T20:10:52  * Luke-Jr wonders if versionbits has GBT extensions yet
686 2016-03-10T20:12:06  <sipa> Luke-Jr: is it not enough to report nVersionm
687 2016-03-10T20:12:08  <sipa> ?
688 2016-03-10T20:12:16  <gmaxwell> morcos: right, so two questions: avoiding that for this one change vs in the long term.
689 2016-03-10T20:12:21  <Luke-Jr> sipa: no, because nVersion could mean different things
690 2016-03-10T20:12:46  <morcos> gmaxwell: yes, i agree that perhaps your long term change makes sense
691 2016-03-10T20:13:09  <sdaftuar> gmaxwell: morcos: seems to me like we should do both things you guys are suggesting
692 2016-03-10T20:13:12  <morcos> i mean your change now to solve the longer term problem
693 2016-03-10T20:13:22  <sipa> Luke-Jr: ?
694 2016-03-10T20:13:46  <Luke-Jr> sipa: version=69632 could mean different softforks depending on context of the block
695 2016-03-10T20:13:57  <sipa> so?
696 2016-03-10T20:14:10  <gmaxwell> morcos: in the long term I think it's adequate to refuse to serve GBT requests after a BIP9 activiation triggers. (and perhaps mine only empty blocks during the quiet period for further visibility)
697 2016-03-10T20:14:22  <gmaxwell> sipa: matters if you're adding additional txn to the gbt output.
698 2016-03-10T20:14:24  <Luke-Jr> sipa: so the GBT client won't know which softforks to enable
699 2016-03-10T20:14:37  <gmaxwell> morcos: for the current issue, I agree that an upgrade to >=5 may be needed.
700 2016-03-10T20:14:46  <sipa> Luke-Jr: nobody is doing that, right?
701 2016-03-10T20:15:20  <gmaxwell> Luke-Jr: I think you actually want to expose the mempool validation flags in GBT for that, not just softforks.
702 2016-03-10T20:15:26  <Luke-Jr> sipa: adding transactions, not at the moment AFAIK, but GBT clients always must be aware of what the block rules are to some extent
703 2016-03-10T20:15:38  <sdaftuar> note that the version bits do not indicate what the consensus rules are
704 2016-03-10T20:15:50  <sipa> Luke-Jr: i guess those can be per-softfork extensions to GBT
705 2016-03-10T20:16:11  <sipa> as their effects can be hard to generalize
706 2016-03-10T20:16:13  <Luke-Jr> sipa: some way to indicate them is still needed, but yes
707 2016-03-10T20:16:51  <Luke-Jr> ie, we don't want old GBT clients to think they can handle bit X, but interpret it differently
708 2016-03-10T20:17:10  <morcos> Luke-Jr: any time you are setting bit X it by definition means that soft fork isn't even active yet
709 2016-03-10T20:17:21  <morcos> or at least by implementation
710 2016-03-10T20:18:03  <Luke-Jr> more likely the GBT client would be the side setting the bits it implements
711 2016-03-10T20:20:07  <gmaxwell> Luke-Jr: trying to move network consensus logic into gbt clients seems inadvisible and should only be done where strictly needed.
712 2016-03-10T20:22:45  <sipa> gmaxwell: +1
713 2016-03-10T20:25:15  <BlueMatt> instead we should be pulling out as MUCH logic as possible from gbt clients/pool servers into bitcoind
714 2016-03-10T20:25:18  <BlueMatt> and also kill getblocktemplate
715 2016-03-10T20:25:23  <BlueMatt> because no one uses it and everyone hates it
716 2016-03-10T20:29:48  *** Thireus has quit IRC
717 2016-03-10T20:30:06  *** Thireus has joined #bitcoin-core-dev
718 2016-03-10T20:31:01  <gmaxwell> BlueMatt: so mean. By "kill" you mean "optimize".
719 2016-03-10T20:31:14  *** Thireus has quit IRC
720 2016-03-10T20:31:22  <BlueMatt> gmaxwell: I mean replace entirely
721 2016-03-10T20:31:22  <sipa> making it observable what is being mined makes sense
722 2016-03-10T20:31:38  *** Thireus has joined #bitcoin-core-dev
723 2016-03-10T20:32:06  <BlueMatt> gmaxwell: no one cares about the features provided by gbt, and every time I talk to /anyone/ using it (except eloipool) the response is "omg, just replace it with a binary something-or-other that has nearly opposite features of what gbt provides"
724 2016-03-10T20:32:14  <sipa> but i don't think GBT's goal should be letting block construction outside of bitcoind
725 2016-03-10T20:32:21  <BlueMatt> ^that
726 2016-03-10T20:32:28  <BlueMatt> is also what people want
727 2016-03-10T20:32:30  *** Thireus has joined #bitcoin-core-dev
728 2016-03-10T20:32:43  <BlueMatt> most folks just want the minimal data they need to be able to twiddle extranonce
729 2016-03-10T20:32:47  <gmaxwell> if the nonce in header fork were done we could go back to getwork. :)
730 2016-03-10T20:32:53  <BlueMatt> and that
731 2016-03-10T20:33:27  *** Thireus has quit IRC
732 2016-03-10T20:36:46  *** Thireus has joined #bitcoin-core-dev
733 2016-03-10T20:37:48  <btcdrak> BlueMatt: is there any more progress on HF contents?
734 2016-03-10T20:38:40  <BlueMatt> btcdrak: I havent seen anything on bitcoin-dev?
735 2016-03-10T20:38:43  <BlueMatt> btcdrak: also #bitcoin-dev
736 2016-03-10T20:38:54  *** Thireus has quit IRC
737 2016-03-10T20:39:03  <Luke-Jr> sipa: so just give up on decentralised mining entirely?
738 2016-03-10T20:39:15  <BlueMatt> Luke-Jr: that is a false dichotomy
739 2016-03-10T20:39:48  <gmaxwell> there are other ways to do that, e.g. telling bitcoind what the requirements are for a block it creates and letting it create it.
740 2016-03-10T20:39:53  <BlueMatt> Luke-Jr: the amount of data you need to twiddle the extranonce is almost the same as the amount of data you need to create a coinbase for gbt in the same way you want people to do decentralized mining
741 2016-03-10T20:39:55  <gmaxwell> E.g. coinbase must pay to X.
742 2016-03-10T20:40:03  <BlueMatt> gmaxwell: you can create the coinbase downstream of bitcoind
743 2016-03-10T20:40:21  *** Thireus has joined #bitcoin-core-dev
744 2016-03-10T20:40:24  <gmaxwell> only by implementing consensus rules outside of bitcoind, however.
745 2016-03-10T20:40:30  *** Thireus has quit IRC
746 2016-03-10T20:40:39  <BlueMatt> bitcoind should be able to tell you things like requirements for what scriptSig should look like
747 2016-03-10T20:40:49  <gmaxwell> BlueMatt: you are reinventing GBT. :)
748 2016-03-10T20:40:55  <Luke-Jr> gmaxwell: this is higher latency
749 2016-03-10T20:41:04  *** Thireus has joined #bitcoin-core-dev
750 2016-03-10T20:41:05  <BlueMatt> gmaxwell: no, gbt gives you all kinds of shit like details for every transaction in the block
751 2016-03-10T20:41:12  <BlueMatt> you should only be providing minimal merkle tree info
752 2016-03-10T20:41:29  <gmaxwell> BlueMatt: which is actually needed if you're building your own coinbase, because you may need to drop out transactions to make room.
753 2016-03-10T20:41:32  <BlueMatt> gmaxwell: also, phantomcircuit has a protocol designed for this
754 2016-03-10T20:41:34  <BlueMatt> that is pretty minimal
755 2016-03-10T20:41:54  *** Thireus has quit IRC
756 2016-03-10T20:42:00  <BlueMatt> gmaxwell: "meh", your coinbase shouldnt be /that/ large
757 2016-03-10T20:42:22  <gmaxwell> go look at a p2pool coinbase txn.
758 2016-03-10T20:42:31  <BlueMatt> I'm aware
759 2016-03-10T20:43:12  *** Eliel has quit IRC
760 2016-03-10T20:43:15  <BlueMatt> ehh, whatever, fine, give bitcoind a coinbase output list
761 2016-03-10T20:43:54  <BlueMatt> either way, push complexity into bitcoind :)
762 2016-03-10T20:43:56  * Luke-Jr notes that's the approach he took originally and gave up after years of it not being merged.
763 2016-03-10T20:43:57  <morcos> i know nothing about mining, so hopefully im not wasting peoples time
764 2016-03-10T20:44:14  <morcos> but it seems to me that it would be reasonable to require miners to run a bitcoind
765 2016-03-10T20:44:16  *** Thireus has joined #bitcoin-core-dev
766 2016-03-10T20:44:32  * gmaxwell plays taps for 'coinbaser'
767 2016-03-10T20:44:35  <morcos> and we should provide an API by which they can submit a block to to a pool and say hey, is this acceptable
768 2016-03-10T20:44:41  <morcos> and then they can work on that
769 2016-03-10T20:44:48  <morcos> i know thats the idea behind GBT (sort of)
770 2016-03-10T20:44:56  <morcos> but instead of building all the functionality into the API
771 2016-03-10T20:44:58  <BlueMatt> Luke-Jr: to be fair, people also hate json, so need something outside the existing rpc
772 2016-03-10T20:45:06  *** Thireus has quit IRC
773 2016-03-10T20:45:07  <Luke-Jr> BlueMatt: it wasn't via RPC ;)
774 2016-03-10T20:45:17  <BlueMatt> hmm, fair enough
775 2016-03-10T20:45:21  <morcos> just have a testBlock RPC call that the pool can say, yeah thats cool pays the right coinbase or whatever and is valid according to our consensus rules
776 2016-03-10T20:45:51  *** Thireus has joined #bitcoin-core-dev
777 2016-03-10T20:46:03  <Luke-Jr> preferably there'd be a way to avoid sending the entire gen-tx around.
778 2016-03-10T20:46:27  *** Thireus has quit IRC
779 2016-03-10T20:46:49  <BlueMatt> Luke-Jr: so revive it now :)
780 2016-03-10T20:46:55  <Luke-Jr> BlueMatt: ?
781 2016-03-10T20:46:55  *** laurentmt has quit IRC
782 2016-03-10T20:47:00  *** Thireus has joined #bitcoin-core-dev
783 2016-03-10T20:47:15  *** belcher has joined #bitcoin-core-dev
784 2016-03-10T20:47:55  <Luke-Jr> not sure the point
785 2016-03-10T20:53:03  <jtimon> sipa morcos, what about always producing 0010... (even when no deployments are being checked) after the the starttime of the first deployment? (my own solution was to just do it right away for new miners, even before any start time, but sipa complained that old nodes would get warnings before start time [they're going to receive warnings before activation anyway, so I wasn't too concerned about that])
786 2016-03-10T20:53:24  *** Eliel has joined #bitcoin-core-dev
787 2016-03-10T20:53:38  <morcos> jtimon: yeah i think its strictly better for the old nodes to get the warnings earlier
788 2016-03-10T20:53:44  *** Thireus has quit IRC
789 2016-03-10T20:54:06  *** Thireus has joined #bitcoin-core-dev
790 2016-03-10T20:54:25  <jtimon> that was my point, the dicsussion is there in some outdated comment in #7575
791 2016-03-10T20:54:30  *** jgarzik has joined #bitcoin-core-dev
792 2016-03-10T20:54:30  *** jgarzik has joined #bitcoin-core-dev
793 2016-03-10T20:55:01  <jtimon> and that solution doesn't require any additional consensus checks, which seems to be what people dislike more from your proposal
794 2016-03-10T20:59:22  *** e0_ has joined #bitcoin-core-dev
795 2016-03-10T20:59:36  <e0_> The variables  pathCached and pathCachedNetSpecific in util.cpp appears to be unused (find doesn't return any results of them being set) but can cause interesting segfaults since depending on the order in which objects are created they can be uninitialized.  Are they actually unused
796 2016-03-10T20:59:41  <e0_> [3:38]
797 2016-03-10T20:59:44  <e0_> ?
798 2016-03-10T20:59:47  <e0_> https://github.com/bitcoin/bitcoin/blob/master/src/util.cpp#L485
799 2016-03-10T20:59:55  <e0_> I have a pull request, but I don't want to waste peoples time in case I am missing something
800 2016-03-10T21:00:58  *** Thireus has quit IRC
801 2016-03-10T21:01:21  *** Thireus has joined #bitcoin-core-dev
802 2016-03-10T21:04:20  *** Thireus has quit IRC
803 2016-03-10T21:12:24  *** wallet42 has quit IRC
804 2016-03-10T21:14:51  *** gevs has quit IRC
805 2016-03-10T21:18:16  *** wallet42 has joined #bitcoin-core-dev
806 2016-03-10T21:23:01  *** Thireus has joined #bitcoin-core-dev
807 2016-03-10T21:25:42  *** Thireus has quit IRC
808 2016-03-10T21:26:33  *** Thireus has joined #bitcoin-core-dev
809 2016-03-10T21:57:39  *** Guyver2 has quit IRC
810 2016-03-10T22:04:42  *** jgarzik has quit IRC
811 2016-03-10T22:12:02  *** mrkent_ has joined #bitcoin-core-dev
812 2016-03-10T22:14:28  *** Arnavion has quit IRC
813 2016-03-10T22:14:44  *** mrkent has quit IRC
814 2016-03-10T22:29:54  *** Arnavion has joined #bitcoin-core-dev
815 2016-03-10T22:35:57  *** gevs has joined #bitcoin-core-dev
816 2016-03-10T22:47:45  *** zooko has joined #bitcoin-core-dev
817 2016-03-10T22:55:45  *** lahwran is now known as lauren
818 2016-03-10T23:11:13  <dgenr8> 144*365
819 2016-03-10T23:15:28  *** Adiabat has quit IRC
820 2016-03-10T23:17:20  *** gevs has quit IRC
821 2016-03-10T23:20:02  *** jannes has quit IRC
822 2016-03-10T23:21:50  *** musalbas has joined #bitcoin-core-dev
823 2016-03-10T23:22:07  *** randy-waterhouse has joined #bitcoin-core-dev
824 2016-03-10T23:22:40  *** musalbas has left #bitcoin-core-dev
825 2016-03-10T23:22:54  *** musalbas has joined #bitcoin-core-dev
826 2016-03-10T23:26:09  *** Arnavion has quit IRC
827 2016-03-10T23:48:30  *** laurentmt has joined #bitcoin-core-dev
828 2016-03-10T23:49:08  *** laurentmt has quit IRC