1 2016-04-07T00:01:02  <jtimon> never mind, origin/0.12 already has 68/112/113
  2 2016-04-07T00:14:55  *** Giszmo has joined #bitcoin-core-dev
  3 2016-04-07T00:36:30  *** zooko has joined #bitcoin-core-dev
  4 2016-04-07T00:54:54  *** Chris_Stewart_5 has quit IRC
  5 2016-04-07T01:06:29  *** PaulCapestany has quit IRC
  6 2016-04-07T01:08:51  *** PaulCapestany has joined #bitcoin-core-dev
  7 2016-04-07T01:11:03  *** Ylbam has quit IRC
  8 2016-04-07T01:16:54  *** btcdrak has quit IRC
  9 2016-04-07T01:30:06  *** dermoth has quit IRC
 10 2016-04-07T01:30:56  *** dermoth has joined #bitcoin-core-dev
 11 2016-04-07T01:39:45  *** RoyceX has joined #bitcoin-core-dev
 12 2016-04-07T01:39:46  *** RoyceX has joined #bitcoin-core-dev
 13 2016-04-07T01:41:56  *** Cheeseo has quit IRC
 14 2016-04-07T01:43:24  *** wallet42 has joined #bitcoin-core-dev
 15 2016-04-07T01:44:09  *** arubi has quit IRC
 16 2016-04-07T01:45:21  *** fengling has joined #bitcoin-core-dev
 17 2016-04-07T01:45:54  *** frankenmint has joined #bitcoin-core-dev
 18 2016-04-07T01:47:56  *** zooko has quit IRC
 19 2016-04-07T02:00:05  *** dermoth has quit IRC
 20 2016-04-07T02:00:57  *** dermoth has joined #bitcoin-core-dev
 21 2016-04-07T02:02:42  *** supasonic has quit IRC
 22 2016-04-07T02:03:08  *** supasonic has joined #bitcoin-core-dev
 23 2016-04-07T02:03:25  *** BCBot has quit IRC
 24 2016-04-07T02:06:28  *** BCBot has joined #bitcoin-core-dev
 25 2016-04-07T02:19:58  *** johnwhitton has joined #bitcoin-core-dev
 26 2016-04-07T02:33:27  *** supasonic has quit IRC
 27 2016-04-07T02:40:36  *** fengling has quit IRC
 28 2016-04-07T02:45:22  *** frankenmint has quit IRC
 29 2016-04-07T02:58:58  *** Squidicuz has joined #bitcoin-core-dev
 30 2016-04-07T03:00:19  *** hsmiths has quit IRC
 31 2016-04-07T03:00:42  *** Squidicc has quit IRC
 32 2016-04-07T03:00:48  *** hsmiths has joined #bitcoin-core-dev
 33 2016-04-07T03:04:13  *** zooko has joined #bitcoin-core-dev
 34 2016-04-07T03:14:02  *** johnwhitton has quit IRC
 35 2016-04-07T03:15:14  *** johnwhitton has joined #bitcoin-core-dev
 36 2016-04-07T03:23:31  *** jtimon has quit IRC
 37 2016-04-07T03:23:59  *** jtimon has joined #bitcoin-core-dev
 38 2016-04-07T03:25:11  *** Giszmo has quit IRC
 39 2016-04-07T03:33:02  *** Alopex has quit IRC
 40 2016-04-07T03:34:07  *** Alopex has joined #bitcoin-core-dev
 41 2016-04-07T03:48:11  *** gevs has quit IRC
 42 2016-04-07T03:50:03  *** gevs has joined #bitcoin-core-dev
 43 2016-04-07T03:51:20  *** aj has quit IRC
 44 2016-04-07T03:51:29  *** aj has joined #bitcoin-core-dev
 45 2016-04-07T04:03:29  *** fengling has joined #bitcoin-core-dev
 46 2016-04-07T04:34:07  *** johnwhitton has quit IRC
 47 2016-04-07T04:36:04  *** johnwhitton has joined #bitcoin-core-dev
 48 2016-04-07T05:11:15  *** frankenmint has joined #bitcoin-core-dev
 49 2016-04-07T05:23:10  *** Luke-Jr has quit IRC
 50 2016-04-07T05:27:57  *** Luke-Jr has joined #bitcoin-core-dev
 51 2016-04-07T05:39:21  *** zooko has quit IRC
 52 2016-04-07T05:40:56  *** fengling has quit IRC
 53 2016-04-07T05:42:30  *** arubi has joined #bitcoin-core-dev
 54 2016-04-07T05:49:31  *** zxzzt has quit IRC
 55 2016-04-07T05:49:42  *** morcos has quit IRC
 56 2016-04-07T05:49:43  *** sdaftuar has quit IRC
 57 2016-04-07T05:51:20  *** sdaftuar has joined #bitcoin-core-dev
 58 2016-04-07T05:51:32  *** morcos has joined #bitcoin-core-dev
 59 2016-04-07T05:51:38  *** zxzzt has joined #bitcoin-core-dev
 60 2016-04-07T05:53:44  *** johnwhitton has quit IRC
 61 2016-04-07T05:54:30  *** johnwhitton has joined #bitcoin-core-dev
 62 2016-04-07T06:00:06  *** dermoth has quit IRC
 63 2016-04-07T06:00:48  *** dermoth has joined #bitcoin-core-dev
 64 2016-04-07T06:03:00  *** johnwhitton has quit IRC
 65 2016-04-07T06:05:35  *** btcdrak has joined #bitcoin-core-dev
 66 2016-04-07T06:12:02  *** Alopex has quit IRC
 67 2016-04-07T06:12:45  *** Ylbam has joined #bitcoin-core-dev
 68 2016-04-07T06:13:07  *** Alopex has joined #bitcoin-core-dev
 69 2016-04-07T06:14:17  *** xiangfu has joined #bitcoin-core-dev
 70 2016-04-07T06:17:14  *** fengling has joined #bitcoin-core-dev
 71 2016-04-07T06:23:27  *** p15 has quit IRC
 72 2016-04-07T06:25:17  *** p15 has joined #bitcoin-core-dev
 73 2016-04-07T07:07:08  *** abritoid has joined #bitcoin-core-dev
 74 2016-04-07T07:08:11  *** p15_ has joined #bitcoin-core-dev
 75 2016-04-07T07:08:31  *** jtimon has quit IRC
 76 2016-04-07T07:10:47  *** p15 has quit IRC
 77 2016-04-07T07:21:25  <jonasschnelli> wumpus: does "getlabeladdress" would still make sense for labels only? https://github.com/bitcoin/bitcoin/pull/7729/files#diff-df7d84ff2f53fcb2a0dc15a3a51e55ceR2506
 78 2016-04-07T07:21:36  <jonasschnelli> What if an the same label is used for multiple addresses?
 79 2016-04-07T07:21:58  <wumpus> jonasschnelli: I don't think so, I say the same in my OP :) (see the discussion with Luke-Jr in the pull)
 80 2016-04-07T07:22:07  <jonasschnelli> Okay.
 81 2016-04-07T07:22:36  <wumpus> he's using the functionality for his miner and that was my only reason to make that consession, I suggested another way of working but haven't heard back.
 82 2016-04-07T07:22:38  <jonasschnelli> Haven't seen that.
 83 2016-04-07T07:23:16  <jonasschnelli> I cloned now the wallet, made it runnable in parallel and removing accounts. I take some parts out of 7729
 84 2016-04-07T07:25:06  <wumpus> awesome!
 85 2016-04-07T07:28:13  <wumpus> well I wouldn't blame you if you don't take getlabeladdress, it makes very little sense for labels and makes it necessary to keep around a CAccount structure we'd rather get rid of. I honestly think he should find a different solution
 86 2016-04-07T07:35:33  <jonasschnelli> Yes. I have removed it.
 87 2016-04-07T08:15:47  *** jannes has joined #bitcoin-core-dev
 88 2016-04-07T08:27:45  *** Guyver2 has joined #bitcoin-core-dev
 89 2016-04-07T08:29:10  *** ebfull has quit IRC
 90 2016-04-07T08:32:46  *** ebfull has joined #bitcoin-core-dev
 91 2016-04-07T08:44:57  *** rubensayshi has joined #bitcoin-core-dev
 92 2016-04-07T08:53:31  <GitHub110> [bitcoin] jonasschnelli opened pull request #7830: [Wallet] Add cloned wallet, remove accounts, reset version (master...2016/04/wallet2) https://github.com/bitcoin/bitcoin/pull/7830
 93 2016-04-07T09:10:23  *** hsmiths2 has joined #bitcoin-core-dev
 94 2016-04-07T09:10:32  *** hsmiths has quit IRC
 95 2016-04-07T09:23:56  *** Guyver2 has quit IRC
 96 2016-04-07T09:27:59  *** frankenmint has quit IRC
 97 2016-04-07T09:34:04  <GitHub72> [bitcoin] jonasschnelli opened pull request #7831: [CLI] refactor wallets RPC JSON conversions (master...2016/04/cli_conversion) https://github.com/bitcoin/bitcoin/pull/7831
 98 2016-04-07T09:52:54  *** BCBot has quit IRC
 99 2016-04-07T09:52:57  *** BCBot_ has joined #bitcoin-core-dev
100 2016-04-07T09:56:20  *** AaronvanW has joined #bitcoin-core-dev
101 2016-04-07T09:59:33  <wumpus> for anyone that wants to do perf measurements of their own I've open sourced the lmdb experiment, be sure to read README.md https://github.com/laanwj/bitcoin/tree/2016_04_mdb
102 2016-04-07T10:02:21  <sipa> If you manage to
103 2016-04-07T10:02:21  <sipa> +suffer financial or other losses due to this code I demand compensation for
104 2016-04-07T10:02:24  <sipa> +feelings of misplaced guilt.
105 2016-04-07T10:02:26  <sipa> LOL
106 2016-04-07T10:03:24  <wumpus> :-)
107 2016-04-07T10:03:44  *** p15_ has quit IRC
108 2016-04-07T10:04:54  *** p15 has joined #bitcoin-core-dev
109 2016-04-07T10:07:23  *** ebfull has quit IRC
110 2016-04-07T10:08:23  *** ebfull has joined #bitcoin-core-dev
111 2016-04-07T10:34:34  *** p15 has quit IRC
112 2016-04-07T10:58:29  *** ebfull has quit IRC
113 2016-04-07T10:59:42  *** ebfull has joined #bitcoin-core-dev
114 2016-04-07T10:59:52  <GitHub82> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3bc71e1572cb...bbaf5976af84
115 2016-04-07T10:59:52  <GitHub82> bitcoin/master 07398e8 Wladimir J. van der Laan: init: allow shutdown during 'Activating best chain...'...
116 2016-04-07T10:59:53  <GitHub82> bitcoin/master bbaf597 Wladimir J. van der Laan: Merge #7821: init: allow shutdown during 'Activating best chain...'...
117 2016-04-07T10:59:56  <GitHub122> [bitcoin] laanwj closed pull request #7821: init: allow shutdown during 'Activating best chain...' (master...2016_04_shutdown_during_activate_best_chain) https://github.com/bitcoin/bitcoin/pull/7821
118 2016-04-07T11:00:59  <GitHub0> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/4226aacdba7d0e1e22555dac69363b3b460a166b
119 2016-04-07T11:00:59  <GitHub0> bitcoin/0.12 4226aac Wladimir J. van der Laan: init: allow shutdown during 'Activating best chain...'...
120 2016-04-07T11:03:44  *** laurentmt has joined #bitcoin-core-dev
121 2016-04-07T11:07:31  <GitHub95> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/bbaf5976af84...1ddf0cee679d
122 2016-04-07T11:07:32  <GitHub95> bitcoin/master 2d1d658 Pieter Wuille: Track block download times per individual block...
123 2016-04-07T11:07:32  <GitHub95> bitcoin/master 0e24bbf Pieter Wuille: Self check after the last peer is removed
124 2016-04-07T11:07:33  <GitHub95> bitcoin/master 1ddf0ce Wladimir J. van der Laan: Merge #7804: Track block download times per individual block...
125 2016-04-07T11:07:41  <GitHub85> [bitcoin] laanwj closed pull request #7804: Track block download times per individual block (master...betterkicktimeout) https://github.com/bitcoin/bitcoin/pull/7804
126 2016-04-07T11:13:13  *** laurentmt has quit IRC
127 2016-04-07T11:16:41  <GitHub39> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/90f1d246d38803eb546c6652ddce5ebea55eec98
128 2016-04-07T11:16:41  <GitHub39> bitcoin/0.12 90f1d24 Pieter Wuille: Track block download times per individual block...
129 2016-04-07T11:19:29  *** cryptapus has joined #bitcoin-core-dev
130 2016-04-07T11:19:35  <GitHub161> [bitcoin] laanwj opened pull request #7832: Reduce block timeout to 10 minutes (master...2016_04_reduce_block_timeout) https://github.com/bitcoin/bitcoin/pull/7832
131 2016-04-07T11:29:22  *** wallet42 has quit IRC
132 2016-04-07T11:35:30  *** d_t has joined #bitcoin-core-dev
133 2016-04-07T11:35:39  *** randy-waterhouse has quit IRC
134 2016-04-07T11:38:25  *** xiangfu has quit IRC
135 2016-04-07T11:41:29  *** AaronvanW has quit IRC
136 2016-04-07T11:44:13  <jonasschnelli> wumpus: did you already try to run it (your LMDB branch) on a standard 64 bit Linux?
137 2016-04-07T11:44:29  <wumpus> yep
138 2016-04-07T11:44:39  *** AaronvanW has joined #bitcoin-core-dev
139 2016-04-07T11:44:54  <wumpus> passes the tests and seems to work
140 2016-04-07T11:45:18  <jonasschnelli> Okay. Then I'll give it a try on my Debian Server (fresh sync from random peers).
141 2016-04-07T11:45:56  *** fengling has quit IRC
142 2016-04-07T11:52:58  <GitHub3> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1ddf0cee679d...5851915a006a
143 2016-04-07T11:52:58  <GitHub3> bitcoin/master 62b9a55 Wladimir J. van der Laan: Reduce block timeout to 10 minutes...
144 2016-04-07T11:52:59  <GitHub3> bitcoin/master 5851915 Wladimir J. van der Laan: Merge #7832: Reduce block timeout to 10 minutes...
145 2016-04-07T11:53:05  <GitHub61> [bitcoin] laanwj closed pull request #7832: Reduce block timeout to 10 minutes (master...2016_04_reduce_block_timeout) https://github.com/bitcoin/bitcoin/pull/7832
146 2016-04-07T11:57:13  *** lamagra has joined #bitcoin-core-dev
147 2016-04-07T11:58:45  <jonasschnelli> wumpus: is there a reason to reserve 8GB for the chainstate2/data.mdb db?
148 2016-04-07T11:58:56  <jonasschnelli> or is that just on my end...
149 2016-04-07T11:59:09  <wumpus> well it's bound to not be too little, for now
150 2016-04-07T11:59:21  <wumpus> see https://github.com/laanwj/bitcoin/tree/2016_04_mdb#mapsize
151 2016-04-07T11:59:44  <jonasschnelli> Ah. The readme was shortened on my smartphone. Nice.
152 2016-04-07T11:59:54  <wumpus> you can patch the code to set it lower, but I didn't feel like finding the lower bound
153 2016-04-07T12:00:59  <GitHub32> [bitcoin] laanwj pushed 2 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/90f1d246d388...cada7c2418ef
154 2016-04-07T12:01:00  <GitHub32> bitcoin/0.12 4c3a00d Wladimir J. van der Laan: Reduce block timeout to 10 minutes...
155 2016-04-07T12:01:00  <GitHub32> bitcoin/0.12 cada7c2 Wladimir J. van der Laan: Fill in rest of release notes
156 2016-04-07T12:01:28  <jonasschnelli> > Only 64-bit. Sorry, life is not fair.
157 2016-04-07T12:01:29  <jonasschnelli> hah
158 2016-04-07T12:02:40  <wumpus> doing some last-minute tests, going to tag 0.12.0rc1 in a bit
159 2016-04-07T12:03:32  <assder> 0.12.1rc1?
160 2016-04-07T12:03:41  <wumpus> yes, .1
161 2016-04-07T12:05:32  * jonasschnelli is slowly dust his gitian builder
162 2016-04-07T12:07:27  *** fengling has joined #bitcoin-core-dev
163 2016-04-07T12:09:13  <wumpus> :D
164 2016-04-07T12:10:41  <sipa> hmm, wallet.py rpc test doesn't work here, even though i didn't change anything wallet related
165 2016-04-07T12:10:49  * sipa rebases
166 2016-04-07T12:11:08  <wumpus> on 0.12?
167 2016-04-07T12:11:32  <wumpus> Passed here: Running testscript wallet.py ... Tests successful Duration: 62 s
168 2016-04-07T12:11:56  *** fengling has quit IRC
169 2016-04-07T12:12:30  <sipa> no, master
170 2016-04-07T12:12:41  <sipa> Unexpected exception caught during testing: No JSON object could be decoded
171 2016-04-07T12:13:28  <sipa> let me try actual master
172 2016-04-07T12:14:01  <wumpus> seems to work fine here, too
173 2016-04-07T12:19:08  <sipa> hmm, master fails for me
174 2016-04-07T12:19:29  <sipa> actually, all rpc tests fail
175 2016-04-07T12:19:35  * sipa blames himself
176 2016-04-07T12:28:11  *** frankenmint has joined #bitcoin-core-dev
177 2016-04-07T12:28:27  *** zooko has joined #bitcoin-core-dev
178 2016-04-07T12:29:57  <sipa> eh, HTTP 403
179 2016-04-07T12:33:19  <sipa> how is the test framework supposed to authenticate?
180 2016-04-07T12:33:58  <MarcoFalke> rpcuser, rpcpassword
181 2016-04-07T12:33:59  <wumpus> there's only one way to get forbidden: if your IP isn't allowed to connect
182 2016-04-07T12:34:22  <sipa> ah, it writes a bitcoin.conf file
183 2016-04-07T12:34:28  <sipa> with username/password rt
184 2016-04-07T12:35:42  <wumpus> wrong user or password will get you HTTP_UNAUTHORIZED (401)
185 2016-04-07T12:38:33  <wumpus> no idea how an RPC test could end up connecting through a non-allowed IP though, afaik  none of the tests sets rpcallow
186 2016-04-07T12:39:41  <sipa> 2016-04-07 12:38:02 Received a POST request for / from 192.168.44.1:58356
187 2016-04-07T12:39:58  <sipa> why is it using my LAN address...?
188 2016-04-07T12:40:05  <wumpus> yes that seems wrong
189 2016-04-07T12:40:15  <wumpus> why is it binding on your LAN address
190 2016-04-07T12:40:18  <sipa> i played with iptables a while ago, perhaps i haven't rebooted yet
191 2016-04-07T12:41:16  <sipa> sorry for bothering you with it
192 2016-04-07T12:41:41  <wumpus> well I'd still like to know what caused this
193 2016-04-07T12:43:57  <sipa> iptables -t nat -A POSTROUTING -j MASQUERADE
194 2016-04-07T12:43:57  <sipa> iptables -A FORWARD -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
195 2016-04-07T12:44:00  <sipa> iptables -A FORWARD -i eth0 -j ACCEPT
196 2016-04-07T12:44:23  *** laurentmt has joined #bitcoin-core-dev
197 2016-04-07T12:44:29  *** laurentmt has quit IRC
198 2016-04-07T12:45:07  *** d_t has quit IRC
199 2016-04-07T12:47:07  <wumpus> rpc_url, the function to determine the RPC URL to connect to, hardcodes 127.0.0.1 unless variable rpchost is set - the only test crazy enough to set that is rpcbind_test.py
200 2016-04-07T12:47:32  <wumpus> (which isn't ever started automatically IIRC)
201 2016-04-07T12:48:33  <wumpus> so this must be a really strange network configuration indeed :)
202 2016-04-07T12:52:45  <wumpus> maybe connections to localhost got masqueraded to your LAN address
203 2016-04-07T12:56:06  <wumpus> probably the error "Unexpected exception caught during testing: No JSON object could be decoded" could be improved though, it shouldn't really expect a JSON object in the case of a non-OK response
204 2016-04-07T12:57:47  <wumpus> oh fuck it does, JSONErrorReply still converts some JSON RPC errors to HTTP errors, thought that was changed at some point
205 2016-04-07T12:57:56  <wumpus> not 401 or 403 though
206 2016-04-07T13:01:57  *** zooko has quit IRC
207 2016-04-07T13:10:25  *** RoyceX has quit IRC
208 2016-04-07T13:10:53  *** RoyceX has joined #bitcoin-core-dev
209 2016-04-07T13:13:54  *** laurentmt has joined #bitcoin-core-dev
210 2016-04-07T13:14:23  <wumpus> easy solution though: actually check that "Content-Type" is "application/json" before starting decoding
211 2016-04-07T13:22:24  *** MarcoFalke has quit IRC
212 2016-04-07T13:23:39  *** MarcoFalke has joined #bitcoin-core-dev
213 2016-04-07T13:27:01  *** MarcoFalke has quit IRC
214 2016-04-07T13:32:50  <Luke-Jr> why not make it both JSON-RPC and HTTP error?
215 2016-04-07T13:34:45  *** loltastic has joined #bitcoin-core-dev
216 2016-04-07T13:37:27  <wumpus> that's exactly what happens, JSON RPC errors are mapped to HTTP errors here:  https://github.com/bitcoin/bitcoin/blob/master/src/httprpc.cpp#L75    I don't know what the JSON RPC spec says I think it's a bit of a level violation
217 2016-04-07T13:38:05  <wumpus> in any case for this it doesn't matter, it just shouldn't be trying to parse responses with the wrong content type as JSON
218 2016-04-07T13:38:47  <sipa> wumpus: the 0.12 travis failure is spurious, i think?
219 2016-04-07T13:39:17  *** loltastic has quit IRC
220 2016-04-07T13:42:00  <wumpus> make[5]: Entering directory `/home/travis/build/bitcoin/bitcoin/bitcoin-i686-w64-mingw32/src/secp256k1' random seed = 7810890d4968c3f148a3cdd563177c92 err:seh:setup_exception_record stack overflow 1040 bytes in thread 0009 eip 7bc46e38 esp 00540f20 stack 0x540000-0x541000-0x740000 FAIL: tests.exe
221 2016-04-07T13:42:06  <wumpus> wow that's one I've never seen before
222 2016-04-07T13:42:31  <wumpus> but it must be a transient failure, yes
223 2016-04-07T13:43:14  <wumpus> there haven't been any recent changes to secp256k1
224 2016-04-07T13:43:29  <wumpus> (at least the one in bitcoin)
225 2016-04-07T13:47:01  <GitHub136> [bitcoin] laanwj opened pull request #7833: tests: Check Content-Type header returned from RPC server (master...2016_04_rpc_tests_check_content_type) https://github.com/bitcoin/bitcoin/pull/7833
226 2016-04-07T13:48:22  *** xabbix has quit IRC
227 2016-04-07T13:49:10  *** xabbix has joined #bitcoin-core-dev
228 2016-04-07T13:57:13  *** zooko has joined #bitcoin-core-dev
229 2016-04-07T14:09:55  *** fengling has joined #bitcoin-core-dev
230 2016-04-07T14:12:27  *** Giszmo has joined #bitcoin-core-dev
231 2016-04-07T14:14:36  *** fengling has quit IRC
232 2016-04-07T14:22:10  *** assder has quit IRC
233 2016-04-07T14:27:00  *** Chris_Stewart_5 has joined #bitcoin-core-dev
234 2016-04-07T14:29:00  *** zooko has quit IRC
235 2016-04-07T14:39:33  *** johnwhitton has joined #bitcoin-core-dev
236 2016-04-07T14:40:07  *** MarcoFalke has joined #bitcoin-core-dev
237 2016-04-07T14:57:03  *** Cheeseo has joined #bitcoin-core-dev
238 2016-04-07T14:57:03  *** Cheeseo has joined #bitcoin-core-dev
239 2016-04-07T14:58:59  *** RoyceX has quit IRC
240 2016-04-07T15:05:25  *** frankenmint has quit IRC
241 2016-04-07T15:12:42  *** laurentmt has quit IRC
242 2016-04-07T15:32:14  *** abritoid has quit IRC
243 2016-04-07T15:50:59  <wumpus>  * [new tag]         v0.12.1rc1 -> v0.12.1rc1
244 2016-04-07T15:51:45  *** Chris_Stewart_5 has quit IRC
245 2016-04-07T16:06:29  *** frankenmint has joined #bitcoin-core-dev
246 2016-04-07T16:07:23  *** Chris_Stewart_5 has joined #bitcoin-core-dev
247 2016-04-07T16:12:07  *** frankenmint has quit IRC
248 2016-04-07T16:12:44  *** fengling has joined #bitcoin-core-dev
249 2016-04-07T16:13:09  <instagibbs> a failed assert for onlyMaybeDeadlock means it's actually deadlocked?
250 2016-04-07T16:14:41  *** d_t has joined #bitcoin-core-dev
251 2016-04-07T16:17:36  *** fengling has quit IRC
252 2016-04-07T16:17:47  *** PaulCapestany has quit IRC
253 2016-04-07T16:20:29  *** PaulCapestany has joined #bitcoin-core-dev
254 2016-04-07T16:27:52  <wumpus> instagibbs: probably not, it's  a common intermittent error: https://github.com/bitcoin/bitcoin/issues/7470
255 2016-04-07T16:29:07  <instagibbs> oh, right, i didn't see "Assertion" in the issue before. Thanks.
256 2016-04-07T16:35:05  <sipa> why is that case classified as a potential deadlock?
257 2016-04-07T16:35:16  <sipa> there are not even 2 locks that overlap
258 2016-04-07T16:35:47  <sipa> cs_main is the only one shared
259 2016-04-07T16:38:32  *** Chris_Stewart_5 has quit IRC
260 2016-04-07T16:56:30  <instagibbs> how am I supposed to read the log?
261 2016-04-07T17:07:26  *** molly has joined #bitcoin-core-dev
262 2016-04-07T17:08:36  *** frankenmint has joined #bitcoin-core-dev
263 2016-04-07T17:10:29  *** molz has quit IRC
264 2016-04-07T17:13:03  *** frankenmint has quit IRC
265 2016-04-07T17:14:12  *** jtimon has joined #bitcoin-core-dev
266 2016-04-07T17:25:09  *** laurentmt has joined #bitcoin-core-dev
267 2016-04-07T18:02:44  <jonasschnelli> wumpus: F.Y.I: the lmdb node crashed.
268 2016-04-07T18:02:45  <jonasschnelli> sync.cpp:112: void potential_deadlock_detected(const std::pair<void*, void*>&, const LockStack&, const
269 2016-04-07T18:02:45  <jonasschnelli> LockStack&): Assertion `onlyMaybeDeadlock' failed.
270 2016-04-07T18:03:12  <wumpus> another potential deadlock, ugh
271 2016-04-07T18:03:21  <wumpus> that should be unrelated to lmdb though, I haven't touched any locking
272 2016-04-07T18:03:24  <jonasschnelli> Seems unrelated to lmdb
273 2016-04-07T18:03:33  <wumpus> yes it's the #7470
274 2016-04-07T18:03:46  <wumpus> another such report and I'm going to just reip out the potential deadlock detection
275 2016-04-07T18:03:55  <wumpus> travis also crashes on it frequently
276 2016-04-07T18:04:41  <jonasschnelli> http://pastebin.com/raw/zWehjWKw
277 2016-04-07T18:05:02  <wumpus> the problem is that at some point the lock debugging was enabled by default with --enable-debug
278 2016-04-07T18:05:15  <wumpus> ever since people have been getting this frequenltly
279 2016-04-07T18:05:25  <instagibbs> wumpus, I just deactivated it in my config :/
280 2016-04-07T18:05:30  <jonasschnelli> Is the crash-assert only active in --enable-debug?
281 2016-04-07T18:05:35  <instagibbs> it was literally firing off each time my wallet rebroadcast a txn
282 2016-04-07T18:05:49  <instagibbs> jonasschnelli, if you enable that it has it, yes
283 2016-04-07T18:05:57  <wumpus>  jonasschnell: that's the only way to enable it with autoconf, yes
284 2016-04-07T18:06:01  <instagibbs> -    CPPFLAGS="$CPPFLAGS -DDEBUG -DDEBUG_LOCKORDER"
285 2016-04-07T18:06:03  <instagibbs> +    CPPFLAGS="$CPPFLAGS -DDEBUG"
286 2016-04-07T18:06:25  <jonasschnelli> hmm.. we should have an extra autoconf -enable for -DDEBUG_LOCKORDER...
287 2016-04-07T18:06:37  <jonasschnelli> IIRC it once was like this.
288 2016-04-07T18:06:50  <wumpus> it used to be that you had to manually provide `CPPFLAGS=-DDEBUG_LOCKORDER` after configure to enable it
289 2016-04-07T18:06:55  *** laurentmt has quit IRC
290 2016-04-07T18:07:00  <wumpus> yes it was
291 2016-04-07T18:07:11  <wumpus> this seemed like a good idea at the time to get more test coverage
292 2016-04-07T18:07:17  <wumpus> and theoretically it is
293 2016-04-07T18:07:25  <wumpus> but not if the check is broken in the first place
294 2016-04-07T18:08:08  <wumpus> because those things have *never* got me a deadlock when not building without -enable-debug
295 2016-04-07T18:08:14  <wumpus> -not
296 2016-04-07T18:08:46  <wumpus> I'd be ok with a --debug-locks though jonasschnelli :)
297 2016-04-07T18:09:04  <wumpus> or rather --enable-debug-locks, which isn't implied by --enable-debug
298 2016-04-07T18:09:07  <jonasschnelli> I mean we could still enable it by default..
299 2016-04-07T18:09:12  <wumpus> nah
300 2016-04-07T18:09:19  *** frankenmint has joined #bitcoin-core-dev
301 2016-04-07T18:09:23  <wumpus> only if we can fix it
302 2016-04-07T18:09:40  <wumpus> we know the drill by now - false alarms are worse than no alarms
303 2016-04-07T18:09:49  <jonasschnelli> Indeed!
304 2016-04-07T18:13:33  *** frankenmint has quit IRC
305 2016-04-07T18:14:11  *** wallet42 has joined #bitcoin-core-dev
306 2016-04-07T18:14:18  *** jannes has quit IRC
307 2016-04-07T18:15:03  <gmaxwell> never having gotten wedged in practice doesn't mean there isn't a lock inversion that needs to be fixed though.
308 2016-04-07T18:15:08  *** ebfull has quit IRC
309 2016-04-07T18:15:17  <gmaxwell> but yes, false alarms are worse than no alarms.
310 2016-04-07T18:15:38  *** ebfull has joined #bitcoin-core-dev
311 2016-04-07T18:15:59  *** fengling has joined #bitcoin-core-dev
312 2016-04-07T18:16:20  <gmaxwell> the historical low accessiblity of the detector means that relatively little testing has been done with it... we should probably get it out of travis but also go beat on it some.
313 2016-04-07T18:19:14  <phantomcircuit> gmaxwell, it detects some stuff where the lock ordering is different in init.cpp from everywhere else
314 2016-04-07T18:19:24  <phantomcircuit> which never causes a deadlock
315 2016-04-07T18:20:36  *** fengling has quit IRC
316 2016-04-07T18:22:03  <jtimon> sorry, the meeting is in 1 h 40 mins, right?
317 2016-04-07T18:22:09  <jonasschnelli> jtimon: in 40mins
318 2016-04-07T18:22:35  <jtimon> jonasschnelli: ok, thank you, I definitely needed to ask :)
319 2016-04-07T18:22:41  <wumpus> 40 minutes, yes
320 2016-04-07T18:24:21  <gmaxwell> phantomcircuit: we shouldn't be doing that in init.cpp then, yes it doesn't cause a deadlock -- but it undermines the simple and useful error detection here and produces false positives. An alernative would be to have the lock detector not activate until there are multiple threads... without looking at the specific cases I don't know which would be easier.
321 2016-04-07T18:26:08  <wumpus> in my experience the deadlock detector code is hard to understand, and changes are hard to review
322 2016-04-07T18:28:09  <wumpus> anything that makes it even harder to debug, like making it check if there are multiple threads, doesn't sound like a good idea to me
323 2016-04-07T18:29:00  <wumpus> I think it already does that though. It keeps a lock stack per thread, and if the order of acquiring the locks differs it signals that
324 2016-04-07T18:29:04  <wumpus> at least it used to do that
325 2016-04-07T18:29:17  *** zooko has joined #bitcoin-core-dev
326 2016-04-07T18:29:18  <sipa> wumpus: i'll have a look, i think i know how it works and how it should work
327 2016-04-07T18:29:22  <wumpus> it seems pretty broken now
328 2016-04-07T18:29:44  <wumpus> so let's disable it for --enable-debug and travis at least, keeping it as option makes sense
329 2016-04-07T18:30:35  <wumpus> I think where it mainly fails is when try_lock is used
330 2016-04-07T18:32:54  <morcos> wumpus: i'm not familiar with that code at all, but what you are tlaking about changing wouldn't get rid of the AssertLockHeld checks would it?  b/c i think its important to keep those routinely tested
331 2016-04-07T18:33:37  <wumpus> yes I think we should keep AssertLockHeld checks, they don't give problems
332 2016-04-07T18:33:48  <wumpus> (I added many of them actually :)
333 2016-04-07T18:34:18  <wumpus> it's only the deadlock detection that gives trouble, so yes makes sense to split that out
334 2016-04-07T18:34:37  <morcos> yeah, right now they're both under -DDEBUG_LOCKORDER
335 2016-04-07T18:35:28  <wumpus> yes they use the same underlying tracking
336 2016-04-07T18:37:51  *** zooko has quit IRC
337 2016-04-07T18:37:58  <wumpus> but maybe sipa can solve it :) I'd say he has enough to do though
338 2016-04-07T18:40:52  <sipa> wumpus: the report in that bug report is wrong, it should not trigger the warning
339 2016-04-07T18:41:04  <sipa> not even if they weren't try locks
340 2016-04-07T18:41:35  <wumpus> yes it seems to be a false alert
341 2016-04-07T18:42:18  <wumpus> and a lot of those happen, all with slightly different locks involved
342 2016-04-07T18:42:52  <wumpus> if there are any real reports it's really hard to narrow down *which* locks are the problem from that output
343 2016-04-07T18:43:20  <wumpus> it's very possible that the detection is just broken and generating spurious reports
344 2016-04-07T18:46:43  <gmaxwell> another option is to stop using it and switch to helgrind for this purpose.
345 2016-04-07T18:47:44  <wumpus> yes
346 2016-04-07T18:48:44  <gmaxwell> (it wouldn't replace assert-lockheld though)
347 2016-04-07T18:49:18  <gmaxwell> though due to performance I don't think helgrind would be usable on arm.
348 2016-04-07T18:49:28  <wumpus> assert-lockheld works so we should just keep that, and disable the lockorder check until someone fixes it
349 2016-04-07T18:49:59  <gmaxwell> But it helgrind will also catch a lot more than potential lock inversions.
350 2016-04-07T18:50:58  <wumpus> yes the drawback of the *grind tools is the performance loss involved in instrumenting the code
351 2016-04-07T18:52:26  <gmaxwell> seems people have not been running helgrind on the codebase.
352 2016-04-07T18:53:39  <wumpus> (-DDEBUG_LOCKORDER also adds overhead, but only on aquiring/releasing locks)
353 2016-04-07T18:53:57  <gmaxwell> and the overhead of being wrong and not getting used? :P
354 2016-04-07T18:54:38  <wumpus> yes and the overhead of tons of open issues on the repository
355 2016-04-07T19:00:37  * btcdrak rings the bell
356 2016-04-07T19:00:58  <wumpus> #startmeeting
357 2016-04-07T19:00:58  <lightningbot> Meeting started Thu Apr  7 19:00:58 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
358 2016-04-07T19:00:58  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
359 2016-04-07T19:01:47  <wumpus> PSA: 0.12.1rc1 has been tagged, please start your gitian builders
360 2016-04-07T19:01:54  <jonasschnelli> I have three topic proposals
361 2016-04-07T19:01:55  <jonasschnelli> (1) How to proceed with cores wallet (I have a proposal)
362 2016-04-07T19:01:55  <jonasschnelli> (2) CoreDev Hacking convention in Zurich (short announcement)
363 2016-04-07T19:01:55  <jonasschnelli> (3) Dealing with RBF RPC/UI
364 2016-04-07T19:02:16  <petertodd> jonasschnelli: ack, and I need an excuse to visit Zurich :)
365 2016-04-07T19:02:42  <jonasschnelli> http://coredev.tech
366 2016-04-07T19:02:53  <jonasschnelli> (sketch)
367 2016-04-07T19:02:57  <wumpus> for the last meeting we have ACTION: start generating mtp violating transactions (gmaxwell) (wumpus, 19:08:21)
368 2016-04-07T19:03:05  <wumpus> ACTION: #7543 has 5 tested ACKs so far. It should be ready for merge (wumpus, 19:22:52)
369 2016-04-07T19:03:16  *** sanada has quit IRC
370 2016-04-07T19:03:23  *** MarcoFalke_ has joined #bitcoin-core-dev
371 2016-04-07T19:03:28  <wumpus> that was done
372 2016-04-07T19:03:28  *** sanada has joined #bitcoin-core-dev
373 2016-04-07T19:03:33  <gmaxwell> RE: mtp violations, I did. I generated a number... none were mined. I am still working on this-- I suspect I need to relay harder.
374 2016-04-07T19:03:41  <wumpus> ACTION: disable bad-chain alert for 0.12.1 (wumpus, 19:38:39)
375 2016-04-07T19:03:44  <wumpus> that was also done
376 2016-04-07T19:04:37  <wumpus> ACTION: disable bad-alert detection in master if it doesn't improve enough by 0.13 (and don't forget!) - well I tagged dgenr8's issue for 0.13, not sure what the progress there was
377 2016-04-07T19:05:02  <wumpus> ok let's start with jonasschnelli's topics
378 2016-04-07T19:05:15  <wumpus> #topic How to proceed with cores wallet
379 2016-04-07T19:05:16  <btcdrak> wumpus ack
380 2016-04-07T19:05:26  <jonasschnelli> My proposal for a concept: extend #7830: copy the wallet, remove backward compatibility (not required), remove accounts, replace BDB with LogDB, add BIP32, add SPV (= process separation)
381 2016-04-07T19:05:35  <jonasschnelli> It would help to merge it as soon as it is usefull (remove accounts and add label RPC calls, reset wallet-version)
382 2016-04-07T19:05:52  <jonasschnelli> If we agree on the concept. I'm happy to write tests, etc.
383 2016-04-07T19:06:13  <jonasschnelli> So we can ensure that the second wallet runs smoothly along with the main wallet
384 2016-04-07T19:06:19  <gmaxwell> This sounds conceptually okay to me, though how will we deal with improvements that flow to the current wallet? apply them twice (as applicable)?
385 2016-04-07T19:06:20  <wumpus> sounds good to me, we're kind of held up on updates on the current wallet, if you want to work on a  new one that makes sense
386 2016-04-07T19:06:25  *** johnwhitton has quit IRC
387 2016-04-07T19:06:41  <jonasschnelli> gmaxwell: Yes. Important improvments could be applied on both wallets.
388 2016-04-07T19:06:41  <btcdrak> jonasschnelli: sounds great
389 2016-04-07T19:06:43  <gmaxwell> I think it's much better than a boil the ocean rewrite.
390 2016-04-07T19:06:49  <jonasschnelli> The second wallet should not have a stable API for now.
391 2016-04-07T19:07:01  <jonasschnelli> And we could merge more aggressively there.
392 2016-04-07T19:07:20  <sipa> well if you intentionally break things in it, it may not get sufficient testing
393 2016-04-07T19:07:25  <jonasschnelli> I would also be happy to be the maintainer of that second / currently experimental wallet.
394 2016-04-07T19:07:25  <sipa> but concept ack
395 2016-04-07T19:07:31  <wumpus> or maybe it will get sufficient testing
396 2016-04-07T19:07:42  <wumpus> some people are waiting for things to be broken, especially the account system
397 2016-04-07T19:08:14  <wumpus> but any update to the current wallet goes so slow, partially because every time backwards compatiblity has to be considered
398 2016-04-07T19:08:20  <gmaxwell> it probably won't get 'sufficient' testing for now. But thats okay. It'll get some toying around with, which will be good feed back-- but most importantly we can make incremental progress.
399 2016-04-07T19:08:26  <wumpus> so it's kind of circular
400 2016-04-07T19:08:52  <gmaxwell> we really will need to up the quality and rigor of wallet tests for new functionality there; right now our testing for the wallet (what exists) has many checks that check exact behavior, which makes development hard. That kind of test can be tolerable for consensus code... it's a huge burden for wallet code.
401 2016-04-07T19:08:54  <jonasschnelli> Yes. We could mark it as experimental, don't use it with large amounts.
402 2016-04-07T19:09:03  <wumpus> also updates to the current wallet don't get sufficient testing/review either, there's just no energy behind it
403 2016-04-07T19:09:04  <morcos> is the idea that every important change to the existing wallet will need to be replicated though?  if so we maybe shouldn't stay in this state too long.  or someone has to volunteer to do those copies.
404 2016-04-07T19:09:22  <sipa> was just about the bring that up
405 2016-04-07T19:09:28  <wumpus> morcos: well I expect them to diverge soon enough that that won't say a problem for long
406 2016-04-07T19:09:32  <GitHub118> [bitcoin] sdaftuar opened pull request #7835: Version 2 transactions remain non-standard until CSV activates (master...CSV-relay-after-softfork) https://github.com/bitcoin/bitcoin/pull/7835
407 2016-04-07T19:09:36  *** johnwhitton has joined #bitcoin-core-dev
408 2016-04-07T19:09:40  <phantomcircuit> gmaxwell: i can help you with relaying harder
409 2016-04-07T19:09:41  <jonasschnelli> morcos: I think as we proceed, most features will only make sense on one or the other side.
410 2016-04-07T19:09:43  <sipa> we can't put the burden on external contributors to duplicate
411 2016-04-07T19:09:59  <wumpus> features will mostly end up in the new wallet
412 2016-04-07T19:10:08  *** frankenmint has joined #bitcoin-core-dev
413 2016-04-07T19:10:08  <wumpus> the old wallet should still receive bugfixes etc
414 2016-04-07T19:10:18  <wumpus> it's a bit like stable versions/master
415 2016-04-07T19:10:20  <morcos> hmm..  lots of things would apply to both,  conflicts, abandoned transactions, fee estimates
416 2016-04-07T19:10:20  <jonasschnelli> wumpus: +1
417 2016-04-07T19:10:40  *** fkhan_ has quit IRC
418 2016-04-07T19:10:50  <wumpus> in any case I'd say this is up to the people doing the work
419 2016-04-07T19:10:52  <morcos> wumpus: oh ok.  that makes sense, but when would the target be for the new wallet to be production ready
420 2016-04-07T19:10:55  <morcos> 0.14
421 2016-04-07T19:10:56  <morcos> ?
422 2016-04-07T19:11:02  <wumpus> morcos: when it's ready
423 2016-04-07T19:11:10  <jonasschnelli> morcos: sure. But the second wallet should once be independent from the core. So we should work towards a clear interface.
424 2016-04-07T19:11:22  <morcos> i guess i dont' wnat us to be in a state where the old wallet has deteriorated due to lack of attention and the new wallet is not yet stable
425 2016-04-07T19:11:29  <gmaxwell> wumpus: things like the recent performance improvements would apply to both; (sufficiently) poor performance is a bug.  ... I think doing this will have a _serious_ cost, but the alternative of continuing to not advance in that area of the software is worse.
426 2016-04-07T19:11:30  <morcos> we need something that is good to use
427 2016-04-07T19:11:44  <jonasschnelli> New wallet without account and without BDB could be in 0.13, stable API in 0.15, ... non-beta in 0.16
428 2016-04-07T19:11:47  <morcos> right, i'm not opposed to doing this, i think we need to do something
429 2016-04-07T19:11:48  <wumpus> morcos: it's a risk, but you can't stop people from working on a new wallet if that's what they prefer
430 2016-04-07T19:12:05  <sipa> yes, i think we should aim to have the new wallet production ready soon, but just no stable onterface
431 2016-04-07T19:12:10  <wumpus> (or maybe jonasschnelli and me should start a fork of bitcoin core *ducks*)
432 2016-04-07T19:12:10  <sipa> *interface
433 2016-04-07T19:12:40  <jonasschnelli> wumpus: I did that already... but the amount of reviewers was... lets say ... extremely tiny.
434 2016-04-07T19:12:46  <jonasschnelli> We can't say SPV is doomed and not improvig the wallet at the same time.
435 2016-04-07T19:12:47  <sipa> also, a lot of the unit tests for non-wallet features rely on having a wallet
436 2016-04-07T19:13:06  <wumpus> yes, the unit tests should be less dependent on the wallet
437 2016-04-07T19:13:11  <wumpus> but that's a different issue
438 2016-04-07T19:13:23  <jonasschnelli> Yes. Hard to send around coins then. But agree.
439 2016-04-07T19:13:41  <sipa> iwe can replicate a wallet in the python framework *ducjs*
440 2016-04-07T19:13:43  <wumpus> (well, the non-wallet unit tests). In any case the unit tests can use the old wallet for now.
441 2016-04-07T19:13:52  <petertodd> sipa: please do; python-bitcoinlib needs a wallet :)
442 2016-04-07T19:13:56  <wumpus> sipa: yes :)
443 2016-04-07T19:13:59  <wumpus> a python wallet please
444 2016-04-07T19:14:09  <wumpus> :D
445 2016-04-07T19:14:09  <sipa> the why do we need a wallet in core? ;)
446 2016-04-07T19:14:15  <btcdrak> !
447 2016-04-07T19:14:25  <paveljanik> for testing...
448 2016-04-07T19:14:28  <wumpus> well one idea was to begin a new wallet outside of core
449 2016-04-07T19:14:29  *** frankenmint has quit IRC
450 2016-04-07T19:14:32  <jonasschnelli> I agree long term we could remove the wallet... but in tiny steps.
451 2016-04-07T19:14:37  * gmaxwell bangs gavel
452 2016-04-07T19:14:37  <sipa> ok
453 2016-04-07T19:14:43  <sipa> who is gavel?
454 2016-04-07T19:14:55  <jonasschnelli> Outside of core does not work for now.
455 2016-04-07T19:15:00  <sipa> indeed
456 2016-04-07T19:15:05  <wumpus> but anyhow the work is currently in the direction of adding a new-wallet in core, so I'd just like to support that
457 2016-04-07T19:15:20  <wumpus> if you want to create a wallet outside of core no one needs any permission at all from anyone here :p
458 2016-04-07T19:15:24  <jonasschnelli> As soon as the wallet can run SPV, we can think about moving it.
459 2016-04-07T19:15:28  <btcdrak> sipa: do I need to call an ambulance?
460 2016-04-07T19:15:41  <paveljanik> can't just work on the interaface/API for wallet and the new wallet to be outside of Core?
461 2016-04-07T19:15:55  <sipa> jonasschnelli: i think it will still share a large part of the codebase, even if it's not runnijg in the same process
462 2016-04-07T19:15:58  <wumpus> sure, feel free to do what you want to do outside of core paveljanik
463 2016-04-07T19:16:28  <petertodd> jonasschnelli: why worry about SPV? write one that scans full blocks, grabbing them from a local bitcoind
464 2016-04-07T19:16:30  <jonasschnelli> sipa: Yes. Once it can run SPV, it shares some base code, also the net stuff.
465 2016-04-07T19:16:34  <sipa> jonasschnelli: please, modularization first, separate process next, and then we can start talking about other repository
466 2016-04-07T19:16:41  <paveljanik> wumpus, that nees Core to provide API/something Jonas is already working on...
467 2016-04-07T19:16:41  <wumpus> it makes sense, e.g. joinmarket has a wallet outside of core, although it's somewhat suboptimal
468 2016-04-07T19:16:48  <sipa> petertodd: that's the idea
469 2016-04-07T19:16:56  <sipa> petertodd: spv does not imply bip37
470 2016-04-07T19:17:05  <wumpus> (still relies on the wallet inside core but using watch-only)
471 2016-04-07T19:17:11  <jonasschnelli> I think it's to early to remove the wallet from core. We can think about it in 2-3 years.
472 2016-04-07T19:17:34  <wumpus> jonasschnelli: yes
473 2016-04-07T19:17:51  <wumpus> no one is actually proposing doing that now, but it's always how this discussion goes
474 2016-04-07T19:17:53  <wumpus> and has gone for years
475 2016-04-07T19:17:58  <morcos> would it be helpful to try to document the plan a bit more clearly  (not the whole future long term plan, but exactly what jonas is going to be workign on and how we can best support him)
476 2016-04-07T19:18:03  <morcos> in an issue or something
477 2016-04-07T19:18:03  <jonasschnelli> petertodd: Right. Running Core in full-block SPV is easy. Adapting the wallet so its not depending on a mempool, etc. is a bit harder.
478 2016-04-07T19:18:06  <wumpus> any progress you make is helpful jonasschnelli
479 2016-04-07T19:18:24  <btcdrak> next topic?
480 2016-04-07T19:18:29  <sipa> agree
481 2016-04-07T19:18:32  <jonasschnelli> morcos: I'll write a proposal.
482 2016-04-07T19:18:34  <jonasschnelli> agree next t.
483 2016-04-07T19:18:41  <sipa> (my battery is at 11%)
484 2016-04-07T19:18:49  <morcos> i'm just worried about falling into a position where the new wallet is not ready fast enough and needed improvements / bug fixes / etc are sometimes applied to one and sometimes the other and sometimes both
485 2016-04-07T19:18:58  <wumpus> #topic CoreDev Hacking convention in Zurich (short announcement)
486 2016-04-07T19:19:02  <morcos> the plan doesn't have to be perfect, but it helps if its clear
487 2016-04-07T19:19:13  <wumpus> morcos: it's a risk, but it's how it goes in open source
488 2016-04-07T19:19:25  <jonasschnelli> I think we could all meet together and hack at some important stuff.
489 2016-04-07T19:19:26  <jonasschnelli> http://coredev.tech
490 2016-04-07T19:19:29  <gmaxwell> jonasschnelli: please just propose things for the short/mid term for now.
491 2016-04-07T19:19:35  <phantomcircuit> petertodd: spv in this context really just means that the spv proofs are being saved such that the wallet could operate in a true spv mode, not that it will
492 2016-04-07T19:19:57  <jonasschnelli> Best would be to get SW nailed at the meeting in ZH.
493 2016-04-07T19:20:10  <wumpus> awesome jonasschnelli
494 2016-04-07T19:20:11  <jonasschnelli> I'm also convinced if we do that, we find sponsors pretty easy.
495 2016-04-07T19:20:26  <jonasschnelli> Room, food, etc. is organized.
496 2016-04-07T19:20:44  <jonasschnelli> If someone needs travel subsidy, please tell me.
497 2016-04-07T19:20:53  <morcos> i like the idea, but unfortunately can't attend that weekend
498 2016-04-07T19:20:58  <jonasschnelli> Important: Because of the short timelime, please tell me if you are interested to attend during the next 7 days.
499 2016-04-07T19:21:22  <sipa> is the date fixed?
500 2016-04-07T19:21:25  <wumpus> sure I will
501 2016-04-07T19:21:34  <jtimon> I probably will as well
502 2016-04-07T19:21:38  <jonasschnelli> Date is semi-fixed. :)
503 2016-04-07T19:21:39  <petertodd> jonasschnelli: I can attend
504 2016-04-07T19:21:50  <sipa> i can attend
505 2016-04-07T19:22:01  <sipa> (13 minute tram ride)
506 2016-04-07T19:22:05  <sdaftuar> jonasschnelli: i'm interested, though not sure yet if i can make it
507 2016-04-07T19:22:05  <jonasschnelli> Hah.
508 2016-04-07T19:22:08  <wumpus> i can attend too, nothing else on that date at laest
509 2016-04-07T19:22:23  <jonasschnelli> Its soon. Please try to give me a yes/no during the next 7 days.
510 2016-04-07T19:22:38  <jonasschnelli> Okay. I'll flag wumpus, petertodd and sipa as "confirmed".
511 2016-04-07T19:22:51  <jonasschnelli> and jtimon (he lives in spain and needs to come!)
512 2016-04-07T19:22:52  *** fkhan_ has joined #bitcoin-core-dev
513 2016-04-07T19:23:12  <gmaxwell> If you want people to come, more advanced planning would help, in the future! :)
514 2016-04-07T19:23:22  <jtimon> jonasschnelli: yeah, unless something unexpected prevents me from going, sounds great to me
515 2016-04-07T19:23:34  <jonasschnelli> gmaxwell: Agree. I just can't in June/Juli/Aug!
516 2016-04-07T19:23:50  <jonasschnelli> If it wont work, I'll organize another one in fall.
517 2016-04-07T19:24:01  <petertodd> gmaxwell: heh, I feel lucky when I have a whole two months of notice to travel halfway around the world - a week is more common :)
518 2016-04-07T19:24:03  <btcdrak> jonasschnelli: seems like you have a lot of takers already
519 2016-04-07T19:24:15  <sipa> petertodd: agree
520 2016-04-07T19:24:21  <jonasschnelli> And Zurich is great! :-)
521 2016-04-07T19:24:40  <jtimon> never been there, happy to visit it
522 2016-04-07T19:24:40  <petertodd> I was in Zug for a week, and it was so beautiful that a cup of coffee cost $10
523 2016-04-07T19:24:53  <jonasschnelli> </topic>
524 2016-04-07T19:24:58  <wumpus> hehe
525 2016-04-07T19:25:13  <sipa> next topic?
526 2016-04-07T19:25:14  <wumpus> #topic Dealing with RBF RPC/UI
527 2016-04-07T19:25:14  <jtimon> maybe I've been in the airport...sorry, yeah, next topic
528 2016-04-07T19:25:42  <michagogo> (null) <jonasschnelli> New wallet without account and without BDB could be in 0.13, stable API in 0.15, ... non-beta in 0.16
529 2016-04-07T19:25:56  <michagogo> Sorry I'm late, but: Bitcoin Core is still in beta, no?
530 2016-04-07T19:26:05  <sipa> haha
531 2016-04-07T19:26:13  <petertodd> speaking of, opt-in RBF is getting used by someone at least: http://p2sh.info/dashboard/db/replace-by-fee
532 2016-04-07T19:26:19  <jonasschnelli> RBF: I dont have a clear vision how the RPC should deal with RBF
533 2016-04-07T19:26:27  <gmaxwell> michagogo: the "beta" was dropped from the description years ago.
534 2016-04-07T19:26:29  <michagogo> Huh, that timestamp broke weirdly
535 2016-04-07T19:26:41  <michagogo> gmaxwell: really? I must have missed that
536 2016-04-07T19:26:44  <gmaxwell> michagogo: and some stupid lable wouldn't excuse shoddy support.
537 2016-04-07T19:27:06  <michagogo> gmaxwell: obviously, I was just commenting on the "non-beta" milestone
538 2016-04-07T19:27:12  <jonasschnelli> Opt-in is one issue to deal with, the second one is: how does the process looks like if someone adds an output/input?
539 2016-04-07T19:27:41  <jonasschnelli> Ensure that the RBF rules are respected (>fee, pay for the bandwith, etc.)
540 2016-04-07T19:27:56  <petertodd> so, I think what you actually need to do here from an RPC point of view is think in terms of what addresses the user wanted to pay, and whether or not known (confirmed) txs succesfully did that - which isn't really how the wallet works right now
541 2016-04-07T19:28:10  <MarcoFalke_> Shouldn't we only support fee bump as a fist step?
542 2016-04-07T19:28:16  <petertodd> MarcoFalke_: ack
543 2016-04-07T19:28:27  <paveljanik> MarcoFalke: +1
544 2016-04-07T19:28:30  <sipa> ack
545 2016-04-07T19:28:38  <jonasschnelli> *exhales*
546 2016-04-07T19:28:49  <gmaxwell> In many ways, adding outputs is more useful... but "fee bump only" was also my initial impression at jonasschnelli's efforts.
547 2016-04-07T19:28:55  <phantomcircuit> petertodd: the wallet does track which outputs are change, so nominally it's also trakcing which outputs where intended as payments
548 2016-04-07T19:28:58  <jtimon> one step at a time sounds good to me
549 2016-04-07T19:29:01  <jonasschnelli> I think we should have a fee-bump RBF in 0.13 (RBF was in 0.11.x and 0.12).
550 2016-04-07T19:29:05  <petertodd> MarcoFalke_: and with fee bump, first implementation should probably *not* add inputs, which complicates things
551 2016-04-07T19:29:23  <jonasschnelli> | How would a feebump over RPC looks like?
552 2016-04-07T19:29:33  <petertodd> jonasschnelli: hmm? I released RBF for v0.11, but Core didn't
553 2016-04-07T19:29:56  <jonasschnelli> sry, mixed up with CLTV... right. 0.12
554 2016-04-07T19:30:47  <petertodd> jonasschnelli: https://github.com/petertodd/replace-by-fee-tools/blob/master/bump-fee.py <- there's my implementation, with is basically bumpfee <txid> <ratio/delta-fees> => <new txid>
555 2016-04-07T19:31:19  <gmaxwell> for adding outputs, I think the best way involves some larger workflow changes. E.g. the ability to queue sends, and auto-sendmany from the queue.. then that could be extended to auto-add-outputs for queued sends where the original is sent.
556 2016-04-07T19:31:25  <gmaxwell> or something like that.
557 2016-04-07T19:31:26  <jonasschnelli> petertodd: bumpfee ... yes. maybe we find a call-name that is more flexible for the future?
558 2016-04-07T19:31:35  <petertodd> jonasschnelli: I didn't handle the case where you'd respent the change, but just having fee bumping error out in that case isn't all that bad; a slightly smarter version could combine the dependent txs (assuming they're all yours)
559 2016-04-07T19:31:57  <sipa> related: cpfp?
560 2016-04-07T19:31:58  <gmaxwell> RE: feebump, I think a different approach should be used.
561 2016-04-07T19:32:07  <phantomcircuit> petertodd: there's significant privacy implications to combining payments
562 2016-04-07T19:32:10  <petertodd> jonasschnelli: AbstractRespendWithSomeThingChangedFactoryBean?
563 2016-04-07T19:32:19  <jonasschnelli> ^^
564 2016-04-07T19:32:32  <petertodd> phantomcircuit: sure, which is why getting estimates right in the first place helps a lot
565 2016-04-07T19:32:51  <sipa> jonasschnelli: it shall be called BeeFump
566 2016-04-07T19:32:51  <petertodd> phantomcircuit: but if fee bumping is a once-in-a-while thing, I'm not that concerned re: privacy
567 2016-04-07T19:32:55  <jonasschnelli> altertransaction was something we once have talked about
568 2016-04-07T19:32:56  <Lightsword> petertodd, your factory needs a factory :P
569 2016-04-07T19:32:56  <petertodd> sipa: +1
570 2016-04-07T19:33:10  <gmaxwell> Instead of having a command to 'bump' we should implement "adaptive fee" where it just precreates the bumps with nlocktimes and queues them.  Expecting the user to always need to manually bump will not make for a good expirence.
571 2016-04-07T19:33:11  <sipa> gmaxwell: elaborate?
572 2016-04-07T19:33:22  <sipa> ah
573 2016-04-07T19:33:24  <petertodd> Lightsword: I'm not going to grey-goo the world just to bump fees... :)
574 2016-04-07T19:33:53  <wumpus> sure, that'd be even better, but even a simple 'bump fee' command would be better than nothing
575 2016-04-07T19:33:57  <petertodd> gmaxwell: yeah, ack on that being better, although the code to do feebumping will get reused by the nlocktime version
576 2016-04-07T19:34:11  <gmaxwell> Also, for a direct manual bumprpc. it sould probably have an api that encourages a multiplicative increase. Since otherwise you can end up needing to bump stupid numbers of time.
577 2016-04-07T19:34:13  <jonasschnelli> Okay. Will work on "bumpfee".
578 2016-04-07T19:34:29  <jonasschnelli> How do we estimate fees for replacements?
579 2016-04-07T19:34:31  <petertodd> gmaxwell: my python script does it based on a ratio
580 2016-04-07T19:34:42  <kanzure> #action bumpfee work
581 2016-04-07T19:34:46  <petertodd> jonasschnelli: double every time by default? it's a good start
582 2016-04-07T19:34:52  <gmaxwell> where as 1.5x each time (subject to the protocol constraint) can span all possible values is a fairly small number of bumps with a maximum overpayment of 50%.
583 2016-04-07T19:35:02  <petertodd> jonasschnelli: having to bump a fee implies that your fee estimation isn't working anyway :)
584 2016-04-07T19:35:12  <jonasschnelli> petertodd: indeed!
585 2016-04-07T19:35:17  <wumpus> exponential fee backoff
586 2016-04-07T19:35:20  <gmaxwell> petertodd: well it could be working now, just not precognative. :)
587 2016-04-07T19:35:51  <phantomcircuit> gmaxwell: we'd need to be very careful with automatic fee bumping to ensure that people are aware of it and expect that behavior
588 2016-04-07T19:35:57  <gmaxwell> unrelated, it would be kinda cool to run the fee estimator on all unconfirmed txn in the mempool and display the current estimate on them.
589 2016-04-07T19:35:58  <paveljanik> BTW - when we bump fee, will we just lower the change? Or different way to do so to not help Sybil-network-attackers to identify the change?
590 2016-04-07T19:36:05  <wumpus> phantomcircuit: agreed
591 2016-04-07T19:36:17  <gmaxwell> phantomcircuit: jonasschnelli had a checkbox in the UI for the things he was doing so far.
592 2016-04-07T19:36:33  *** laurentmt has joined #bitcoin-core-dev
593 2016-04-07T19:36:56  <petertodd> paveljanik: just lowering the change is by far the easiest; doing better re: privacy is always going to be more expensive, and tricky to be succesful at
594 2016-04-07T19:36:56  <jonasschnelli> Yes. We don't opt-in automatically for now I guess.
595 2016-04-07T19:37:03  <gmaxwell> paveljanik: the main thing to do is to get the estimate right in the first place, though right now change is so throughly identifyable you're closing the barn door after the horse has left. :)
596 2016-04-07T19:37:08  <wumpus> phantomcircuit: automatic behavior in the wallet can be somewhat scary, at least now you have to click confirm to pay a certain fee
597 2016-04-07T19:37:24  <wumpus> phantomcircuit: (although you could have the same, just agree on a certain *max* fee)
598 2016-04-07T19:37:32  <gmaxwell> wumpus: what I suggested on the PR for that was just to list the possible fees (by the checkbox)
599 2016-04-07T19:37:37  <jonasschnelli> wumpus: Agree. No automatic behavior that spends inputs automatically.
600 2016-04-07T19:37:55  <btcdrak> I would just have "increase fee" and give an amount.
601 2016-04-07T19:38:00  <gmaxwell> Fee of x/y/z/q after 0/2/3/4 blocks.
602 2016-04-07T19:38:26  <morcos> Ok so not to beat a dead horse here, but just b/c i want to understand.  This kind of change to wallet behavior is something would be only added to new wallet or to both?
603 2016-04-07T19:38:34  <jonasschnelli> I though we could re-use the fee slider (but with ~x2 values).
604 2016-04-07T19:38:51  <petertodd> morcos: fee bumping itself I think we should add to the existing wallet; more complex strategies may be infeasible with the current wallet
605 2016-04-07T19:39:04  <wumpus> morcos: depends on the order in which things actually get implemented, I'd say
606 2016-04-07T19:39:08  <wumpus> yes agree with petertodd there
607 2016-04-07T19:39:27  <gmaxwell> morcos: for example the queuing behavior I described above may be unrealistic to do in the current wallet because all our apis expect to return txid.
608 2016-04-07T19:39:34  <jonasschnelli> morcos: the old wallet could just have a fee bump, ..the new wallet a feature to add outputs.
609 2016-04-07T19:39:47  <gmaxwell> I think new wallet API should break that and instead return a handle, that can be used to get the txid if it's available yet.
610 2016-04-07T19:39:57  <jtimon> jonasschnelli: will the new and the old wallet share a common interface (even if one of them just throws a non-implemented error on some methods or something)?
611 2016-04-07T19:40:09  <sipa> jtimon: imho, no
612 2016-04-07T19:40:13  <sipa> or not initially
613 2016-04-07T19:40:16  <wumpus> the idea is tthat the new wallet can have a completely new interface
614 2016-04-07T19:40:27  <wumpus> throwing out all the old cruft
615 2016-04-07T19:40:28  <jonasschnelli> jtimon: if we want to depracate the old wallet and remove it once, it should probably be independent.
616 2016-04-07T19:40:51  <wumpus> of course if there are things that make sense they can be kept
617 2016-04-07T19:40:56  <morcos> it seems to me that there ought to be an rpc call to jus tincrease the fee by an amount (as btcdrak says) and then there ought to be an rpc call/gui option that says expedite which replaces the fee on an existing transaction wiht the new estimates (assumign the new estimate is higher), you may have changed the target.
618 2016-04-07T19:41:06  <jonasschnelli> Also while writing on the new wallet, we can care more about core interaction. No mempool access everywhere.
619 2016-04-07T19:41:24  <sipa> jonasschnelli: that may be... hard
620 2016-04-07T19:41:28  <wumpus> jonasschnelli: at least make it event driven
621 2016-04-07T19:41:31  <jtimon> mhmm, I'm just worried about calling code for both wallets from the same place
622 2016-04-07T19:41:35  <wumpus> jonasschnelli: no assumption on *immediate* mempool access
623 2016-04-07T19:41:47  <gmaxwell> jonasschnelli: many good features benefit from mempool access.
624 2016-04-07T19:41:58  <sipa> jtimon: is that a problem?
625 2016-04-07T19:42:09  <wumpus> the mistake we made in the GUI is to do a lot of calls directly, which makes it very hard to move things to another process or make them network transparent
626 2016-04-07T19:42:22  <jtimon> with my suggestion the new wallet could have a different interface in practice (as said the old wallet can just throw errors)
627 2016-04-07T19:42:24  <wumpus> and it also holds up the GUI thread for things that shouldn't
628 2016-04-07T19:42:31  <sipa> hey, main.cpp used to call the gui directly
629 2016-04-07T19:42:42  <jonasschnelli> :-)
630 2016-04-07T19:42:44  <wumpus> it's fine to have a query mempool, but it should be regarded as asynchronous
631 2016-04-07T19:42:57  <wumpus> heh true sipa, we made a step forward with  bitcoin-qt :-)
632 2016-04-07T19:43:24  <sipa> other topic?
633 2016-04-07T19:43:35  <petertodd> wumpus: once you're talking about async access, probably easier just to keep a copy of the mempool on your local app
634 2016-04-07T19:43:36  <sipa> as we seem to have backtracked to a previous o e
635 2016-04-07T19:43:38  <wumpus> better to have something then make a wild plan which grows so huge it can never be executed
636 2016-04-07T19:44:01  <jtimon> sipa: mhmm, seems that code of the form if(fSomething) { // call old wallet } else { // call new wallet} doesn't really make removing the old wallet easier in the future
637 2016-04-07T19:44:04  <wumpus> petertodd: I don't know, depends on the application
638 2016-04-07T19:44:15  <sipa> jtimon: oh hell no, that isn't allowed
639 2016-04-07T19:44:23  <sipa> jtimon: everything through validationinterface
640 2016-04-07T19:44:32  <petertodd> wumpus: well, unless you're memory constrained, keeping a copy locally and keeping that in sync can't be that hard
641 2016-04-07T19:44:36  <jtimon> sipa: oh, that was my question then, thanks
642 2016-04-07T19:45:24  <wumpus> jtimon: yes, wallets (as well as other modules) register their own RPC calls, there's no need for if(fSomething) logic
643 2016-04-07T19:46:06  <wumpus> any other topics?
644 2016-04-07T19:46:11  <jtimon> great, that was my only concern about jonasschnelli's plan, I knew I was probably misunderstanding something
645 2016-04-07T19:46:30  <jonasschnelli> I'll write a clean concept.
646 2016-04-07T19:47:07  <sipa> oh, small question: are we ok with backporting master's script/tx unit tests to 0.12?
647 2016-04-07T19:47:44  <petertodd> sipa: ack
648 2016-04-07T19:47:45  *** laurentmt has quit IRC
649 2016-04-07T19:47:49  <paveljanik> why not?
650 2016-04-07T19:47:51  <wumpus> well if the tests are better it always makes sense to backport them
651 2016-04-07T19:48:04  <sipa> testd are not typically something we backport
652 2016-04-07T19:48:09  <wumpus> I'm fine with copying all the tests from master to 0.12 given that the funcitnality is supported
653 2016-04-07T19:48:17  <sipa> but i think it makes total sense as we want softforks backported too
654 2016-04-07T19:48:22  <sdaftuar> wumpus: i wanted to flag #7835 which i just opened for 0.12.1
655 2016-04-07T19:48:25  <petertodd> sipa: agreed
656 2016-04-07T19:48:39  <wumpus> sdaftuar: too late, 0.12.1 was just tagged
657 2016-04-07T19:48:49  <sipa> sdaftuar: just rc1?
658 2016-04-07T19:48:55  <sipa> wumpus: ^
659 2016-04-07T19:49:00  <wumpus> yes
660 2016-04-07T19:49:03  <sipa> or no rc cycle?
661 2016-04-07T19:49:17  <btcdrak> Freudian slip
662 2016-04-07T19:49:23  <jtimon> well, as a not important topic, I would appreciate some feedback on a little experiment in #7829 . I still need to improve the PR description, but the basic idea is helping new people to get their first PR merged and get familiar with git, the review process or whatever, by telling them to do stuff I want done
663 2016-04-07T19:49:30  <MarcoFalke_> lets hope rc1 one is the final release ;)
664 2016-04-07T19:49:38  <wumpus> [21:01:15] <wumpus> PSA: 0.12.1rc1 has been tagged, please start your gitian builders
665 2016-04-07T19:49:50  <morcos> right, so its not too late for 0.12.1 right?
666 2016-04-07T19:49:58  <btcdrak> 20:01:47 <wumpus> PSA: 0.12.1rc1 has been tagged, please start your gitian builders
667 2016-04-07T19:50:11  <wumpus> well there will only be a rc2 if necessary, does this need to block the release?
668 2016-04-07T19:50:55  <sdaftuar> i think so.  i think there's a problem with the mempool being able to be filled with things that may not be mined
669 2016-04-07T19:50:57  <sipa> wumpus: we should consider it i thonk
670 2016-04-07T19:51:08  <sdaftuar> without the change, which is simple
671 2016-04-07T19:51:19  <wumpus> ok...
672 2016-04-07T19:51:24  <sipa> sowwy
673 2016-04-07T19:51:32  <wumpus> rc1 is dead folks
674 2016-04-07T19:51:37  <wumpus> don't bother building it
675 2016-04-07T19:51:43  * btcdrak stops his gitian builder
676 2016-04-07T19:51:50  <wumpus> long live rc2
677 2016-04-07T19:51:58  <btcdrak> I thought we had discussed this exact thing before regarding V2
678 2016-04-07T19:52:09  <morcos> wumpus you know i save these things until after your release candidates just for the entertainment value right?
679 2016-04-07T19:52:41  <wumpus> morcos: I know, no offense taken :) better now than later, almost no one wasted cycles on rc1 yet
680 2016-04-07T19:52:44  *** laurentmt has joined #bitcoin-core-dev
681 2016-04-07T19:52:55  <morcos> btcdrak: yeah i dont' think we properly thought through what happens when things end up in your mempool that won't be reliably mined
682 2016-04-07T19:52:59  <btcdrak> sdaftuar: that's quite an elegant solution.
683 2016-04-07T19:53:16  <sdaftuar> btcdrak: that's because i stole it from sipa's segwit
684 2016-04-07T19:53:36  <wumpus> #action review and ACK https://github.com/bitcoin/bitcoin/pull/7835/files asap
685 2016-04-07T19:53:37  <btcdrak> long live sipa
686 2016-04-07T19:53:49  <morcos> we should add this to our list of standard ways to implement things whenever we relax standardness rules
687 2016-04-07T19:53:58  <btcdrak> morcos: agreed
688 2016-04-07T19:55:11  <sipa> 2% battery left for me; anything else?
689 2016-04-07T19:55:20  <morcos> travel charger?
690 2016-04-07T19:55:23  <jonasschnelli> lol
691 2016-04-07T19:55:34  <wumpus> I don't think so
692 2016-04-07T19:55:45  <wumpus> #endmeeting
693 2016-04-07T19:55:45  <lightningbot> Meeting ended Thu Apr  7 19:55:45 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
694 2016-04-07T19:55:45  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-07-19.00.html
695 2016-04-07T19:55:45  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-07-19.00.txt
696 2016-04-07T19:55:45  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-07-19.00.log.html
697 2016-04-07T19:56:20  *** cryptapus has quit IRC
698 2016-04-07T19:56:43  <achow101> wait, is rc1 actually dead?
699 2016-04-07T19:56:54  <wumpus> yes, dead as a doornail
700 2016-04-07T19:57:11  *** MarcoFalke_ has quit IRC
701 2016-04-07T19:57:15  <btcdrak> "it's dead Jim"
702 2016-04-07T19:57:41  <wumpus> we'll probably tag rc2 tomorrow
703 2016-04-07T19:58:03  <achow101> ok
704 2016-04-07T19:58:05  <wumpus> doesn't make sense to do a gitian process in the mean time
705 2016-04-07T20:02:40  *** Guyver2 has joined #bitcoin-core-dev
706 2016-04-07T20:12:20  *** zooko has joined #bitcoin-core-dev
707 2016-04-07T20:18:40  *** fengling has joined #bitcoin-core-dev
708 2016-04-07T20:22:56  *** fengling has quit IRC
709 2016-04-07T20:25:20  *** d_t has quit IRC
710 2016-04-07T20:33:58  *** frankenmint has joined #bitcoin-core-dev
711 2016-04-07T20:35:36  *** spikeheadon has joined #bitcoin-core-dev
712 2016-04-07T20:38:04  *** frankenmint has quit IRC
713 2016-04-07T20:39:22  *** wallet42 has quit IRC
714 2016-04-07T20:42:22  *** xabbix has quit IRC
715 2016-04-07T20:43:22  *** xabbix has joined #bitcoin-core-dev
716 2016-04-07T20:43:22  *** xabbix has joined #bitcoin-core-dev
717 2016-04-07T20:46:14  *** lamagra has quit IRC
718 2016-04-07T20:49:53  *** zooko has quit IRC
719 2016-04-07T20:50:28  *** zooko has joined #bitcoin-core-dev
720 2016-04-07T20:51:13  *** laurentmt has quit IRC
721 2016-04-07T21:04:24  *** zooko has quit IRC
722 2016-04-07T21:15:28  *** cryptapus_afk is now known as cryptapus
723 2016-04-07T21:16:43  *** murch has joined #bitcoin-core-dev
724 2016-04-07T21:20:58  *** belcher has joined #bitcoin-core-dev
725 2016-04-07T21:23:42  *** kangx has joined #bitcoin-core-dev
726 2016-04-07T21:29:08  *** wallet42 has joined #bitcoin-core-dev
727 2016-04-07T21:51:18  *** johnwhitton has quit IRC
728 2016-04-07T21:57:23  *** zooko has joined #bitcoin-core-dev
729 2016-04-07T21:59:12  *** belcher has quit IRC
730 2016-04-07T22:00:03  *** belcher has joined #bitcoin-core-dev
731 2016-04-07T22:02:28  *** belcher has quit IRC
732 2016-04-07T22:04:00  *** zooko has quit IRC
733 2016-04-07T22:25:22  *** cryptapus is now known as cryptapus_afk
734 2016-04-07T22:36:52  *** AaronvanW has quit IRC
735 2016-04-07T22:39:22  *** johnwhitton has joined #bitcoin-core-dev
736 2016-04-07T22:42:34  *** belcher has joined #bitcoin-core-dev
737 2016-04-07T22:55:19  *** johnwhitton has quit IRC
738 2016-04-07T22:56:13  *** zooko has joined #bitcoin-core-dev
739 2016-04-07T22:56:14  *** johnwhitton has joined #bitcoin-core-dev
740 2016-04-07T23:03:12  *** johnwhitton has quit IRC
741 2016-04-07T23:07:26  *** murch has quit IRC
742 2016-04-07T23:26:09  *** laurentmt has joined #bitcoin-core-dev
743 2016-04-07T23:26:27  *** Thireus has quit IRC
744 2016-04-07T23:26:39  *** Guyver2 has quit IRC
745 2016-04-07T23:26:51  *** laurentmt has quit IRC
746 2016-04-07T23:59:22  *** wallet42 has quit IRC