--- Day changed Thu Apr 07 2016
00:07 -!- abritoid [~abritoid@46.16.193.99] has joined #bitcoin-core-dev
00:08 -!- p15_ [~p15@183.91.145.64.unassigned.bringover.net] has joined #bitcoin-core-dev
00:08 -!- jtimon [~quassel@227.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 252 seconds]
00:10 -!- p15 [~p15@130.91.145.64.unassigned.bringover.net] has quit [Ping timeout: 260 seconds]
00:21 < jonasschnelli> wumpus: does "getlabeladdress" would still make sense for labels only? https://github.com/bitcoin/bitcoin/pull/7729/files#diff-df7d84ff2f53fcb2a0dc15a3a51e55ceR2506 
00:21 < jonasschnelli> What if an the same label is used for multiple addresses?
00:22 < wumpus> jonasschnelli: I don't think so, I say the same in my OP :) (see the discussion with Luke-Jr in the pull)
00:22 < jonasschnelli> Okay.
00:22 < 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.
00:22 < jonasschnelli> Haven't seen that.
00:23 < jonasschnelli> I cloned now the wallet, made it runnable in parallel and removing accounts. I take some parts out of 7729
00:25 < wumpus> awesome!
00:28 < 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
00:35 < jonasschnelli> Yes. I have removed it.
01:15 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev
01:27 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
01:29 -!- ebfull [~sean@73.34.119.0] has quit [Ping timeout: 244 seconds]
01:32 -!- ebfull [~sean@73.34.119.0] has joined #bitcoin-core-dev
01:44 -!- rubensayshi [~ruben@c89225.upc-c.chello.nl] has joined #bitcoin-core-dev
01:53 < 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
02:10 -!- hsmiths2 [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has joined #bitcoin-core-dev
02:10 -!- hsmiths [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has quit [Read error: Connection reset by peer]
02:23 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
02:28 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection]
02:34 < 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
02:52 -!- BCBot [~BCBot@nb-10350.ethz.ch] has quit [Remote host closed the connection]
02:52 -!- BCBot_ [~BCBot@pc-5305.ethz.ch] has joined #bitcoin-core-dev
02:56 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
02:59 < 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
03:02 < sipa> If you manage to
03:02 < sipa> +suffer financial or other losses due to this code I demand compensation for
03:02 < sipa> +feelings of misplaced guilt.
03:02 < sipa> LOL
03:03 < wumpus> :-)
03:03 -!- p15_ [~p15@183.91.145.64.unassigned.bringover.net] has quit [Ping timeout: 244 seconds]
03:04 -!- p15 [~p15@183.91.145.64.unassigned.bringover.net] has joined #bitcoin-core-dev
03:07 -!- ebfull [~sean@73.34.119.0] has quit [Ping timeout: 244 seconds]
03:08 -!- ebfull [~sean@73.34.119.0] has joined #bitcoin-core-dev
03:34 -!- p15 [~p15@183.91.145.64.unassigned.bringover.net] has quit [Ping timeout: 268 seconds]
03:58 -!- ebfull [~sean@73.34.119.0] has quit [Ping timeout: 244 seconds]
03:59 -!- ebfull [~sean@73.34.119.0] has joined #bitcoin-core-dev
03:59 < GitHub82> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3bc71e1572cb...bbaf5976af84
03:59 < GitHub82> bitcoin/master 07398e8 Wladimir J. van der Laan: init: allow shutdown during 'Activating best chain...'...
03:59 < GitHub82> bitcoin/master bbaf597 Wladimir J. van der Laan: Merge #7821: init: allow shutdown during 'Activating best chain...'...
03:59 < 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
04:01 < GitHub0> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/4226aacdba7d0e1e22555dac69363b3b460a166b
04:01 < GitHub0> bitcoin/0.12 4226aac Wladimir J. van der Laan: init: allow shutdown during 'Activating best chain...'...
04:03 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
04:07 < GitHub95> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/bbaf5976af84...1ddf0cee679d
04:07 < GitHub95> bitcoin/master 2d1d658 Pieter Wuille: Track block download times per individual block...
04:07 < GitHub95> bitcoin/master 0e24bbf Pieter Wuille: Self check after the last peer is removed
04:07 < GitHub95> bitcoin/master 1ddf0ce Wladimir J. van der Laan: Merge #7804: Track block download times per individual block...
04:07 < GitHub85> [bitcoin] laanwj closed pull request #7804: Track block download times per individual block (master...betterkicktimeout) https://github.com/bitcoin/bitcoin/pull/7804
04:13 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
04:16 < GitHub39> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/90f1d246d38803eb546c6652ddce5ebea55eec98
04:16 < GitHub39> bitcoin/0.12 90f1d24 Pieter Wuille: Track block download times per individual block...
04:19 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
04:19 < 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
04:29 -!- wallet42 [uid154231@gateway/web/irccloud.com/x-rsouyldvlllpbjcn] has quit [Quit: Connection closed for inactivity]
04:35 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev
04:35 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
04:38 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Remote host closed the connection]
04:41 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
04:44 < jonasschnelli> wumpus: did you already try to run it (your LMDB branch) on a standard 64 bit Linux?
04:44 < wumpus> yep
04:44 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
04:44 < wumpus> passes the tests and seems to work
04:45 < jonasschnelli> Okay. Then I'll give it a try on my Debian Server (fresh sync from random peers).
04:45 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
04:53 < GitHub3> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1ddf0cee679d...5851915a006a
04:53 < GitHub3> bitcoin/master 62b9a55 Wladimir J. van der Laan: Reduce block timeout to 10 minutes...
04:53 < GitHub3> bitcoin/master 5851915 Wladimir J. van der Laan: Merge #7832: Reduce block timeout to 10 minutes...
04:53 < 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
04:57 -!- lamagra [~lamagra@159.14.216.139.sta.dodo.net.au] has joined #bitcoin-core-dev
04:58 < jonasschnelli> wumpus: is there a reason to reserve 8GB for the chainstate2/data.mdb db?
04:58 < jonasschnelli> or is that just on my end...
04:59 < wumpus> well it's bound to not be too little, for now
04:59 < wumpus> see https://github.com/laanwj/bitcoin/tree/2016_04_mdb#mapsize
04:59 < jonasschnelli> Ah. The readme was shortened on my smartphone. Nice.
04:59 < wumpus> you can patch the code to set it lower, but I didn't feel like finding the lower bound
05:01 < GitHub32> [bitcoin] laanwj pushed 2 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/90f1d246d388...cada7c2418ef
05:01 < GitHub32> bitcoin/0.12 4c3a00d Wladimir J. van der Laan: Reduce block timeout to 10 minutes...
05:01 < GitHub32> bitcoin/0.12 cada7c2 Wladimir J. van der Laan: Fill in rest of release notes
05:01 < jonasschnelli> > Only 64-bit. Sorry, life is not fair.
05:01 < jonasschnelli> hah
05:02 < wumpus> doing some last-minute tests, going to tag 0.12.0rc1 in a bit
05:03 < assder> 0.12.1rc1?
05:03 < wumpus> yes, .1
05:05  * jonasschnelli is slowly dust his gitian builder
05:07 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
05:09 < wumpus> :D
05:10 < sipa> hmm, wallet.py rpc test doesn't work here, even though i didn't change anything wallet related
05:10  * sipa rebases
05:11 < wumpus> on 0.12?
05:11 < wumpus> Passed here: Running testscript wallet.py ... Tests successful Duration: 62 s
05:11 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
05:12 < sipa> no, master
05:12 < sipa> Unexpected exception caught during testing: No JSON object could be decoded
05:13 < sipa> let me try actual master
05:14 < wumpus> seems to work fine here, too
05:19 < sipa> hmm, master fails for me
05:19 < sipa> actually, all rpc tests fail
05:19  * sipa blames himself
05:28 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
05:28 -!- zooko [~user@50.141.119.35] has joined #bitcoin-core-dev
05:29 < sipa> eh, HTTP 403
05:33 < sipa> how is the test framework supposed to authenticate?
05:34 < MarcoFalke> rpcuser, rpcpassword
05:34 < wumpus> there's only one way to get forbidden: if your IP isn't allowed to connect
05:34 < sipa> ah, it writes a bitcoin.conf file
05:34 < sipa> with username/password rt
05:35 < wumpus> wrong user or password will get you HTTP_UNAUTHORIZED (401)
05:38 < wumpus> no idea how an RPC test could end up connecting through a non-allowed IP though, afaik  none of the tests sets rpcallow
05:39 < sipa> 2016-04-07 12:38:02 Received a POST request for / from 192.168.44.1:58356
05:40 < sipa> why is it using my LAN address...?
05:40 < wumpus> yes that seems wrong
05:40 < wumpus> why is it binding on your LAN address
05:40 < sipa> i played with iptables a while ago, perhaps i haven't rebooted yet
05:41 < sipa> sorry for bothering you with it
05:41 < wumpus> well I'd still like to know what caused this
05:43 < sipa> iptables -t nat -A POSTROUTING -j MASQUERADE
05:43 < sipa> iptables -A FORWARD -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
05:44 < sipa> iptables -A FORWARD -i eth0 -j ACCEPT
05:44 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
05:44 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
05:45 -!- d_t [~textual@185.69.203.10] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
05:47 < 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
05:47 < wumpus> (which isn't ever started automatically IIRC)
05:48 < wumpus> so this must be a really strange network configuration indeed :)
05:52 < wumpus> maybe connections to localhost got masqueraded to your LAN address 
05:56 < 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
05:57 < wumpus> oh fuck it does, JSONErrorReply still converts some JSON RPC errors to HTTP errors, thought that was changed at some point
05:57 < wumpus> not 401 or 403 though
06:01 -!- zooko [~user@50.141.119.35] has quit [Ping timeout: 268 seconds]
06:10 -!- RoyceX [~x@unaffiliated/cheeseo] has quit [Read error: Connection reset by peer]
06:10 -!- RoyceX [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev
06:13 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
06:14 < wumpus> easy solution though: actually check that "Content-Type" is "application/json" before starting decoding
06:22 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
06:23 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has joined #bitcoin-core-dev
06:27 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has quit [Client Quit]
06:32 < Luke-Jr> why not make it both JSON-RPC and HTTP error?
06:34 -!- loltastic [~loltastic@cpe-76-176-190-83.san.res.rr.com] has joined #bitcoin-core-dev
06:37 < 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
06:38 < 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
06:38 < sipa> wumpus: the 0.12 travis failure is spurious, i think?
06:39 -!- loltastic [~loltastic@cpe-76-176-190-83.san.res.rr.com] has quit [Client Quit]
06:42 < 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
06:42 < wumpus> wow that's one I've never seen before
06:42 < wumpus> but it must be a transient failure, yes
06:43 < wumpus> there haven't been any recent changes to secp256k1
06:43 < wumpus> (at least the one in bitcoin)
06:47 < 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
06:48 -!- xabbix [~xabbix@unaffiliated/xabbix] has quit [Ping timeout: 252 seconds]
06:49 -!- xabbix [~xabbix@unaffiliated/xabbix] has joined #bitcoin-core-dev
06:57 -!- zooko [~user@50.141.118.215] has joined #bitcoin-core-dev
07:09 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
07:12 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev
07:14 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
07:22 -!- assder [82ebca3a@gateway/web/freenode/ip.130.235.202.58] has quit [Ping timeout: 250 seconds]
07:27 -!- Chris_Stewart_5 [~Chris_Ste@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev
07:29 -!- zooko [~user@50.141.118.215] has quit [Ping timeout: 246 seconds]
07:39 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
07:40 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has joined #bitcoin-core-dev
07:57 -!- Cheeseo [~x@c-71-58-178-138.hsd1.pa.comcast.net] has joined #bitcoin-core-dev
07:57 -!- Cheeseo [~x@c-71-58-178-138.hsd1.pa.comcast.net] has quit [Changing host]
07:57 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev
07:59 -!- RoyceX [~x@unaffiliated/cheeseo] has quit [Ping timeout: 260 seconds]
08:05 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection]
08:12 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
08:32 -!- abritoid [~abritoid@46.16.193.99] has quit [Ping timeout: 248 seconds]
08:51 < wumpus>  * [new tag]         v0.12.1rc1 -> v0.12.1rc1
08:51 -!- Chris_Stewart_5 [~Chris_Ste@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 276 seconds]
09:06 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
09:07 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
09:12 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 244 seconds]
09:12 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
09:13 < instagibbs> a failed assert for onlyMaybeDeadlock means it's actually deadlocked?
09:14 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev
09:17 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
09:17 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Quit: .]
09:20 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
09:27 < wumpus> instagibbs: probably not, it's  a common intermittent error: https://github.com/bitcoin/bitcoin/issues/7470
09:29 < instagibbs> oh, right, i didn't see "Assertion" in the issue before. Thanks.
09:35 < sipa> why is that case classified as a potential deadlock?
09:35 < sipa> there are not even 2 locks that overlap
09:35 < sipa> cs_main is the only one shared
09:38 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 0.4.2]
09:56 < instagibbs> how am I supposed to read the log?
10:07 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
10:08 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
10:10 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
10:13 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 240 seconds]
10:14 -!- jtimon [~quassel@227.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
10:25 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
11:02 < jonasschnelli> wumpus: F.Y.I: the lmdb node crashed.
11:02 < jonasschnelli> sync.cpp:112: void potential_deadlock_detected(const std::pair<void*, void*>&, const LockStack&, const 
11:02 < jonasschnelli> LockStack&): Assertion `onlyMaybeDeadlock' failed.
11:03 < wumpus> another potential deadlock, ugh
11:03 < wumpus> that should be unrelated to lmdb though, I haven't touched any locking
11:03 < jonasschnelli> Seems unrelated to lmdb
11:03 < wumpus> yes it's the #7470
11:03 < wumpus> another such report and I'm going to just reip out the potential deadlock detection
11:03 < wumpus> travis also crashes on it frequently
11:04 < jonasschnelli> http://pastebin.com/raw/zWehjWKw
11:05 < wumpus> the problem is that at some point the lock debugging was enabled by default with --enable-debug
11:05 < wumpus> ever since people have been getting this frequenltly
11:05 < instagibbs> wumpus, I just deactivated it in my config :/
11:05 < jonasschnelli> Is the crash-assert only active in --enable-debug?
11:05 < instagibbs> it was literally firing off each time my wallet rebroadcast a txn
11:05 < instagibbs> jonasschnelli, if you enable that it has it, yes
11:05 < wumpus>  jonasschnell: that's the only way to enable it with autoconf, yes
11:06 < instagibbs> -    CPPFLAGS="$CPPFLAGS -DDEBUG -DDEBUG_LOCKORDER"
11:06 < instagibbs> +    CPPFLAGS="$CPPFLAGS -DDEBUG"
11:06 < jonasschnelli> hmm.. we should have an extra autoconf -enable for -DDEBUG_LOCKORDER...
11:06 < jonasschnelli> IIRC it once was like this.
11:06 < wumpus> it used to be that you had to manually provide `CPPFLAGS=-DDEBUG_LOCKORDER` after configure to enable it
11:06 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
11:07 < wumpus> yes it was
11:07 < wumpus> this seemed like a good idea at the time to get more test coverage
11:07 < wumpus> and theoretically it is
11:07 < wumpus> but not if the check is broken in the first place
11:08 < wumpus> because those things have *never* got me a deadlock when not building without -enable-debug
11:08 < wumpus> -not
11:08 < wumpus> I'd be ok with a --debug-locks though jonasschnelli :)
11:09 < wumpus> or rather --enable-debug-locks, which isn't implied by --enable-debug
11:09 < jonasschnelli> I mean we could still enable it by default..
11:09 < wumpus> nah
11:09 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
11:09 < wumpus> only if we can fix it
11:09 < wumpus> we know the drill by now - false alarms are worse than no alarms
11:09 < jonasschnelli> Indeed!
11:13 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 240 seconds]
11:14 -!- wallet42 [uid154231@gateway/web/irccloud.com/x-ixfnmzkvkyocudyr] has joined #bitcoin-core-dev
11:14 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]
11:15 < gmaxwell> never having gotten wedged in practice doesn't mean there isn't a lock inversion that needs to be fixed though.
11:15 -!- ebfull [~sean@73.34.119.0] has quit [Quit: Konversation terminated!]
11:15 < gmaxwell> but yes, false alarms are worse than no alarms.
11:15 -!- ebfull [~sean@73.34.119.0] has joined #bitcoin-core-dev
11:16 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
11:16 < 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.
11:19 < phantomcircuit> gmaxwell, it detects some stuff where the lock ordering is different in init.cpp from everywhere else
11:19 < phantomcircuit> which never causes a deadlock
11:20 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
11:22 < jtimon> sorry, the meeting is in 1 h 40 mins, right?
11:22 < jonasschnelli> jtimon: in 40mins
11:22 < jtimon> jonasschnelli: ok, thank you, I definitely needed to ask :)
11:22 < wumpus> 40 minutes, yes
11:24 < 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.
11:26 < wumpus> in my experience the deadlock detector code is hard to understand, and changes are hard to review
11:28 < 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
11:29 < 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
11:29 < wumpus> at least it used to do that
11:29 -!- zooko [~user@172.56.8.198] has joined #bitcoin-core-dev
11:29 < sipa> wumpus: i'll have a look, i think i know how it works and how it should work
11:29 < wumpus> it seems pretty broken now
11:29 < wumpus> so let's disable it for --enable-debug and travis at least, keeping it as option makes sense
11:30 < wumpus> I think where it mainly fails is when try_lock is used
11:32 < 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
11:33 < wumpus> yes I think we should keep AssertLockHeld checks, they don't give problems
11:33 < wumpus> (I added many of them actually :)
11:34 < wumpus> it's only the deadlock detection that gives trouble, so yes makes sense to split that out
11:34 < morcos> yeah, right now they're both under -DDEBUG_LOCKORDER
11:35 < wumpus> yes they use the same underlying tracking
11:37 -!- zooko [~user@172.56.8.198] has quit [Ping timeout: 246 seconds]
11:38 < wumpus> but maybe sipa can solve it :) I'd say he has enough to do though
11:40 < sipa> wumpus: the report in that bug report is wrong, it should not trigger the warning
11:41 < sipa> not even if they weren't try locks
11:41 < wumpus> yes it seems to be a false alert
11:42 < wumpus> and a lot of those happen, all with slightly different locks involved
11:42 < wumpus> if there are any real reports it's really hard to narrow down *which* locks are the problem from that output
11:43 < wumpus> it's very possible that the detection is just broken and generating spurious reports
11:46 < gmaxwell> another option is to stop using it and switch to helgrind for this purpose. 
11:47 < wumpus> yes
11:48 < gmaxwell> (it wouldn't replace assert-lockheld though)
11:49 < gmaxwell> though due to performance I don't think helgrind would be usable on arm.
11:49 < wumpus> assert-lockheld works so we should just keep that, and disable the lockorder check until someone fixes it
11:50 < gmaxwell> But it helgrind will also catch a lot more than potential lock inversions.
11:51 < wumpus> yes the drawback of the *grind tools is the performance loss involved in instrumenting the code
11:52 < gmaxwell> seems people have not been running helgrind on the codebase.
11:53 < wumpus> (-DDEBUG_LOCKORDER also adds overhead, but only on aquiring/releasing locks)
11:53 < gmaxwell> and the overhead of being wrong and not getting used? :P
11:54 < wumpus> yes and the overhead of tons of open issues on the repository
12:00  * btcdrak rings the bell
12:01 < wumpus> #startmeeting
12:01 < lightningbot> Meeting started Thu Apr  7 19:00:58 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:01 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:01 < wumpus> PSA: 0.12.1rc1 has been tagged, please start your gitian builders
12:01 < jonasschnelli> I have three topic proposals
12:01 < jonasschnelli> (1) How to proceed with cores wallet (I have a proposal)
12:01 < jonasschnelli> (2) CoreDev Hacking convention in Zurich (short announcement)
12:01 < jonasschnelli> (3) Dealing with RBF RPC/UI
12:02 < petertodd> jonasschnelli: ack, and I need an excuse to visit Zurich :)
12:02 < jonasschnelli> http://coredev.tech
12:02 < jonasschnelli> (sketch)
12:02 < wumpus> for the last meeting we have ACTION: start generating mtp violating transactions (gmaxwell) (wumpus, 19:08:21)
12:03 < wumpus> ACTION: #7543 has 5 tested ACKs so far. It should be ready for merge (wumpus, 19:22:52)
12:03 -!- sanada [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has quit [Read error: Connection reset by peer]
12:03 -!- MarcoFalke_ [579f3eec@gateway/web/cgi-irc/kiwiirc.com/ip.87.159.62.236] has joined #bitcoin-core-dev
12:03 < wumpus> that was done
12:03 -!- sanada [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has joined #bitcoin-core-dev
12:03 < 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.
12:03 < wumpus> ACTION: disable bad-chain alert for 0.12.1 (wumpus, 19:38:39)
12:03 < wumpus> that was also done
12:04 < 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
12:05 < wumpus> ok let's start with jonasschnelli's topics
12:05 < wumpus> #topic How to proceed with cores wallet
12:05 < btcdrak> wumpus ack
12:05 < 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)
12:05 < jonasschnelli> It would help to merge it as soon as it is usefull (remove accounts and add label RPC calls, reset wallet-version)
12:05 < jonasschnelli> If we agree on the concept. I'm happy to write tests, etc.
12:06 < jonasschnelli> So we can ensure that the second wallet runs smoothly along with the main wallet
12:06 < 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)?
12:06 < 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
12:06 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has quit [Quit: johnwhitton]
12:06 < jonasschnelli> gmaxwell: Yes. Important improvments could be applied on both wallets.
12:06 < btcdrak> jonasschnelli: sounds great
12:06 < gmaxwell> I think it's much better than a boil the ocean rewrite.
12:06 < jonasschnelli> The second wallet should not have a stable API for now.
12:07 < jonasschnelli> And we could merge more aggressively there.
12:07 < sipa> well if you intentionally break things in it, it may not get sufficient testing
12:07 < jonasschnelli> I would also be happy to be the maintainer of that second / currently experimental wallet.
12:07 < sipa> but concept ack
12:07 < wumpus> or maybe it will get sufficient testing
12:07 < wumpus> some people are waiting for things to be broken, especially the account system
12:08 < wumpus> but any update to the current wallet goes so slow, partially because every time backwards compatiblity has to be considered
12:08 < 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.
12:08 < wumpus> so it's kind of circular
12:08 < 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.
12:08 < jonasschnelli> Yes. We could mark it as experimental, don't use it with large amounts.
12:09 < wumpus> also updates to the current wallet don't get sufficient testing/review either, there's just no energy behind it
12:09 < 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.
12:09 < sipa> was just about the bring that up
12:09 < wumpus> morcos: well I expect them to diverge soon enough that that won't say a problem for long
12:09 < 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
12:09 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
12:09 < phantomcircuit> gmaxwell: i can help you with relaying harder
12:09 < jonasschnelli> morcos: I think as we proceed, most features will only make sense on one or the other side.
12:09 < sipa> we can't put the burden on external contributors to duplicate
12:10 < wumpus> features will mostly end up in the new wallet
12:10 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
12:10 < wumpus> the old wallet should still receive bugfixes etc
12:10 < wumpus> it's a bit like stable versions/master
12:10 < morcos> hmm..  lots of things would apply to both,  conflicts, abandoned transactions, fee estimates
12:10 < jonasschnelli> wumpus: +1
12:10 -!- fkhan_ [weechat@gateway/vpn/mullvad/x-tybwsejfjbsbwaca] has quit [Ping timeout: 252 seconds]
12:10 < wumpus> in any case I'd say this is up to the people doing the work
12:10 < morcos> wumpus: oh ok.  that makes sense, but when would the target be for the new wallet to be production ready
12:10 < morcos> 0.14
12:10 < morcos> ?
12:11 < wumpus> morcos: when it's ready
12:11 < jonasschnelli> morcos: sure. But the second wallet should once be independent from the core. So we should work towards a clear interface.
12:11 < 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
12:11 < 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.
12:11 < morcos> we need something that is good to use
12:11 < jonasschnelli> New wallet without account and without BDB could be in 0.13, stable API in 0.15, ... non-beta in 0.16
12:11 < morcos> right, i'm not opposed to doing this, i think we need to do something
12:11 < wumpus> morcos: it's a risk, but you can't stop people from working on a new wallet if that's what they prefer
12:12 < sipa> yes, i think we should aim to have the new wallet production ready soon, but just no stable onterface
12:12 < wumpus> (or maybe jonasschnelli and me should start a fork of bitcoin core *ducks*)
12:12 < sipa> *interface
12:12 < jonasschnelli> wumpus: I did that already... but the amount of reviewers was... lets say ... extremely tiny.  
12:12 < jonasschnelli> We can't say SPV is doomed and not improvig the wallet at the same time.
12:12 < sipa> also, a lot of the unit tests for non-wallet features rely on having a wallet
12:13 < wumpus> yes, the unit tests should be less dependent on the wallet
12:13 < wumpus> but that's a different issue
12:13 < jonasschnelli> Yes. Hard to send around coins then. But agree.
12:13 < sipa> iwe can replicate a wallet in the python framework *ducjs*
12:13 < wumpus> (well, the non-wallet unit tests). In any case the unit tests can use the old wallet for now.
12:13 < petertodd> sipa: please do; python-bitcoinlib needs a wallet :)
12:13 < wumpus> sipa: yes :)
12:14 < wumpus> a python wallet please
12:14 < wumpus> :D
12:14 < sipa> the why do we need a wallet in core? ;)
12:14 < btcdrak> !
12:14 < paveljanik> for testing...
12:14 < wumpus> well one idea was to begin a new wallet outside of core
12:14 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 260 seconds]
12:14 < jonasschnelli> I agree long term we could remove the wallet... but in tiny steps.
12:14  * gmaxwell bangs gavel
12:14 < sipa> ok
12:14 < sipa> who is gavel?
12:14 < jonasschnelli> Outside of core does not work for now.
12:15 < sipa> indeed
12:15 < 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
12:15 < wumpus> if you want to create a wallet outside of core no one needs any permission at all from anyone here :p
12:15 < jonasschnelli> As soon as the wallet can run SPV, we can think about moving it.
12:15 < btcdrak> sipa: do I need to call an ambulance?
12:15 < paveljanik> can't just work on the interaface/API for wallet and the new wallet to be outside of Core?
12:15 < sipa> jonasschnelli: i think it will still share a large part of the codebase, even if it's not runnijg in the same process
12:16 < wumpus> sure, feel free to do what you want to do outside of core paveljanik
12:16 < petertodd> jonasschnelli: why worry about SPV? write one that scans full blocks, grabbing them from a local bitcoind
12:16 < jonasschnelli> sipa: Yes. Once it can run SPV, it shares some base code, also the net stuff.
12:16 < sipa> jonasschnelli: please, modularization first, separate process next, and then we can start talking about other repository
12:16 < paveljanik> wumpus, that nees Core to provide API/something Jonas is already working on...
12:16 < wumpus> it makes sense, e.g. joinmarket has a wallet outside of core, although it's somewhat suboptimal
12:16 < sipa> petertodd: that's the idea
12:16 < sipa> petertodd: spv does not imply bip37
12:17 < wumpus> (still relies on the wallet inside core but using watch-only)
12:17 < jonasschnelli> I think it's to early to remove the wallet from core. We can think about it in 2-3 years.
12:17 < wumpus> jonasschnelli: yes
12:17 < wumpus> no one is actually proposing doing that now, but it's always how this discussion goes
12:17 < wumpus> and has gone for years
12:18 < 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)
12:18 < morcos> in an issue or something
12:18 < 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.
12:18 < wumpus> any progress you make is helpful jonasschnelli
12:18 < btcdrak> next topic?
12:18 < sipa> agree
12:18 < jonasschnelli> morcos: I'll write a proposal.
12:18 < jonasschnelli> agree next t.
12:18 < sipa> (my battery is at 11%)
12:18 < 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
12:19 < wumpus> #topic CoreDev Hacking convention in Zurich (short announcement)
12:19 < morcos> the plan doesn't have to be perfect, but it helps if its clear
12:19 < wumpus> morcos: it's a risk, but it's how it goes in open source
12:19 < jonasschnelli> I think we could all meet together and hack at some important stuff.
12:19 < jonasschnelli> http://coredev.tech
12:19 < gmaxwell> jonasschnelli: please just propose things for the short/mid term for now.
12:19 < 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
12:19 < jonasschnelli> Best would be to get SW nailed at the meeting in ZH.
12:20 < wumpus> awesome jonasschnelli
12:20 < jonasschnelli> I'm also convinced if we do that, we find sponsors pretty easy.
12:20 < jonasschnelli> Room, food, etc. is organized.
12:20 < jonasschnelli> If someone needs travel subsidy, please tell me.
12:20 < morcos> i like the idea, but unfortunately can't attend that weekend 
12:21 < jonasschnelli> Important: Because of the short timelime, please tell me if you are interested to attend during the next 7 days.
12:21 < sipa> is the date fixed?
12:21 < wumpus> sure I will
12:21 < jtimon> I probably will as well
12:21 < jonasschnelli> Date is semi-fixed. :)
12:21 < petertodd> jonasschnelli: I can attend
12:21 < sipa> i can attend
12:22 < sipa> (13 minute tram ride)
12:22 < sdaftuar> jonasschnelli: i'm interested, though not sure yet if i can make it
12:22 < jonasschnelli> Hah.
12:22 < wumpus> i can attend too, nothing else on that date at laest
12:22 < jonasschnelli> Its soon. Please try to give me a yes/no during the next 7 days.
12:22 < jonasschnelli> Okay. I'll flag wumpus, petertodd and sipa as "confirmed".
12:22 < jonasschnelli> and jtimon (he lives in spain and needs to come!)
12:22 -!- fkhan_ [weechat@gateway/vpn/mullvad/x-tanwjzqkslkprnbi] has joined #bitcoin-core-dev
12:23 < gmaxwell> If you want people to come, more advanced planning would help, in the future! :) 
12:23 < jtimon> jonasschnelli: yeah, unless something unexpected prevents me from going, sounds great to me
12:23 < jonasschnelli> gmaxwell: Agree. I just can't in June/Juli/Aug!
12:23 < jonasschnelli> If it wont work, I'll organize another one in fall.
12:24 < 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 :)
12:24 < btcdrak> jonasschnelli: seems like you have a lot of takers already
12:24 < sipa> petertodd: agree
12:24 < jonasschnelli> And Zurich is great! :-)
12:24 < jtimon> never been there, happy to visit it
12:24 < petertodd> I was in Zug for a week, and it was so beautiful that a cup of coffee cost $10
12:24 < jonasschnelli> </topic>
12:25 < wumpus> hehe
12:25 < sipa> next topic?
12:25 < wumpus> #topic Dealing with RBF RPC/UI
12:25 < jtimon> maybe I've been in the airport...sorry, yeah, next topic
12:25 < 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
12:25 < michagogo> Sorry I'm late, but: Bitcoin Core is still in beta, no?
12:26 < sipa> haha
12:26 < petertodd> speaking of, opt-in RBF is getting used by someone at least: http://p2sh.info/dashboard/db/replace-by-fee
12:26 < jonasschnelli> RBF: I dont have a clear vision how the RPC should deal with RBF
12:26 < gmaxwell> michagogo: the "beta" was dropped from the description years ago.
12:26 < michagogo> Huh, that timestamp broke weirdly
12:26 < michagogo> gmaxwell: really? I must have missed that
12:26 < gmaxwell> michagogo: and some stupid lable wouldn't excuse shoddy support. 
12:27 < michagogo> gmaxwell: obviously, I was just commenting on the "non-beta" milestone
12:27 < 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?
12:27 < jonasschnelli> Ensure that the RBF rules are respected (>fee, pay for the bandwith, etc.)
12:27 < 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
12:28 < MarcoFalke_> Shouldn't we only support fee bump as a fist step?
12:28 < petertodd> MarcoFalke_: ack
12:28 < paveljanik> MarcoFalke: +1
12:28 < sipa> ack
12:28 < jonasschnelli> *exhales*
12:28 < gmaxwell> In many ways, adding outputs is more useful... but "fee bump only" was also my initial impression at jonasschnelli's efforts.
12:28 < phantomcircuit> petertodd: the wallet does track which outputs are change, so nominally it's also trakcing which outputs where intended as payments
12:29 < jtimon> one step at a time sounds good to me
12:29 < jonasschnelli> I think we should have a fee-bump RBF in 0.13 (RBF was in 0.11.x and 0.12).
12:29 < petertodd> MarcoFalke_: and with fee bump, first implementation should probably *not* add inputs, which complicates things
12:29 < jonasschnelli> | How would a feebump over RPC looks like?
12:29 < petertodd> jonasschnelli: hmm? I released RBF for v0.11, but Core didn't
12:29 < jonasschnelli> sry, mixed up with CLTV... right. 0.12
12:30 < 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>
12:31 < 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.
12:31 < gmaxwell> or something like that.
12:31 < jonasschnelli> petertodd: bumpfee ... yes. maybe we find a call-name that is more flexible for the future?
12:31 < 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)
12:31 < sipa> related: cpfp?
12:32 < gmaxwell> RE: feebump, I think a different approach should be used.
12:32 < phantomcircuit> petertodd: there's significant privacy implications to combining payments
12:32 < petertodd> jonasschnelli: AbstractRespendWithSomeThingChangedFactoryBean?
12:32 < jonasschnelli> ^^
12:32 < petertodd> phantomcircuit: sure, which is why getting estimates right in the first place helps a lot
12:32 < sipa> jonasschnelli: it shall be called BeeFump
12:32 < petertodd> phantomcircuit: but if fee bumping is a once-in-a-while thing, I'm not that concerned re: privacy
12:32 < jonasschnelli> altertransaction was something we once have talked about
12:32 < Lightsword> petertodd, your factory needs a factory :P
12:32 < petertodd> sipa: +1
12:33 < 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. 
12:33 < sipa> gmaxwell: elaborate?
12:33 < sipa> ah
12:33 < petertodd> Lightsword: I'm not going to grey-goo the world just to bump fees... :)
12:33 < wumpus> sure, that'd be even better, but even a simple 'bump fee' command would be better than nothing
12:33 < petertodd> gmaxwell: yeah, ack on that being better, although the code to do feebumping will get reused by the nlocktime version
12:34 < 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.
12:34 < jonasschnelli> Okay. Will work on "bumpfee".
12:34 < jonasschnelli> How do we estimate fees for replacements?
12:34 < petertodd> gmaxwell: my python script does it based on a ratio
12:34 < kanzure> #action bumpfee work
12:34 < petertodd> jonasschnelli: double every time by default? it's a good start
12:34 < 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%.
12:35 < petertodd> jonasschnelli: having to bump a fee implies that your fee estimation isn't working anyway :)
12:35 < jonasschnelli> petertodd: indeed!
12:35 < wumpus> exponential fee backoff
12:35 < gmaxwell> petertodd: well it could be working now, just not precognative. :)
12:35 < 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
12:35 < 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.
12:36 < 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?
12:36 < wumpus> phantomcircuit: agreed
12:36 < gmaxwell> phantomcircuit: jonasschnelli had a checkbox in the UI for the things he was doing so far.
12:36 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
12:36 < 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
12:36 < jonasschnelli> Yes. We don't opt-in automatically for now I guess.
12:37 < 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. :)
12:37 < wumpus> phantomcircuit: automatic behavior in the wallet can be somewhat scary, at least now you have to click confirm to pay a certain fee
12:37 < wumpus> phantomcircuit: (although you could have the same, just agree on a certain *max* fee)
12:37 < gmaxwell> wumpus: what I suggested on the PR for that was just to list the possible fees (by the checkbox)
12:37 < jonasschnelli> wumpus: Agree. No automatic behavior that spends inputs automatically.
12:37 < btcdrak> I would just have "increase fee" and give an amount.
12:38 < gmaxwell> Fee of x/y/z/q after 0/2/3/4 blocks.
12:38 < 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?
12:38 < jonasschnelli> I though we could re-use the fee slider (but with ~x2 values).
12:38 < petertodd> morcos: fee bumping itself I think we should add to the existing wallet; more complex strategies may be infeasible with the current wallet
12:39 < wumpus> morcos: depends on the order in which things actually get implemented, I'd say
12:39 < wumpus> yes agree with petertodd there
12:39 < 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.
12:39 < jonasschnelli> morcos: the old wallet could just have a fee bump, ..the new wallet a feature to add outputs.
12:39 < 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.
12:39 < 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)?
12:40 < sipa> jtimon: imho, no
12:40 < sipa> or not initially
12:40 < wumpus> the idea is tthat the new wallet can have a completely new interface
12:40 < wumpus> throwing out all the old cruft
12:40 < jonasschnelli> jtimon: if we want to depracate the old wallet and remove it once, it should probably be independent.
12:40 < wumpus> of course if there are things that make sense they can be kept
12:40 < 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.
12:41 < jonasschnelli> Also while writing on the new wallet, we can care more about core interaction. No mempool access everywhere.
12:41 < sipa> jonasschnelli: that may be... hard
12:41 < wumpus> jonasschnelli: at least make it event driven
12:41 < jtimon> mhmm, I'm just worried about calling code for both wallets from the same place
12:41 < wumpus> jonasschnelli: no assumption on *immediate* mempool access
12:41 < gmaxwell> jonasschnelli: many good features benefit from mempool access.
12:42 < sipa> jtimon: is that a problem?
12:42 < 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
12:42 < jtimon> with my suggestion the new wallet could have a different interface in practice (as said the old wallet can just throw errors)
12:42 < wumpus> and it also holds up the GUI thread for things that shouldn't
12:42 < sipa> hey, main.cpp used to call the gui directly
12:42 < jonasschnelli> :-)
12:42 < wumpus> it's fine to have a query mempool, but it should be regarded as asynchronous
12:42 < wumpus> heh true sipa, we made a step forward with  bitcoin-qt :-)
12:43 < sipa> other topic?
12:43 < petertodd> wumpus: once you're talking about async access, probably easier just to keep a copy of the mempool on your local app
12:43 < sipa> as we seem to have backtracked to a previous o e
12:43 < wumpus> better to have something then make a wild plan which grows so huge it can never be executed
12:44 < 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
12:44 < wumpus> petertodd: I don't know, depends on the application
12:44 < sipa> jtimon: oh hell no, that isn't allowed
12:44 < sipa> jtimon: everything through validationinterface
12:44 < petertodd> wumpus: well, unless you're memory constrained, keeping a copy locally and keeping that in sync can't be that hard
12:44 < jtimon> sipa: oh, that was my question then, thanks
12:45 < wumpus> jtimon: yes, wallets (as well as other modules) register their own RPC calls, there's no need for if(fSomething) logic
12:46 < wumpus> any other topics?
12:46 < jtimon> great, that was my only concern about jonasschnelli's plan, I knew I was probably misunderstanding something
12:46 < jonasschnelli> I'll write a clean concept.
12:47 < sipa> oh, small question: are we ok with backporting master's script/tx unit tests to 0.12?
12:47 < petertodd> sipa: ack
12:47 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
12:47 < paveljanik> why not?
12:47 < wumpus> well if the tests are better it always makes sense to backport them
12:48 < sipa> testd are not typically something we backport
12:48 < wumpus> I'm fine with copying all the tests from master to 0.12 given that the funcitnality is supported
12:48 < sipa> but i think it makes total sense as we want softforks backported too
12:48 < sdaftuar> wumpus: i wanted to flag #7835 which i just opened for 0.12.1
12:48 < petertodd> sipa: agreed
12:48 < wumpus> sdaftuar: too late, 0.12.1 was just tagged
12:48 < sipa> sdaftuar: just rc1?
12:48 < sipa> wumpus: ^
12:49 < wumpus> yes
12:49 < sipa> or no rc cycle?
12:49 < btcdrak> Freudian slip 
12:49 < 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
12:49 < MarcoFalke_> lets hope rc1 one is the final release ;)
12:49 < wumpus> [21:01:15] <wumpus> PSA: 0.12.1rc1 has been tagged, please start your gitian builders
12:49 < morcos> right, so its not too late for 0.12.1 right?
12:50 < btcdrak> 20:01:47 <wumpus> PSA: 0.12.1rc1 has been tagged, please start your gitian builders
12:50 < wumpus> well there will only be a rc2 if necessary, does this need to block the release?
12:50 < 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
12:50 < sipa> wumpus: we should consider it i thonk
12:51 < sdaftuar> without the change, which is simple
12:51 < wumpus> ok...
12:51 < sipa> sowwy
12:51 < wumpus> rc1 is dead folks
12:51 < wumpus> don't bother building it
12:51  * btcdrak stops his gitian builder
12:51 < wumpus> long live rc2
12:51 < btcdrak> I thought we had discussed this exact thing before regarding V2
12:52 < morcos> wumpus you know i save these things until after your release candidates just for the entertainment value right?
12:52 < wumpus> morcos: I know, no offense taken :) better now than later, almost no one wasted cycles on rc1 yet
12:52 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
12:52 < 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
12:53 < btcdrak> sdaftuar: that's quite an elegant solution.
12:53 < sdaftuar> btcdrak: that's because i stole it from sipa's segwit
12:53 < wumpus> #action review and ACK https://github.com/bitcoin/bitcoin/pull/7835/files asap
12:53 < btcdrak> long live sipa
12:53 < morcos> we should add this to our list of standard ways to implement things whenever we relax standardness rules
12:54 < btcdrak> morcos: agreed
12:55 < sipa> 2% battery left for me; anything else?
12:55 < morcos> travel charger?
12:55 < jonasschnelli> lol
12:55 < wumpus> I don't think so
12:55 < wumpus> #endmeeting
12:55 < lightningbot> Meeting ended Thu Apr  7 19:55:45 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:55 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-07-19.00.html
12:55 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-07-19.00.txt
12:55 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-07-19.00.log.html
12:56 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has quit [Ping timeout: 244 seconds]
12:56 < achow101> wait, is rc1 actually dead?
12:56 < wumpus> yes, dead as a doornail
12:57 -!- MarcoFalke_ [579f3eec@gateway/web/cgi-irc/kiwiirc.com/ip.87.159.62.236] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
12:57 < btcdrak> "it's dead Jim"
12:57 < wumpus> we'll probably tag rc2 tomorrow
12:58 < achow101> ok
12:58 < wumpus> doesn't make sense to do a gitian process in the mean time
13:02 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
13:12 -!- zooko [~user@172.56.8.198] has joined #bitcoin-core-dev
13:18 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
13:22 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
13:25 -!- d_t [~textual@185.69.203.10] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
13:34 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
13:35 -!- spikeheadon [~spikes@122.168.199.215] has joined #bitcoin-core-dev
13:38 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 240 seconds]
13:39 -!- wallet42 [uid154231@gateway/web/irccloud.com/x-ixfnmzkvkyocudyr] has quit [Quit: Connection closed for inactivity]
13:42 -!- xabbix [~xabbix@unaffiliated/xabbix] has quit [Ping timeout: 244 seconds]
13:43 -!- xabbix [~xabbix@bzq-79-178-52-49.red.bezeqint.net] has joined #bitcoin-core-dev
13:43 -!- xabbix [~xabbix@bzq-79-178-52-49.red.bezeqint.net] has quit [Changing host]
13:43 -!- xabbix [~xabbix@unaffiliated/xabbix] has joined #bitcoin-core-dev
13:46 -!- lamagra [~lamagra@159.14.216.139.sta.dodo.net.au] has quit [Remote host closed the connection]
13:49 -!- zooko [~user@172.56.8.198] has quit [Read error: Connection reset by peer]
13:50 -!- zooko [~user@172.56.8.198] has joined #bitcoin-core-dev
13:51 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
14:04 -!- zooko [~user@172.56.8.198] has quit [Ping timeout: 276 seconds]
14:15 -!- cryptapus_afk is now known as cryptapus
14:16 -!- murch [~murch@p4FE394B9.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
14:21 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
14:23 -!- kangx [2f2168ed@gateway/web/freenode/ip.47.33.104.237] has joined #bitcoin-core-dev
14:29 -!- wallet42 [uid154231@gateway/web/irccloud.com/x-emnrhtrldkdehoyi] has joined #bitcoin-core-dev
14:51 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has quit [Quit: johnwhitton]
14:57 -!- zooko [~user@2601:281:8001:26aa:70cd:e0c2:6c28:236c] has joined #bitcoin-core-dev
14:59 -!- belcher [~user@unaffiliated/belcher] has quit [Read error: Connection reset by peer]
15:00 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
15:02 -!- belcher [~user@unaffiliated/belcher] has quit [Read error: Connection reset by peer]
15:04 -!- zooko [~user@2601:281:8001:26aa:70cd:e0c2:6c28:236c] has quit [Ping timeout: 268 seconds]
15:25 -!- cryptapus is now known as cryptapus_afk
15:36 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
15:39 -!- johnwhitton [~johnwhitt@142-254-34-220.dsl.dynamic.sonic.net] has joined #bitcoin-core-dev
15:42 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
15:55 -!- johnwhitton [~johnwhitt@142-254-34-220.dsl.dynamic.sonic.net] has quit [Quit: johnwhitton]
15:56 -!- zooko [~user@c-73-229-199-227.hsd1.co.comcast.net] has joined #bitcoin-core-dev
15:56 -!- johnwhitton [~johnwhitt@142-254-34-220.dsl.dynamic.sonic.net] has joined #bitcoin-core-dev
16:03 -!- johnwhitton [~johnwhitt@142-254-34-220.dsl.dynamic.sonic.net] has quit [Quit: johnwhitton]
16:07 -!- murch [~murch@p4FE394B9.dip0.t-ipconnect.de] has quit [Quit: Leaving.]
16:26 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
16:26 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Ping timeout: 248 seconds]
16:26 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
16:26 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
16:59 -!- wallet42 [uid154231@gateway/web/irccloud.com/x-emnrhtrldkdehoyi] has quit [Quit: Connection closed for inactivity]
17:09 -!- Amnez777 [~Amnez777@unaffiliated/amnez777] has quit [Ping timeout: 264 seconds]
17:12 -!- Amnez777 [~Amnez777@37.157.216.147] has joined #bitcoin-core-dev
17:26 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
17:30 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
17:31 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
17:37 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
17:39 -!- jtimon [~quassel@227.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 248 seconds]
17:43 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection]
17:45 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
17:48 -!- OGF-US [~StringerB@c-73-210-225-26.hsd1.il.comcast.net] has left #bitcoin-core-dev []
17:51 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-fxnjudigjaumpucn] has quit [Quit: Connection closed for inactivity]
17:55 -!- gevs [~greg@unaffiliated/gevs] has quit [Remote host closed the connection]
18:22 -!- spikeheadon [~spikes@122.168.199.215] has quit [Ping timeout: 244 seconds]
18:30 -!- dermoth [~thomas@dsl-216-221-56-157.mtl.aei.ca] has quit [Read error: Connection reset by peer]
18:30 -!- dermoth [~thomas@dsl-216-221-56-157.mtl.aei.ca] has joined #bitcoin-core-dev
18:41 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
19:00 -!- dermoth [~thomas@dsl-216-221-56-157.mtl.aei.ca] has quit [Read error: Connection reset by peer]
19:01 -!- dermoth [~thomas@dsl-216-221-56-157.mtl.aei.ca] has joined #bitcoin-core-dev
19:15 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Ping timeout: 250 seconds]
19:16 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev
19:19 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
19:20 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
19:34 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 244 seconds]
19:36 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
19:44 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev
19:47 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 240 seconds]
19:50 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
19:53 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev
19:54 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
19:54 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
20:01 -!- zooko [~user@c-73-229-199-227.hsd1.co.comcast.net] has quit [Remote host closed the connection]
20:05 -!- PaulCape_ [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
20:07 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 260 seconds]
20:31 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Remote host closed the connection]
20:35 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.]
21:03 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
21:04 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
21:35 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
21:36 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
22:04 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Remote host closed the connection]
22:14 -!- fkhan_ [weechat@gateway/vpn/mullvad/x-tanwjzqkslkprnbi] has quit [Ping timeout: 264 seconds]
22:30 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
22:30 -!- fkhan_ [weechat@gateway/vpn/mullvad/x-lyaogylpotuucrgl] has joined #bitcoin-core-dev
22:40 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
22:41 < gmaxwell>     "minping": 9223372036854.775,
22:41 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
22:44 < gmaxwell> interestingly one is on an outbound tor peer, another is on an inbound local peer.
22:44 < gmaxwell> oh.. right this host is running core in valgrind.
22:47 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
22:49 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
22:50 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection]
22:51 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
22:56 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
22:57 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
23:00 -!- dermoth [~thomas@dsl-216-221-56-157.mtl.aei.ca] has quit [Read error: Connection reset by peer]
23:00 -!- dermoth [~thomas@dsl-216-221-56-157.mtl.aei.ca] has joined #bitcoin-core-dev
23:04 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
23:04 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
23:07 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ndvovvicnwwbekvn] has joined #bitcoin-core-dev
23:18 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
23:19 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
23:30 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has quit [Quit: johnwhitton]
23:35 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
23:38 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has quit [Client Quit]
23:38 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
23:38 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has quit [Client Quit]
23:41 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
23:43 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has quit [Client Quit]
23:44 -!- [Author] [~Author]@2401:a400:3202:2000:bad:d09:15:90d] has quit [Ping timeout: 240 seconds]
23:44 < wumpus> gmaxwell: there used to be a problem where minping was not initialized
23:45 < michagogo> I kicked off my gitian build script last night before going to bed. Linux and Windows completed without any problems, but the OS X build failed
23:45 < michagogo> It went as far as building protobuf, but then failed when extracting boost
23:45 < wumpus> I managed to build all three - what's the issue?
23:46 < michagogo> Tons of error messages from tar, cannot mkdir/open: read-only file system o_O
23:46 < wumpus> gmaxwell: or is that std::numeric_limits<int64_t>::max()?
23:47 < wumpus> yes it is. Okay that means that there hasn't been a ping ever
23:51 -!- spikeheadon [~spikes@122.168.199.215] has joined #bitcoin-core-dev
23:51 -!- abritoid [~abritoid@46.16.193.99] has joined #bitcoin-core-dev
23:53 -!- [Author] [~Author]@2401:a400:3202:2000:bad:d09:15:90d] has joined #bitcoin-core-dev
23:56 < wumpus> unfortunately JSON in their infinite wisdom didn't take into account special floating point values like inf, NaN, -inf, so we cannot use those to indicate 'no ping ever'
23:57 < gmaxwell> should we leave the field out in that case? we do that elsewhere for not-applicable; (I somewhat dislike this as it'll end up with a rare corner case that applications will not handle)
23:57 < wumpus> and using a string or 'null' where people expect a value may be a bit mean (though a good way to check input validation)
23:57 < wumpus> in any case whatever the behavior it needs to be documented in 'help' of the RPC call