1 2016-03-03T00:00:46  *** wallet42 has joined #bitcoin-core-dev
  2 2016-03-03T00:05:16  *** belcher has quit IRC
  3 2016-03-03T00:06:36  *** Don_John has joined #bitcoin-core-dev
  4 2016-03-03T00:17:48  *** Squidicuz has joined #bitcoin-core-dev
  5 2016-03-03T00:22:44  *** Don_John has quit IRC
  6 2016-03-03T00:41:02  *** gevs has quit IRC
  7 2016-03-03T00:48:41  *** frankenmint has joined #bitcoin-core-dev
  8 2016-03-03T00:49:38  *** randy-waterhouse has joined #bitcoin-core-dev
  9 2016-03-03T00:53:43  *** frankenmint has quit IRC
 10 2016-03-03T00:53:44  *** gevs has joined #bitcoin-core-dev
 11 2016-03-03T01:00:09  *** evoskuil has joined #bitcoin-core-dev
 12 2016-03-03T01:06:45  *** AaronvanW has quit IRC
 13 2016-03-03T01:15:04  *** rubensayshi has quit IRC
 14 2016-03-03T01:15:32  *** tr0nk has joined #bitcoin-core-dev
 15 2016-03-03T01:16:20  *** wallet42 has quit IRC
 16 2016-03-03T01:21:34  *** wallet42 has joined #bitcoin-core-dev
 17 2016-03-03T01:25:11  *** zooko has joined #bitcoin-core-dev
 18 2016-03-03T01:25:41  *** _alp_ has joined #bitcoin-core-dev
 19 2016-03-03T01:26:17  *** fengling_ has joined #bitcoin-core-dev
 20 2016-03-03T01:26:46  *** Don_John has joined #bitcoin-core-dev
 21 2016-03-03T01:28:28  *** Ylbam has quit IRC
 22 2016-03-03T01:29:04  *** rubensayshi has joined #bitcoin-core-dev
 23 2016-03-03T01:33:15  *** wallet42 has quit IRC
 24 2016-03-03T01:34:29  *** zooko has quit IRC
 25 2016-03-03T01:38:23  *** windsok has joined #bitcoin-core-dev
 26 2016-03-03T01:52:32  *** wallet42 has joined #bitcoin-core-dev
 27 2016-03-03T01:56:31  *** wallet42 has quit IRC
 28 2016-03-03T01:57:56  *** wallet42 has joined #bitcoin-core-dev
 29 2016-03-03T02:09:42  *** laurentmt has joined #bitcoin-core-dev
 30 2016-03-03T02:09:45  *** laurentmt has quit IRC
 31 2016-03-03T02:10:27  *** wallet42 has quit IRC
 32 2016-03-03T02:11:01  *** wallet42 has joined #bitcoin-core-dev
 33 2016-03-03T02:17:20  <gmaxwell> 12:47 < paveljanik> ECDSA Key Extraction from Mobile Devices via Nonintrusive Physical Side Channels (http://eprint.iacr.org/2016/230.pdf)
 34 2016-03-03T02:17:56  <gmaxwell> Indeed, we were aware that OpenSSL was vulnerable to this kind of attack (though the pratical exploitation of it is quite interesting) and stopped using it several years ago as a result.
 35 2016-03-03T02:19:01  *** zibbo has joined #bitcoin-core-dev
 36 2016-03-03T02:19:22  *** nkuttler_ has joined #bitcoin-core-dev
 37 2016-03-03T02:22:46  *** xiangfu has joined #bitcoin-core-dev
 38 2016-03-03T02:22:59  *** justanot1eruser has joined #bitcoin-core-dev
 39 2016-03-03T02:23:16  *** justanotheruser has quit IRC
 40 2016-03-03T02:23:49  *** viderizer2 has quit IRC
 41 2016-03-03T02:23:49  *** zibbo_ has quit IRC
 42 2016-03-03T02:23:50  *** nkuttler has quit IRC
 43 2016-03-03T02:23:52  *** nkuttler_ is now known as nkuttler
 44 2016-03-03T02:24:18  *** viderizer2 has joined #bitcoin-core-dev
 45 2016-03-03T02:45:44  *** jtimon has quit IRC
 46 2016-03-03T02:47:10  *** wallet42 has quit IRC
 47 2016-03-03T03:01:03  *** p15 has quit IRC
 48 2016-03-03T03:07:41  *** frankenmint has joined #bitcoin-core-dev
 49 2016-03-03T03:10:34  *** zooko has joined #bitcoin-core-dev
 50 2016-03-03T03:14:49  *** frankenm_ has joined #bitcoin-core-dev
 51 2016-03-03T03:15:31  *** zooko has quit IRC
 52 2016-03-03T03:22:40  *** frankenmint has quit IRC
 53 2016-03-03T03:25:43  *** kinlo_ has joined #bitcoin-core-dev
 54 2016-03-03T03:25:45  *** helo_ has joined #bitcoin-core-dev
 55 2016-03-03T03:25:47  *** adam3us_ has joined #bitcoin-core-dev
 56 2016-03-03T03:25:47  *** roasbeef_ has joined #bitcoin-core-dev
 57 2016-03-03T03:25:59  *** nickler_ has joined #bitcoin-core-dev
 58 2016-03-03T03:26:07  *** nullpt_ has joined #bitcoin-core-dev
 59 2016-03-03T03:26:14  *** fkhan_ has joined #bitcoin-core-dev
 60 2016-03-03T03:26:26  *** Bootvis_ has joined #bitcoin-core-dev
 61 2016-03-03T03:26:29  *** fkhan has quit IRC
 62 2016-03-03T03:26:29  *** evoskuil has quit IRC
 63 2016-03-03T03:26:31  *** murr4y has quit IRC
 64 2016-03-03T03:26:34  *** nanotube has quit IRC
 65 2016-03-03T03:26:35  *** ebfull has quit IRC
 66 2016-03-03T03:26:35  *** kinlo has quit IRC
 67 2016-03-03T03:26:36  *** zxzzt has quit IRC
 68 2016-03-03T03:26:36  *** nullpt has quit IRC
 69 2016-03-03T03:26:36  *** roasbeef has quit IRC
 70 2016-03-03T03:26:36  *** berndj has quit IRC
 71 2016-03-03T03:26:37  *** nickler has quit IRC
 72 2016-03-03T03:26:37  *** helo has quit IRC
 73 2016-03-03T03:26:37  *** Bootvis has quit IRC
 74 2016-03-03T03:26:38  *** adam3us has quit IRC
 75 2016-03-03T03:26:38  *** evoskuil has joined #bitcoin-core-dev
 76 2016-03-03T03:26:53  *** berndj-blackout has joined #bitcoin-core-dev
 77 2016-03-03T03:27:03  *** kinlo_ is now known as kinlo
 78 2016-03-03T03:27:50  *** murr4y has joined #bitcoin-core-dev
 79 2016-03-03T03:30:53  *** nanotube has joined #bitcoin-core-dev
 80 2016-03-03T03:33:11  *** zxzzt has joined #bitcoin-core-dev
 81 2016-03-03T03:39:02  *** Alopex has quit IRC
 82 2016-03-03T03:40:07  *** Alopex has joined #bitcoin-core-dev
 83 2016-03-03T03:47:45  *** Giszmo has quit IRC
 84 2016-03-03T04:07:59  *** evoskuil has quit IRC
 85 2016-03-03T04:22:54  *** evoskuil has joined #bitcoin-core-dev
 86 2016-03-03T04:41:01  *** Alopex has quit IRC
 87 2016-03-03T04:42:06  *** Alopex has joined #bitcoin-core-dev
 88 2016-03-03T04:51:18  *** p15x has joined #bitcoin-core-dev
 89 2016-03-03T04:57:02  *** Alopex has quit IRC
 90 2016-03-03T04:58:07  *** Alopex has joined #bitcoin-core-dev
 91 2016-03-03T05:17:00  *** p15x has quit IRC
 92 2016-03-03T05:25:03  *** fkhan_ has quit IRC
 93 2016-03-03T05:38:22  *** fkhan_ has joined #bitcoin-core-dev
 94 2016-03-03T05:44:02  *** p15x has joined #bitcoin-core-dev
 95 2016-03-03T05:58:12  *** fengling_ has quit IRC
 96 2016-03-03T05:58:19  *** xiangfu has quit IRC
 97 2016-03-03T05:59:02  *** fengling_ has joined #bitcoin-core-dev
 98 2016-03-03T06:00:06  *** xiangfu has joined #bitcoin-core-dev
 99 2016-03-03T06:00:36  *** p15x has quit IRC
100 2016-03-03T06:04:08  *** pavel_ has quit IRC
101 2016-03-03T06:04:17  *** paveljanik has joined #bitcoin-core-dev
102 2016-03-03T06:09:52  *** Cheeseo has quit IRC
103 2016-03-03T06:13:03  *** Don_John has quit IRC
104 2016-03-03T06:39:15  *** Cheeseo has joined #bitcoin-core-dev
105 2016-03-03T06:46:26  *** p15 has joined #bitcoin-core-dev
106 2016-03-03T06:53:58  *** wallet42 has joined #bitcoin-core-dev
107 2016-03-03T07:08:57  *** wallet421 has joined #bitcoin-core-dev
108 2016-03-03T07:09:02  *** jarret has quit IRC
109 2016-03-03T07:12:23  *** wallet42 has quit IRC
110 2016-03-03T07:13:32  *** BitcoinErrorLog has quit IRC
111 2016-03-03T07:50:59  *** randy-waterhouse has quit IRC
112 2016-03-03T07:54:40  *** BashCo has quit IRC
113 2016-03-03T07:58:03  *** Thireus has quit IRC
114 2016-03-03T08:03:10  *** schmidty has quit IRC
115 2016-03-03T08:09:40  *** Ylbam has joined #bitcoin-core-dev
116 2016-03-03T08:20:37  *** Thireus has joined #bitcoin-core-dev
117 2016-03-03T08:27:33  *** BashCo has joined #bitcoin-core-dev
118 2016-03-03T08:32:42  *** paveljanik has quit IRC
119 2016-03-03T08:46:04  *** tr0nk has quit IRC
120 2016-03-03T08:47:42  *** p15x has joined #bitcoin-core-dev
121 2016-03-03T08:55:49  *** AaronvanW has joined #bitcoin-core-dev
122 2016-03-03T09:06:15  *** inaltoasinistra has joined #bitcoin-core-dev
123 2016-03-03T09:15:10  *** chris2000 has joined #bitcoin-core-dev
124 2016-03-03T09:26:17  *** wallet421 has quit IRC
125 2016-03-03T09:26:58  *** paveljanik has joined #bitcoin-core-dev
126 2016-03-03T09:39:44  *** jannes has joined #bitcoin-core-dev
127 2016-03-03T09:59:25  *** nickler_ is now known as nickler
128 2016-03-03T10:08:07  *** randy-waterhouse has joined #bitcoin-core-dev
129 2016-03-03T10:35:33  <GitHub33> [bitcoin] elliotolds opened pull request #7635: [Documentation] Add dependency info to test docs (master...docs4) https://github.com/bitcoin/bitcoin/pull/7635
130 2016-03-03T10:51:30  <GitHub21> [bitcoin] jtimon closed pull request #7310: MOVEONLY: Move consensus functions out of main (master...consensus-moveonly-0.13.99) https://github.com/bitcoin/bitcoin/pull/7310
131 2016-03-03T10:53:00  <GitHub57> [bitcoin] jtimon closed pull request #6907: Chainparams: Use a regular factory for creating chainparams (master...chainparams-factory-0.12.99) https://github.com/bitcoin/bitcoin/pull/6907
132 2016-03-03T10:53:20  <GitHub133> [bitcoin] jtimon closed pull request #7566: WIP: Implement BIP9 and get BIP113 to be ready to be deployed with it as an example (master...bip9-0.12.99) https://github.com/bitcoin/bitcoin/pull/7566
133 2016-03-03T10:55:16  <GitHub13> [bitcoin] jtimon closed pull request #7565: bip9/bip113/libconsensus-p2a: Deployment preparations forBIP113 + #7552 + Introduce Consensus::VerifyTx() (master...libconsensus-p2a-verifytx-bip113-0.12.99) https://github.com/bitcoin/bitcoin/pull/7565
134 2016-03-03T11:01:30  *** inaltoas1nistra has joined #bitcoin-core-dev
135 2016-03-03T11:04:37  *** inaltoasinistra has quit IRC
136 2016-03-03T11:11:39  <GitHub153> [bitcoin] makevoid opened pull request #7636: Add bitcoin address label to request payment QR code (master...request_payment_qrcode_address_label) https://github.com/bitcoin/bitcoin/pull/7636
137 2016-03-03T11:19:12  <jouke> bitcoind -help-debug checks if bitcoin core is running?
138 2016-03-03T11:19:24  <jouke> bitcoind -help does not. Intended behaviour?
139 2016-03-03T11:22:21  <jouke> oh, --help -help-debug
140 2016-03-03T11:22:27  <jouke> never mind
141 2016-03-03T11:23:10  *** tr0nk has joined #bitcoin-core-dev
142 2016-03-03T11:23:47  *** MarcoFalke has joined #bitcoin-core-dev
143 2016-03-03T11:24:14  *** gevs has quit IRC
144 2016-03-03T11:43:24  *** randy-waterhouse has left #bitcoin-core-dev
145 2016-03-03T11:45:19  *** tr0nk has quit IRC
146 2016-03-03T11:45:47  *** jannes_ has joined #bitcoin-core-dev
147 2016-03-03T11:46:36  *** jannes has quit IRC
148 2016-03-03T11:54:39  <GitHub198> [bitcoin] jtimon closed pull request #7563: libconsensus-p2a: Decouple pow.o from chain.o and move it to the consensus package (master...libconsensus-p2a-chain-cpp-interface-0.12.99) https://github.com/bitcoin/bitcoin/pull/7563
149 2016-03-03T11:57:57  <GitHub11> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/409f843f2ed2...1b68de35250e
150 2016-03-03T11:57:57  <GitHub11> bitcoin/master fa1b80d MarcoFalke: [travis] Only run check-doc.py once
151 2016-03-03T11:57:58  <GitHub11> bitcoin/master 1b68de3 Wladimir J. van der Laan: Merge #7620: [travis] Only run check-doc.py once...
152 2016-03-03T11:58:07  <GitHub17> [bitcoin] laanwj closed pull request #7620: [travis] Only run check-doc.py once (master...patch-1) https://github.com/bitcoin/bitcoin/pull/7620
153 2016-03-03T12:17:13  *** inaltoas1nistra has quit IRC
154 2016-03-03T12:19:14  *** inaltoasinistra has joined #bitcoin-core-dev
155 2016-03-03T12:31:52  <GitHub58> [bitcoin] laanwj opened pull request #7637: Fix memleak in TorController [rework] (master...2016_03_torcontrol_leak) https://github.com/bitcoin/bitcoin/pull/7637
156 2016-03-03T12:32:07  <GitHub143> [bitcoin] laanwj closed pull request #7610: Fix memleak in TorController (master...2016/02/torctrl_memleak) https://github.com/bitcoin/bitcoin/pull/7610
157 2016-03-03T12:37:08  *** xiangfu has quit IRC
158 2016-03-03T12:43:33  *** rubensayshi has quit IRC
159 2016-03-03T12:56:16  <GitHub137> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1b68de35250e...7f001bdf641d
160 2016-03-03T12:56:17  <GitHub137> bitcoin/master 5ecfa36 Jonas Schnelli: Remove openssl info from init/log and from Qt debug window
161 2016-03-03T12:56:17  <GitHub137> bitcoin/master 7f001bd Wladimir J. van der Laan: Merge #7605: Remove openssl info from init/log and from Qt debug window...
162 2016-03-03T12:56:21  <GitHub45> [bitcoin] laanwj closed pull request #7605: Remove openssl info from init/log and from Qt debug window (master...2016/02/rm_openssl_log) https://github.com/bitcoin/bitcoin/pull/7605
163 2016-03-03T12:56:31  <GitHub59> [bitcoin] laanwj closed pull request #7586: fixes/refactoring for building against LibreSSL (master...2016/02/fix_openssl_libressl) https://github.com/bitcoin/bitcoin/pull/7586
164 2016-03-03T12:57:10  *** rubensayshi has joined #bitcoin-core-dev
165 2016-03-03T12:58:53  *** Giszmo has joined #bitcoin-core-dev
166 2016-03-03T13:06:06  *** gevs has joined #bitcoin-core-dev
167 2016-03-03T13:06:07  *** gevs has joined #bitcoin-core-dev
168 2016-03-03T13:20:03  *** berndj-blackout is now known as berndj
169 2016-03-03T13:32:44  <GitHub83> [bitcoin] laanwj reopened pull request #7517: test: script_error checking in script_invalid tests (master...2016_02_test_script_errors) https://github.com/bitcoin/bitcoin/pull/7517
170 2016-03-03T13:41:03  *** Ylbam has quit IRC
171 2016-03-03T13:43:11  *** jl2012 has quit IRC
172 2016-03-03T13:52:03  *** jl2012 has joined #bitcoin-core-dev
173 2016-03-03T13:52:45  *** Ylbam has joined #bitcoin-core-dev
174 2016-03-03T13:59:41  *** jarret has joined #bitcoin-core-dev
175 2016-03-03T14:10:26  <GitHub6> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7f001bdf641d...3368895c3b94
176 2016-03-03T14:10:26  <GitHub6> bitcoin/master 5a2b1c0 Alex Morcos: Don't resend wallet txs that aren't in our own mempool
177 2016-03-03T14:10:27  <GitHub6> bitcoin/master 3368895 Wladimir J. van der Laan: Merge #7521: Don't resend wallet txs that aren't in our own mempool...
178 2016-03-03T14:10:31  <GitHub64> [bitcoin] laanwj closed pull request #7521: Don't resend wallet txs that aren't in our own mempool (master...testBeforeRelay) https://github.com/bitcoin/bitcoin/pull/7521
179 2016-03-03T14:20:31  *** helo_ is now known as helo
180 2016-03-03T14:21:52  *** mesmer_ has quit IRC
181 2016-03-03T14:25:06  *** chris2000 has quit IRC
182 2016-03-03T14:29:25  *** paveljanik has quit IRC
183 2016-03-03T14:43:10  <jouke> wallet config has spendzeroconfchange=0, but with 0.12 it does create transactions with inputs that were not confirmed yet.
184 2016-03-03T14:59:09  *** Guyver2 has joined #bitcoin-core-dev
185 2016-03-03T15:00:00  *** zooko has joined #bitcoin-core-dev
186 2016-03-03T15:04:18  <wumpus> jouke: ugh! can you open an issue?
187 2016-03-03T15:06:04  <wumpus> strange, I wonder what changed in that code, looking at CWalletTx::IsTrusted() it still returns false when depth is not >=1 and that option isn't set
188 2016-03-03T15:07:21  <wumpus> so is it spending outputs that aren't IsTrusted?
189 2016-03-03T15:08:12  <wumpus> shouldn't be, AvailableCoins is always called with fOnlyConfirmed, and it skips coins that aren't trusted if that is set
190 2016-03-03T15:08:17  <wumpus> no, I don't see how this could happen :/
191 2016-03-03T15:08:44  <wumpus> maybe there was a reorg, and a transaction went from 1 to 0 confirms?
192 2016-03-03T15:12:18  <jonasschnelli> jouke, wumpus: interesting... testing local
193 2016-03-03T15:17:03  <jonasschnelli> Can't reproduce in a local test.
194 2016-03-03T15:17:19  <jonasschnelli> -spendzeroconfchange=0 worked for me
195 2016-03-03T15:17:27  <jonasschnelli> maybe a reorg thing.. yes.
196 2016-03-03T15:18:13  *** frankenm_ has quit IRC
197 2016-03-03T15:19:55  *** ebfull has joined #bitcoin-core-dev
198 2016-03-03T15:27:10  <GitHub120> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3368895c3b94...7f966713a413
199 2016-03-03T15:27:10  <GitHub120> bitcoin/master fa5f193 MarcoFalke: [travis] Exit early when check-doc.py fails
200 2016-03-03T15:27:11  <GitHub120> bitcoin/master 7f96671 Wladimir J. van der Laan: Merge #7455: [travis] Exit early when check-doc.py fails...
201 2016-03-03T15:27:15  <GitHub163> [bitcoin] laanwj closed pull request #7455: [travis] Exit early when check-doc.py fails (master...Mf1601-travisCheckDoc) https://github.com/bitcoin/bitcoin/pull/7455
202 2016-03-03T15:32:56  *** TZander has quit IRC
203 2016-03-03T15:46:46  *** paveljanik has joined #bitcoin-core-dev
204 2016-03-03T15:50:06  *** wumpus has quit IRC
205 2016-03-03T15:50:49  *** wumpus has joined #bitcoin-core-dev
206 2016-03-03T15:51:28  *** CyrusV has quit IRC
207 2016-03-03T16:04:38  *** CyrusV has joined #bitcoin-core-dev
208 2016-03-03T16:08:41  *** laurentmt has joined #bitcoin-core-dev
209 2016-03-03T16:11:21  *** jtimon has joined #bitcoin-core-dev
210 2016-03-03T16:14:34  *** Thireus has quit IRC
211 2016-03-03T16:14:48  *** zooko has quit IRC
212 2016-03-03T16:31:39  *** laurentmt has quit IRC
213 2016-03-03T16:31:44  *** davec_ has quit IRC
214 2016-03-03T16:32:17  *** BashCo has quit IRC
215 2016-03-03T16:32:23  *** davec has joined #bitcoin-core-dev
216 2016-03-03T16:33:35  *** Cheeseo has quit IRC
217 2016-03-03T16:34:25  *** inaltoasinistra has quit IRC
218 2016-03-03T17:00:09  *** BashCo has joined #bitcoin-core-dev
219 2016-03-03T17:10:44  *** Cheeseo has joined #bitcoin-core-dev
220 2016-03-03T17:10:44  *** Cheeseo has joined #bitcoin-core-dev
221 2016-03-03T17:27:35  *** zooko has joined #bitcoin-core-dev
222 2016-03-03T17:29:17  *** droark has quit IRC
223 2016-03-03T17:38:12  *** gevs has quit IRC
224 2016-03-03T17:39:20  *** Cheeseo has quit IRC
225 2016-03-03T17:42:01  *** Thireus has joined #bitcoin-core-dev
226 2016-03-03T18:06:08  *** Cheeseo has joined #bitcoin-core-dev
227 2016-03-03T18:06:08  *** Cheeseo has joined #bitcoin-core-dev
228 2016-03-03T18:33:17  *** chris2000 has joined #bitcoin-core-dev
229 2016-03-03T18:46:25  *** tr0nk has joined #bitcoin-core-dev
230 2016-03-03T18:57:18  *** tr0nk has quit IRC
231 2016-03-03T18:59:53  *** MarcoFalke has quit IRC
232 2016-03-03T19:00:00  <gmaxwell> Meeting time?
233 2016-03-03T19:00:08  <Luke-Jr> yep
234 2016-03-03T19:01:01  <gmaxwell> jonasschnelli: wumpus: phantomcircuit: petertodd: sipa: paveljanik: sdaftuar: morcos: BlueMatt:
235 2016-03-03T19:02:23  <petertodd> hi
236 2016-03-03T19:03:01  <gmaxwell> petertodd: I figured we should wait for some more people to show to start.
237 2016-03-03T19:03:28  <sdaftuar> present
238 2016-03-03T19:04:11  <sipa> present
239 2016-03-03T19:05:31  <CodeShark> Hello
240 2016-03-03T19:05:49  <gmaxwell> cfields: btcdrak: CodeShark:
241 2016-03-03T19:06:04  *** zooko has quit IRC
242 2016-03-03T19:06:26  <gmaxwell> #startmeeting
243 2016-03-03T19:06:26  <lightningbot> Meeting started Thu Mar  3 19:06:26 2016 UTC.  The chair is gmaxwell. Information about MeetBot at http://wiki.debian.org/MeetBot.
244 2016-03-03T19:06:26  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
245 2016-03-03T19:06:33  <gmaxwell> #topic Agenda
246 2016-03-03T19:06:52  <gmaxwell> What things need to be discussed today?
247 2016-03-03T19:07:21  <CodeShark> Versionbits, segwit status
248 2016-03-03T19:08:06  <gmaxwell> okay lets start on versionbits for now and we'll see what else gets raised?
249 2016-03-03T19:08:12  <gmaxwell> #topic Versionbits (BIP9)
250 2016-03-03T19:08:21  <btcdrak> hi
251 2016-03-03T19:08:42  <sipa> i'm about to push a few changes to 7575 (non semantic ones), and it should be ready for review
252 2016-03-03T19:08:49  <gmaxwell> Sipa has been working on refining the proposal and has made some recent changes which I think are pretty good-- eliminate some corner cases around start/stop.
253 2016-03-03T19:09:12  <btcdrak> The BIP update is looking nice.
254 2016-03-03T19:09:15  <CodeShark> Yes, I like the latest changes
255 2016-03-03T19:09:16  <sipa> so BIP9 currently guarantees that as long as the start/end times of deployments are non-overlapping, the bits are never ambiguous
256 2016-03-03T19:09:44  <sipa> so no need for dependency tracking between different deployments, just choose start/end times sanely
257 2016-03-03T19:10:28  <CodeShark> Yes, that's what I had in mind in my implementation but sipa did it better :)
258 2016-03-03T19:10:38  <sipa> 7575 currently implements that, and has tests (for the low-level logic, not for the integration with consensus logic)
259 2016-03-03T19:11:05  <gmaxwell> I continue to be a little concerned that the activation threshold may be too high considering the low variance triggering mechenism, and activation delay. But I see nothing to do about that except try it and see if our first versionbits fork attempt fails to activate in a reasonable time.
260 2016-03-03T19:11:29  <sipa> we can reduce the threshold if needed
261 2016-03-03T19:11:49  <sipa> increasing is harder, as it may cause warning to not fire
262 2016-03-03T19:12:08  <sdaftuar> sipa: is 7575 going to eventually include deployment code for BIP68/112/113, or are you going to remove the last commit for a different PR?
263 2016-03-03T19:12:27  <sipa> sdaftuar: going to remove the last commit, and replace with whatever is agreed
264 2016-03-03T19:12:29  <gmaxwell> Thats a good argument. (that it's easier to reduce the threshold)
265 2016-03-03T19:12:47  <btcdrak> sdaftuar: I have the deployment code done for VB
266 2016-03-03T19:13:07  <morcos> sipa: should the regtest window be smaller than 2016?
267 2016-03-03T19:13:19  <sdaftuar> btcdrak: ok great.  i was just going to say that saving the deployment for a subsequent PR might be easier for reviewing tests, etc
268 2016-03-03T19:13:49  <morcos> just seems like it'll make the tests less cumbersome if you want to watch what happens as you go up and down through a couple different windows
269 2016-03-03T19:13:50  <btcdrak> I was going to say, regtest with 2016 retarget is cumbersome
270 2016-03-03T19:13:55  <gmaxwell> we need to fix regtest to not fall over at retargeting.
271 2016-03-03T19:14:01  <sdaftuar> i think that is fixed
272 2016-03-03T19:14:03  <morcos> didn't we do that
273 2016-03-03T19:14:08  <gmaxwell> oh sorry! :)
274 2016-03-03T19:14:10  <sdaftuar> but it still might be cumbersome to generate long chains
275 2016-03-03T19:14:18  <sipa> yes, regtest just never changes difficulty now
276 2016-03-03T19:14:27  <btcdrak> it's cumbersome to generate long chains, since there are two retarget windows required.
277 2016-03-03T19:14:40  <sipa> but good point; i can set the regtest window/threshold lower
278 2016-03-03T19:14:49  <cfields> whoops, present. thanks gmaxwell.
279 2016-03-03T19:14:51  <btcdrak> sipa: +1
280 2016-03-03T19:14:52  <gmaxwell> why is typing setgenerate 4032 a problem?
281 2016-03-03T19:15:01  <sdaftuar> however i also worry that we're no longer testing mainnet parameters, and the consensus parameters are duplicated for each chain
282 2016-03-03T19:15:07  <sipa> gmaxwell: you want generate 4032
283 2016-03-03T19:15:16  <btcdrak> gmaxwell: it's too much for RPC tests
284 2016-03-03T19:15:24  <sipa> gmaxwell: setgenerate starts the internal miner with the specified number of cores; it no longer has special casing for regtest
285 2016-03-03T19:15:28  <morcos> it just takes a little longer...
286 2016-03-03T19:15:39  <gmaxwell> I do like to avoid avoidable differences between regtest and mainnet.
287 2016-03-03T19:16:16  <gmaxwell> perhaps the answer if it's taking to long is to make regtest even faster?
288 2016-03-03T19:16:36  <sipa> reintroduce SSE mining code? :p
289 2016-03-03T19:16:44  <btcdrak> :p
290 2016-03-03T19:16:52  <gmaxwell> I meant lower the difficulty. :)
291 2016-03-03T19:17:07  <morcos> 12 secs
292 2016-03-03T19:17:08  <sipa> the regtest difficulty is 1/2000000000
293 2016-03-03T19:17:25  <sipa> you can at most get a 2x speedup
294 2016-03-03T19:17:38  <morcos> i think it would make the rpc test for this pretty slow as i imagine you'd need to do that many times
295 2016-03-03T19:17:50  <gmaxwell> OK, suggestion withdrawn.
296 2016-03-03T19:18:08  * paveljanik is late, sorry
297 2016-03-03T19:18:23  <sdaftuar> i worry more that a typo in the mainnet chain's deployment bitmask might go unnoticed/untested
298 2016-03-03T19:18:40  <gmaxwell> (why is it so slow? 6 seconds for 4k blocks seems like a lot)
299 2016-03-03T19:19:13  <sdaftuar> would anything catch that?
300 2016-03-03T19:19:17  <sipa> i'm still fine with lower window for regtest
301 2016-03-03T19:19:41  <gmaxwell> sdaftuar: review; I guess. (hahaha)
302 2016-03-03T19:20:02  *** zooko has joined #bitcoin-core-dev
303 2016-03-03T19:20:06  <btcdrak> gmaxwell: it's much slower on RPC tests
304 2016-03-03T19:20:40  <sdaftuar> especially if there's stuff in your mempool right?
305 2016-03-03T19:21:08  <sdaftuar> blockindex consistency checks and mempool consistency checks both add up i guess
306 2016-03-03T19:21:21  <morcos> maybe we didn't fix everything...  blocks 4k -> 8k = 32 secs,   blocks 8k -> 12k = 53 secs
307 2016-03-03T19:21:22  <sdaftuar> i'd guess*
308 2016-03-03T19:21:30  <btcdrak> yeah it's like 45 seconds for me
309 2016-03-03T19:21:32  <sdaftuar> blockindex checks are n^2 no?
310 2016-03-03T19:21:38  <sdaftuar> er
311 2016-03-03T19:21:45  <morcos> i suppose..  i think we're in the weeds
312 2016-03-03T19:21:48  <sdaftuar> yeah sorry
313 2016-03-03T19:22:20  <gmaxwell> So, sipa what do you need now for versionbits?
314 2016-03-03T19:23:09  <sipa> let me push a few changes, and then review
315 2016-03-03T19:23:18  <sipa> and tests are welcome
316 2016-03-03T19:23:43  <gmaxwell> #action after sipa pushes a few changes; reivew/test 7575, review BIP9
317 2016-03-03T19:24:11  <gmaxwell> Move on to segwit status? anyone have other agenda items to add?
318 2016-03-03T19:24:24  <paveljanik> feefilter review etc. please
319 2016-03-03T19:24:36  <morcos> and i hae a quick comment on tx backlog
320 2016-03-03T19:24:39  <paveljanik> BIP113
321 2016-03-03T19:24:58  <gmaxwell> k, lets do txbacklog right now.
322 2016-03-03T19:24:58  <Luke-Jr> I still think feefilter should be a little more flexible.
323 2016-03-03T19:25:02  <gmaxwell> #topic txbacklog
324 2016-03-03T19:25:30  <Luke-Jr> is there one?
325 2016-03-03T19:25:33  <morcos> i was wondering what kind of improvements are acceptable for minor releases
326 2016-03-03T19:25:37  <paveljanik> s/113/133/
327 2016-03-03T19:25:51  <sdaftuar> CPFP mining! :)
328 2016-03-03T19:25:56  <sipa> morcos: in response to an urgent problem, i'd say "anything"
329 2016-03-03T19:26:03  <morcos> i've noticed block validation seems to have slowed down significantly..  my theory is this is due to the daily cache flush and now many txs in blocks are older than that
330 2016-03-03T19:26:09  <morcos> this isn't urgent for sure
331 2016-03-03T19:26:12  <sipa> ok
332 2016-03-03T19:26:32  <gmaxwell> Right now there has been an increase in tx with fees over 1 satoshi per byte. The months standing background spam load of a around a gigabyte below that seems largely unchanged to me.
333 2016-03-03T19:26:36  <morcos> but it seems to me if we can correctly fix the "write but don't flush" aspect of the coinsviewcache, then that should be a significant performance boost
334 2016-03-03T19:27:08  <morcos> i guess it depends on whether we think validation times are a significant bottleneck for anything
335 2016-03-03T19:27:08  <sipa> morcos: yes...
336 2016-03-03T19:27:19  <gmaxwell> morcos: I've noticed the startup checks being much slower and was wondering if we'd made some regression someplace. Haven't tried bisecting.
337 2016-03-03T19:27:27  <petertodd> morcos: until we change to sending blocks before validating them they do add up
338 2016-03-03T19:27:44  <Luke-Jr> has anyone looked into whether the new txs are real or spam?
339 2016-03-03T19:28:05  <gmaxwell> Luke-Jr: some people have, petertodd was tweeting some analysis that strongly supported the latter.
340 2016-03-03T19:28:08  <petertodd> Luke-Jr: yeah, they look like long chains where eventually everything goes back to the sender, apaprently
341 2016-03-03T19:28:15  <petertodd> Luke-Jr: but no formal writeups exist yet
342 2016-03-03T19:28:15  <Luke-Jr> hmm
343 2016-03-03T19:28:21  <morcos> heh, you mean short chains..  woo hoo for chain limits!
344 2016-03-03T19:28:40  <Luke-Jr> any patterns to identify it with?
345 2016-03-03T19:28:40  <petertodd> morcos: no, they're long chains - once the txs confirm the chain is extended further
346 2016-03-03T19:29:29  <gmaxwell> in general most wallets are responding well (hurray! big improvement from 6 months ago) though not all.
347 2016-03-03T19:29:53  <petertodd> gmaxwell: speaking of, I noticed greenaddress has rbf code in their github repo
348 2016-03-03T19:29:57  <morcos> it looks to me like the backlog is diminishing as well
349 2016-03-03T19:29:57  <petertodd> gmaxwell: (for sending)
350 2016-03-03T19:30:56  <gmaxwell> petertodd: interesting, yes.. gait has been working on that; I think he was off in a design rathole on how to best support updating with additional outputs.
351 2016-03-03T19:31:23  <petertodd> gmaxwell: yeah, lots of possible ways wallets can do that, some of them quite different from how wallets work right now
352 2016-03-03T19:31:24  <gmaxwell> FWIW, with the new proposal for schnorr aggregate signatures, updating for more outputs will be much more attractive.
353 2016-03-03T19:31:38  <cfields> gmaxwell: speaking of, the -mintxfee behavior change may be worth a quick discussion.
354 2016-03-03T19:32:06  <sipa> cfields: the -paytxfee change you mean? :)
355 2016-03-03T19:32:12  <sipa> (too many fee parameters...)
356 2016-03-03T19:32:19  <petertodd> gmaxwell: oh! that's a good point!
357 2016-03-03T19:33:03  <cfields> sipa: er yes
358 2016-03-03T19:33:06  <morcos> i think we just bungled not more clearly announcing the change in semantics for paytxfee
359 2016-03-03T19:33:52  <morcos> surprising none of us flagged that as important at the time of the PR...  which does raise another issue, we should have a checklist of things to revisit before release
360 2016-03-03T19:34:00  <gmaxwell> Did we know we really changed them? my view on the history was that it was changed to not round a long time ago, but another bug covered it up. That bug was fixed, and no one realized an announcement was needed.
361 2016-03-03T19:34:10  <morcos> multiple times now we've said, ok we'll just need to fix that before release, and then forgotten or almost so
362 2016-03-03T19:34:24  <morcos> gmaxwell: oh perhaps?
363 2016-03-03T19:34:27  <Luke-Jr> morcos: well, the change in behaviour is definitely correct
364 2016-03-03T19:34:43  <gmaxwell> I'm not sure that even if I realized it was a change I would have put "fee computation more accurate" as high importance-- since mining priority was changed to be precise a really long time ago. (0.6?)
365 2016-03-03T19:35:01  <sipa> morcos: when i saw that discussion, i remembered the "fPayAtLeastCustomFee" global and associated problems, but I don't think I ever realized that that global and its default value equal to true was ever released
366 2016-03-03T19:35:42  *** Don_John has joined #bitcoin-core-dev
367 2016-03-03T19:35:45  <gmaxwell> yea, I saw that fix but don't think I realized that it was ever in a release. When sipa asked me about paytxfee yesturday I told him it was changed to be accurate forever ago.
368 2016-03-03T19:35:56  <gmaxwell> So I think thats the sequence of errors here.
369 2016-03-03T19:36:13  <gmaxwell> A checklist would be useful, though I don't know if it would have saved us here.
370 2016-03-03T19:36:31  <sipa> so what i think happened is that at some point we switched the mining code to be per byte instead of per kb, later that global was introduced which implicitly retained the behaviour of "rounding up to 1000 bytes for fee calculation" even though the rest of the code was updated to be per byte, and only now, with the global going away, we actually get the accurate change
371 2016-03-03T19:36:34  <gmaxwell> asking people to document if a bug being fixed was ever released might have helped.
372 2016-03-03T19:36:36  <morcos> yeah , a checklist on changing behavior of any options or rpc calls being properly documented
373 2016-03-03T19:36:58  <morcos> another example is -maxsigcachesize
374 2016-03-03T19:37:04  <sipa> and i expect that people who made these changes were aware of it, as they updated the rpc tests accordingly, but not review
375 2016-03-03T19:37:08  <morcos> i pity the poor fool who has that set to 100000
376 2016-03-03T19:37:50  <gmaxwell> you don't have 100 gb ram?
377 2016-03-03T19:37:52  <Luke-Jr> ideally we should probably do the release notes in the PR itself
378 2016-03-03T19:37:59  <morcos> i'm not sure how many people would catch all these warnings in the 2 foot think binder of release notes, but its still good to have them
379 2016-03-03T19:38:37  <gmaxwell> I don't think it was a big deal here, but it could have been one.
380 2016-03-03T19:38:37  <sipa> well if we'd have warning for unknown options, we can just switch to a practice of renaming them whenever their meaning changes
381 2016-03-03T19:38:41  <CodeShark> make sure to say "WARNING" first so it's searchable :)
382 2016-03-03T19:38:57  <btcdrak> yeah I've been meaning to suggest we add at least brief release note documentation in PRs
383 2016-03-03T19:39:14  <sipa> btcdrak: i always do (or try to...)
384 2016-03-03T19:39:23  <gmaxwell> okay, we're going on a tangent.
385 2016-03-03T19:39:36  <sipa> going on a tangent is a sin
386 2016-03-03T19:39:41  <gmaxwell> Anything more to say about backlog before we move to talk fee filter?
387 2016-03-03T19:39:43  <morcos> oh no
388 2016-03-03T19:39:48  <CodeShark> no trig puns
389 2016-03-03T19:39:58  <sipa> CodeShark: i co-sign that
390 2016-03-03T19:39:58  <gmaxwell> My sides hurt.
391 2016-03-03T19:40:00  <btcdrak> sipa: can you cosign this?
392 2016-03-03T19:40:12  <Luke-Jr> lol
393 2016-03-03T19:40:23  <Luke-Jr> ♥ sipa
394 2016-03-03T19:40:26  <sdaftuar> so how about that fee filter
395 2016-03-03T19:40:33  <gmaxwell> #topic feefilter
396 2016-03-03T19:40:45  <morcos> it seems to work pretty well
397 2016-03-03T19:40:49  <gmaxwell> Feefilter is awesome. I have not yet run it.
398 2016-03-03T19:41:00  <Luke-Jr> sorry, I need to run.. I think feefilter at least needs some kind of "mode" for things like "how do we measure size" etc, but not a huge deal
399 2016-03-03T19:41:05  <morcos> i mentioned in another context, it reduces tx send and rx bandwidth by around 40+%
400 2016-03-03T19:41:28  <gmaxwell> thats fantastic.
401 2016-03-03T19:41:28  <morcos> Luke-Jr: I'm basically of the mindset that we don't introduce complication until we need it
402 2016-03-03T19:41:47  <morcos> its totally optional, so no reason not to replace it later with a more generic one if we ever bother implementing
403 2016-03-03T19:42:02  <gmaxwell> We will not run out of message types, so we could introduce a modefilter later. I support that thinking.
404 2016-03-03T19:42:11  <morcos> it seems to me the message type is the version, yep
405 2016-03-03T19:42:19  <gmaxwell> I expect the way relay works to change substantially in the next couple years; so we should probably not overdesign here.
406 2016-03-03T19:43:09  <morcos> i need to do a trivial pr rebase, but i guess it just needs more review
407 2016-03-03T19:43:10  *** tr0nk has joined #bitcoin-core-dev
408 2016-03-03T19:43:23  <morcos> i'm not sure what there is to discuss
409 2016-03-03T19:43:38  <gmaxwell> Okay, I will test and review. Thanks for working on this.
410 2016-03-03T19:43:50  <morcos> sure
411 2016-03-03T19:43:58  <gmaxwell> #action Test and review fee filter. Morcos reports unicorns and rainbows result.
412 2016-03-03T19:44:09  <paveljanik> great!
413 2016-03-03T19:44:14  <morcos> well all depends on your test setup i guess.. :)
414 2016-03-03T19:44:20  <gmaxwell> #topic CPFP mining
415 2016-03-03T19:44:31  <gmaxwell> sdaftuar: hows it going?
416 2016-03-03T19:44:33  <sdaftuar> it's awesome.
417 2016-03-03T19:44:53  <sdaftuar> i've been running live for the last two days
418 2016-03-03T19:45:16  <btcdrak> The PR number is #7600
419 2016-03-03T19:45:20  <sdaftuar> comparing existing mining algorithm to new one
420 2016-03-03T19:45:25  <sdaftuar> every ~128 tx's or so
421 2016-03-03T19:45:57  <sdaftuar> looking at the last call to CNB before a block is found, i see a 72% increase in fee/block on the last 144 data points
422 2016-03-03T19:45:58  <gmaxwell> I believe it should be making some pretty significant differences in selection from what I've seen. A number of users of OTHERBRAND wallet that has no fee estimation and always spends unconfirmed change seem to frequently produce chains of very low fee, very high fee (after realizing they needed more fee from the first tx).
423 2016-03-03T19:46:08  <morcos> 72% ?!?!??!
424 2016-03-03T19:46:15  <sdaftuar> that could obviously be due to a small number of tx's that aren't getting mined for extended periods
425 2016-03-03T19:46:26  <sdaftuar> but geez we need this deployed, i think
426 2016-03-03T19:46:41  <btcdrak> amazing
427 2016-03-03T19:46:42  <sipa> sdaftuar: i believe that test would result in an exaggerated result
428 2016-03-03T19:46:48  <gmaxwell> the effect is likely exagerated due to the pattern I just described: the human controlled fees are exagerating the needed increase.
429 2016-03-03T19:47:06  <sipa> sdaftuar: as you're not actually creating blocks on the network with the new CPFP algorithm, i guess?
430 2016-03-03T19:47:09  <sdaftuar> yep
431 2016-03-03T19:47:10  <sdaftuar> correct
432 2016-03-03T19:47:21  <sdaftuar> so if a tx stays around for a day, and isn't selected by the old code, you'd count it over and over
433 2016-03-03T19:47:33  <sipa> sdaftuar: meaning that in a real setting, those "better" transactions would be mined once and cleaned up, reducing the effect for later blocks
434 2016-03-03T19:47:37  <sipa> right,
435 2016-03-03T19:47:37  <sdaftuar> correct
436 2016-03-03T19:47:47  <sipa> sdaftuar: how about performance?
437 2016-03-03T19:48:01  <sdaftuar> so there are three areas of performance to consider
438 2016-03-03T19:48:11  <sdaftuar> one is the additional work of the mempool to keep the index
439 2016-03-03T19:48:19  <sdaftuar> another is the part of CNB before TestBlockValidity is called
440 2016-03-03T19:48:38  <sdaftuar> and the last is the time TestBlockValidity takes (much larger than the rest of CNB, which is why i think it makes sense to split it out)
441 2016-03-03T19:48:58  <gmaxwell> (whom ever makes the lay summary, please don't report 72% increase as what CPFP does; in consideration of sipa's above point about N-fold counting)
442 2016-03-03T19:49:19  <sdaftuar> the mempool work isn't really a steady state increase, the concern i think is in what happens when a block is connected
443 2016-03-03T19:49:29  <sdaftuar> because then we have to update all the scores for every in-block transaction's descendants
444 2016-03-03T19:49:54  <morcos> gmaxwell: also the previous number he reported to me was 1%.. :)
445 2016-03-03T19:50:08  <sdaftuar> (when you add a tx to the mempool, you statically count its ancestors once, so that's basically negligible additional work)
446 2016-03-03T19:50:40  <sdaftuar> so i timed that extra delay in mempool.removeForBlock
447 2016-03-03T19:50:44  <morcos> but i think it is a good point, that if the increase is sometimes very big, its important for miners to take it...  presumably the average increase wouldn't ever be much different from 0, as we don't see txs permantely residing in mempool
448 2016-03-03T19:50:46  <sdaftuar> and reported some numbers in #7594
449 2016-03-03T19:51:14  <sdaftuar> looks like what i saw was an increase from an average of 10.9ms to 11.2ms
450 2016-03-03T19:51:26  <sdaftuar> that was on half a month's data from october
451 2016-03-03T19:51:32  <sdaftuar> er 10 days i guess actually
452 2016-03-03T19:52:04  <sdaftuar> so i figure that's negligible enough to not really worry about, especially because if we really cared, we could make block relay happen while the mempool was still being updated, though it'd take some work
453 2016-03-03T19:52:13  <gmaxwell> do we worry that CPFP's utility is compromised without package relay? -- I guess these measurements suggest its not.
454 2016-03-03T19:52:22  <sdaftuar> moving on to CreateNewBlock's performance:
455 2016-03-03T19:52:36  <sdaftuar> vast majority of CNB's total time is taken up by TestBlockValidity
456 2016-03-03T19:53:06  <CodeShark> sorry to interrupt - we only have 8 minutes and I wanted to discuss segwit
457 2016-03-03T19:53:16  <sdaftuar> somehow, TBV is slightly faster using the new code than the old one.  i haven't dived into it, but my guess is that maybe it's faster to look up mempool inputs than pcoinsTip inputs?
458 2016-03-03T19:53:43  <sdaftuar> that speed increase is actually larger than the small hit to performance on the rest of CNB, so it's actually faster in total.  anyway numbers are in the PR #7600
459 2016-03-03T19:53:45  <morcos> gmaxwell: i don't see that as a big concern...  i think it'll likely become common practice to avoid fees so small that they get evicted unless its actual spam.  and CPFP will be useful for when you guess wrong on getting confirmed quickly
460 2016-03-03T19:53:46  <sdaftuar> i think this is a clear win
461 2016-03-03T19:54:06  <gmaxwell> sdaftuar: it sounds great, what now do you think we need to do to move forward?
462 2016-03-03T19:54:27  <sdaftuar> review! i broke the work into 3 PR's for review.  one just adds the ancestor feerate index to the mempool (7594)
463 2016-03-03T19:54:29  <gmaxwell> morcos: I guess thats one upside over the overly large mempool default size.
464 2016-03-03T19:54:38  <sdaftuar> another is by morcos, which refactors CNB
465 2016-03-03T19:54:49  <sdaftuar> and then 7600 builds on both with the change to CNB
466 2016-03-03T19:55:13  <morcos> #7598
467 2016-03-03T19:55:30  <gmaxwell> #action whip people into wroking on review for CFPF 7594 / 7598 / 7600  it's nicely broken up.
468 2016-03-03T19:55:39  <gmaxwell> Can we segwit for CodeShark?
469 2016-03-03T19:55:43  <CodeShark> lol
470 2016-03-03T19:55:44  <gmaxwell> #topic segwit status
471 2016-03-03T19:55:52  <CodeShark> we had a fork a few days ago
472 2016-03-03T19:56:05  <sipa> i haven't had time to investigate
473 2016-03-03T19:56:19  <sipa> my hope is that it is caused by miners running older versions of the code
474 2016-03-03T19:56:23  <sipa> and not something else
475 2016-03-03T19:56:27  <gmaxwell> Time for science then.
476 2016-03-03T19:56:43  <CodeShark> that's most probable - but we haven't narrowed down the conditional that actually caused it
477 2016-03-03T19:56:48  <sipa> i was planning on doing a segnet4 very soon, but we'd need to understand what's causing this first
478 2016-03-03T19:56:59  <morcos> well is there anyone stuck on the short fork?
479 2016-03-03T19:57:13  <CodeShark> I think there might still be a few
480 2016-03-03T19:57:26  <morcos> seems like would be helpful to know what errors they have and what code they are running
481 2016-03-03T19:57:36  <cfields> hmm, i'd be interested in taking a look there. sipa: any helpful references/context ?
482 2016-03-03T19:57:45  <gmaxwell> might be useful if regtest networks put their git build info in their version numbers. awful for privacy... but would be useful here.
483 2016-03-03T19:57:50  <sipa> cfields: CodeShark probably knows more
484 2016-03-03T19:58:10  <gmaxwell> (e.g. a chainparam to put that info in the subver)
485 2016-03-03T19:58:11  <cfields> ok. will ping CodeShark after
486 2016-03-03T19:58:22  <CodeShark> I think the offending block was something like 22130
487 2016-03-03T19:58:26  <CodeShark> or 22132
488 2016-03-03T19:58:29  <CodeShark> or somewhere around there
489 2016-03-03T19:59:12  <gmaxwell> okay So-- sounds good, a fleet of flying monkies will contemplate the segnet fork.  Posting forked IPs in the segwit IRC channel might get someone's attention.
490 2016-03-03T19:59:18  <btcdrak> it's in the logs of #segwit-dev
491 2016-03-03T19:59:22  <cfields> ok, thanks
492 2016-03-03T19:59:24  <morcos> whats the actual block we're on now?
493 2016-03-03T19:59:40  <CodeShark> 22769
494 2016-03-03T20:00:06  <CodeShark> https://segnet.smartbit.com.au/ is still stuck on 22153
495 2016-03-03T20:00:09  <gmaxwell> okay any emergencies worth going over?
496 2016-03-03T20:00:11  <CodeShark> so it's still running he old code
497 2016-03-03T20:00:31  <gmaxwell> #endmeeting
498 2016-03-03T20:00:31  <lightningbot> Meeting ended Thu Mar  3 20:00:31 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
499 2016-03-03T20:00:31  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-03-19.06.html
500 2016-03-03T20:00:31  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-03-19.06.txt
501 2016-03-03T20:00:31  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-03-19.06.log.html
502 2016-03-03T20:00:44  <gmaxwell> Thanks everyone (of course feel free to keep discussing!)
503 2016-03-03T20:01:57  <gmaxwell> Sorry we didn't get to all the topics.
504 2016-03-03T20:01:58  <morcos> we still need tests for the soft fork BIPS right
505 2016-03-03T20:02:15  *** chris2000 has quit IRC
506 2016-03-03T20:02:21  <morcos> and 7187 still needs to be merged as well..
507 2016-03-03T20:02:59  <btcdrak> morcos: I'm waiting on the python tests from sdaftuar for #7187
508 2016-03-03T20:03:36  *** chris200_ has joined #bitcoin-core-dev
509 2016-03-03T20:03:57  <gmaxwell> sdaftuar: if CPFP appears to be moderately stable, we might consider asking a moderately large miner to run it (in parallel to other stuff);  it would have most of it's usability benefit for the network if only one moderately large miner was running it.
510 2016-03-03T20:05:18  <sdaftuar> gmaxwell: yeah i was wondering if any miners might be set up to test the new code using their production parameters at least?  so that we can measure performance in production settings and know we haven't missed anything
511 2016-03-03T20:05:45  <sdaftuar> i thought it might make sense to wait until it was merged into master to ask someone to do that
512 2016-03-03T20:11:33  *** treehug88 has joined #bitcoin-core-dev
513 2016-03-03T20:21:14  <gmaxwell> sdaftuar: assuming that the surrounding enviroment is sufficently fail safe, even if it's a crash problem then it should be safe to try. but also no harm in getting some more maturity under its belt first.
514 2016-03-03T20:21:32  <gmaxwell> The only reason I suggested it is because there are at least a few users whos delays could be avoided by it.
515 2016-03-03T20:24:39  <sdaftuar> gmaxwell: that sounds reasonable to me.  do you have someone in mind to reach out to, or should i send out an email to the -dev list?
516 2016-03-03T20:32:45  *** fredrin has quit IRC
517 2016-03-03T20:35:04  *** fredrin has joined #bitcoin-core-dev
518 2016-03-03T20:37:30  <gmaxwell> sdaftuar: I have someone in mind.
519 2016-03-03T20:39:33  *** fredrin has quit IRC
520 2016-03-03T20:41:30  *** fredrin has joined #bitcoin-core-dev
521 2016-03-03T20:46:18  *** fredrin has quit IRC
522 2016-03-03T20:46:46  <sdaftuar> gmaxwell: cool, feel free to put them in touch with me
523 2016-03-03T20:46:57  *** fredrin has joined #bitcoin-core-dev
524 2016-03-03T20:52:34  *** Guest66849 has joined #bitcoin-core-dev
525 2016-03-03T20:52:41  *** Guest66849 has joined #bitcoin-core-dev
526 2016-03-03T20:52:42  *** Guest66849 is now known as schmidty
527 2016-03-03T21:02:44  *** jannes_ has quit IRC
528 2016-03-03T21:04:57  *** tr0nk has quit IRC
529 2016-03-03T21:24:00  *** xabbix has joined #bitcoin-core-dev
530 2016-03-03T21:41:27  *** chiwawa_ has joined #bitcoin-core-dev
531 2016-03-03T21:47:32  *** treehug88 has quit IRC
532 2016-03-03T21:56:06  *** tr0nk has joined #bitcoin-core-dev
533 2016-03-03T22:07:45  *** tr0nk has quit IRC
534 2016-03-03T22:14:40  *** tr0nk has joined #bitcoin-core-dev
535 2016-03-03T22:16:32  *** gevs has joined #bitcoin-core-dev
536 2016-03-03T22:26:45  *** Guyver2 has quit IRC
537 2016-03-03T22:32:45  *** laurentmt has joined #bitcoin-core-dev
538 2016-03-03T22:55:44  *** laurentmt has quit IRC
539 2016-03-03T22:57:56  *** chiwawa_ has quit IRC
540 2016-03-03T23:22:08  *** justanot1eruser is now known as justanotheruser