--- Day changed Tue Nov 24 2015 00:12 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 00:13 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.] 00:24 < GitHub187> [bitcoin] MarcoFalke opened pull request #7088: [trivial] pull secp256k1subtree (master...MarcoFalke-2015-syncSecp256k1) https://github.com/bitcoin/bitcoin/pull/7088 00:30 < GitHub13> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f91e29fd4d0e...ed34e0577e8d 00:30 < GitHub13> bitcoin/master a0953cd MarcoFalke: [qa] python-bitcoinrpc is no longer a subtree... 00:30 < GitHub13> bitcoin/master ed34e05 Wladimir J. van der Laan: Merge pull request #7052... 00:30 < GitHub133> [bitcoin] laanwj closed pull request #7052: [qa] python-bitcoinrpc is no longer a subtree (master...MarcoFalke-2015-qaSubtree) https://github.com/bitcoin/bitcoin/pull/7052 00:31 < gmaxwell> Anyone know why zapwallettxes might use a lot more memory than a rescan? 00:32 < gmaxwell> my huge wallet test host (500k txn wallet) OOM killed on a zap, with about 24GB used--- where normally it uses about 15GB. 00:33 < GitHub69> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/ed34e0577e8d...b1fcdec68790 00:33 < GitHub69> bitcoin/master 2fcb849 fanquake: [doc][trivial] Remove source forge from Debian watch. 00:33 < GitHub69> bitcoin/master 70899d7 fanquake: [doc][trivial] Update Debian control description... 00:33 < GitHub69> bitcoin/master b1fcdec Wladimir J. van der Laan: Merge pull request #7042... 00:33 < GitHub56> [bitcoin] laanwj closed pull request #7042: [doc] Update Debian watch & control (master...update-debian) https://github.com/bitcoin/bitcoin/pull/7042 00:38 -!- JackH [~Jack@host-80-43-142-236.as13285.net] has joined #bitcoin-core-dev 00:50 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] 00:51 < GitHub105> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b1fcdec68790...72dccfc29dfc 00:51 < GitHub105> bitcoin/master 2aa49ce Luke Dashjr: Bugfix: Use unique autostart filenames on Linux for testnet/regtest 00:51 < GitHub105> bitcoin/master 72dccfc Wladimir J. van der Laan: Merge pull request #7045... 00:51 < GitHub148> [bitcoin] laanwj closed pull request #7045: Bugfix: Use unique autostart filenames on Linux for testnet/regtest (master...linux_autostart_unique) https://github.com/bitcoin/bitcoin/pull/7045 00:53 -!- tulip [~tulip@unaffiliated/tulip] has quit [] 01:02 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Remote host closed the connection] 01:02 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #bitcoin-core-dev 01:03 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Remote host closed the connection] 01:03 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #bitcoin-core-dev 01:04 -!- MarcoFalke [3e4bef15@gateway/web/cgi-irc/kiwiirc.com/ip.62.75.239.21] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 01:34 < GitHub146> [bitcoin] laanwj closed pull request #7066: [Trivial,Doc] Add missing "blocktime" description to listtransactions help, fix formatting. (master...listtransactions_blocktime) https://github.com/bitcoin/bitcoin/pull/7066 01:47 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.] 01:53 < GitHub1> [bitcoin] laanwj closed pull request #6306: Prevent peer flooding inv request queue (redux) (master...no_duplicate_askfor) https://github.com/bitcoin/bitcoin/pull/6306 01:54 < GitHub98> [bitcoin] laanwj reopened pull request #7066: [Trivial,Doc] Add missing "blocktime" description to listtransactions help, fix formatting. (master...listtransactions_blocktime) https://github.com/bitcoin/bitcoin/pull/7066 01:55 < GitHub67> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/72dccfc29dfc...02a0f348c210 01:55 < GitHub67> bitcoin/master 5c2fd38 Pavel Janík: Add missing "blocktime" description to listtransactions help, fix formatting. 01:55 < GitHub67> bitcoin/master 02a0f34 Wladimir J. van der Laan: Merge pull request #7066... 01:56 < GitHub135> [bitcoin] laanwj closed pull request #7066: [Trivial,Doc] Add missing "blocktime" description to listtransactions help, fix formatting. (master...listtransactions_blocktime) https://github.com/bitcoin/bitcoin/pull/7066 02:09 < phantomcircuit> it's kind of comical how much more productive i am without video games 02:10 < phantomcircuit> gmaxwell, iirc zapwallettxs keeps two walletdb objects open, so will presumably use a minimum of double the memory 02:11 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev 02:24 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev 02:28 < sipa> phantomcircuit: you should sold *all* your gpus after the gpu mining era was over 02:29 < phantomcircuit> sipa, heh 02:45 < wumpus> heh I stopped playing video games at the same time I stopped striving to be a game developer. Just lost interest with modern games and the PC upgrade treadmill 02:49 -!- MarcoFalke [8af602b2@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.178] has joined #bitcoin-core-dev 02:51 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 02:52 < phantomcircuit> wumpus, it helps when you're using old 7970s from a mining farm 02:53 < phantomcircuit> wumpus, need anything else on 7087 ? 02:55 < wumpus> no, looks good to me now 03:03 < midnightmagic> wumpus: independent game devs can make it these days. A friend of mine is in the middle of doing it, he lives in norway right now. 03:05 < wumpus> midnightmagic: yes that still sounds kind of fun 03:07 < midnightmagic> definitely an appetite for cleverness that's within the grasp of small teams, it seems. and ios can be done by one or two people. retro gaming scene is hot. 03:07 < MarcoFalke> wumups, not sure we should silently "ignore" negative values from GetArg()? 03:07 -!- jl2012 [~jl2012@unaffiliated/jl2012] has joined #bitcoin-core-dev 03:07 -!- jl2012_ [~jl2012@pn-204-72.itsc.cuhk.edu.hk] has quit [Ping timeout: 255 seconds] 03:08 < MarcoFalke> is done very rarely, though. 03:08 < MarcoFalke> *Sanitization is done very rarely, though. 03:09 < MarcoFalke> * wumpus, 03:12 < MarcoFalke> We need to collect all accepted config args and their valid range. Also warn about unknown config args. 03:22 < wumpus> MarcoFalke: definitely not ignore 03:23 < wumpus> yea, we're ignoring a lot of command-line issues, I have a very old issue about this https://github.com/bitcoin/bitcoin/issues/1044 03:27 < phantomcircuit> gmaxwell, did you see my PR for 7082 ? 03:29 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Ping timeout: 250 seconds] 03:30 < MarcoFalke> Changed it to uint_ and dropped the < 0 check like you suggested. 03:30 < MarcoFalke> Now, we get funny errors like Error: -maxmempool must be at least 1.84467e+16 MB, at least. 03:30 < wumpus> so a negative value is an explicit error now? 03:30 < wumpus> eh, that's definitely not an improvemnt 03:31 < wumpus> just leave it as is then 03:31 < MarcoFalke> I like it uint ;) 03:31 < wumpus> sure, uint makes sense, but that's only acceptable if you avoid the user from passing negative values and causing overflows 03:32 < wumpus> (which the old code did, so probably my suggestion was just wrong) 03:33 < MarcoFalke> Usually -1 means "just make it large enogh that I don't have to care about it" 03:33 < wumpus> it just looked weird to compare to both 0 and that limit value, a typical developer trap 'hey, this could be simpler...' 03:34 < wumpus> which is fine if you handle it explicitly, don't rely on integer overflow 03:35 < gmaxwell> phantomcircuit: thanks, I wouldn't have. 03:39 < gmaxwell> phantomcircuit: you dropped the node network compare, otherwise your PR is just a reordering, and a fine one, go fix that. 03:42 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev 03:45 < phantomcircuit> gmaxwell, ha derp so i did 03:49 < phantomcircuit> gmaxwell, ok there you go 03:52 -!- MarcoFalke [8af602b2@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.178] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 03:57 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.] 04:33 -!- MarcoFalke [8af602b2@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.178] has joined #bitcoin-core-dev 04:52 < MarcoFalke> Restored original behavior: "Error: -maxmempool must be at least -120 MB 04:52 < MarcoFalke> " 04:55 < wumpus> ok.. 04:57 -!- Guest1328 is now known as pigeons 04:58 < wumpus> we probably want to check -limitdescendantsize against 0 as well, or can it be usefully negative? 04:59 < sdaftuar> wumpus: limitdescendantsize cannot be usefully negative 05:00 < wumpus> in other places we assign the result to a size_t 05:01 < wumpus> type-safe argument parsing would be great to have at some point in the future, bit of a mish-mash now, but checking that it is >=0 at least prevents this from being an issue 05:04 < MarcoFalke> Is this framework sipa mentions ready for copy & paste? https://github.com/bitcoin/bitcoin/pull/4194#issuecomment-44521490 05:04 < wumpus> I doubt it 05:05 < sipa> i started writing that a long time ago, but never finished it 05:05 < wumpus> although the approach is a lot saner than what we have now 05:07 < wumpus> I think it's complicated by various options that, in turn, determine each other's ranges. But even basic type and sane-range checking with a consistent system would be a way forward. 05:08 < wumpus> and at least having base argument parsing in one place so that it can flag unknown arguments 05:10 -!- MarcoFalke [8af602b2@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.178] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 05:10 -!- MarcoFalke [8af602b2@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.178] has joined #bitcoin-core-dev 05:24 -!- MarcoFalke [8af602b2@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.178] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 05:25 -!- MarcoFalke [8af602b2@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.178] has joined #bitcoin-core-dev 05:37 -!- ParadoxSpiral [~ParadoxSp@p508B90DC.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 05:43 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Quit: Lost terminal] 05:44 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev 05:51 -!- MarcoFalke [8af602b2@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.178] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 06:36 < GitHub197> [bitcoin] petertodd opened pull request #7090: Connect to Tor hidden services by default (master...2015-11-onion-by-default) https://github.com/bitcoin/bitcoin/pull/7090 07:02 < GitHub18> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/02a0f348c210...b19fe277dd62 07:02 < GitHub18> bitcoin/master 4846543 tulip: Move time data log print to 'net' category to reduce log noise 07:02 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer] 07:02 < GitHub18> bitcoin/master b19fe27 Wladimir J. van der Laan: Merge pull request #7075... 07:02 < GitHub64> [bitcoin] laanwj closed pull request #7075: [Trivial] Move time data log print to 'net' category to reduce noise (master...no-time-offset-logging) https://github.com/bitcoin/bitcoin/pull/7075 07:02 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev 07:07 < GitHub149> [bitcoin] jtimon opened pull request #7091: Consensus build package (master...consensus-build) https://github.com/bitcoin/bitcoin/pull/7091 07:40 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Remote host closed the connection] 07:56 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev 08:08 -!- MarcoFalke [3e4bef15@gateway/web/cgi-irc/kiwiirc.com/ip.62.75.239.21] has joined #bitcoin-core-dev 08:29 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Ping timeout: 250 seconds] 08:46 < MarcoFalke> travis is only running 3 jobs in parallel instead of 5, what it used to be... 09:06 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Remote host closed the connection] 09:13 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 09:32 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 09:45 -!- ParadoxSpiral_ [~ParadoxSp@p508B8071.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 09:48 -!- ParadoxSpiral [~ParadoxSp@p508B90DC.dip0.t-ipconnect.de] has quit [Ping timeout: 244 seconds] 11:44 -!- MarcoFalke [3e4bef15@gateway/web/cgi-irc/kiwiirc.com/ip.62.75.239.21] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 11:46 < phantomcircuit> sipa, huh ActivateBestChain seems to be super slow when it's able to connect a large number of blocks all at once 11:51 < sipa> phantomcircuit: it is, it should cache things 12:08 < cfields_> jonasschnelli: ping. regarding osx perms, looks to me like perms are correct in gitian, but they're wrong in the created image 12:08 < cfields_> jtimon: will have a look 12:16 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev 12:32 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev 12:33 < jtimon> cfields_: awesome, for some reason I haven't found out yet travis doesn't like it, even if it built locally yesterday 12:59 < jonasschnelli> cfields_: so it could be a issue created by the dmg tool? 13:01 -!- cocoBTC [~cocoBTC__@c-233a71d5.136-1-64736c10.cust.bredbandsbolaget.se] has joined #bitcoin-core-dev 13:03 < cfields_> jtimon: you need $() 13:04 < cfields_> jonasschnelli: yea, looks that way to me. testing a fix now 13:05 < jonasschnelli> cfields_ : nice! Thanks for looking at it. It's an ugly OSX bug that we should solve in 0.12 and backport. 13:05 < cfields_> jonasschnelli: np. I'm still trying to figure out why it's not an issue for me 13:13 < cfields_> jonasschnelli: yea, that fixes 13:13 -!- raedah [~raedah@172.56.38.154] has joined #bitcoin-core-dev 13:14 < cfields_> fixes the perms, anyway. I can't reproduce, but i assume setting the dir to 0755 is enough 13:18 < GitHub91> [bitcoin] theuni opened pull request #7092: build: Set osx permissions in the dmg to make Gatekeeper happy (master...osx-perm-fix) https://github.com/bitcoin/bitcoin/pull/7092 13:27 < jonasschnelli> cfields_: super. Thanks. Testing tomorrow (in about 10h). 13:27 < cfields_> jonasschnelli: great, thanks 13:38 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 13:44 < phantomcircuit> would anybody be opposed to adding a last ditch peer discovery mechanism (even after trying the hard coded nodes) of "scan the internetz" 13:45 < sipa> phantomcircuit: as in: try random IPs? :o 13:46 < jtimon> cfields_: this should fix it? https://github.com/bitcoin/bitcoin/commit/164870c3f43f09330611fa939b7ae7fe468c1cf1 13:47 < jtimon> cfields_: in any case, I'm more interested in your opinion than making travis happy at this point 13:48 < cfields_> jtimon: from the looks, i believe that now involves building each object 3 times 13:48 < jtimon> how so? 13:48 < jtimon> one for libconsensus and one for the rest, no? 13:48 < jtimon> like before, no? 13:49 < cfields_> ah sorry, misread. yes. 13:49 * jtimon naively let himself think he was saving one build 13:50 < cfields_> jtimon: to save the build, you'd have to add the objects rather than the sources 13:50 < cfields_> don't think libtool will let you do that, though 13:51 < jtimon> never mind, I was expecting you to maybe complain about https://github.com/jtimon/bitcoin/commit/083e1344f7162d516ffcf2bb30622b28767e415e 13:51 < jtimon> or https://github.com/jtimon/bitcoin/commit/f37ff9b61375f8f667f17d529b6422e9c2c353c4 (it makes bitcoin-tx a little bit bigger) 13:52 < jtimon> not much bigger though 13:52 < cfields_> jtimon: yes, i'm not a fan of that. I see your reasoning, though. 13:52 < jtimon> but it signals the intend to put verifyBlock in the consensus package, which bitcoin-tx will still have to depend on 13:53 < jtimon> not a fan of which part? 13:53 < cfields_> breaking crypto out of its contained unit 13:54 < jtimon> I don't care much about the crypto part, it is currently well encapsulated and protected in the same way it would be in the consensus package, I guess we can leave that for the time when libconsensus gets its own repo (after exposing verifyblock) 13:56 < jtimon> any concerns about libconsensus depending on hmac_sha256 (without using it) by depending on the whole crypto package instead of all files but one? 13:57 < jtimon> that way we can say libconsensus contains the libsecp256k1, crypto and consensus packages 13:58 < jtimon> forget about that for now, I will update the branch without unifying crypto but in a way that I still like it and ask again 13:58 < jtimon> what about https://github.com/jtimon/bitcoin/commit/f37ff9b61375f8f667f17d529b6422e9c2c353c4 ? 13:58 < phantomcircuit> sipa, yeah and why not? 14:00 < sipa> phantomcircuit: nobody implemented it :) 14:00 < GitHub147> [bitcoin] gmaxwell opened pull request #7093: Address mempool information leak and resource wasting attacks. (master...mempool_infoleak) https://github.com/bitcoin/bitcoin/pull/7093 14:00 < sipa> phantomcircuit: it's very rarely an issue 14:05 -!- ParadoxSpiral_ [~ParadoxSp@p508B8071.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 14:05 < gmaxwell> I think I fixed the mempool dos attack/information leak problem. 14:06 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.] 14:06 < gmaxwell> phantomcircuit: doing that pisses off network operators and gets your software firewalled off. Also we have such a low nodecount that it's not a very effective mechenism. 14:07 < phantomcircuit> gmaxwell, yes i was thinking of it as something that wouldn't run for at least 30 minutes 14:07 < phantomcircuit> and would be pretty slow even then 14:08 < gmaxwell> phantomcircuit: slow = never find peers. :P 14:08 < phantomcircuit> gmaxwell, "slowish" 14:08 < gmaxwell> phantomcircuit: go look at my candidate mempool attack fix 14:08 < phantomcircuit> gmaxwell, in about an hour i have to go move my car now... 14:08 < phantomcircuit> who does street sweeping at 3pm? 14:16 * jgarzik reads 14:17 * sipa sleeps 14:19 < cfields_> jtimon: how about something more like this: http://pastebin.com/raw.php?i=JBqjPYAr ? 14:20 < cfields_> (it's a quick hack, the other targets need to be updated, i only changed bitcoind) 14:22 < gmaxwell> cfields_: if you get a chance, https://github.com/bitcoin/secp256k1/pull/356#issuecomment-156839307 14:22 < cfields_> that creates an internal helper lib that the other libs include. means everything's only built ones. and provides a clear distinction between what's consensus and what isn't 14:23 < jtimon> we still remove the files from util and common, I think I get your point, putting it all closer to the libconsensus stuff 14:23 < jtimon> should I put the .h directly in libbitcoinconsensusint_la_SOURCES? 14:24 < jtimon> btw, what does the int stand for? 14:24 < cfields_> jtimon: just an idea, i haven't really thought it through 14:24 < cfields_> internal. again, just a quick hack 14:24 < cfields_> gmaxwell: i'm having trouble parsing that too. You just want openssl optional, and only add the comparison tests if it's found/enabled ? 14:25 < jtimon> cfields_: I mean, the way I see it, this is mostly levearaing work that is already done, just make it harder or more obvious for contributors to break the existing encapsulation 14:27 < cfields_> jtimon: yea. that way, each lib-friendly module is built with its own flags. We can control include paths that way, making it not possible to accidentally add unsafe headers/objects 14:28 < jtimon> cfields_: one secondary goal is putting together whatever we plan to take out with libconsensus' subtree once it is complete 14:28 < jtimon> but that can wait 14:28 < gmaxwell> cfields_: Yes, it should be optional, and be switchable off. OpenSSL is actually a constant irritation for me when testing on random systems, because it throws a zillion and one valgrind errors (openssl is not valgrind clean unless compiled to be so) 14:28 < cfields_> gmaxwell: ok, that's already how it works. Looks like you just want the option to explicitly disable openssl rather than using it if it's found? 14:29 < gmaxwell> cfields_: yes. 14:29 < cfields_> roger 14:30 < jtimon> cfields_: got it, so no BITCOIN_CONSENSUS_H, put the .h and the .cpp together directly 14:30 < jtimon> cfields_: like in the crypto package 14:30 < cfields_> jtimon: i have no real preference there 14:31 < jtimon> cfields_: well, me neither, so... 14:31 < gmaxwell> cfields_: interested in running coverity again? we haven't run it in a while. I added directory masks for our new directories under src. (If you're no longer setup to run it, I'll run it... I just don't want to stomp on you if you are. Path changes can make the reports somewhat less useful if you bounce between systems that its run on) 14:32 < jtimon> I think I'll just copy the ways of crypto then 14:32 < cfields_> gmaxwell: go for it, i haven't messed with it in a while. I poke at it with clang tools now and then, i'd be curious to see how the results differ 14:33 < gmaxwell> cfields_: mostly I wanted to get a run against current libsecp256k1. :) 14:33 < cfields_> heh 14:34 < cfields_> gmaxwell: while you're at it, make sure to throw clang-tidy at it. It's turned up some useful stuff 14:34 < jtimon> but the main question...is it ok to add primitives/block, arith_uint256, version.h, serialize.h and company to the consensus package (and therefore to bitcoin-tx)? 14:37 < jtimon> s/"version.h, serialize.h"/"consensus/params.h, consensus/validation.h"/ 14:40 < cfields_> jtimon: the headers are only listed to keep track of what files go into the tarball. they're not actually used in depenency resolution 14:41 < cfields_> so just do whatever makes it the most clear 14:42 < jtimon> cfields_: so nothing can fail in the build by .h files having circular package dependencies and stuff? what a pity 14:42 < cfields_> jtimon: i don't believe so. Need to control it with paths. 14:42 < jtimon> I think it still makes it clearer 14:44 < jtimon> currently https://github.com/libbitcoin/libbitcoin-consensus/tree/master/src/clone is more clear than libbitcoinconsensus_la_SOURCES 14:45 < jtimon> thanks for the feedback, I will force push an updated version 14:45 < cfields_> np 14:48 < jtimon> cfields_: could you push your raw patch somewhere on github for convenience? 14:49 < cfields_> jtimon: will do in a few min, that's mixed in with my current branch 14:49 < jtimon> oh, I see, no hurry 14:50 < jtimon> hehe, I wasn't sure if it was on top of master or one of my commits 14:51 < cfields_> nah, master 14:52 < jtimon> oh, never mind then 15:03 < cfields_> ok 15:03 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 15:03 -!- Guyver2_ is now known as Guyver2 15:03 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer] 15:22 < phantomcircuit> gmaxwell, we're keeping travis very busy 15:24 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev 16:03 < raedah> which file creates the info displayed in 'Show transaction details' ? Looking at src/qt/transactionrecord.cpp and src/qt/transactiontablemodel.cpp 16:05 < raedah> ah, looks like its in transactiondesc.cpp 16:20 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.] 16:21 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev 16:54 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-zowntxnmndwnhcxr] has quit [Quit: Connection closed for inactivity] 16:57 -!- blkdb [~supybot@2a01:4f8:212:1ea2::2] has joined #bitcoin-core-dev 17:07 -!- blkdb [~supybot@2a01:4f8:212:1ea2::2] has quit [Quit: Ctrl-C at console.] 17:07 -!- blkdb [~supybot@2a01:4f8:212:1ea2::2] has joined #bitcoin-core-dev 17:12 -!- blkdb [~supybot@2a01:4f8:212:1ea2::2] has quit [Client Quit] 17:12 -!- phantomcircuit [phantomcir@2600:3c01::f03c:91ff:fe73:6892] has quit [Quit: quit] 17:12 -!- phantomcircuit [phantomcir@2600:3c01::f03c:91ff:fe73:6892] has joined #bitcoin-core-dev 17:12 -!- blkdb [~supybot@2a01:4f8:212:1ea2::2] has joined #bitcoin-core-dev 17:15 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Ping timeout: 260 seconds] 17:16 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 17:21 -!- blkdb [~supybot@2a01:4f8:212:1ea2::2] has quit [Quit: Ctrl-C at console.] 17:25 -!- cocoBTC [~cocoBTC__@c-233a71d5.136-1-64736c10.cust.bredbandsbolaget.se] has quit [Quit: Leaving] 17:30 -!- raedah [~raedah@172.56.38.154] has quit [Ping timeout: 244 seconds] 17:32 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev 17:52 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds] 18:01 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has quit [Ping timeout: 240 seconds] 18:03 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-dev 18:09 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 18:41 < GitHub190> [bitcoin] pstratem opened pull request #7094: Assert now > 0 in GetTime GetTimeMillis GetTimeMicros (master...2015-11-24-assert-time) https://github.com/bitcoin/bitcoin/pull/7094 18:44 < gmaxwell> Guess my PR answered the question of if we still had tests that were expecting the mempool RPC to behave in certian ways. :) 18:45 < phantomcircuit> gmaxwell, it also failed on INT64_MAX for some reason 18:46 < phantomcircuit> see my note on the outdated diff 18:47 < gmaxwell> phantomcircuit: yea, I had a host that it did that on too. Which is weird because stdint.h is included in that file; but whatever; you were right: I should have done it consistently. 18:47 < phantomcircuit> oh you fixed that already 18:48 < phantomcircuit> i dont have any strong tie to either method but we've been using std::numeric_limits everywhere else (apparently for a reason, which i cant discern either) 18:52 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving] 18:52 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev 18:55 < gmaxwell> phantomcircuit: now the issue is that the blocktester (foolishly) depends on this. 19:00 -!- tulip [~tulip@unaffiliated/tulip] has joined #bitcoin-core-dev 19:20 < cfields_> anyone happen to know why dns seeds register a second dns query result as their source in addrman, rather than some dummy value? 19:24 < gmaxwell> er. it's supposted to be like.. the dns seed identifer as a source. 19:25 -!- blkdb [~blkdb@2a01:4f8:212:1ea2::2] has joined #bitcoin-core-dev 19:26 < cfields_> gmaxwell: right. that identifier requires another resolve, which i suppose could fail and result in a source of "0.0.0.0". 19:26 < cfields_> (or am i reading it wrong?) 19:27 < gmaxwell> yea, it's brain damaged that it's resolving though, since thats going to return some random stuff. 19:28 < gmaxwell> We should be filling it in with a dummy value and a distinct dummy value per dnsseed. 19:28 < gmaxwell> I wonder if that resolution is a DNS leak when running on TOR? 19:29 < cfields_> i don't believe so, it should be stopped later down the path 19:30 < cfields_> er yikes.. maybe not 19:31 -!- blkdb [~blkdb@2a01:4f8:212:1ea2::2] has quit [Remote host closed the connection] 19:33 < cfields_> gmaxwell: ok yea, that's ok. oneshots are used if a proxy is enabled, so that path isn't taken 19:35 -!- blkdb [~blkdb@2a01:4f8:212:1ea2::2] has joined #bitcoin-core-dev 19:53 < phantomcircuit> gmaxwell, ./qa/pull-tester/rpc-tests.py passes all tests on 7093 20:00 < gmaxwell> phantomcircuit: yea, it's matt's blocktester thats failing. It's monitoring node status via p2p mempool calls. 20:04 < phantomcircuit> oh 20:04 < phantomcircuit> BlueMatt, ^ 20:05 -!- blur3d [~blur3d@pa49-197-5-211.pa.qld.optusnet.com.au] has joined #bitcoin-core-dev 20:06 < BlueMatt> gmaxwell: why are you not responding to queries if the node just asked for mempool now? 20:07 < BlueMatt> gmaxwell: that seems like an annoying hack :/ 20:08 < gmaxwell> BlueMatt: It already answered. 20:08 < gmaxwell> it's not resending the same stuff it already sent. 20:10 < gmaxwell> BlueMatt: you've been whined at before about the pull tester using mempool... mempool behavior isn't consensus normative. :) 20:13 < BlueMatt> gmaxwell: yea, yea... 20:14 < BlueMatt> gmaxwell: the goal of it has changed slightly over time 20:14 < gmaxwell> in any case, I could add a hidden option to turn off this behavior, or bypass it for whitelisted peers or... 20:15 < gmaxwell> but I do think we need to limit how mempool P2P command works (Jeff suggested removing it entirely; but it's widely used by SPV wallets) 20:15 < gmaxwell> and I think my patch mostly solves the privacy and dos attacks without breaking SPV wallets (well, apparently mycelium redoes filterloads and mempools again, so I need some additional handling there) 20:17 < BlueMatt> allow X-per-Y 20:17 < BlueMatt> then everything works :) 20:17 < BlueMatt> i think the tester only does like 3 or 4 total anyway 20:18 < gmaxwell> well I'm breaking the tester because I don't return duplicate results. 20:19 < gmaxwell> The delay means that a spv wallet will need to mempool again 30 seconds after connecting in order to get _everything_, and it would be nice to only send it INVs for the things it missed. 20:19 < BlueMatt> yea, just multiply your quanitization interval by X and allow X requests each interval 20:22 < gmaxwell> I can allow more requests, but you're missing my point. It won't be able to stop returning old data then, so it'll send duplicates. 20:22 < BlueMatt> yea, my point was "meh" 20:22 < gmaxwell> then it remains a bandwidth exhaustion attack to keep calling mempool often. 20:23 < BlueMatt> not really 20:23 < BlueMatt> because you limit how often you can call it 20:23 < BlueMatt> to the same rate as your patch 20:25 -!- mm_1 [bnc33@bnc33.nitrado.net] has quit [Ping timeout: 260 seconds] 20:26 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.] 20:26 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev 20:27 -!- mm_1 [bnc33@bnc33.nitrado.net] has joined #bitcoin-core-dev 20:28 < phantomcircuit> tulip, ha 20:28 < tulip> the blown up ping? 20:28 < phantomcircuit> i knew that someone would show up having seen that in production 20:28 < phantomcircuit> "production" 20:28 < phantomcircuit> there's lots of things using wall clock time that should be using monotonic time 20:29 < phantomcircuit> but i think for now it's better to explode than to silently do crazy things 20:31 < cfields_> gmaxwell: suggestions for a uuid for seeds rather than a second lookup? best i can come up with is designating a tiny chunk of the FC00::/7 range for groups. I'd say we should just feed addrman a deterministic hash for the source, but the address is serialized to disk 20:32 < gmaxwell> phantomcircuit: I have pointed out before that we should be using monotone time. I don't thinke we have any need for wallclock time, except logging (and even there, if logtimes are non-monotone it will break some log parsing tools for sure) 20:32 < gmaxwell> phantomcircuit: we already have code that does time ofsetting so it can just adjust the offset between the monotone clock and what we want it to be (in a way that preserves monotonicity!) 20:33 < gmaxwell> phantomcircuit: reworking time in bitcoin core is something I've wanted to do since 2011 but its so unimportant that I never will. 20:34 < gmaxwell> cfields_: 127.0.0.2 127.0.0.3 perhaps? :P (I forget if we look at the source netgroup) 20:34 < gmaxwell> even though it gets saved to disk, I don't think we care too much if its not fully consistent across versions. I suppose it's preferable if it is. 20:35 < gmaxwell> phantomcircuit: e.g. I think all Time() in core should be monotone, network time should be largely monotone but with the ability to step if its way out of wack. 20:37 < cfields_> gmaxwell: heh, i figured you'd smack me for not coming up with something more clever than a dummy range. if you're ok with that, i'll go ahead and do it that way and we can bikeshed about what actual range to use in the PR. 127.0.0.x sounds as good as any to me. 20:40 -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has joined #bitcoin-core-dev 20:40 < phantomcircuit> gmaxwell, agreed, but we would definitely want to review everywhere that GetTime* is used before changing their behavior 20:41 < phantomcircuit> but a simple find/replace to GetMonotonicTime 20:41 < phantomcircuit> or maybe just change GetTime to be monotonic and add GetWallclockTime 20:41 < phantomcircuit> which could keep the assert 20:43 < phantomcircuit> either way i think exploding all over the place is the best option for something doable right now today 20:45 < gmaxwell> cfields_: the only downside I see w/ the dummy range is that if we reorder the list it'll behave suboptimally. But this is no great crime. :) 20:45 < gmaxwell> but as I said, if we're currently paying attention to source netgroups (I think we might in one table) them they should probably be in different netgroups. 20:46 < cfields_> gmaxwell: not sure what you mean about reordering? 20:46 < gmaxwell> phantomcircuit: well it's more complex. monotone time is not calibrated to any particular starting point. So that means any place we print one of our stored times we may need to process it. 20:47 < tulip> phantomcircuit: I don't think I would have noticed except that the script the output was being piped to didn't like graphing a ping with 300,000 years of network latency. 20:47 < cfields_> gmaxwell: oh, you mean re-querying with existing addrman data? 20:47 < gmaxwell> cfields_: e.g. if the list is seed1, seed2, seed3 and we change to seed2, seed4, seed1, seed3 in a new release then addresses will go into different groups, perhaps giving one seed or another more share of your addrman than it should. But who cares. 20:48 < cfields_> gmaxwell: roger, and agreed. 20:49 < cfields_> gmaxwell: for background, i'm poking at this in order to make dns async. as-is, it's all tangled up if one resolve has to wait on another. 20:49 < cfields_> so there's more motivation than just "that looks weird" 20:49 < gmaxwell> phantomcircuit: but I think we should return numbers in network time, and then just have a function that converts any absolute time we display to network time. 20:49 < gmaxwell> cfields_: fantastic. 20:50 < gmaxwell> (and I think our log messages should log both network time and local time; /me wants for wumpus to shoot him) 20:50 < phantomcircuit> gmaxwell, static int64_t first_time; int64_t now = monotonic_time - first_time + 1; 20:50 < phantomcircuit> ? 20:50 < phantomcircuit> basically always start at 1 20:51 < gmaxwell> phantomcircuit: actually on most systems the monotone clocks starts at 0 at boot. 20:51 < phantomcircuit> oh 20:51 < phantomcircuit> then *shrug* 20:51 < cfields_> gmaxwell: you'll be happy to know also, the async networking coalesces 4 threads to 1. Not sure how many of those unused threads i get to spend myself, though :) 20:52 * gmaxwell looks at x86 virtual address space usage 20:52 < gmaxwell> :( 20:52 < gmaxwell> -3 20:52 < gmaxwell> :) 20:53 < gmaxwell> phantomcircuit: it's no big deal, we already handle network time being some arbritary offset from local time; so instead it would just be network time is an arbritary offset from monotone time, and that offset is initilized with localtime at start. 20:53 * cfields_ calls shotgun on at least one freed up thread for async block handling of some kind 20:53 < gmaxwell> phantomcircuit: most calculation internally would use monotone time, but display would convert to network time. (and obviously the network time needing things would use network time). 20:56 < phantomcircuit> gmaxwell, oh you mean the adjusted network time thingie? 20:56 < gmaxwell> yup yup. 20:59 < phantomcircuit> hmm yeah that makes sense 20:59 < phantomcircuit> and then finangle that such that it's monotonic unless something crazy happens 21:00 < gmaxwell> well the network time should be monotone except for steps, and we should probably log steps. 21:01 < gmaxwell> but it doesn't need to be, and most of our use of time is differential, and its more important that it be monotone than it have any particular timebase. 21:11 < CodeShark> we have such poor temporal resolution anyhow - ultimately consensus is about well-ordering of events 21:14 < gmaxwell> CodeShark: internally we have high resolution and do varrious things where time going backwards can cause breakage. See tulip's example with the 300 thousand year pingtime. 21:16 < CodeShark> was that part of an earlier discussion here? (scrolling back) 21:16 < tulip> yes, and #7094 21:19 < CodeShark> why were signed ints used for timestamps in the first place? 21:19 < CodeShark> :) 21:19 < CodeShark> what's the 300 thousand year pingtime? 21:20 < tulip> https://github.com/bitcoin/bitcoin/pull/7094#issuecomment-159487966 21:20 < phantomcircuit> CodeShark, his clock went backwards or something insane 21:20 < phantomcircuit> oh no i know 21:20 < gmaxwell> CodeShark: because they mostly get used for time differences, which are naturally signed. Not using signed values are part of what creates issues like the 300 years pingtime (instead of negative pingtimes) 21:21 < phantomcircuit> his clock started at 1970-1-1 and jumped to the current time 21:21 < phantomcircuit> or something like that 21:21 < gmaxwell> phantomcircuit: More likely it just went backwards a microsecond, and then the -1 was converted to unsigned at some point before it hit the screen. 21:21 < CodeShark> hah 21:22 < phantomcircuit> so many comical possibilities! 21:22 < phantomcircuit> :) 21:22 < phantomcircuit> gmaxwell, are there systems where the monotonic clock will wrap? 21:22 < gmaxwell> because people have the expectation that time does not flow backwards and write software accordingly. 21:22 < phantomcircuit> i'd like to think the kernel detects that and helps you out but... 21:23 < gmaxwell> phantomcircuit: the monotone clock returned by the OS should be cleaned of any vulgar hardware weirdness. 21:23 < gmaxwell> If it doesn't, we're allowed to fail. :) 21:23 < phantomcircuit> fail catastrophically? "your clock is broken" 21:23 < phantomcircuit> heh 21:23 < gmaxwell> (it's pretty easy to unwrap a monotone clock!) 21:23 < phantomcircuit> gmaxwell, as long as you're polling more frequently than the wrap interval yes 21:23 < gmaxwell> (so long as you know its period and poll it at least twice per cycle ) 21:24 < tulip> phantomcircuit: 9223372036854 seconds is 9223372036854000000 microseconds, which is pretty close to 2**64. I think the clock just skipped back further than the ping time. 21:25 < phantomcircuit> yup 21:25 < gmaxwell> independant of this monotone time stuff, we should probably figure out where that stat goes unsigned and make it signed. 21:26 < gmaxwell> or discard negative values before they get that far. :) 21:27 < phantomcircuit> gmaxwell, ok now i can see the need for negative values 21:27 < phantomcircuit> :P 21:29 < CodeShark> why do we care about the other node's clock when doing a ping? 21:31 < tulip> it's the network time thing. 21:32 < tulip> -debug (-debug=net in master) will dump out the deltas of your peers timestamps. spoiler is, they're usually pretty awful. 21:39 -!- blur3d [~blur3d@pa49-197-5-211.pa.qld.optusnet.com.au] has quit [Quit: blur3d] 21:53 < gmaxwell> CodeShark: we don't know _anything_ about the other nodes clock when doing a ping. 21:53 < gmaxwell> CodeShark: it's not the other nodes clock at all. 21:54 < gmaxwell> GetTime() is not monotone. It can go back. Time_ping_returned-Time_ping_sent can be negative. 21:55 < CodeShark> time_t now = time(NULL); - how can that go back unless the user's system clock gets changed? 21:55 < tulip> NTP will change the system clock backwards if it needs to. 21:55 < CodeShark> oh, ok 21:56 < CodeShark> if you only need to measure time intervals, isn't there a better option than time(NULL) that is unaffected by system clock changes? 21:57 < gmaxwell> yes, you ask the system for a monotone clock. 21:58 < CodeShark> is that part of the time.h library? 21:59 < CodeShark> I guess there's the timer stuff 21:59 < gmaxwell> tulip: NTP tries pretty hard to not move the clock backwards, but it will do so if its too far behind... and this can happen like.. constantly, if the path delay asymmetry of the NTP servers you're using changes. (e.g. due to servers going up/down or internet rerouting). 22:01 < tulip> phantomcircuit: RE doing things that rely on the accuracy of peer clocks, here's the offsets from a crawl of about 1000 random IPv4 peers. the data doesn't account for latency so +-300ms is probably within the noise when the nodes are far away. http://pastebin.com/raw.php?i=3zmQDyK0 22:03 < CodeShark> to force monotonicity, could we do something like static int prev = 0; int GetTime() { time_t now = time(NULL); if (now > prev) { prev = now; } return prev; } 22:05 < gmaxwell> sweet now GetTime() needs to take a lock. :P 22:05 < CodeShark> yeah, it's not thread-safe...but we'll pretend we didn't notice ;) 22:06 < CodeShark> how often does it get called, though? 22:06 < gmaxwell> no, not cool. There is no such thing as a safe data race. It's undefined behavior and can cause spooky memory corruption at a distance. :) 22:06 < gmaxwell> CodeShark: all over the place, used for benchmarking stuf, yadda yadda (esp the microseconds version) 22:07 < CodeShark> so then this brings up another issue - even if the system clock is perfectly accurate, things may execute out-of-order 22:10 < CodeShark> I mean, the monotonicity ceases to be meaningful in a concurrent setting 22:10 < CodeShark> in general we cannot say which of two calls on two separate threads occurred first without using a lock 22:11 < gmaxwell> sure but that isn't the case for many things. We do really know that a ping response came after the request. They're seralized by the IO. 22:11 < CodeShark> right 22:12 < CodeShark> in that particular use case, though, a lock doesn't seem like the bottleneck 22:13 < CodeShark> in any case, we can just zero all negative diffs and basically achieve the same goal :) 22:13 < tulip> that would ruin the "minping" statistic 22:13 < cfields_> gmaxwell: speaking of which, I've been considering creating a bip for an explicitly-allowed out-of-order ping/pong. For ex, if the ping nonce is 0xffff, allow that to mean "this is not meant to be a fence, it's an actual latency measurement" 22:14 < cfields_> gmaxwell: as threading improves, we should have a way of specifying that a ping isn't meant to be a fence. Thoughts? 22:15 < cfields_> er, everyone^^. No clue why that was directed at gmaxwell :p 22:16 < cfields_> only one unordered ping would be allowed in-flight at any given time, so dropping the nonce doesn't cost anything 22:17 < gmaxwell> The purpose of the nonce isn't so much for ordering, its to prevent faking a fast response. 22:18 < gmaxwell> I dunno if an unordered ping is actually useful, for every case where I'd like to use pings, I'd like it to go higher if the peer is busy. But if there is a use, I don't have a problem-- but it shouldn't lose the nonce. :) 22:18 < gmaxwell> tulip: yea, thats why I said discard above. 22:21 < cfields_> gmaxwell: well busy can be fleeting.. so it's not a great metric for discerning peering. "Busy" is also kinda an implementation detail. With better threading, a close-by busy peer may be more helpful than a further away idle one. 22:21 < cfields_> re nonce: point taken 22:23 < gmaxwell> cfields_: close by is best measured by the minimum. 22:23 < gmaxwell> (or minimum with periodic forgetting if you're concerned about it changing.) 22:27 < cfields_> gmaxwell: makes sense i guess. assuming you've stuck around long enough for a good minimum :) 22:47 < phantomcircuit> gmaxwell, atomics horray 22:47 < phantomcircuit> compare_and_swap 23:16 < Luke-Jr> gmaxwell: bool races are unsafe? 23:23 < phantomcircuit> Luke-Jr, yes 23:23 < phantomcircuit> Luke-Jr, dont tell ckpool 23:23 < phantomcircuit> it's funnier this way 23:23 < Luke-Jr> what could possibly go wrong in a bool race? :/ 23:24 < phantomcircuit> Luke-Jr, overwrite a random byte of memory with garbage? 23:24 < Luke-Jr> that'd be a pointer race? 23:25 < phantomcircuit> Luke-Jr, clever compilers doing clever optimizations have the same effect potentially 23:25 < Luke-Jr> real-world optimizations? 23:26 < Luke-Jr> hm, I suppose the compiler could move a condition check outside a busy loop because it knows the value won't change inside it.. 23:26 < Luke-Jr> well, except if for the volatile keyword.. 23:30 < gmaxwell> Luke-Jr: any race is unsafe. The compile can do things like "oh, later I will overwrite this variable, that means I have exclusive access to it, I can store temporary thing to it for now." 23:35 < Luke-Jr> hmm, I wouldn't think that is allowed if it's volatile 23:38 < gmaxwell> Volitile should prevent that; though volitile is frequently misimplemented. 23:40 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Ping timeout: 276 seconds] 23:41 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev 23:47 < wumpus> gmaxwell: log messages should log at least current monotonic time, local time, network time, bulletin of atomic scientists' number of minutes to midnight, and the absolute time since the big bang in Planck time units 23:47 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-kssotdfzbjvavpmi] has joined #bitcoin-core-dev 23:48 < gmaxwell> oh your stabbing is just right. 23:48 < gmaxwell> :) 23:54 < wumpus> gmaxwell: can we have your input on these tests? https://github.com/bitcoin/bitcoin/issues/7086 Looks like one hidden place where openssl is still used, as an oversight, as openssl hasn't been part of consensus in that particular way for ages 23:58 < wumpus> and now the code is running into trouble with newer OpenSSLs