12016-04-07T00:01:02  <jtimon> never mind, origin/0.12 already has 68/112/113
  22016-04-07T00:14:55  *** Giszmo has joined #bitcoin-core-dev
  32016-04-07T00:36:30  *** zooko has joined #bitcoin-core-dev
  42016-04-07T00:54:54  *** Chris_Stewart_5 has quit IRC
  52016-04-07T01:06:29  *** PaulCapestany has quit IRC
  62016-04-07T01:08:51  *** PaulCapestany has joined #bitcoin-core-dev
  72016-04-07T01:11:03  *** Ylbam has quit IRC
  82016-04-07T01:16:54  *** btcdrak has quit IRC
  92016-04-07T01:30:06  *** dermoth has quit IRC
 102016-04-07T01:30:56  *** dermoth has joined #bitcoin-core-dev
 112016-04-07T01:39:45  *** RoyceX has joined #bitcoin-core-dev
 122016-04-07T01:39:46  *** RoyceX has joined #bitcoin-core-dev
 132016-04-07T01:41:56  *** Cheeseo has quit IRC
 142016-04-07T01:43:24  *** wallet42 has joined #bitcoin-core-dev
 152016-04-07T01:44:09  *** arubi has quit IRC
 162016-04-07T01:45:21  *** fengling has joined #bitcoin-core-dev
 172016-04-07T01:45:54  *** frankenmint has joined #bitcoin-core-dev
 182016-04-07T01:47:56  *** zooko has quit IRC
 192016-04-07T02:00:05  *** dermoth has quit IRC
 202016-04-07T02:00:57  *** dermoth has joined #bitcoin-core-dev
 212016-04-07T02:02:42  *** supasonic has quit IRC
 222016-04-07T02:03:08  *** supasonic has joined #bitcoin-core-dev
 232016-04-07T02:03:25  *** BCBot has quit IRC
 242016-04-07T02:06:28  *** BCBot has joined #bitcoin-core-dev
 252016-04-07T02:19:58  *** johnwhitton has joined #bitcoin-core-dev
 262016-04-07T02:33:27  *** supasonic has quit IRC
 272016-04-07T02:40:36  *** fengling has quit IRC
 282016-04-07T02:45:22  *** frankenmint has quit IRC
 292016-04-07T02:58:58  *** Squidicuz has joined #bitcoin-core-dev
 302016-04-07T03:00:19  *** hsmiths has quit IRC
 312016-04-07T03:00:42  *** Squidicc has quit IRC
 322016-04-07T03:00:48  *** hsmiths has joined #bitcoin-core-dev
 332016-04-07T03:04:13  *** zooko has joined #bitcoin-core-dev
 342016-04-07T03:14:02  *** johnwhitton has quit IRC
 352016-04-07T03:15:14  *** johnwhitton has joined #bitcoin-core-dev
 362016-04-07T03:23:31  *** jtimon has quit IRC
 372016-04-07T03:23:59  *** jtimon has joined #bitcoin-core-dev
 382016-04-07T03:25:11  *** Giszmo has quit IRC
 392016-04-07T03:33:02  *** Alopex has quit IRC
 402016-04-07T03:34:07  *** Alopex has joined #bitcoin-core-dev
 412016-04-07T03:48:11  *** gevs has quit IRC
 422016-04-07T03:50:03  *** gevs has joined #bitcoin-core-dev
 432016-04-07T03:51:20  *** aj has quit IRC
 442016-04-07T03:51:29  *** aj has joined #bitcoin-core-dev
 452016-04-07T04:03:29  *** fengling has joined #bitcoin-core-dev
 462016-04-07T04:34:07  *** johnwhitton has quit IRC
 472016-04-07T04:36:04  *** johnwhitton has joined #bitcoin-core-dev
 482016-04-07T05:11:15  *** frankenmint has joined #bitcoin-core-dev
 492016-04-07T05:23:10  *** Luke-Jr has quit IRC
 502016-04-07T05:27:57  *** Luke-Jr has joined #bitcoin-core-dev
 512016-04-07T05:39:21  *** zooko has quit IRC
 522016-04-07T05:40:56  *** fengling has quit IRC
 532016-04-07T05:42:30  *** arubi has joined #bitcoin-core-dev
 542016-04-07T05:49:31  *** zxzzt has quit IRC
 552016-04-07T05:49:42  *** morcos has quit IRC
 562016-04-07T05:49:43  *** sdaftuar has quit IRC
 572016-04-07T05:51:20  *** sdaftuar has joined #bitcoin-core-dev
 582016-04-07T05:51:32  *** morcos has joined #bitcoin-core-dev
 592016-04-07T05:51:38  *** zxzzt has joined #bitcoin-core-dev
 602016-04-07T05:53:44  *** johnwhitton has quit IRC
 612016-04-07T05:54:30  *** johnwhitton has joined #bitcoin-core-dev
 622016-04-07T06:00:06  *** dermoth has quit IRC
 632016-04-07T06:00:48  *** dermoth has joined #bitcoin-core-dev
 642016-04-07T06:03:00  *** johnwhitton has quit IRC
 652016-04-07T06:05:35  *** btcdrak has joined #bitcoin-core-dev
 662016-04-07T06:12:02  *** Alopex has quit IRC
 672016-04-07T06:12:45  *** Ylbam has joined #bitcoin-core-dev
 682016-04-07T06:13:07  *** Alopex has joined #bitcoin-core-dev
 692016-04-07T06:14:17  *** xiangfu has joined #bitcoin-core-dev
 702016-04-07T06:17:14  *** fengling has joined #bitcoin-core-dev
 712016-04-07T06:23:27  *** p15 has quit IRC
 722016-04-07T06:25:17  *** p15 has joined #bitcoin-core-dev
 732016-04-07T07:07:08  *** abritoid has joined #bitcoin-core-dev
 742016-04-07T07:08:11  *** p15_ has joined #bitcoin-core-dev
 752016-04-07T07:08:31  *** jtimon has quit IRC
 762016-04-07T07:10:47  *** p15 has quit IRC
 772016-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
 782016-04-07T07:21:36  <jonasschnelli> What if an the same label is used for multiple addresses?
 792016-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)
 802016-04-07T07:22:07  <jonasschnelli> Okay.
 812016-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.
 822016-04-07T07:22:38  <jonasschnelli> Haven't seen that.
 832016-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
 842016-04-07T07:25:06  <wumpus> awesome!
 852016-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
 862016-04-07T07:35:33  <jonasschnelli> Yes. I have removed it.
 872016-04-07T08:15:47  *** jannes has joined #bitcoin-core-dev
 882016-04-07T08:27:45  *** Guyver2 has joined #bitcoin-core-dev
 892016-04-07T08:29:10  *** ebfull has quit IRC
 902016-04-07T08:32:46  *** ebfull has joined #bitcoin-core-dev
 912016-04-07T08:44:57  *** rubensayshi has joined #bitcoin-core-dev
 922016-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
 932016-04-07T09:10:23  *** hsmiths2 has joined #bitcoin-core-dev
 942016-04-07T09:10:32  *** hsmiths has quit IRC
 952016-04-07T09:23:56  *** Guyver2 has quit IRC
 962016-04-07T09:27:59  *** frankenmint has quit IRC
 972016-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
 982016-04-07T09:52:54  *** BCBot has quit IRC
 992016-04-07T09:52:57  *** BCBot_ has joined #bitcoin-core-dev
1002016-04-07T09:56:20  *** AaronvanW has joined #bitcoin-core-dev
1012016-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
1022016-04-07T10:02:21  <sipa> If you manage to
1032016-04-07T10:02:21  <sipa> +suffer financial or other losses due to this code I demand compensation for
1042016-04-07T10:02:24  <sipa> +feelings of misplaced guilt.
1052016-04-07T10:02:26  <sipa> LOL
1062016-04-07T10:03:24  <wumpus> :-)
1072016-04-07T10:03:44  *** p15_ has quit IRC
1082016-04-07T10:04:54  *** p15 has joined #bitcoin-core-dev
1092016-04-07T10:07:23  *** ebfull has quit IRC
1102016-04-07T10:08:23  *** ebfull has joined #bitcoin-core-dev
1112016-04-07T10:34:34  *** p15 has quit IRC
1122016-04-07T10:58:29  *** ebfull has quit IRC
1132016-04-07T10:59:42  *** ebfull has joined #bitcoin-core-dev
1142016-04-07T10:59:52  <GitHub82> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3bc71e1572cb...bbaf5976af84
1152016-04-07T10:59:52  <GitHub82> bitcoin/master 07398e8 Wladimir J. van der Laan: init: allow shutdown during 'Activating best chain...'...
1162016-04-07T10:59:53  <GitHub82> bitcoin/master bbaf597 Wladimir J. van der Laan: Merge #7821: init: allow shutdown during 'Activating best chain...'...
1172016-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
1182016-04-07T11:00:59  <GitHub0> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/4226aacdba7d0e1e22555dac69363b3b460a166b
1192016-04-07T11:00:59  <GitHub0> bitcoin/0.12 4226aac Wladimir J. van der Laan: init: allow shutdown during 'Activating best chain...'...
1202016-04-07T11:03:44  *** laurentmt has joined #bitcoin-core-dev
1212016-04-07T11:07:31  <GitHub95> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/bbaf5976af84...1ddf0cee679d
1222016-04-07T11:07:32  <GitHub95> bitcoin/master 2d1d658 Pieter Wuille: Track block download times per individual block...
1232016-04-07T11:07:32  <GitHub95> bitcoin/master 0e24bbf Pieter Wuille: Self check after the last peer is removed
1242016-04-07T11:07:33  <GitHub95> bitcoin/master 1ddf0ce Wladimir J. van der Laan: Merge #7804: Track block download times per individual block...
1252016-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
1262016-04-07T11:13:13  *** laurentmt has quit IRC
1272016-04-07T11:16:41  <GitHub39> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/90f1d246d38803eb546c6652ddce5ebea55eec98
1282016-04-07T11:16:41  <GitHub39> bitcoin/0.12 90f1d24 Pieter Wuille: Track block download times per individual block...
1292016-04-07T11:19:29  *** cryptapus has joined #bitcoin-core-dev
1302016-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
1312016-04-07T11:29:22  *** wallet42 has quit IRC
1322016-04-07T11:35:30  *** d_t has joined #bitcoin-core-dev
1332016-04-07T11:35:39  *** randy-waterhouse has quit IRC
1342016-04-07T11:38:25  *** xiangfu has quit IRC
1352016-04-07T11:41:29  *** AaronvanW has quit IRC
1362016-04-07T11:44:13  <jonasschnelli> wumpus: did you already try to run it (your LMDB branch) on a standard 64 bit Linux?
1372016-04-07T11:44:29  <wumpus> yep
1382016-04-07T11:44:39  *** AaronvanW has joined #bitcoin-core-dev
1392016-04-07T11:44:54  <wumpus> passes the tests and seems to work
1402016-04-07T11:45:18  <jonasschnelli> Okay. Then I'll give it a try on my Debian Server (fresh sync from random peers).
1412016-04-07T11:45:56  *** fengling has quit IRC
1422016-04-07T11:52:58  <GitHub3> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1ddf0cee679d...5851915a006a
1432016-04-07T11:52:58  <GitHub3> bitcoin/master 62b9a55 Wladimir J. van der Laan: Reduce block timeout to 10 minutes...
1442016-04-07T11:52:59  <GitHub3> bitcoin/master 5851915 Wladimir J. van der Laan: Merge #7832: Reduce block timeout to 10 minutes...
1452016-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
1462016-04-07T11:57:13  *** lamagra has joined #bitcoin-core-dev
1472016-04-07T11:58:45  <jonasschnelli> wumpus: is there a reason to reserve 8GB for the chainstate2/data.mdb db?
1482016-04-07T11:58:56  <jonasschnelli> or is that just on my end...
1492016-04-07T11:59:09  <wumpus> well it's bound to not be too little, for now
1502016-04-07T11:59:21  <wumpus> see https://github.com/laanwj/bitcoin/tree/2016_04_mdb#mapsize
1512016-04-07T11:59:44  <jonasschnelli> Ah. The readme was shortened on my smartphone. Nice.
1522016-04-07T11:59:54  <wumpus> you can patch the code to set it lower, but I didn't feel like finding the lower bound
1532016-04-07T12:00:59  <GitHub32> [bitcoin] laanwj pushed 2 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/90f1d246d388...cada7c2418ef
1542016-04-07T12:01:00  <GitHub32> bitcoin/0.12 4c3a00d Wladimir J. van der Laan: Reduce block timeout to 10 minutes...
1552016-04-07T12:01:00  <GitHub32> bitcoin/0.12 cada7c2 Wladimir J. van der Laan: Fill in rest of release notes
1562016-04-07T12:01:28  <jonasschnelli> > Only 64-bit. Sorry, life is not fair.
1572016-04-07T12:01:29  <jonasschnelli> hah
1582016-04-07T12:02:40  <wumpus> doing some last-minute tests, going to tag 0.12.0rc1 in a bit
1592016-04-07T12:03:32  <assder> 0.12.1rc1?
1602016-04-07T12:03:41  <wumpus> yes, .1
1612016-04-07T12:05:32  * jonasschnelli is slowly dust his gitian builder
1622016-04-07T12:07:27  *** fengling has joined #bitcoin-core-dev
1632016-04-07T12:09:13  <wumpus> :D
1642016-04-07T12:10:41  <sipa> hmm, wallet.py rpc test doesn't work here, even though i didn't change anything wallet related
1652016-04-07T12:10:49  * sipa rebases
1662016-04-07T12:11:08  <wumpus> on 0.12?
1672016-04-07T12:11:32  <wumpus> Passed here: Running testscript wallet.py ... Tests successful Duration: 62 s
1682016-04-07T12:11:56  *** fengling has quit IRC
1692016-04-07T12:12:30  <sipa> no, master
1702016-04-07T12:12:41  <sipa> Unexpected exception caught during testing: No JSON object could be decoded
1712016-04-07T12:13:28  <sipa> let me try actual master
1722016-04-07T12:14:01  <wumpus> seems to work fine here, too
1732016-04-07T12:19:08  <sipa> hmm, master fails for me
1742016-04-07T12:19:29  <sipa> actually, all rpc tests fail
1752016-04-07T12:19:35  * sipa blames himself
1762016-04-07T12:28:11  *** frankenmint has joined #bitcoin-core-dev
1772016-04-07T12:28:27  *** zooko has joined #bitcoin-core-dev
1782016-04-07T12:29:57  <sipa> eh, HTTP 403
1792016-04-07T12:33:19  <sipa> how is the test framework supposed to authenticate?
1802016-04-07T12:33:58  <MarcoFalke> rpcuser, rpcpassword
1812016-04-07T12:33:59  <wumpus> there's only one way to get forbidden: if your IP isn't allowed to connect
1822016-04-07T12:34:22  <sipa> ah, it writes a bitcoin.conf file
1832016-04-07T12:34:28  <sipa> with username/password rt
1842016-04-07T12:35:42  <wumpus> wrong user or password will get you HTTP_UNAUTHORIZED (401)
1852016-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
1862016-04-07T12:39:41  <sipa> 2016-04-07 12:38:02 Received a POST request for / from 192.168.44.1:58356
1872016-04-07T12:39:58  <sipa> why is it using my LAN address...?
1882016-04-07T12:40:05  <wumpus> yes that seems wrong
1892016-04-07T12:40:15  <wumpus> why is it binding on your LAN address
1902016-04-07T12:40:18  <sipa> i played with iptables a while ago, perhaps i haven't rebooted yet
1912016-04-07T12:41:16  <sipa> sorry for bothering you with it
1922016-04-07T12:41:41  <wumpus> well I'd still like to know what caused this
1932016-04-07T12:43:57  <sipa> iptables -t nat -A POSTROUTING -j MASQUERADE
1942016-04-07T12:43:57  <sipa> iptables -A FORWARD -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
1952016-04-07T12:44:00  <sipa> iptables -A FORWARD -i eth0 -j ACCEPT
1962016-04-07T12:44:23  *** laurentmt has joined #bitcoin-core-dev
1972016-04-07T12:44:29  *** laurentmt has quit IRC
1982016-04-07T12:45:07  *** d_t has quit IRC
1992016-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
2002016-04-07T12:47:32  <wumpus> (which isn't ever started automatically IIRC)
2012016-04-07T12:48:33  <wumpus> so this must be a really strange network configuration indeed :)
2022016-04-07T12:52:45  <wumpus> maybe connections to localhost got masqueraded to your LAN address
2032016-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
2042016-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
2052016-04-07T12:57:56  <wumpus> not 401 or 403 though
2062016-04-07T13:01:57  *** zooko has quit IRC
2072016-04-07T13:10:25  *** RoyceX has quit IRC
2082016-04-07T13:10:53  *** RoyceX has joined #bitcoin-core-dev
2092016-04-07T13:13:54  *** laurentmt has joined #bitcoin-core-dev
2102016-04-07T13:14:23  <wumpus> easy solution though: actually check that "Content-Type" is "application/json" before starting decoding
2112016-04-07T13:22:24  *** MarcoFalke has quit IRC
2122016-04-07T13:23:39  *** MarcoFalke has joined #bitcoin-core-dev
2132016-04-07T13:27:01  *** MarcoFalke has quit IRC
2142016-04-07T13:32:50  <Luke-Jr> why not make it both JSON-RPC and HTTP error?
2152016-04-07T13:34:45  *** loltastic has joined #bitcoin-core-dev
2162016-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
2172016-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
2182016-04-07T13:38:47  <sipa> wumpus: the 0.12 travis failure is spurious, i think?
2192016-04-07T13:39:17  *** loltastic has quit IRC
2202016-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
2212016-04-07T13:42:06  <wumpus> wow that's one I've never seen before
2222016-04-07T13:42:31  <wumpus> but it must be a transient failure, yes
2232016-04-07T13:43:14  <wumpus> there haven't been any recent changes to secp256k1
2242016-04-07T13:43:29  <wumpus> (at least the one in bitcoin)
2252016-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
2262016-04-07T13:48:22  *** xabbix has quit IRC
2272016-04-07T13:49:10  *** xabbix has joined #bitcoin-core-dev
2282016-04-07T13:57:13  *** zooko has joined #bitcoin-core-dev
2292016-04-07T14:09:55  *** fengling has joined #bitcoin-core-dev
2302016-04-07T14:12:27  *** Giszmo has joined #bitcoin-core-dev
2312016-04-07T14:14:36  *** fengling has quit IRC
2322016-04-07T14:22:10  *** assder has quit IRC
2332016-04-07T14:27:00  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2342016-04-07T14:29:00  *** zooko has quit IRC
2352016-04-07T14:39:33  *** johnwhitton has joined #bitcoin-core-dev
2362016-04-07T14:40:07  *** MarcoFalke has joined #bitcoin-core-dev
2372016-04-07T14:57:03  *** Cheeseo has joined #bitcoin-core-dev
2382016-04-07T14:57:03  *** Cheeseo has joined #bitcoin-core-dev
2392016-04-07T14:58:59  *** RoyceX has quit IRC
2402016-04-07T15:05:25  *** frankenmint has quit IRC
2412016-04-07T15:12:42  *** laurentmt has quit IRC
2422016-04-07T15:32:14  *** abritoid has quit IRC
2432016-04-07T15:50:59  <wumpus>  * [new tag]         v0.12.1rc1 -> v0.12.1rc1
2442016-04-07T15:51:45  *** Chris_Stewart_5 has quit IRC
2452016-04-07T16:06:29  *** frankenmint has joined #bitcoin-core-dev
2462016-04-07T16:07:23  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2472016-04-07T16:12:07  *** frankenmint has quit IRC
2482016-04-07T16:12:44  *** fengling has joined #bitcoin-core-dev
2492016-04-07T16:13:09  <instagibbs> a failed assert for onlyMaybeDeadlock means it's actually deadlocked?
2502016-04-07T16:14:41  *** d_t has joined #bitcoin-core-dev
2512016-04-07T16:17:36  *** fengling has quit IRC
2522016-04-07T16:17:47  *** PaulCapestany has quit IRC
2532016-04-07T16:20:29  *** PaulCapestany has joined #bitcoin-core-dev
2542016-04-07T16:27:52  <wumpus> instagibbs: probably not, it's  a common intermittent error: https://github.com/bitcoin/bitcoin/issues/7470
2552016-04-07T16:29:07  <instagibbs> oh, right, i didn't see "Assertion" in the issue before. Thanks.
2562016-04-07T16:35:05  <sipa> why is that case classified as a potential deadlock?
2572016-04-07T16:35:16  <sipa> there are not even 2 locks that overlap
2582016-04-07T16:35:47  <sipa> cs_main is the only one shared
2592016-04-07T16:38:32  *** Chris_Stewart_5 has quit IRC
2602016-04-07T16:56:30  <instagibbs> how am I supposed to read the log?
2612016-04-07T17:07:26  *** molly has joined #bitcoin-core-dev
2622016-04-07T17:08:36  *** frankenmint has joined #bitcoin-core-dev
2632016-04-07T17:10:29  *** molz has quit IRC
2642016-04-07T17:13:03  *** frankenmint has quit IRC
2652016-04-07T17:14:12  *** jtimon has joined #bitcoin-core-dev
2662016-04-07T17:25:09  *** laurentmt has joined #bitcoin-core-dev
2672016-04-07T18:02:44  <jonasschnelli> wumpus: F.Y.I: the lmdb node crashed.
2682016-04-07T18:02:45  <jonasschnelli> sync.cpp:112: void potential_deadlock_detected(const std::pair<void*, void*>&, const LockStack&, const
2692016-04-07T18:02:45  <jonasschnelli> LockStack&): Assertion `onlyMaybeDeadlock' failed.
2702016-04-07T18:03:12  <wumpus> another potential deadlock, ugh
2712016-04-07T18:03:21  <wumpus> that should be unrelated to lmdb though, I haven't touched any locking
2722016-04-07T18:03:24  <jonasschnelli> Seems unrelated to lmdb
2732016-04-07T18:03:33  <wumpus> yes it's the #7470
2742016-04-07T18:03:46  <wumpus> another such report and I'm going to just reip out the potential deadlock detection
2752016-04-07T18:03:55  <wumpus> travis also crashes on it frequently
2762016-04-07T18:04:41  <jonasschnelli> http://pastebin.com/raw/zWehjWKw
2772016-04-07T18:05:02  <wumpus> the problem is that at some point the lock debugging was enabled by default with --enable-debug
2782016-04-07T18:05:15  <wumpus> ever since people have been getting this frequenltly
2792016-04-07T18:05:25  <instagibbs> wumpus, I just deactivated it in my config :/
2802016-04-07T18:05:30  <jonasschnelli> Is the crash-assert only active in --enable-debug?
2812016-04-07T18:05:35  <instagibbs> it was literally firing off each time my wallet rebroadcast a txn
2822016-04-07T18:05:49  <instagibbs> jonasschnelli, if you enable that it has it, yes
2832016-04-07T18:05:57  <wumpus>  jonasschnell: that's the only way to enable it with autoconf, yes
2842016-04-07T18:06:01  <instagibbs> -    CPPFLAGS="$CPPFLAGS -DDEBUG -DDEBUG_LOCKORDER"
2852016-04-07T18:06:03  <instagibbs> +    CPPFLAGS="$CPPFLAGS -DDEBUG"
2862016-04-07T18:06:25  <jonasschnelli> hmm.. we should have an extra autoconf -enable for -DDEBUG_LOCKORDER...
2872016-04-07T18:06:37  <jonasschnelli> IIRC it once was like this.
2882016-04-07T18:06:50  <wumpus> it used to be that you had to manually provide `CPPFLAGS=-DDEBUG_LOCKORDER` after configure to enable it
2892016-04-07T18:06:55  *** laurentmt has quit IRC
2902016-04-07T18:07:00  <wumpus> yes it was
2912016-04-07T18:07:11  <wumpus> this seemed like a good idea at the time to get more test coverage
2922016-04-07T18:07:17  <wumpus> and theoretically it is
2932016-04-07T18:07:25  <wumpus> but not if the check is broken in the first place
2942016-04-07T18:08:08  <wumpus> because those things have *never* got me a deadlock when not building without -enable-debug
2952016-04-07T18:08:14  <wumpus> -not
2962016-04-07T18:08:46  <wumpus> I'd be ok with a --debug-locks though jonasschnelli :)
2972016-04-07T18:09:04  <wumpus> or rather --enable-debug-locks, which isn't implied by --enable-debug
2982016-04-07T18:09:07  <jonasschnelli> I mean we could still enable it by default..
2992016-04-07T18:09:12  <wumpus> nah
3002016-04-07T18:09:19  *** frankenmint has joined #bitcoin-core-dev
3012016-04-07T18:09:23  <wumpus> only if we can fix it
3022016-04-07T18:09:40  <wumpus> we know the drill by now - false alarms are worse than no alarms
3032016-04-07T18:09:49  <jonasschnelli> Indeed!
3042016-04-07T18:13:33  *** frankenmint has quit IRC
3052016-04-07T18:14:11  *** wallet42 has joined #bitcoin-core-dev
3062016-04-07T18:14:18  *** jannes has quit IRC
3072016-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.
3082016-04-07T18:15:08  *** ebfull has quit IRC
3092016-04-07T18:15:17  <gmaxwell> but yes, false alarms are worse than no alarms.
3102016-04-07T18:15:38  *** ebfull has joined #bitcoin-core-dev
3112016-04-07T18:15:59  *** fengling has joined #bitcoin-core-dev
3122016-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.
3132016-04-07T18:19:14  <phantomcircuit> gmaxwell, it detects some stuff where the lock ordering is different in init.cpp from everywhere else
3142016-04-07T18:19:24  <phantomcircuit> which never causes a deadlock
3152016-04-07T18:20:36  *** fengling has quit IRC
3162016-04-07T18:22:03  <jtimon> sorry, the meeting is in 1 h 40 mins, right?
3172016-04-07T18:22:09  <jonasschnelli> jtimon: in 40mins
3182016-04-07T18:22:35  <jtimon> jonasschnelli: ok, thank you, I definitely needed to ask :)
3192016-04-07T18:22:41  <wumpus> 40 minutes, yes
3202016-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.
3212016-04-07T18:26:08  <wumpus> in my experience the deadlock detector code is hard to understand, and changes are hard to review
3222016-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
3232016-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
3242016-04-07T18:29:04  <wumpus> at least it used to do that
3252016-04-07T18:29:17  *** zooko has joined #bitcoin-core-dev
3262016-04-07T18:29:18  <sipa> wumpus: i'll have a look, i think i know how it works and how it should work
3272016-04-07T18:29:22  <wumpus> it seems pretty broken now
3282016-04-07T18:29:44  <wumpus> so let's disable it for --enable-debug and travis at least, keeping it as option makes sense
3292016-04-07T18:30:35  <wumpus> I think where it mainly fails is when try_lock is used
3302016-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
3312016-04-07T18:33:37  <wumpus> yes I think we should keep AssertLockHeld checks, they don't give problems
3322016-04-07T18:33:48  <wumpus> (I added many of them actually :)
3332016-04-07T18:34:18  <wumpus> it's only the deadlock detection that gives trouble, so yes makes sense to split that out
3342016-04-07T18:34:37  <morcos> yeah, right now they're both under -DDEBUG_LOCKORDER
3352016-04-07T18:35:28  <wumpus> yes they use the same underlying tracking
3362016-04-07T18:37:51  *** zooko has quit IRC
3372016-04-07T18:37:58  <wumpus> but maybe sipa can solve it :) I'd say he has enough to do though
3382016-04-07T18:40:52  <sipa> wumpus: the report in that bug report is wrong, it should not trigger the warning
3392016-04-07T18:41:04  <sipa> not even if they weren't try locks
3402016-04-07T18:41:35  <wumpus> yes it seems to be a false alert
3412016-04-07T18:42:18  <wumpus> and a lot of those happen, all with slightly different locks involved
3422016-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
3432016-04-07T18:43:20  <wumpus> it's very possible that the detection is just broken and generating spurious reports
3442016-04-07T18:46:43  <gmaxwell> another option is to stop using it and switch to helgrind for this purpose.
3452016-04-07T18:47:44  <wumpus> yes
3462016-04-07T18:48:44  <gmaxwell> (it wouldn't replace assert-lockheld though)
3472016-04-07T18:49:18  <gmaxwell> though due to performance I don't think helgrind would be usable on arm.
3482016-04-07T18:49:28  <wumpus> assert-lockheld works so we should just keep that, and disable the lockorder check until someone fixes it
3492016-04-07T18:49:59  <gmaxwell> But it helgrind will also catch a lot more than potential lock inversions.
3502016-04-07T18:50:58  <wumpus> yes the drawback of the *grind tools is the performance loss involved in instrumenting the code
3512016-04-07T18:52:26  <gmaxwell> seems people have not been running helgrind on the codebase.
3522016-04-07T18:53:39  <wumpus> (-DDEBUG_LOCKORDER also adds overhead, but only on aquiring/releasing locks)
3532016-04-07T18:53:57  <gmaxwell> and the overhead of being wrong and not getting used? :P
3542016-04-07T18:54:38  <wumpus> yes and the overhead of tons of open issues on the repository
3552016-04-07T19:00:37  * btcdrak rings the bell
3562016-04-07T19:00:58  <wumpus> #startmeeting
3572016-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.
3582016-04-07T19:00:58  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3592016-04-07T19:01:47  <wumpus> PSA: 0.12.1rc1 has been tagged, please start your gitian builders
3602016-04-07T19:01:54  <jonasschnelli> I have three topic proposals
3612016-04-07T19:01:55  <jonasschnelli> (1) How to proceed with cores wallet (I have a proposal)
3622016-04-07T19:01:55  <jonasschnelli> (2) CoreDev Hacking convention in Zurich (short announcement)
3632016-04-07T19:01:55  <jonasschnelli> (3) Dealing with RBF RPC/UI
3642016-04-07T19:02:16  <petertodd> jonasschnelli: ack, and I need an excuse to visit Zurich :)
3652016-04-07T19:02:42  <jonasschnelli> http://coredev.tech
3662016-04-07T19:02:53  <jonasschnelli> (sketch)
3672016-04-07T19:02:57  <wumpus> for the last meeting we have ACTION: start generating mtp violating transactions (gmaxwell) (wumpus, 19:08:21)
3682016-04-07T19:03:05  <wumpus> ACTION: #7543 has 5 tested ACKs so far. It should be ready for merge (wumpus, 19:22:52)
3692016-04-07T19:03:16  *** sanada has quit IRC
3702016-04-07T19:03:23  *** MarcoFalke_ has joined #bitcoin-core-dev
3712016-04-07T19:03:28  <wumpus> that was done
3722016-04-07T19:03:28  *** sanada has joined #bitcoin-core-dev
3732016-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.
3742016-04-07T19:03:41  <wumpus> ACTION: disable bad-chain alert for 0.12.1 (wumpus, 19:38:39)
3752016-04-07T19:03:44  <wumpus> that was also done
3762016-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
3772016-04-07T19:05:02  <wumpus> ok let's start with jonasschnelli's topics
3782016-04-07T19:05:15  <wumpus> #topic How to proceed with cores wallet
3792016-04-07T19:05:16  <btcdrak> wumpus ack
3802016-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)
3812016-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)
3822016-04-07T19:05:52  <jonasschnelli> If we agree on the concept. I'm happy to write tests, etc.
3832016-04-07T19:06:13  <jonasschnelli> So we can ensure that the second wallet runs smoothly along with the main wallet
3842016-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)?
3852016-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
3862016-04-07T19:06:25  *** johnwhitton has quit IRC
3872016-04-07T19:06:41  <jonasschnelli> gmaxwell: Yes. Important improvments could be applied on both wallets.
3882016-04-07T19:06:41  <btcdrak> jonasschnelli: sounds great
3892016-04-07T19:06:43  <gmaxwell> I think it's much better than a boil the ocean rewrite.
3902016-04-07T19:06:49  <jonasschnelli> The second wallet should not have a stable API for now.
3912016-04-07T19:07:01  <jonasschnelli> And we could merge more aggressively there.
3922016-04-07T19:07:20  <sipa> well if you intentionally break things in it, it may not get sufficient testing
3932016-04-07T19:07:25  <jonasschnelli> I would also be happy to be the maintainer of that second / currently experimental wallet.
3942016-04-07T19:07:25  <sipa> but concept ack
3952016-04-07T19:07:31  <wumpus> or maybe it will get sufficient testing
3962016-04-07T19:07:42  <wumpus> some people are waiting for things to be broken, especially the account system
3972016-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
3982016-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.
3992016-04-07T19:08:26  <wumpus> so it's kind of circular
4002016-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.
4012016-04-07T19:08:54  <jonasschnelli> Yes. We could mark it as experimental, don't use it with large amounts.
4022016-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
4032016-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.
4042016-04-07T19:09:22  <sipa> was just about the bring that up
4052016-04-07T19:09:28  <wumpus> morcos: well I expect them to diverge soon enough that that won't say a problem for long
4062016-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
4072016-04-07T19:09:36  *** johnwhitton has joined #bitcoin-core-dev
4082016-04-07T19:09:40  <phantomcircuit> gmaxwell: i can help you with relaying harder
4092016-04-07T19:09:41  <jonasschnelli> morcos: I think as we proceed, most features will only make sense on one or the other side.
4102016-04-07T19:09:43  <sipa> we can't put the burden on external contributors to duplicate
4112016-04-07T19:09:59  <wumpus> features will mostly end up in the new wallet
4122016-04-07T19:10:08  *** frankenmint has joined #bitcoin-core-dev
4132016-04-07T19:10:08  <wumpus> the old wallet should still receive bugfixes etc
4142016-04-07T19:10:18  <wumpus> it's a bit like stable versions/master
4152016-04-07T19:10:20  <morcos> hmm..  lots of things would apply to both,  conflicts, abandoned transactions, fee estimates
4162016-04-07T19:10:20  <jonasschnelli> wumpus: +1
4172016-04-07T19:10:40  *** fkhan_ has quit IRC
4182016-04-07T19:10:50  <wumpus> in any case I'd say this is up to the people doing the work
4192016-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
4202016-04-07T19:10:55  <morcos> 0.14
4212016-04-07T19:10:56  <morcos> ?
4222016-04-07T19:11:02  <wumpus> morcos: when it's ready
4232016-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.
4242016-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
4252016-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.
4262016-04-07T19:11:30  <morcos> we need something that is good to use
4272016-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
4282016-04-07T19:11:47  <morcos> right, i'm not opposed to doing this, i think we need to do something
4292016-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
4302016-04-07T19:12:05  <sipa> yes, i think we should aim to have the new wallet production ready soon, but just no stable onterface
4312016-04-07T19:12:10  <wumpus> (or maybe jonasschnelli and me should start a fork of bitcoin core *ducks*)
4322016-04-07T19:12:10  <sipa> *interface
4332016-04-07T19:12:40  <jonasschnelli> wumpus: I did that already... but the amount of reviewers was... lets say ... extremely tiny.
4342016-04-07T19:12:46  <jonasschnelli> We can't say SPV is doomed and not improvig the wallet at the same time.
4352016-04-07T19:12:47  <sipa> also, a lot of the unit tests for non-wallet features rely on having a wallet
4362016-04-07T19:13:06  <wumpus> yes, the unit tests should be less dependent on the wallet
4372016-04-07T19:13:11  <wumpus> but that's a different issue
4382016-04-07T19:13:23  <jonasschnelli> Yes. Hard to send around coins then. But agree.
4392016-04-07T19:13:41  <sipa> iwe can replicate a wallet in the python framework *ducjs*
4402016-04-07T19:13:43  <wumpus> (well, the non-wallet unit tests). In any case the unit tests can use the old wallet for now.
4412016-04-07T19:13:52  <petertodd> sipa: please do; python-bitcoinlib needs a wallet :)
4422016-04-07T19:13:56  <wumpus> sipa: yes :)
4432016-04-07T19:13:59  <wumpus> a python wallet please
4442016-04-07T19:14:09  <wumpus> :D
4452016-04-07T19:14:09  <sipa> the why do we need a wallet in core? ;)
4462016-04-07T19:14:15  <btcdrak> !
4472016-04-07T19:14:25  <paveljanik> for testing...
4482016-04-07T19:14:28  <wumpus> well one idea was to begin a new wallet outside of core
4492016-04-07T19:14:29  *** frankenmint has quit IRC
4502016-04-07T19:14:32  <jonasschnelli> I agree long term we could remove the wallet... but in tiny steps.
4512016-04-07T19:14:37  * gmaxwell bangs gavel
4522016-04-07T19:14:37  <sipa> ok
4532016-04-07T19:14:43  <sipa> who is gavel?
4542016-04-07T19:14:55  <jonasschnelli> Outside of core does not work for now.
4552016-04-07T19:15:00  <sipa> indeed
4562016-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
4572016-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
4582016-04-07T19:15:24  <jonasschnelli> As soon as the wallet can run SPV, we can think about moving it.
4592016-04-07T19:15:28  <btcdrak> sipa: do I need to call an ambulance?
4602016-04-07T19:15:41  <paveljanik> can't just work on the interaface/API for wallet and the new wallet to be outside of Core?
4612016-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
4622016-04-07T19:15:58  <wumpus> sure, feel free to do what you want to do outside of core paveljanik
4632016-04-07T19:16:28  <petertodd> jonasschnelli: why worry about SPV? write one that scans full blocks, grabbing them from a local bitcoind
4642016-04-07T19:16:30  <jonasschnelli> sipa: Yes. Once it can run SPV, it shares some base code, also the net stuff.
4652016-04-07T19:16:34  <sipa> jonasschnelli: please, modularization first, separate process next, and then we can start talking about other repository
4662016-04-07T19:16:41  <paveljanik> wumpus, that nees Core to provide API/something Jonas is already working on...
4672016-04-07T19:16:41  <wumpus> it makes sense, e.g. joinmarket has a wallet outside of core, although it's somewhat suboptimal
4682016-04-07T19:16:48  <sipa> petertodd: that's the idea
4692016-04-07T19:16:56  <sipa> petertodd: spv does not imply bip37
4702016-04-07T19:17:05  <wumpus> (still relies on the wallet inside core but using watch-only)
4712016-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.
4722016-04-07T19:17:34  <wumpus> jonasschnelli: yes
4732016-04-07T19:17:51  <wumpus> no one is actually proposing doing that now, but it's always how this discussion goes
4742016-04-07T19:17:53  <wumpus> and has gone for years
4752016-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)
4762016-04-07T19:18:03  <morcos> in an issue or something
4772016-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.
4782016-04-07T19:18:06  <wumpus> any progress you make is helpful jonasschnelli
4792016-04-07T19:18:24  <btcdrak> next topic?
4802016-04-07T19:18:29  <sipa> agree
4812016-04-07T19:18:32  <jonasschnelli> morcos: I'll write a proposal.
4822016-04-07T19:18:34  <jonasschnelli> agree next t.
4832016-04-07T19:18:41  <sipa> (my battery is at 11%)
4842016-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
4852016-04-07T19:18:58  <wumpus> #topic CoreDev Hacking convention in Zurich (short announcement)
4862016-04-07T19:19:02  <morcos> the plan doesn't have to be perfect, but it helps if its clear
4872016-04-07T19:19:13  <wumpus> morcos: it's a risk, but it's how it goes in open source
4882016-04-07T19:19:25  <jonasschnelli> I think we could all meet together and hack at some important stuff.
4892016-04-07T19:19:26  <jonasschnelli> http://coredev.tech
4902016-04-07T19:19:29  <gmaxwell> jonasschnelli: please just propose things for the short/mid term for now.
4912016-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
4922016-04-07T19:19:57  <jonasschnelli> Best would be to get SW nailed at the meeting in ZH.
4932016-04-07T19:20:10  <wumpus> awesome jonasschnelli
4942016-04-07T19:20:11  <jonasschnelli> I'm also convinced if we do that, we find sponsors pretty easy.
4952016-04-07T19:20:26  <jonasschnelli> Room, food, etc. is organized.
4962016-04-07T19:20:44  <jonasschnelli> If someone needs travel subsidy, please tell me.
4972016-04-07T19:20:53  <morcos> i like the idea, but unfortunately can't attend that weekend
4982016-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.
4992016-04-07T19:21:22  <sipa> is the date fixed?
5002016-04-07T19:21:25  <wumpus> sure I will
5012016-04-07T19:21:34  <jtimon> I probably will as well
5022016-04-07T19:21:38  <jonasschnelli> Date is semi-fixed. :)
5032016-04-07T19:21:39  <petertodd> jonasschnelli: I can attend
5042016-04-07T19:21:50  <sipa> i can attend
5052016-04-07T19:22:01  <sipa> (13 minute tram ride)
5062016-04-07T19:22:05  <sdaftuar> jonasschnelli: i'm interested, though not sure yet if i can make it
5072016-04-07T19:22:05  <jonasschnelli> Hah.
5082016-04-07T19:22:08  <wumpus> i can attend too, nothing else on that date at laest
5092016-04-07T19:22:23  <jonasschnelli> Its soon. Please try to give me a yes/no during the next 7 days.
5102016-04-07T19:22:38  <jonasschnelli> Okay. I'll flag wumpus, petertodd and sipa as "confirmed".
5112016-04-07T19:22:51  <jonasschnelli> and jtimon (he lives in spain and needs to come!)
5122016-04-07T19:22:52  *** fkhan_ has joined #bitcoin-core-dev
5132016-04-07T19:23:12  <gmaxwell> If you want people to come, more advanced planning would help, in the future! :)
5142016-04-07T19:23:22  <jtimon> jonasschnelli: yeah, unless something unexpected prevents me from going, sounds great to me
5152016-04-07T19:23:34  <jonasschnelli> gmaxwell: Agree. I just can't in June/Juli/Aug!
5162016-04-07T19:23:50  <jonasschnelli> If it wont work, I'll organize another one in fall.
5172016-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 :)
5182016-04-07T19:24:03  <btcdrak> jonasschnelli: seems like you have a lot of takers already
5192016-04-07T19:24:15  <sipa> petertodd: agree
5202016-04-07T19:24:21  <jonasschnelli> And Zurich is great! :-)
5212016-04-07T19:24:40  <jtimon> never been there, happy to visit it
5222016-04-07T19:24:40  <petertodd> I was in Zug for a week, and it was so beautiful that a cup of coffee cost $10
5232016-04-07T19:24:53  <jonasschnelli> </topic>
5242016-04-07T19:24:58  <wumpus> hehe
5252016-04-07T19:25:13  <sipa> next topic?
5262016-04-07T19:25:14  <wumpus> #topic Dealing with RBF RPC/UI
5272016-04-07T19:25:14  <jtimon> maybe I've been in the airport...sorry, yeah, next topic
5282016-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
5292016-04-07T19:25:56  <michagogo> Sorry I'm late, but: Bitcoin Core is still in beta, no?
5302016-04-07T19:26:05  <sipa> haha
5312016-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
5322016-04-07T19:26:19  <jonasschnelli> RBF: I dont have a clear vision how the RPC should deal with RBF
5332016-04-07T19:26:27  <gmaxwell> michagogo: the "beta" was dropped from the description years ago.
5342016-04-07T19:26:29  <michagogo> Huh, that timestamp broke weirdly
5352016-04-07T19:26:41  <michagogo> gmaxwell: really? I must have missed that
5362016-04-07T19:26:44  <gmaxwell> michagogo: and some stupid lable wouldn't excuse shoddy support.
5372016-04-07T19:27:06  <michagogo> gmaxwell: obviously, I was just commenting on the "non-beta" milestone
5382016-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?
5392016-04-07T19:27:41  <jonasschnelli> Ensure that the RBF rules are respected (>fee, pay for the bandwith, etc.)
5402016-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
5412016-04-07T19:28:10  <MarcoFalke_> Shouldn't we only support fee bump as a fist step?
5422016-04-07T19:28:16  <petertodd> MarcoFalke_: ack
5432016-04-07T19:28:27  <paveljanik> MarcoFalke: +1
5442016-04-07T19:28:30  <sipa> ack
5452016-04-07T19:28:38  <jonasschnelli> *exhales*
5462016-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.
5472016-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
5482016-04-07T19:28:58  <jtimon> one step at a time sounds good to me
5492016-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).
5502016-04-07T19:29:05  <petertodd> MarcoFalke_: and with fee bump, first implementation should probably *not* add inputs, which complicates things
5512016-04-07T19:29:23  <jonasschnelli> | How would a feebump over RPC looks like?
5522016-04-07T19:29:33  <petertodd> jonasschnelli: hmm? I released RBF for v0.11, but Core didn't
5532016-04-07T19:29:56  <jonasschnelli> sry, mixed up with CLTV... right. 0.12
5542016-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>
5552016-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.
5562016-04-07T19:31:25  <gmaxwell> or something like that.
5572016-04-07T19:31:26  <jonasschnelli> petertodd: bumpfee ... yes. maybe we find a call-name that is more flexible for the future?
5582016-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)
5592016-04-07T19:31:57  <sipa> related: cpfp?
5602016-04-07T19:31:58  <gmaxwell> RE: feebump, I think a different approach should be used.
5612016-04-07T19:32:07  <phantomcircuit> petertodd: there's significant privacy implications to combining payments
5622016-04-07T19:32:10  <petertodd> jonasschnelli: AbstractRespendWithSomeThingChangedFactoryBean?
5632016-04-07T19:32:19  <jonasschnelli> ^^
5642016-04-07T19:32:32  <petertodd> phantomcircuit: sure, which is why getting estimates right in the first place helps a lot
5652016-04-07T19:32:51  <sipa> jonasschnelli: it shall be called BeeFump
5662016-04-07T19:32:51  <petertodd> phantomcircuit: but if fee bumping is a once-in-a-while thing, I'm not that concerned re: privacy
5672016-04-07T19:32:55  <jonasschnelli> altertransaction was something we once have talked about
5682016-04-07T19:32:56  <Lightsword> petertodd, your factory needs a factory :P
5692016-04-07T19:32:56  <petertodd> sipa: +1
5702016-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.
5712016-04-07T19:33:11  <sipa> gmaxwell: elaborate?
5722016-04-07T19:33:22  <sipa> ah
5732016-04-07T19:33:24  <petertodd> Lightsword: I'm not going to grey-goo the world just to bump fees... :)
5742016-04-07T19:33:53  <wumpus> sure, that'd be even better, but even a simple 'bump fee' command would be better than nothing
5752016-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
5762016-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.
5772016-04-07T19:34:13  <jonasschnelli> Okay. Will work on "bumpfee".
5782016-04-07T19:34:29  <jonasschnelli> How do we estimate fees for replacements?
5792016-04-07T19:34:31  <petertodd> gmaxwell: my python script does it based on a ratio
5802016-04-07T19:34:42  <kanzure> #action bumpfee work
5812016-04-07T19:34:46  <petertodd> jonasschnelli: double every time by default? it's a good start
5822016-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%.
5832016-04-07T19:35:02  <petertodd> jonasschnelli: having to bump a fee implies that your fee estimation isn't working anyway :)
5842016-04-07T19:35:12  <jonasschnelli> petertodd: indeed!
5852016-04-07T19:35:17  <wumpus> exponential fee backoff
5862016-04-07T19:35:20  <gmaxwell> petertodd: well it could be working now, just not precognative. :)
5872016-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
5882016-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.
5892016-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?
5902016-04-07T19:36:05  <wumpus> phantomcircuit: agreed
5912016-04-07T19:36:17  <gmaxwell> phantomcircuit: jonasschnelli had a checkbox in the UI for the things he was doing so far.
5922016-04-07T19:36:33  *** laurentmt has joined #bitcoin-core-dev
5932016-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
5942016-04-07T19:36:56  <jonasschnelli> Yes. We don't opt-in automatically for now I guess.
5952016-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. :)
5962016-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
5972016-04-07T19:37:24  <wumpus> phantomcircuit: (although you could have the same, just agree on a certain *max* fee)
5982016-04-07T19:37:32  <gmaxwell> wumpus: what I suggested on the PR for that was just to list the possible fees (by the checkbox)
5992016-04-07T19:37:37  <jonasschnelli> wumpus: Agree. No automatic behavior that spends inputs automatically.
6002016-04-07T19:37:55  <btcdrak> I would just have "increase fee" and give an amount.
6012016-04-07T19:38:00  <gmaxwell> Fee of x/y/z/q after 0/2/3/4 blocks.
6022016-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?
6032016-04-07T19:38:34  <jonasschnelli> I though we could re-use the fee slider (but with ~x2 values).
6042016-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
6052016-04-07T19:39:04  <wumpus> morcos: depends on the order in which things actually get implemented, I'd say
6062016-04-07T19:39:08  <wumpus> yes agree with petertodd there
6072016-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.
6082016-04-07T19:39:34  <jonasschnelli> morcos: the old wallet could just have a fee bump, ..the new wallet a feature to add outputs.
6092016-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.
6102016-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)?
6112016-04-07T19:40:09  <sipa> jtimon: imho, no
6122016-04-07T19:40:13  <sipa> or not initially
6132016-04-07T19:40:16  <wumpus> the idea is tthat the new wallet can have a completely new interface
6142016-04-07T19:40:27  <wumpus> throwing out all the old cruft
6152016-04-07T19:40:28  <jonasschnelli> jtimon: if we want to depracate the old wallet and remove it once, it should probably be independent.
6162016-04-07T19:40:51  <wumpus> of course if there are things that make sense they can be kept
6172016-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.
6182016-04-07T19:41:06  <jonasschnelli> Also while writing on the new wallet, we can care more about core interaction. No mempool access everywhere.
6192016-04-07T19:41:24  <sipa> jonasschnelli: that may be... hard
6202016-04-07T19:41:28  <wumpus> jonasschnelli: at least make it event driven
6212016-04-07T19:41:31  <jtimon> mhmm, I'm just worried about calling code for both wallets from the same place
6222016-04-07T19:41:35  <wumpus> jonasschnelli: no assumption on *immediate* mempool access
6232016-04-07T19:41:47  <gmaxwell> jonasschnelli: many good features benefit from mempool access.
6242016-04-07T19:41:58  <sipa> jtimon: is that a problem?
6252016-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
6262016-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)
6272016-04-07T19:42:24  <wumpus> and it also holds up the GUI thread for things that shouldn't
6282016-04-07T19:42:31  <sipa> hey, main.cpp used to call the gui directly
6292016-04-07T19:42:42  <jonasschnelli> :-)
6302016-04-07T19:42:44  <wumpus> it's fine to have a query mempool, but it should be regarded as asynchronous
6312016-04-07T19:42:57  <wumpus> heh true sipa, we made a step forward with  bitcoin-qt :-)
6322016-04-07T19:43:24  <sipa> other topic?
6332016-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
6342016-04-07T19:43:36  <sipa> as we seem to have backtracked to a previous o e
6352016-04-07T19:43:38  <wumpus> better to have something then make a wild plan which grows so huge it can never be executed
6362016-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
6372016-04-07T19:44:04  <wumpus> petertodd: I don't know, depends on the application
6382016-04-07T19:44:15  <sipa> jtimon: oh hell no, that isn't allowed
6392016-04-07T19:44:23  <sipa> jtimon: everything through validationinterface
6402016-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
6412016-04-07T19:44:36  <jtimon> sipa: oh, that was my question then, thanks
6422016-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
6432016-04-07T19:46:06  <wumpus> any other topics?
6442016-04-07T19:46:11  <jtimon> great, that was my only concern about jonasschnelli's plan, I knew I was probably misunderstanding something
6452016-04-07T19:46:30  <jonasschnelli> I'll write a clean concept.
6462016-04-07T19:47:07  <sipa> oh, small question: are we ok with backporting master's script/tx unit tests to 0.12?
6472016-04-07T19:47:44  <petertodd> sipa: ack
6482016-04-07T19:47:45  *** laurentmt has quit IRC
6492016-04-07T19:47:49  <paveljanik> why not?
6502016-04-07T19:47:51  <wumpus> well if the tests are better it always makes sense to backport them
6512016-04-07T19:48:04  <sipa> testd are not typically something we backport
6522016-04-07T19:48:09  <wumpus> I'm fine with copying all the tests from master to 0.12 given that the funcitnality is supported
6532016-04-07T19:48:17  <sipa> but i think it makes total sense as we want softforks backported too
6542016-04-07T19:48:22  <sdaftuar> wumpus: i wanted to flag #7835 which i just opened for 0.12.1
6552016-04-07T19:48:25  <petertodd> sipa: agreed
6562016-04-07T19:48:39  <wumpus> sdaftuar: too late, 0.12.1 was just tagged
6572016-04-07T19:48:49  <sipa> sdaftuar: just rc1?
6582016-04-07T19:48:55  <sipa> wumpus: ^
6592016-04-07T19:49:00  <wumpus> yes
6602016-04-07T19:49:03  <sipa> or no rc cycle?
6612016-04-07T19:49:17  <btcdrak> Freudian slip
6622016-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
6632016-04-07T19:49:30  <MarcoFalke_> lets hope rc1 one is the final release ;)
6642016-04-07T19:49:38  <wumpus> [21:01:15] <wumpus> PSA: 0.12.1rc1 has been tagged, please start your gitian builders
6652016-04-07T19:49:50  <morcos> right, so its not too late for 0.12.1 right?
6662016-04-07T19:49:58  <btcdrak> 20:01:47 <wumpus> PSA: 0.12.1rc1 has been tagged, please start your gitian builders
6672016-04-07T19:50:11  <wumpus> well there will only be a rc2 if necessary, does this need to block the release?
6682016-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
6692016-04-07T19:50:57  <sipa> wumpus: we should consider it i thonk
6702016-04-07T19:51:08  <sdaftuar> without the change, which is simple
6712016-04-07T19:51:19  <wumpus> ok...
6722016-04-07T19:51:24  <sipa> sowwy
6732016-04-07T19:51:32  <wumpus> rc1 is dead folks
6742016-04-07T19:51:37  <wumpus> don't bother building it
6752016-04-07T19:51:43  * btcdrak stops his gitian builder
6762016-04-07T19:51:50  <wumpus> long live rc2
6772016-04-07T19:51:58  <btcdrak> I thought we had discussed this exact thing before regarding V2
6782016-04-07T19:52:09  <morcos> wumpus you know i save these things until after your release candidates just for the entertainment value right?
6792016-04-07T19:52:41  <wumpus> morcos: I know, no offense taken :) better now than later, almost no one wasted cycles on rc1 yet
6802016-04-07T19:52:44  *** laurentmt has joined #bitcoin-core-dev
6812016-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
6822016-04-07T19:52:59  <btcdrak> sdaftuar: that's quite an elegant solution.
6832016-04-07T19:53:16  <sdaftuar> btcdrak: that's because i stole it from sipa's segwit
6842016-04-07T19:53:36  <wumpus> #action review and ACK https://github.com/bitcoin/bitcoin/pull/7835/files asap
6852016-04-07T19:53:37  <btcdrak> long live sipa
6862016-04-07T19:53:49  <morcos> we should add this to our list of standard ways to implement things whenever we relax standardness rules
6872016-04-07T19:53:58  <btcdrak> morcos: agreed
6882016-04-07T19:55:11  <sipa> 2% battery left for me; anything else?
6892016-04-07T19:55:20  <morcos> travel charger?
6902016-04-07T19:55:23  <jonasschnelli> lol
6912016-04-07T19:55:34  <wumpus> I don't think so
6922016-04-07T19:55:45  <wumpus> #endmeeting
6932016-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)
6942016-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
6952016-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
6962016-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
6972016-04-07T19:56:20  *** cryptapus has quit IRC
6982016-04-07T19:56:43  <achow101> wait, is rc1 actually dead?
6992016-04-07T19:56:54  <wumpus> yes, dead as a doornail
7002016-04-07T19:57:11  *** MarcoFalke_ has quit IRC
7012016-04-07T19:57:15  <btcdrak> "it's dead Jim"
7022016-04-07T19:57:41  <wumpus> we'll probably tag rc2 tomorrow
7032016-04-07T19:58:03  <achow101> ok
7042016-04-07T19:58:05  <wumpus> doesn't make sense to do a gitian process in the mean time
7052016-04-07T20:02:40  *** Guyver2 has joined #bitcoin-core-dev
7062016-04-07T20:12:20  *** zooko has joined #bitcoin-core-dev
7072016-04-07T20:18:40  *** fengling has joined #bitcoin-core-dev
7082016-04-07T20:22:56  *** fengling has quit IRC
7092016-04-07T20:25:20  *** d_t has quit IRC
7102016-04-07T20:33:58  *** frankenmint has joined #bitcoin-core-dev
7112016-04-07T20:35:36  *** spikeheadon has joined #bitcoin-core-dev
7122016-04-07T20:38:04  *** frankenmint has quit IRC
7132016-04-07T20:39:22  *** wallet42 has quit IRC
7142016-04-07T20:42:22  *** xabbix has quit IRC
7152016-04-07T20:43:22  *** xabbix has joined #bitcoin-core-dev
7162016-04-07T20:43:22  *** xabbix has joined #bitcoin-core-dev
7172016-04-07T20:46:14  *** lamagra has quit IRC
7182016-04-07T20:49:53  *** zooko has quit IRC
7192016-04-07T20:50:28  *** zooko has joined #bitcoin-core-dev
7202016-04-07T20:51:13  *** laurentmt has quit IRC
7212016-04-07T21:04:24  *** zooko has quit IRC
7222016-04-07T21:15:28  *** cryptapus_afk is now known as cryptapus
7232016-04-07T21:16:43  *** murch has joined #bitcoin-core-dev
7242016-04-07T21:20:58  *** belcher has joined #bitcoin-core-dev
7252016-04-07T21:23:42  *** kangx has joined #bitcoin-core-dev
7262016-04-07T21:29:08  *** wallet42 has joined #bitcoin-core-dev
7272016-04-07T21:51:18  *** johnwhitton has quit IRC
7282016-04-07T21:57:23  *** zooko has joined #bitcoin-core-dev
7292016-04-07T21:59:12  *** belcher has quit IRC
7302016-04-07T22:00:03  *** belcher has joined #bitcoin-core-dev
7312016-04-07T22:02:28  *** belcher has quit IRC
7322016-04-07T22:04:00  *** zooko has quit IRC
7332016-04-07T22:25:22  *** cryptapus is now known as cryptapus_afk
7342016-04-07T22:36:52  *** AaronvanW has quit IRC
7352016-04-07T22:39:22  *** johnwhitton has joined #bitcoin-core-dev
7362016-04-07T22:42:34  *** belcher has joined #bitcoin-core-dev
7372016-04-07T22:55:19  *** johnwhitton has quit IRC
7382016-04-07T22:56:13  *** zooko has joined #bitcoin-core-dev
7392016-04-07T22:56:14  *** johnwhitton has joined #bitcoin-core-dev
7402016-04-07T23:03:12  *** johnwhitton has quit IRC
7412016-04-07T23:07:26  *** murch has quit IRC
7422016-04-07T23:26:09  *** laurentmt has joined #bitcoin-core-dev
7432016-04-07T23:26:27  *** Thireus has quit IRC
7442016-04-07T23:26:39  *** Guyver2 has quit IRC
7452016-04-07T23:26:51  *** laurentmt has quit IRC
7462016-04-07T23:59:22  *** wallet42 has quit IRC