--- Day changed Thu Feb 01 2018
00:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
00:10 -!- bsm117532 [~mcelrath@173-9-124-61-NewEngland.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
00:14 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
00:22 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has quit [Quit: Snoozing.]     
00:31 -!- Krellan [~Krellan@2601:640:4000:9258:198e:d0a0:9a01:8279] has quit [Read error: Connection reset by peer]     
00:32 -!- Krellan [~Krellan@2601:640:4000:9258:a969:a35a:344f:d6d1] has joined #bitcoin-core-dev     
00:36 -!- anja_ [7be77f97@gateway/web/freenode/ip.123.231.127.151] has joined #bitcoin-core-dev     
00:36 -!- anja_ [7be77f97@gateway/web/freenode/ip.123.231.127.151] has quit [Client Quit]     
00:53 -!- indistylo [~indistylo@27.59.28.141] has quit [Ping timeout: 264 seconds]     
01:02 -!- Sinclair6 [sinclair6@gateway/vpn/privateinternetaccess/sinclair6] has quit []     
01:04 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]     
01:06 -!- keks_ [5b4055c9@gateway/web/freenode/ip.91.64.85.201] has joined #bitcoin-core-dev     
01:07 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev     
01:12 -!- sanada [~bitktn@36-2-119-80.chiba.ap.gmo-isp.jp] has quit []     
01:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
01:17 -!- indistylo [~indistylo@119.82.105.106] has joined #bitcoin-core-dev     
01:17 -!- sanada [~bitktn@36-2-119-80.chiba.ap.gmo-isp.jp] has joined #bitcoin-core-dev     
01:21 -!- Sinclair6 [sinclair6@gateway/vpn/privateinternetaccess/sinclair6] has joined #bitcoin-core-dev     
01:25 -!- lio17 [~lio17@ns350827.ip-37-187-174.eu] has quit [Remote host closed the connection]     
01:32 -!- indistylo [~indistylo@119.82.105.106] has quit [Ping timeout: 268 seconds]     
01:32 -!- lio17 [~lio17@ns350827.ip-37-187-174.eu] has joined #bitcoin-core-dev     
01:41 -!- sanada [~bitktn@36-2-119-80.chiba.ap.gmo-isp.jp] has quit []     
01:43 -!- sanada [~bitktn@36-2-119-80.chiba.ap.gmo-isp.jp] has joined #bitcoin-core-dev     
01:46 -!- indistylo [~indistylo@106.216.170.220] has joined #bitcoin-core-dev     
01:48 -!- pedrobranco [~pedrobran@bl21-77-63.dsl.telepac.pt] has joined #bitcoin-core-dev     
01:56 < bitcoin-git> [bitcoin] murrayn opened pull request #12322: Docs: Remove step making cloned repository world-writable for Windows build. (master...doc_change) https://github.com/bitcoin/bitcoin/pull/12322
02:04 -!- pedrobranco [~pedrobran@bl21-77-63.dsl.telepac.pt] has quit []     
02:09 -!- farsider350 [~farsider3@pa49-197-196-210.pa.qld.optusnet.com.au] has joined #bitcoin-core-dev     
02:10 -!- go1111111 [go1111111@gateway/vpn/privateinternetaccess/go1111111] has joined #bitcoin-core-dev     
02:24 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 255 seconds]     
02:24 -!- Krellan_ [~Krellan@c-73-223-240-37.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
02:26 -!- Krellan [~Krellan@2601:640:4000:9258:a969:a35a:344f:d6d1] has quit [Read error: Connection reset by peer]     
02:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
02:27 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 248 seconds]     
02:28 -!- farsider350 [~farsider3@pa49-197-196-210.pa.qld.optusnet.com.au] has quit []     
02:28 -!- aruns [~indistylo@119.82.105.106] has joined #bitcoin-core-dev     
02:29 -!- indistylo [~indistylo@106.216.170.220] has quit [Ping timeout: 260 seconds]     
02:29 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
02:30 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
02:31 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
02:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
02:41 -!- Krellan_ [~Krellan@c-73-223-240-37.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds]     
02:42 -!- Krellan [~Krellan@2601:640:4000:9258:a969:a35a:344f:d6d1] has joined #bitcoin-core-dev     
02:44 -!- JackH [~laptop@host-80-47-85-47.as13285.net] has joined #bitcoin-core-dev     
02:45 -!- Lynet [~slem@2a00:c440:20:dcd:b442:c470:ca9:f56c] has quit [Ping timeout: 240 seconds]     
02:48 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
02:53 < dafuq> a PR change to the --help CLI options would fall under what category?
02:58 < wumpus> docs
03:02 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-hbyfzhetemlpdxnt] has joined #bitcoin-core-dev     
03:02 -!- larafale [~larafale@ax213-1-82-66-157-194.fbx.proxad.net] has joined #bitcoin-core-dev     
03:03 -!- MickMSaunders___ [uid270432@gateway/web/irccloud.com/x-yklhvchwjhspzhoi] has joined #bitcoin-core-dev     
03:04 < dafuq> ok, seems most suitable but does involve code changes
03:05 < wumpus> yes, that doesn't matter, as long as it is message changes
03:05 < dafuq> thanks
03:09 -!- midnightmagic_ [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-core-dev     
03:09 -!- Lynet [~slem@1x-193-157-184-63.uio.no] has joined #bitcoin-core-dev     
03:09 -!- helo_ [~helo@unaffiliated/helo] has joined #bitcoin-core-dev     
03:11 -!- Jackielove4u_ [uid43977@gateway/web/irccloud.com/x-fasdwavbdwydomiz] has joined #bitcoin-core-dev     
03:11 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 276 seconds]     
03:11 -!- helo [~helo@unaffiliated/helo] has quit [Ping timeout: 276 seconds]     
03:11 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-sngdygvscesedcro] has quit [Ping timeout: 276 seconds]     
03:11 -!- bitbee [~bitbee@138.197.209.248] has quit [Ping timeout: 276 seconds]     
03:11 -!- nsh [~lol@wikipedia/nsh] has quit [Excess Flood]     
03:11 -!- Jackielove4u_ is now known as Jackielove4u     
03:11 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Ping timeout: 248 seconds]     
03:11 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has quit [Ping timeout: 276 seconds]     
03:11 -!- nsh- [~lol@wikipedia/nsh] has joined #bitcoin-core-dev     
03:11 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has joined #bitcoin-core-dev     
03:12 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-vvuccudgxwtmmzdv] has quit [Ping timeout: 276 seconds]     
03:12 -!- bitbee [~bitbee@138.197.209.248] has joined #bitcoin-core-dev     
03:13 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
03:13 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-bjtgwsnrureudwup] has joined #bitcoin-core-dev     
03:14 -!- lifeofguenter [~lifeofgue@bnc.pro.to.co.ls] has quit [Ping timeout: 260 seconds]     
03:16 -!- lifeofguenter [~lifeofgue@bnc.pro.to.co.ls] has joined #bitcoin-core-dev     
03:17 -!- indistylo [~indistylo@106.206.93.236] has joined #bitcoin-core-dev     
03:20 -!- aruns [~indistylo@119.82.105.106] has quit [Ping timeout: 260 seconds]     
03:21 -!- midnightmagic_ is now known as midnightmagic     
03:24 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Quit: https://quanto.ga/]     
03:25 -!- indistylo [~indistylo@106.206.93.236] has quit [Ping timeout: 256 seconds]     
03:25 -!- lnostdal [~lnostdal@gateway/tor-sasl/lnostdal] has joined #bitcoin-core-dev     
03:27 < wumpus> gmaxwell:  dx25: I've created an issue for the problem, please add more information if you have there https://github.com/bitcoin/bitcoin/issues/12323
03:29 -!- bitcoin-core-dev [c4d20b64@gateway/web/freenode/ip.196.210.11.100] has joined #bitcoin-core-dev     
03:32 -!- Krellan [~Krellan@2601:640:4000:9258:a969:a35a:344f:d6d1] has quit [Ping timeout: 240 seconds]     
03:33 -!- Krellan [~Krellan@2601:640:4000:9258:a969:a35a:344f:d6d1] has joined #bitcoin-core-dev     
03:33 -!- bitcoin-core-dev [c4d20b64@gateway/web/freenode/ip.196.210.11.100] has quit [Client Quit]     
03:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
03:36 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev     
03:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
03:46 -!- indistylo [~indistylo@119.82.105.106] has joined #bitcoin-core-dev     
03:47 -!- lnostdal [~lnostdal@gateway/tor-sasl/lnostdal] has quit [Quit: https://quanto.ga/]     
03:47 -!- lnostdal [~lnostdal@gateway/tor-sasl/lnostdal] has joined #bitcoin-core-dev     
03:52 < bitcoin-git> [bitcoin] AkioNak opened pull request #12324: speed up Unserialize_impl for prevector (master...unserialize) https://github.com/bitcoin/bitcoin/pull/12324
03:57 -!- farsider350 [~farsider3@pa49-197-196-210.pa.qld.optusnet.com.au] has joined #bitcoin-core-dev     
03:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
04:00 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection]     
04:07 -!- Krellan [~Krellan@2601:640:4000:9258:a969:a35a:344f:d6d1] has quit [Ping timeout: 252 seconds]     
04:08 -!- Krellan [~Krellan@2601:640:4000:9258:a969:a35a:344f:d6d1] has joined #bitcoin-core-dev     
04:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
04:09 -!- wxss [~user@95.143.195.106] has joined #bitcoin-core-dev     
04:13 -!- jtimon [~quassel@41.31.134.37.dynamic.jazztel.es] has quit [Remote host closed the connection]     
04:14 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev     
04:16 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
04:24 -!- Lynet [~slem@1x-193-157-184-63.uio.no] has quit [Remote host closed the connection]     
04:25 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
04:38 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev     
04:49 < provoostenator> I'm getting "Fatal Internal Error" during IBD on testnet3 with 0.16.0rc1, twice. Will investigate.
04:50 < bitcoin-git> [bitcoin] kekimusmaximus opened pull request #12325: Use dynamic_cast for downcasting instead of static_cast. (master...use_dynamic_cast_to_downcast) https://github.com/bitcoin/bitcoin/pull/12325
04:50 < provoostenator> Might be a disk permission thing. "Pre-allocating up to position 0x3000000 in blk00002.dat" "ERROR: WriteBlockToDisk: ftell failed" "*** Failed to write block"
04:52 -!- checksauce [~checksauc@184.82.30.95] has quit [Remote host closed the connection]     
04:53 -!- checksauce [~checksauc@184.82.30.95] has joined #bitcoin-core-dev     
04:53 < wumpus> disk full?
04:53 < provoostenator> Also seeing a bunch of "socket recv error Bad file descriptor (9)" messages, not sure what that's about.
04:53 -!- checksauce [~checksauc@184.82.30.95] has quit [Remote host closed the connection]     
04:53 < wumpus> oof bad file descriptor
04:53 < provoostenator> No, plenty of space. It's an external SSD though, so can't rule out a hardware problem.
04:53 < wumpus> provoostenator: see  https://github.com/bitcoin/bitcoin/issues/12323
04:54 < dx25> mine's also an external drive, not ssd tho
04:54 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has joined #bitcoin-core-dev     
04:54 < wumpus> no, it's possibly a regression in 0.16
04:54 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has quit [Client Quit]     
04:54 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
04:55 < provoostenator> Getting this crash every other minute now on testnet. Will try local drive just to rule out hardware issue.
04:55 < dx25> i'm on qubes, fedora25 vm, 4.9.56 kernel
04:57 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Ping timeout: 248 seconds]     
05:00 < wumpus> I really wonder why the bad file descriptor thing happens, normally that happens if either a fd is used that was not returned by open, or a file descriptor that was already closed
05:01 < provoostenator> Same "bad file descriptor" on a fresh testnet3 IBD (MacOS) on the built in harddisk which has plenty of space. Waiting for it to crash.
05:01 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
05:03 < wumpus> I seriously doubt this is a hardware issue
05:03 < wumpus> are you doing anything special with the node? regular RPC requests, for example?
05:04 -!- larafale_ [~larafale@i15-les02-ntr-176-181-166-60.sfr.lns.abo.bbox.fr] has joined #bitcoin-core-dev     
05:04 < wumpus> or any fd related settings in bitcoin.conf?
05:04 < provoostenator> I was running QT production and testnet at the same time for different users on my system, bother in seperate directories. I also suspended the computer (though it should keep syncing in that case). So trying to reproduce with fewer variables now.
05:05 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
05:05 < provoostenator> server=1  rpcuser=... rpcpassword=... listen=0
05:06 < provoostenator> I used a symlink to point to the SSD drive.
05:06 < dx25> i have some weird walletnotify and alertnotify thing calling curl for some reason i can't remember.  haven't tried turning that off yet.
05:06 < provoostenator> Ah there we go again: crash.
05:07 -!- larafale [~larafale@ax213-1-82-66-157-194.fbx.proxad.net] has quit [Ping timeout: 240 seconds]     
05:07 < provoostenator> (no symlink involved this time, nor an external drive). Crashed happened at or after block 64709 (testnet)
05:07 < wumpus> provoostenator: so it happens even without listening
05:07 < dx25> i was doing no rpc stuff
05:08 < wumpus> provoostenator: that rules out some p2p races I guess, but what can it be then...
05:08 -!- larafale [~larafale@ax213-1-82-66-157-194.fbx.proxad.net] has joined #bitcoin-core-dev     
05:08 < wumpus> provoostenator: you're able to reliably reproduce this? could try git bisecting, if it was ok with 0.15.1
05:08 < provoostenator> Meanwhile I had production QT running all night without a problem, so I suspect it's sync related (my testnet node was doing an IBD the first time it crashed)
05:08 < wumpus> (or find some later commit where the issue doesn't exist)
05:08 -!- Angelo28Carroll [~Angelo28C@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
05:09 < provoostenator> I just down the other mainnet QT instance, will try once more. Then I'll compare versions after that.
05:09 < dx25> also sync related here, but on mainnet
05:09 < provoostenator> Pretty reliable so far
05:11 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Disconnected by services]     
05:11 -!- dermoth_ [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev     
05:11 -!- larafale_ [~larafale@i15-les02-ntr-176-181-166-60.sfr.lns.abo.bbox.fr] has quit [Ping timeout: 240 seconds]     
05:11 -!- dermoth_ is now known as dermoth     
05:16 < provoostenator> It was built with: ./configure --disable-tests --disable-bench --with-miniupnpc=no
05:17 < provoostenator> Hooray, another crash. Ok, should be easy to bisect.
05:17 < provoostenator> Height 8089 (testnet)
05:19 < wumpus> yes, would make a backup  of the data directory to make sure you start with the same state every time
05:19 -!- aruns [~indistylo@119.82.105.106] has joined #bitcoin-core-dev     
05:19 < wumpus> at hight 8089 at least that isn't too much data
05:20 < provoostenator> I get this crash with a fresh testnet3 directory.
05:20 < provoostenator> I'll keep a copy for forensics
05:20 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-hbyfzhetemlpdxnt] has quit [Quit: Connection closed for inactivity]     
05:22 -!- indistylo [~indistylo@119.82.105.106] has quit [Ping timeout: 276 seconds]     
05:22 < wumpus> I'll hold up on uploading executables for rc1 for now
05:23 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
05:26 -!- nsh- is now known as nsh     
05:26 < provoostenator> Mmm, I just found a zombie lightningd instance in the background. Maybe it was making RPC requests, not sure.  I'm going to kill it just in case.
05:29 < provoostenator> (no difference)\
05:30 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
05:30 < provoostenator> Height 401 :-)
05:30 < wumpus> I wouldn't expect it to be so predictable in that case
05:31 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
05:44 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has joined #bitcoin-core-dev     
05:45 -!- ProfMac [~ProfMac@2001:470:b8ac:0:9538:7370:a104:11ba] has quit [Ping timeout: 240 seconds]     
05:47 < provoostenator> Other than ccache and skipping tests and bench, any hints on how to make it compile faster?
05:48 < wumpus> do only 'make -j<x> src/bitcoind'
05:48 < wumpus> you don't really need to rebuild cli and such
05:53 -!- aruns__ [~indistylo@119.82.105.106] has joined #bitcoin-core-dev     
05:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
05:55 -!- ProfMac [~ProfMac@2001:470:b8ac:0:2d41:4b66:5eef:a6cf] has joined #bitcoin-core-dev     
05:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
05:55 -!- aruns [~indistylo@119.82.105.106] has quit [Ping timeout: 268 seconds]     
05:56 < provoostenator> Right, I should test if this is QT related first, and otherwise just build bitcoind
05:58 -!- CubicEarths [~cubiceart@201.191.198.123] has joined #bitcoin-core-dev     
06:02 < wumpus> yes, you could also only built -qt with a similar command, but it takes much longer
06:04 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
06:04 < provoostenator> I know, I was doing that (make src/qt/bitcoin-qt) 
06:04 < provoostenator> Is there a reason the binaries end up in the /src path rather than in e.g. /dist?
06:07 -!- CubicEar_ [~cubiceart@ip253-210-159-186.ct.co.cr] has joined #bitcoin-core-dev     
06:07 -!- CubicEar_ [~cubiceart@ip253-210-159-186.ct.co.cr] has quit [Remote host closed the connection]     
06:08 -!- CubicEar_ [~cubiceart@ip253-210-159-186.ct.co.cr] has joined #bitcoin-core-dev     
06:09 < wumpus> that's common for automake build systems, if you want to build somewhere else you can do an out of tree build, if you want to put the binaries somewhere set a prefix and do `make install`<
06:09 -!- Cheeseo [Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
06:10 -!- jamesob [~jamesob@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev     
06:10 -!- CubicEarths [~cubiceart@201.191.198.123] has quit [Ping timeout: 276 seconds]     
06:12 -!- jamesob [~jamesob@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Remote host closed the connection]     
06:12 -!- CubicEar_ [~cubiceart@ip253-210-159-186.ct.co.cr] has quit [Ping timeout: 248 seconds]     
06:12 -!- cheese_ [~Cheeseo@unaffiliated/cheeseo] has quit [Read error: Connection reset by peer]     
06:15 < morcos> just to clarify we think the crash is caused by what?  a Bad file descriptor issue occuring on block write?
06:15 < morcos> We've also seen it on ldb which causes a crash
06:15 < morcos> and on socket send/recv which doesn't
06:16 < provoostenator> Mmm, bitcoind doesn't show "Bad file descriptor" messages (with -debug=1). It does exit with " A fatal internal error occurred, see debug.log for details"
06:17 -!- Krellan [~Krellan@2601:640:4000:9258:a969:a35a:344f:d6d1] has quit [Read error: Connection reset by peer]     
06:18 -!- Krellan [~Krellan@2601:640:4000:9258:a969:a35a:344f:d6d1] has joined #bitcoin-core-dev     
06:19 < provoostenator> But http://termbin.com/83iva
06:19 < provoostenator> I wonder what "Interrupting HTTP server" is about.
06:20 -!- jamesob [~jamesob@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev     
06:21 < wumpus> there is no error there - you didn't simply send a stop command?
06:22 < provoostenator> I didn't. And a stop command wouldn't explain bitcoind exiting with "Error: Error: A fatal internal error occurred, see debug.log for details"
06:22 < provoostenator> I'm blaming gremlins. Bisecting now.
06:23 < wumpus> no, that's true, normally that's accompanied by an error being logged, this looks like a succesful shutdown
06:23 < wumpus> you did paste the right debug.log? :)
06:25 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
06:26 < provoostenator> Not sure actually, double checking
06:27 -!- Krellan [~Krellan@2601:640:4000:9258:a969:a35a:344f:d6d1] has quit [Ping timeout: 252 seconds]     
06:28 < provoostenator> Default og locations changed between 0.15 and 0.16. Will try again.
06:28 -!- Krellan [~Krellan@2601:640:4000:9258:a969:a35a:344f:d6d1] has joined #bitcoin-core-dev     
06:30 < wumpus> default log location changed?!
06:30 < wumpus> should not be the case, it's still <datadir>/debug.log, sounds more likely you've set a different datadir for -qt
06:32 < provoostenator> Or accidentally used mainnet for bitcoind.
06:37 < provoostenator> Ok, now I'm seeing the "Bad file descriptor" messages again. Will wait for crash and upload correct debug log. Then continue with bisect.
06:37 < BlueMatt> provoostenator: if you're trying to bisect, I'd recommend focusing on any changes to net
06:37 < BlueMatt> eg #11363
06:37 < gribble> https://github.com/bitcoin/bitcoin/issues/11363 | net: Split socket create/connect by theuni · Pull Request #11363 · bitcoin/bitcoin · GitHub
06:37 < BlueMatt> and #10663
06:37 < gribble> https://github.com/bitcoin/bitcoin/issues/10663 | net: split resolve out of connect by theuni · Pull Request #10663 · bitcoin/bitcoin · GitHub
06:38 < BlueMatt> though I dont see anything obvious in net on master that should be causing this
06:38 < provoostenator> BlueMatt: bisecting everything involves less thinking :-) 
06:39 < provoostenator> Although I'm not sure yet how long without a crash is long enough. So far it crashes within a few minutes though if it does.
06:40 -!- goatpig [56f75164@gateway/web/freenode/ip.86.247.81.100] has joined #bitcoin-core-dev     
06:40 < provoostenator> Maybe "Bad file descriptor" is a good enough proxy.
06:46 < morcos> cfields asked me to add some asserts for debugging this
06:46 < morcos> https://0bin.net/paste/X-6vyuCUUlN+XY1l#5VoMIrtAP6S0Yex-7eAwDNLJl/7UT2e7medmcgsVtvA
06:46 < gribble> https://github.com/bitcoin/bitcoin/issues/5 | Make the version number the protocol version and not the client version · Issue #5 · bitcoin/bitcoin · GitHub
06:46 < morcos> I just tried a fresh sync of testnet3 with these asserts patched on 0.16.0rc1 and the middle assert triggered
06:47 < morcos> last line in debug log
06:47 < morcos> 2018-02-01 14:40:00.528984 socket select error Bad file descriptor (9)
06:47 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
06:49 < cfields> BlueMatt: that seems like a really good candidate, yes. I went through it earlier this week already, but maybe i keep missing something
06:49 < morcos> here is the backtrace from that thread:
06:49 < morcos> https://0bin.net/paste/OmSDtVV-u0EwBaEp#Muh7dQfn6+kzip0Ib-b5brUozDZtCZblT1ev2lNtfdT
06:49 < wumpus> also going to test with those asserts
06:50 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has quit [Ping timeout: 265 seconds]     
06:50 < cfields> morcos: can you do a 'thread apply all bt' ?
06:50 < cfields> if it's a leak in something like 11363, it won't show up in a bt though :(
06:51 < cfields> though also, a leak should be obvious after a quick peek at /proc
06:51 < wumpus> would be nice if it was able to rewind the process to see what closed fd 9
06:52 < morcos> https://0bin.net/paste/FotU51A-Z98LdS0u#aWgxDyxhAn5L4XIex7Ko+kjMJ+qkAL0CJ77NubzV6io
06:52 < morcos> cfields: ^^
06:52 < cfields> thanks
06:52 < cfields> wumpus: i think 9 is EBADFD, not the fd#
06:52 < morcos> yeah i hope so, b/c it's always 9
06:53 < wumpus> cfields: oh, right it doesn't print the actual fd number
06:53 < provoostenator> http://termbin.com/h7jy
06:54 < provoostenator> "System error: CAutoFile::write: write failed: unspecified iostream_category error"
06:54 < provoostenator> It then happily processes a few more blocks and shuts down
06:54 < wumpus> so the buckshot hit CAutoFile's descriptor this time
06:55 < wumpus> this is so weird, looks like some evil background thread is randomly closing fds
06:55 < provoostenator> Unfortunately that took almost 20 minutes to crash, so this bisect will take a while, but probably worth it.
06:55 < cfields> maybe some callback isn't taking cs_main while touching block files?
06:56 < cfields> provoostenator: it'd be great if you could catch it in gdb
06:56 < cfields> that should allow a 'freeze' long enough to ld your fd's
06:56 < cfields> *ls     
06:56 < provoostenator> gdb?
06:56 < cfields> provoostenator: debugger
06:56 < wumpus> cfields: right, it could well be something else than net calls, I remember there is a PR that changes locking around block files
06:57 < provoostenator> Since morcos is able to reproduce, maybe it's easier if he looks at the debugger, while I just try to pinpoint which commit caused this.
06:58 < cfields> sure
06:58 < provoostenator> That should also provide more assurance that the fix actually fixes it.
06:58 < morcos> cfields: now i hit the first assert
06:58 < cfields> morcos: if it's some fd leak, it'd make sense that you'd get EBADFD randomly, all over the place
06:58 -!- mmgen [~mmgen@gateway/tor-sasl/mmgen] has joined #bitcoin-core-dev     
06:58 < cfields> morcos: any chance you can catch it in gdb?
06:59 < morcos> yeah, ok so if i run in gdb, then you want what, the list of what's in /proc/pid, or what
06:59 < cfields> yea     
06:59 < cfields> try to break on assert (might be _assert or __assert) in gdb, so it hangs before exit is called
07:02 -!- Giszmo [~leo@ip-251-237-219-201.nextelmovil.cl] has joined #bitcoin-core-dev     
07:03 < wumpus> cfields: maybe #11281 / ccd8ef65f93ed82a87cee634660bed3ac17d9eb5?
07:03 < gribble> https://github.com/bitcoin/bitcoin/issues/11281 | Avoid permanent cs_main/cs_wallet lock during RescanFromTime by jonasschnelli · Pull Request #11281 · bitcoin/bitcoin · GitHub
07:04 < morcos> it's on to me, it's not going to crash now
07:04 < wumpus> cfields: it changes locking around block file reading, at least
07:04 < cfields> morcos: heh, gdb tends to throw timings just enough so that everything works perfectly
07:04 -!- aruns__ [~indistylo@119.82.105.106] has quit [Ping timeout: 256 seconds]     
07:05 < cfields> wumpus: good find, taking a look
07:06 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
07:06 < cfields> morcos: wait, you said you hit the first one? that should be much more interesting
07:06 < cfields> i guess th core file is blown away already? :(
07:06 < wumpus> cfields: the one I was thinking of https://github.com/bitcoin/bitcoin/pull/11913 is not merged :)
07:07 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
07:07 < cfields> wumpus: ah, heh
07:07 < wumpus> no problems with testnet sync here w/ cfields's assertions
07:07 < morcos> cfield: no i saved it
07:07 < wumpus> (at least at block 319000)
07:08 < cfields> morcos: could you do a 'thread apply all bt' for that one?
07:08 < morcos> how do i easily output that to a file
07:09 < cfields> the send is more interesting because it may be an optimistic send. in that case, it'd be coming from the message handler thread rather than the sockethandler, so it might show a little more
07:09 < wumpus> gdb logging
07:09 < wumpus> morcos: https://sourceware.org/gdb/onlinedocs/gdb/Logging-Output.html
07:11 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Remote host closed the connection]     
07:12 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev     
07:15 < morcos> some serious user error there
07:15 < morcos> https://0bin.net/paste/43cNNOSrrPlIyVqt#BE1tyObep4Y9aLIpDDVC4kwVFJYxctxlhMJTE3xF08j
07:15 < cfields> thanks
07:15 < wumpus> "Hello. CloseSocket may be called with hSocket uninitialised, at net.cpp:448 (not confirmed to be the cause of this bug, but it seems likely)"
07:16 < wumpus> (https://github.com/bitcoin/bitcoin/issues/12323#issuecomment-362296158)
07:17 < cfields> I don't think it can be called unitialized?
07:18 < wumpus> closing an uninitialized fd would explain this perfectly, though
07:18 < wumpus> if you can reproduce this, maybe log all CloseSocket calls and see if it ends up with any funny data
07:18 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev     
07:18 < cfields> yes it would
07:19 < wumpus> (or at least those for which the close() fails, because we ignore closes return value right now)
07:19 < cfields> and it matches provoostenator's log as well
07:19 < wumpus> yep     
07:20 < cfields> oh wait, that's an else if(), not an else
07:20 < cfields> maybe that can happen
07:21 < morcos> yeah seems like you are missing a catch all else 
07:21 < cfields> looks like it'd happen as a result of a dns seed handing out a bad/local ip
07:22 < morcos> nice find by david60
07:22 < cfields> morcos: do you see dns queries before crashes in your logs?
07:22 < morcos> cfields: that would match my having it happen a lot when i noticed i was using dns seeds a lot
07:22 < morcos> i did previously, i don't know if i exclusively checked , but i had observed it was doing a lot of dns querying
07:23 < cfields> I'll pr a fix for that right now either way. Seems like a really good candidate, though
07:23 < cfields> ok     
07:23 < cfields> maybe you could force it by setting up a phony seed and returning only 127.0.0.1
07:24 < cfields> i think 2 phony entries in /etc/hosts would work
07:25 < morcos> 2?  any 2?  one ip4 and one ip6?
07:25 < provoostenator> That would be nice, in that case you can even write a test for it?
07:27 < cfields> morcos: 127.0.0.1 seed.bitcoin.sipa.be
07:27 < cfields> i think that should do it?
07:28 < morcos> i think i tried that, let me see what happened, it didn't crash yet
07:29 < provoostenator> I've never had a crash before or during headers sync, always during block downloads.
07:31 < cfields> morcos: ok, 127.0.0.1 would still pass IsValid, we'll have to use a more busted value
07:33 < morcos> i got it to crash again not sure if it was because of those entries or what
07:33 < morcos> in gdb
07:34 < bitcoin-git> [bitcoin] theuni opened pull request #12326: net: initialize socket to avoid closing random fd's (master...fix-socket-init) https://github.com/bitcoin/bitcoin/pull/12326
07:35 < cfields> morcos: dns query at the end of your log?
07:35 < morcos> https://0bin.net/paste/3T-vAUCXmHtlqJ9X#1UvKDgv7oZR4uZEEV0WqIGFDNdUQFTW3xFHkE0R-UOe
07:35 < gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
07:35 < provoostenator> gribble: lol
07:35 < cfields> morcos: ok, so you're not running through fd's. Closing a random one makes way more sense
07:35 < morcos> oh that was stupid, i changed the mainnet dns seeds but was running on testnet
07:36 < cfields> heh     
07:36 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
07:37 -!- Giszmo [~leo@ip-251-237-219-201.nextelmovil.cl] has quit [Quit: Leaving.]     
07:37 < cfields> morcos: try setting it to 0.0.0.0 instead. Not sure if the resolver will actually hand that out, though
07:37 -!- Aaronva__ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
07:37 < cfields> actually, if that's the case, I should be able to repro too instead of asking you to :p
07:37 < cfields> off to test
07:38 < morcos> cfields: ok yeah it did load dns seeds before this crash though
07:38 < wumpus> well it also depends on what is in the uninitialized memory
07:39 < morcos> btw, before i forget, it seemed that running in testnet was reading peers.dat from .bitcoin and not testnet3
07:39 < wumpus> if there happen to be zeroes there, or some value that is larger than max fd, it will go unniticed, it still doesn't have to trigger every time
07:39 < morcos> i deleted both of them to force dnsseeds
07:39 < cfields> wumpus: true, but an assert on a successfull close() should point it out quickly i should think
07:39 < cfields> wumpus: wouldn't anything other than -1 in memory cause a problem?
07:40 < wumpus> cfields: it might, though closing fd 0 (stdin) is harmless in our case
07:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]     
07:40 < cfields> hmm     
07:41 < wumpus> at least the first time. Once you close stdin, the next time you use open() you might get that fd, and if it then randomly gets closed again, it will still interfere. So, yeah. THe only harmless values would be very large ones that can't be a fd, ever.
07:41 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds]     
07:42 -!- Giszmo [~leo@ip-251-237-219-201.nextelmovil.cl] has joined #bitcoin-core-dev     
07:43 < cfields> makes sense
07:43 < cfields> morcos: fyi, there's -forcednsseed
07:45 -!- Aaronva__ [~AaronvanW@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer]     
07:46 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
07:46 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 248 seconds]     
07:46 -!- Giszmo [~leo@ip-251-237-219-201.nextelmovil.cl] has quit [Ping timeout: 240 seconds]     
07:47 < morcos> cfields: I added an assert in netbase.cpp CloseSocket that ret != error and I hit it
07:47 < cfields> morcos: great! can you print hSocket there ?
07:47 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 255 seconds]     
07:49 < morcos> 0?     
07:49 < morcos> looks like addrConnect is 0
07:49 < morcos> looks like this is all a test from provoostenator as its coming from his seed
07:50 < cfields> morcos: you didn't set yours in /etc/hosts ?
07:50 < provoostenator> Interesteing, is my testnet seed doing something funny?
07:50 < morcos> actually i'm not sure abou tthat, since i'm not familiar with this code
07:50 < morcos> 0x00005555555ed33a in CConnman::ConnectNode (this=this@entry=0x555556bc8530, addrConnect=..., pszDest=0x0, pszDest@entry=0x7fffac08c150 "seed.testnet.bitcoin.sprovoost.nl", fCountFailure=fCountFailure@entry=false) at net.cpp:448
07:51 < provoostenator> Mmm, it might actually be down. Let me check
07:51 < morcos> cfields i did make changes in /etc/hosts, but isn't seed.bitcoin.sipa.be a mainnet seed?
07:51 < cfields> morcos: yea, but you said you had all of em. didn't know what you set in there
07:51 < sdaftuar> i don't know if this is related, but i have a lot of lines like this in my debug.log: "trying connection seed.testnet.bitcoin.sprovoost.nl lastseen=0.0hrs"
07:52 < cfields> provoostenator: it's down for me...
07:52 < provoostenator> For me as well.
07:52 < cfields> but that should return 0 addresses and not try a connection. It shouldn't end up trying to connect to 0...
07:52 < provoostenator> I still need to setup monitoring.
07:52 < cfields> provoostenator: leave it down while we're testing :)
07:52 < morcos> here is the bt from that thread
07:52 < morcos> https://0bin.net/paste/X7-3MRaRJlLP8PoG#ApzQJmsY+N3H64RbQ-42PwxlbdJhXwpSvnx1BoINmZ+
07:52 < provoostenator> cfields: will do, just ping me when you want me to bring it back
07:53 < morcos> let me know if you want me to look at any particular value
07:55 < cfields> weird, i don't hit an assert there
07:55 < morcos> isn't it telling that in my /proc/pid/fd i didn't have a FD 0 in the earlier paste
07:55 -!- dcousens [~dcousens@101.188.228.91] has quit [Ping timeout: 240 seconds]     
07:55 < morcos> i also don't have one in this paste
07:55 -!- dcousens [~dcousens@101.188.185.250] has joined #bitcoin-core-dev     
07:55 < morcos> sorry not paste, example or whatever
07:55 < wumpus> morcos: that's very telling
07:55 -!- lnostdal [~lnostdal@gateway/tor-sasl/lnostdal] has quit [Remote host closed the connection]     
07:55 < cfields> morcos: very good point. that would explain the environment difference too
07:56 < morcos> didn't follow that last part
07:57 < cfields> morcos: if something about your OS/mem/etc. makes 0 a more likely value for you than everyone else
07:57 < provoostenator> My seed died with: https://0bin.net/paste/2bx9a3iijDdBgWXg#dlXDiXwy9dVkyvR0yuCyjzH4scHaL+6GHT-ll14wOrD
07:58 < sdaftuar> i just added an else {} clause in net.cpp (before the suspicious line 448), and it triggered for me on -testnet when running with -forcednsseeds
07:59 < morcos> huh, the fix didn't fix it?
08:00 < sdaftuar> wasn't running with the fix -- just verifying that hSocket could indeed be uninitialized 
08:00 < cfields> or are you saying that you've verified that you can hit the else branch?
08:00 < sdaftuar> ^ that
08:00 < cfields> ok, great
08:00 -!- checksauce [~checksauc@184.82.30.95] has joined #bitcoin-core-dev     
08:00 < cfields> morcos: have you been on testnet every time you've hit this?
08:01 < cfields> i realize that a mainnet seed could've been returning 0 as well, but that doesn't seem like it'd affect a mainnnet node that's been up for more than a few minutes
08:01 < cfields> but i guess that does jive with your complaints that we're querying the seeds too often
08:02 < cfields> heh, in fact, you would've been noticing that because there'd be an entry at the end of every log file
08:02 -!- helo_ is now known as helo     
08:02 < morcos> no all the prior times were mainnet
08:02 < provoostenator> Doesn't it pick a seed at random?
08:02 < morcos> but yes i was querying dns seeds occasionally
08:02 < morcos> i don't know what you mean about seing an etnry at the end of every log file
08:02 < provoostenator> Or does it ping them all? Because I didn't get crashes only 1 in ~5 times, I got them all the time, with a fresh datadir.
08:03 < morcos> the problem is if there is a dnsseed that is returning garbage somehow, it'll periodically retry it right?
08:03 < morcos> so if everytime it does that, it results in me close fd 0
08:03 < morcos> which at that point has been reused for soemthing else
08:03 < morcos> it'll cause an error 
08:03 -!- owowo [~ovovo@31.7.59.226] has joined #bitcoin-core-dev     
08:03 -!- owowo [~ovovo@31.7.59.226] has quit [Changing host]     
08:03 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev     
08:04 < morcos> but the socket errors aren't fatal, so its only the leveldb or blockwriting errors that cause a crash and show up at the end of the log
08:04 < morcos> but maybe thats what you're saying
08:04 < cfields> morcos: it only hits the seeds if we don't have enough peers
08:04 < cfields> it shouldn't keep retrying anything just because it failed
08:04 -!- Giszmo [~leo@ip-168-237-219-201.nextelmovil.cl] has joined #bitcoin-core-dev     
08:05 < cfields> wait, it might now!
08:06 < provoostenator> Should there be a functional test for dealing with broken DNS seeds?
08:06 < cfields> provoostenator: does your seed support filtering?
08:07 < cfields> it would make sense if a connection was tried because it was a oneshot()...
08:07 < morcos> cfields: it looked to me that it adds it to oneshot
08:07 < morcos> isn't that what it does with dnsseeds
08:07 < morcos> assuming you need them
08:07 < cfields> that's a new change, sec
08:08 < cfields> so we're not differentiating between a failed resolve, and a resolve with 0 results
08:08 < morcos> cfields: yeah can you look at line 390 in net.cpp
08:09 < morcos> i don't know what that does, but what happens if it fails
08:09 < cfields> #11512
08:09 < gribble> https://github.com/bitcoin/bitcoin/issues/11512 | Use GetDesireableServiceFlags in seeds, dnsseeds, fixing static seed adding by TheBlueMatt · Pull Request #11512 · bitcoin/bitcoin · GitHub
08:09 < morcos>         if (Lookup(pszDest, resolved,  default_port, fNameLookup && !HaveNameProxy(), 256) && !resolved.empty()) {
08:10 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
08:11 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Remote host closed the connection]     
08:13 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev     
08:14 < provoostenator> cfields: I use sipa's tool with the default settings, see my 0bin past above for full command
08:16 < cfields> morcos: ok, red herring. I see what's happening.
08:16 < cfields> it fails on the filtered resolve, so it does a oneshot for the unfiltered one. working as intended
08:17 < cfields> but they're both down, so you get a random socket
08:18 < cfields> wumpus: i'm more and more confident that this is the issue
08:19 < wumpus> cfields: great!
08:19 < cfields> and very sorry that i introduced it :(
08:19 < wumpus> means we can do rc2 soon
08:19 -!- CubicEarths [~cubiceart@ip253-210-159-186.ct.co.cr] has joined #bitcoin-core-dev     
08:19 < wumpus> heh no worries
08:20 < wumpus> happy if it's this and some problem deep in leveldb
08:20 < morcos> provoostenator is right though we should have a test for bad dns seed.
08:22 < cfields> we could add that to the travis cron job
08:22 < wumpus> I agree, would be somewhat tricky to spin up a fake dns server in the test framework though, though maybe python has something easy for that I don't know
08:22 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev     
08:23 < cfields> oh, i thought the concern was not knowing that dns seeds were down
08:23 < sdaftuar> i think the concern is making sure we handle it when they are?  or really both i guess...
08:24 < provoostenator> I'll keep the bisect going just in case. Leaving it running for 25 minutes until I "git bisect good" a commit, so it will take few hours. 
08:24 < cfields> 2018-02-01 16:23:47 Closing bad socket: 1266668816
08:24 < cfields> 2018-02-01 16:24:30 Closing bad socket: 100640016
08:24 < cfields> yep, that's it
08:29 -!- PaulCapestany [~PaulCapes@ip72-209-228-50.dc.dc.cox.net] has quit [Ping timeout: 256 seconds]     
08:29 -!- Giszmo [~leo@ip-168-237-219-201.nextelmovil.cl] has quit [Quit: Leaving.]     
08:32 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
08:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
08:37 -!- Krellan [~Krellan@2601:640:4000:9258:a969:a35a:344f:d6d1] has quit [Read error: Connection reset by peer]     
08:38 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds]     
08:39 -!- Krellan [~Krellan@2601:640:4000:9258:a969:a35a:344f:d6d1] has joined #bitcoin-core-dev     
08:39 < provoostenator> Mmm, if it's DNS related bisect might end up finding the PR where my seed was merged. Anyway, we'll see.
08:41 -!- Randolf [~randolf@96.53.47.42] has quit [Ping timeout: 248 seconds]     
08:42 -!- Giszmo [~leo@ip-168-237-219-201.nextelmovil.cl] has joined #bitcoin-core-dev     
08:43 -!- Giszmo [~leo@ip-168-237-219-201.nextelmovil.cl] has quit [Remote host closed the connection]     
08:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
08:44 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
08:45 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
08:46 -!- lnostdal [~lnostdal@gateway/tor-sasl/lnostdal] has joined #bitcoin-core-dev     
08:48 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
08:48 -!- CubicEarths [~cubiceart@ip253-210-159-186.ct.co.cr] has quit [Remote host closed the connection]     
08:50 -!- PaulCapestany [~PaulCapes@ip72-209-228-50.dc.dc.cox.net] has joined #bitcoin-core-dev     
08:51 -!- dund [~dundz@ip72-193-223-242.lv.lv.cox.net] has quit [Read error: Connection reset by peer]     
08:52 -!- dund [~dundz@ip72-193-223-242.lv.lv.cox.net] has joined #bitcoin-core-dev     
08:52 -!- LeMiner2 [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-core-dev     
08:53 -!- SevenTimes_ [~SevenTime@c-73-162-115-183.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
08:53 -!- rfree_irc [~rfree_irc@172.86.120.144] has quit [Ping timeout: 265 seconds]     
08:54 -!- SevenTimes_ [~SevenTime@c-73-162-115-183.hsd1.ca.comcast.net] has quit [Read error: Connection reset by peer]     
08:54 -!- LeMiner [LeMiner@unaffiliated/leminer] has quit [Ping timeout: 248 seconds]     
08:54 -!- LeMiner2 is now known as LeMiner     
08:55 -!- SevenTimes [~SevenTime@c-73-162-115-183.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
08:55 -!- rfree_irc [~rfree_irc@172.86.120.144] has joined #bitcoin-core-dev     
08:57 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev     
08:57 -!- SevenTimes__ [~SevenTime@c-73-162-115-183.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds]     
08:58 -!- SevenTimes_ [~SevenTime@c-73-162-115-183.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
09:00 < bitcoin-git> [bitcoin] promag opened pull request #12327: [gui] Defer coin control instancing (master...2018-02-fix-12312) https://github.com/bitcoin/bitcoin/pull/12327
09:01 -!- SevenTimes [~SevenTime@c-73-162-115-183.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]     
09:01 -!- checksau_ [~checksauc@184.82.31.240] has joined #bitcoin-core-dev     
09:02 -!- CubicEarths [~cubiceart@ip253-210-159-186.ct.co.cr] has joined #bitcoin-core-dev     
09:03 < instagibbs> promag, how come that error doesn't result in *all* qt coin control settings getting ignored?
09:03 -!- checksauce [~checksauc@184.82.30.95] has quit [Ping timeout: 252 seconds]     
09:04 < promag> instagibbs: I think the only affected are `change_type = g_change_type;` and `signalRbf = fWalletRbf;`
09:05 < promag> because these are set with argument
09:07  * instagibbs looking at how feerates are set
09:07 < promag> and CoinControlDialog::coinControl->SetNull() is only when the "Enable coin control features" is unchecked
09:08 < promag> instagibbs: yeah didn't look at that
09:08 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
09:09 -!- CubicEarths [~cubiceart@ip253-210-159-186.ct.co.cr] has quit [Ping timeout: 276 seconds]     
09:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
09:12 -!- aruns__ [~indistylo@27.59.7.205] has joined #bitcoin-core-dev     
09:12 < provoostenator> ^ created the above to track my bisect progress
09:12 < provoostenator> Well, below: #12328
09:12 < gribble> https://github.com/bitcoin/bitcoin/issues/12328 | Consistent crashes for v0.16.0rc1 · Issue #12328 · bitcoin/bitcoin · GitHub
09:14 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
09:14 -!- lnostdal [~lnostdal@gateway/tor-sasl/lnostdal] has quit [Remote host closed the connection]     
09:14 -!- lnostdal [~lnostdal@gateway/tor-sasl/lnostdal] has joined #bitcoin-core-dev     
09:15 < instagibbs> promag, your analysis looks correct, those two should be those effected
09:17 -!- SevenTimes__ [SevenTimes@gateway/vpn/privateinternetaccess/seventimes] has joined #bitcoin-core-dev     
09:17 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev     
09:18 -!- SevenTimes_ [~SevenTime@c-73-162-115-183.hsd1.ca.comcast.net] has quit [Ping timeout: 248 seconds]     
09:22 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
09:28 -!- lnostdal [~lnostdal@gateway/tor-sasl/lnostdal] has quit [Remote host closed the connection]     
09:28 -!- promag [~promag@188.140.98.81] has joined #bitcoin-core-dev     
09:29 -!- lnostdal [~lnostdal@gateway/tor-sasl/lnostdal] has joined #bitcoin-core-dev     
09:31 -!- Guest1780 [~schmidty@c-98-212-53-76.hsd1.il.comcast.net] has joined #bitcoin-core-dev     
09:39 -!- aruns__ [~indistylo@27.59.7.205] has quit [Ping timeout: 268 seconds]     
09:39 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
09:40 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
09:41 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-vwyihccktmddwpva] has joined #bitcoin-core-dev     
09:41 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 248 seconds]     
09:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
09:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
09:46 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
09:52 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 252 seconds]     
09:53 < provoostenator> Produced a crash using an older version: https://github.com/bitcoin/bitcoin/commit/16bac24f60fa3ae27cb2d9d89dfdd245694445d4
09:53 < provoostenator> Four more bisect steps to go
09:53 < provoostenator> Well, that's just 7 days ago...
09:54 < provoostenator> I added the log to the above issue.
09:54 < ProfMac> "should" the DNS discover use IPv4 when onlynet=IPv6?
09:54 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
09:55 -!- Randolf [~randolf@205.250.80.249] has joined #bitcoin-core-dev     
09:56 < wumpus> AFAIK there's no way in the libc API to do DNS resolving only over either IPv4 or IPv6
09:56 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 248 seconds]     
09:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
09:57 -!- PaulCapestany [~PaulCapes@ip72-209-228-50.dc.dc.cox.net] has quit [Ping timeout: 240 seconds]     
09:57 < wumpus> and as many modern linux distros run a DNS cache on localhost, on the IPv4 loopback, that'd effectively mean that DNS seeding cannot be used when onlynet=ipv6
09:58 -!- PaulCape_ [~PaulCapes@ip72-209-228-50.dc.dc.cox.net] has joined #bitcoin-core-dev     
09:59 -!- Guest1780 [~schmidty@c-98-212-53-76.hsd1.il.comcast.net] has quit [Remote host closed the connection]     
10:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]     
10:04 < wumpus> (hm, how many ISPs give out IPv6 DNS servers in the first place?)
10:06 < wumpus> probably only those that only give clients a IPv6 address
10:07 < wumpus> I don't know, it's an interesting though experiment, but I think in practice it's good that use of dns seeding or not is a separate optoin
10:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
10:18 -!- mandric [~mandric@24.1.62.93] has joined #bitcoin-core-dev     
10:20 -!- promag [~promag@188.140.98.81] has quit [Remote host closed the connection]     
10:21 < cfields> wumpus: you can kinda fudge it with AI_ADDRCONFIG, as we do
10:22 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/895fbd768f0c...84291d18dd69
10:22 < bitcoin-git> bitcoin/master 96dbd38 Cory Fields: net: initialize socket to avoid closing random fd's
10:22 < bitcoin-git> bitcoin/master 84291d1 Wladimir J. van der Laan: Merge #12326: net: initialize socket to avoid closing random fd's...
10:22 < cfields> oh, you mean the resolver itself
10:22 < bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.16: https://github.com/bitcoin/bitcoin/commit/e54c1ac110664efd58b7351139da55284f58f2ca
10:22 < bitcoin-git> bitcoin/0.16 e54c1ac Cory Fields: net: initialize socket to avoid closing random fd's...
10:23 < bitcoin-git> [bitcoin] laanwj closed pull request #12326: net: initialize socket to avoid closing random fd's (master...fix-socket-init) https://github.com/bitcoin/bitcoin/pull/12326
10:23 < cfields> wumpus: i think there's another issue there, introduced by (my suggestion in) 11512 
10:24 < wumpus> cfields: yes, I was assuming he meant the network used by the resolver itself, selecting only one kind of results sounds feasible
10:24 < cfields> I believe that failed resolves will end up forever connecting as oneshots, since failed oneshots get re-added
10:24 -!- aruns__ [~indistylo@27.59.7.205] has joined #bitcoin-core-dev     
10:24 < wumpus> whoops
10:25 < cfields> looking into it
10:31 -!- Krellan [~Krellan@2601:640:4000:9258:a969:a35a:344f:d6d1] has quit [Remote host closed the connection]     
10:37 -!- Krellan [~Krellan@2601:640:4000:9258:d827:8677:ea64:833] has joined #bitcoin-core-dev     
10:42 -!- Krellan [~Krellan@2601:640:4000:9258:d827:8677:ea64:833] has quit [Ping timeout: 276 seconds]     
10:48 < cfields> actually, anyone know why oneshots are re-added in the first place? https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp#L1685
10:49 < cfields> sipa maybe ?
10:49 < wumpus> I don't know, I woudln't have expected that either
10:49 < wumpus> if it's one-shot - if it fails, that was the shot
10:50 < cfields> right
10:50 < wumpus> I'm fairly sure I've used 'addnode ... onetry' in the past to probe if a certain node was up, not expecting it to try forever
10:51 < BlueMatt> cfields: if your network is done
10:51 < BlueMatt> or something like that
10:52 < BlueMatt> there was some pr that made things more robust if your net is down
10:52 < BlueMatt> maybe that is related?
10:52 < cfields> BlueMatt: wouldn't that same logic apply to everything, not just oneshots?
10:52 < BlueMatt> uhhhh, uhhhhh
10:52 < BlueMatt> ?     
10:53 -!- arbitrary_guy [~arbitrary@c-67-183-30-122.hsd1.wa.comcast.net] has joined #bitcoin-core-dev     
10:53 < wumpus> for non-oneshot connections I could understand it better
10:53 < wumpus> maybe the logic is the wrong way around?
10:54 < cfields> looks like it's been this way since they were introduced:  478b01d9a797f3ea
10:54 -!- jigawatt [2f2ae8cc@gateway/web/freenode/ip.47.42.232.204] has joined #bitcoin-core-dev     
10:56 < cfields> heh, when provoostenator gets his seed back up and running, he'll likely be DDoS'd like crazy
10:56 < wumpus> maybe it's been the wrong way around since the beginning, and no one ever reasoned this far
10:56 < wumpus> well at least there haven't been rc1 binaries, so the scale of DoS is likely limited :)
10:57 < cfields> heh     
10:59 < cfields> i'll go ahead and PR the removal, maybe someone will chime in with a valid reason otherwise
10:59 < wumpus> agreed
11:00 < wumpus> #startmeeting
11:00 < lightningbot> Meeting started Thu Feb  1 19:00:10 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
11:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:00 < provoostenator> hi     
11:00 < wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
11:00 < achow101> hi     
11:00 < jonasschnelli> hi     
11:00 < cfields> hi     
11:00 < sdaftuar> ack     
11:00 < jcorgan> hey folks
11:01 < meshcollider> hi     
11:01 < luke-jr> hi     
11:01 < BlueMatt> 0.16!
11:01 < meshcollider> \o/     
11:01 < wumpus> so with regard for 0.16.0 status, there already have been some issues that came up with rc1, so I think it makes sense to skip uploading binaries for that and go to rc2 soon
11:01 < BlueMatt> ack     
11:01 < achow101> what issues?
11:01 < cfields> agreed
11:01 < cfields> achow101: see backlog for the last ~3hrs
11:02 < wumpus> https://github.com/bitcoin/bitcoin/milestone/30
11:02 < wumpus> the serious issue is https://github.com/bitcoin/bitcoin/issues/12323
11:02 < achow101> ok     
11:03 < wumpus> there's another issue with onetry connections being re-tried forever, resulting in potential DoS on DNS seeds in the case they temporarily fail
11:03 < wumpus> cfields is working on a patch for that
11:03 < instagibbs> oh right, thursday
11:03 < wumpus> https://github.com/bitcoin/bitcoin/pull/12327 fixes a more minor issue with coin control and the change type setting
11:04 < wumpus> in the gui
11:04 < jonasschnelli> by the way, is it a policy that a DNS seed also runs a node (same ip) for the oneshot?
11:04 < wumpus> jonasschnelli: no, that's not necessary
11:04 < wumpus> jonasschnelli: it looks up the DNS seed which will return a (the first?) node
11:04 < jonasschnelli> wumpus: okay. My seeders will refuse connections to 8333
11:05 < jonasschnelli> wumpus: okay.
11:05 < wumpus> jonasschnelli: that is not the IP of the DNS server. I was confused about that too at some point in the past.
11:05 < jonasschnelli> I think also has something do to with tor mode
11:05 < provoostenator> Using A records is what makes it confusing
11:05 < cfields> yea, it's just some random peer
11:06 < BlueMatt> jonasschnelli: yes, you'd have to include your own ip in the dnsseed to (maybe) get the oneshot to be you, but that would be bad, and a violation of dnsseed policy (IIRC)
11:06 < jonasschnelli> BlueMatt: sure.
11:06 < wumpus> yes, in tor mode no resolving is used to get  multiple results (that'd require some SOCKS5 extension being used), so it uses a one shot to a random node as replacement
11:06 < jonasschnelli> But in tor only mode, don't we do a oneshot to the seeds?
11:06 < wumpus> no     
11:06 < provoostenator> BlueMatt: and an effective way to DDOS yourself
11:07 < jonasschnelli> wumpus: okay. Thanks... never looked that up properly 
11:07 < wumpus> it never looks up the IP of the DNS server at all, that's all happening below the libc abstraction
11:07 < wumpus> any topics?
11:09 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 276 seconds]     
11:10 < jonasschnelli> Everyone already back at work it seems
11:10 < wumpus> ok.. seems not... well please review anything under the 0.16.0 milestone, and anything added in the next day too
11:10 < sdaftuar> if we don't have more pressing things to discuss, i'd like to solicit feedback on #11739 (backdating p2sh /segwit v0 script rules) to genesis
11:10 < gribble> https://github.com/bitcoin/bitcoin/issues/11739 | Enforce SCRIPT_VERIFY_P2SH and SCRIPT_VERIFY_WITNESS from genesis by sdaftuar · Pull Request #11739 · bitcoin/bitcoin · GitHub
11:10 < wumpus> then we'll tag rc2 after that
11:10 < wumpus> and try to find the next round of bugs :)
11:10 < bitcoin-git> [bitcoin] theuni opened pull request #12329: net: don't retry failed oneshot connections forever (master...no-infinite-oneshot) https://github.com/bitcoin/bitcoin/pull/12329
11:10 < wumpus> sdaftuar: okay
11:11 < sdaftuar> mostly i want to know if there are any concept NACKs
11:11 < wumpus> #topic enforce SCRIPT_VERIFY_P2SH and SCRIPT_VERIFY_WITNESS from genesis (sdaftuar)
11:12 < sdaftuar> and i guess the other question is confirming whether/how such a change should be documented
11:12 < cfields> +0     
11:12 < cfields> sdaftuar: going forward, you mean? or this one?
11:12 < sdaftuar> both?
11:12 < sdaftuar> i drafted a BIP for this one
11:13 < cfields> well going forward, i think we could specify this intention as part of a soft-fork bip?
11:13 < wumpus> no NACK from me, if the code can be simplified that way then it's great
11:13 < BlueMatt> +1     
11:13 < wumpus> it doesn't change the rules enforced for current blocks, does it?
11:13 < wumpus> how is it a softfork?
11:13 < sdaftuar> no effect on current blocks
11:13 < wumpus> if it's a softfork I am misunderstanding
11:14 < BlueMatt> its a soft spoon - only prevents a 6-month reorg from removing segwit :p
11:14 < luke-jr> it restricts the rules on older blocks
11:14 < sdaftuar> it's a softfork under a technical definition
11:14 < BlueMatt> not a fork
11:14 < sdaftuar> of making valid things now invalid
11:14 < cfields> sorry, my fault.
11:14 < morcos> +1 as well..  but i do have concerns about how we could do this on a going forward basis
11:14 < wumpus> oh, right
11:14 < provoostenator> Or just Buried Deployment?
11:14 < wumpus> but it makes no difference bencause the old blocks all qualify
11:14 < luke-jr> the question comes down to, are we limiting soft/hardfork definitions to only ones that affect future blocks?
11:14 < morcos> it seems like if this is always our intention, then as soon as we announce a future soft fork
11:14 < morcos> some jack ass is going to mine violations just to make us annoyed
11:15 < BlueMatt> luke-jr: yes, we should start calling buried deployments spoons
11:15 < luke-jr> or do we consider this an implementation detail?
11:15 < cfields> morcos: true
11:15 < sdaftuar> morcos: i think it's not really worth worrying about that
11:15 < wumpus> I see this as an implementation detail to validation
11:15 < wumpus> there's no need to cause a lot of rufus about it
11:15 < wumpus> if you call it softfork you'll have the miners in arms, and whatnot
11:15 < cfields> luke-jr: well if there's an absolutely massive reorg, it's not just an implementation detail, no?
11:15 < morcos> well it addresses cfields point about having the original BIP specify the intention.  i think we should always only consider backdating after the fact
11:16 < sdaftuar> morcos: oh i see your point
11:16 < wumpus> because then it also needs to be signaled some way, I guess
11:16 < luke-jr> cfields: if there's an absolutely massive reorg, it's unclear what the outcome will be period
11:16 < luke-jr> cfields: for example, Knots has a checkpoint on a Segwit block
11:16 < cfields> well isn't the intention here to clarify that outcome?
11:16 < BlueMatt> if there's a 6 month reorg there will be debate as to whether to follow it...whether we follow it or not ends up being a community question anyway :p
11:16 < wumpus> if there's a reorg that big that all segwit blocks are reorged out, well...
11:16 < sdaftuar> i think in this case, it's clear that segwit transactors do not intend for their funds to be spendable on a segwit-inactive chain
11:17 < wumpus> yes, I'm sure there will be discussion enough in that case
11:17 < sdaftuar> so backdating the segwit rules matches consensus, in that sense
11:17 < BlueMatt> so, definitely not a fork
11:17 < wumpus> right
11:18 < luke-jr> in which case, I don't see that we need a BIP for it. I suggest we make a new repo for Core-specific documentation like this.
11:18 < cfields> morcos: i half agree about after-the-fact. Not mentioning backdating with the intention of doing so anyway is a bit... iffy
11:18 < luke-jr> BIPs are for cross-software standards, which doesn't really include implementation details
11:18 < BlueMatt> seems fine to me, I also appreciate gmaxwell's partially-joking suggestion of calling it a spoon
11:18 < wumpus> hehe
11:18 < luke-jr> (actually, we have a repo for gitian docs already, right?)
11:18 < sdaftuar> i personally think that it's helpful to put it in a BIP, because it affects the implementation of existing BIPs
11:18 < BlueMatt> and then doing a bip and just saying "Soft Spoon"
11:19 < sdaftuar> but i don't feel strongly
11:19 < BlueMatt> i mean we use BIPs for things that are core-specific anyway, like getblocktemplate
11:19 < wumpus> but in the end it doesn't matter whether people implement this BIP
11:19 < wumpus> because it's an implementation detail
11:19 < luke-jr> BlueMatt: GBT isn't Core-specific
11:19 < sdaftuar> wumpus: agreed
11:19 < sdaftuar> it's an informational BIP
11:19 < cfields> luke-jr: there are several post-mortem BIPs
11:19 < wumpus> BlueMatt: well that's an interface! interfaces need documentation
11:19 < kanzure> hi.     
11:20 < luke-jr> maybe we can put it in an annex for the BIPs it affects or something? just seems like it will get old to have two BIPs for every fork
11:20 < wumpus> if a softspoon drops at 300000 blocks deep and no one hears it, did it happen at all?
11:20 < luke-jr> one for the deployment and implementation, and another for the reinterpretation of the deployment
11:20 < sdaftuar> luke-jr: that seems reasonable to me as well, if the BIP authors agree?
11:22 < wumpus> luke-jr: agree
11:22 < luke-jr> none of the authors appear to be here now, but I doubt they'd object
11:22 < luke-jr> at least for Segwit
11:23 < provoostenator> And the winner of the git bisect game is....
11:23 < provoostenator> bluematt! https://github.com/bitcoin/bitcoin/commit/62e764219b25f5d5a4de855e53f62c43130ec918
11:23 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
11:23 < BlueMatt> we already decided it was cfields' fault
11:24 < sdaftuar> i knew it was both of you
11:24  * BlueMatt is gonna keep repeating that until someone buys it
11:24 < sdaftuar> :)     
11:24  * BlueMatt *definitely* didnt also review and ack the bug-introducing pr......
11:24 < cfields> heh it was me for sure
11:24 < cfields> the busted part of 62e7642 was even my suggestion!
11:25 < wumpus> it's everyone's fault for not finding the fault in review! :)
11:25 < sdaftuar> +1     
11:25 < cfields> well, sorry everyone. I'm glad it didn't make it into a release.
11:25 < luke-jr> I'm glad someone noticed it before a release XD
11:25 < wumpus> the rc process, it works
11:26 < cfields> yea, the surge of reports in the last ~day is actually really nice to see
11:26 < provoostenator> Bad linux skills on my part (causing the seed not to restart): it works
11:26 < sdaftuar> good thing it was down or we never would have found this before release! 
11:26 < sdaftuar> (which is very disturbing)
11:26 < wumpus> we do need tests for the DNS seed code
11:27 < meshcollider> clearly
11:27 < provoostenator> +1 for tests there
11:27 < cfields> agreed. I'll add some.
11:27 < BlueMatt> lol, maybe keep your dnsseed down until after rc cycle? :P
11:27 < wumpus> any other topics?
11:28 < cfields> or we could just add a dummy seednode to test.com or something :p
11:30 < wumpus> testing that code is not entirely trivial as-is as you somehow need to redirect DNS resolving
11:30 < wumpus> if no other topics, I'm closing the meeting early
11:30 < wumpus> #endmeeting
11:30 < lightningbot> Meeting ended Thu Feb  1 19:30:43 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
11:30 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-02-01-19.00.html
11:30 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-02-01-19.00.txt
11:30 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-02-01-19.00.log.html
11:30 < cfields> sgtm
11:30 < luke-jr> noooooooooooooooooo
11:30 < sdaftuar> ack     
11:30 < gmaxwell> damnit
11:31 < gmaxwell> missed the meeting by 30 seconds.
11:31 < luke-jr> lol     
11:31 < gmaxwell> Without reading the logs, can we apply the fixes for that fd issue and RC2 like lightning?
11:31 < sdaftuar> i believe that is the plan
11:31 < wumpus> yes, that is the plan
11:32 < gmaxwell> Good.
11:32 < wumpus> merge+backport #12323 and #12312 and tag rc2, and just skip executables for rc1
11:32 < gribble> https://github.com/bitcoin/bitcoin/issues/12323 | File descriptor problem, causing leveldb crash · Issue #12323 · bitcoin/bitcoin · GitHub
11:32 < gribble> https://github.com/bitcoin/bitcoin/issues/12312 | QT ignores -changetype=bech32 when coin control features are enabled · Issue #12312 · bitcoin/bitcoin · GitHub
11:33 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Quit: Leaving]     
11:34 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
11:34 < provoostenator> Meanwhile I'm checking if #12326 actually makes the crash go away now, as well as whether removing my seed from v0.16.0rc1 makes it go away (very likely yes).
11:34 < gribble> https://github.com/bitcoin/bitcoin/issues/12326 | net: initialize socket to avoid closing random fds by theuni · Pull Request #12326 · bitcoin/bitcoin · GitHub
11:34 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
11:35 < jcorgan> hey guys, just fyi, i've passed on the management/maintainer/architect roles in gnuradio to new hands (after 12 years), to focus on bitcoin-related work full-time. part of that will be getting back into core dev process. very much looking forward to the change of pace.
11:35 < gmaxwell> jcorgan: awesome!
11:35 < cfields> wumpus: and 12329 ?
11:36 < wumpus> jcorgan: congratulations!
11:36 < gmaxwell> (I mean, nooo sucks for gnuradio; and all my SDR projects)
11:36 < cfields> jcorgan: very cool. 12 years is a long time
11:37 < wumpus> cfields: huh I meant that one
11:37 < jcorgan> i think that's half over some people here's lifetime
11:37 < jcorgan> *of     
11:37 < wumpus> oh cool maybe I can go to gnu radio now
11:37 < sdaftuar> wait what
11:37 < cfields> jcorgan: you're Bitcoin Core maintainer now! congrats.
11:37 < achow101> jcorgan: more than half
11:38 < instagibbs> \o/     
11:39 < instagibbs> who here is best to bug about gitian? I'd hate to blow away my gitian directory yet again...
11:39 < sdaftuar> who is going to answer yes to that question
11:39 < instagibbs> someone who loves... pain
11:39 < achow101> instagibbs: probably cfields 
11:39  * cfields points at achow101
11:39 < sdaftuar> lol     
11:39 < cfields> instagibbs: what's the issue?
11:39  * instagibbs throws VM out the window
11:40 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
11:40 < instagibbs> ill DM, it's likely intractible
11:40 < wumpus> it's surprising in how many different ways gitian can fail
11:40 < cfields> this is going to be the least sexy slide into a DM ever...
11:40 < promag> o/ late..
11:41 < achow101> gitian is kinda outdated. it looks like its doing things that aren't really supported anymore
11:41 < jcorgan> anyway, carry on, i have to go fly a plane in the sky
11:41 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev     
11:42 < instagibbs> cfields, lol
11:42 < wumpus> lol indeed
11:43 -!- zautomata1 [~zautomata@unaffiliated/zautomata] has quit [Quit: WeeChat 1.9.1]     
11:43 < meshcollider> 0.16 crashes my gitian build too grr 0.15.1 was ok
11:43 < meshcollider> I probably need to upgrade something
11:43 < instagibbs> trying as far back as 0.14.1, not working
11:43 < wumpus> strange, nothing should have changed in that regard
11:43 < instagibbs> (something I know this VM did correctly once)
11:43 -!- zautomata [~zautomata@unaffiliated/zautomata] has joined #bitcoin-core-dev     
11:43 < wumpus> still uses the same version of ubuntu for buildling, still uses the same packages, etc
11:44 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
11:44 < achow101> I bet some package updated and that just broke everything
11:48 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Ping timeout: 248 seconds]     
11:50 -!- checksau_ [~checksauc@184.82.31.240] has quit [Remote host closed the connection]     
11:51 < instagibbs> cfields fixed my issue... was looking at my even older version of gitian that I had failed to rename to something sensible
11:53 < bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/84291d18dd69...41363fe11df5
11:53 < bitcoin-git> bitcoin/master 6558f8a João Barbosa: [gui] Defer coin control instancing...
11:53 < bitcoin-git> bitcoin/master 41363fe Jonas Schnelli: Merge #12327: [gui] Defer coin control instancing...
11:54 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
11:54 < bitcoin-git> [bitcoin] jonasschnelli closed pull request #12327: [gui] Defer coin control instancing (master...2018-02-fix-12312) https://github.com/bitcoin/bitcoin/pull/12327
11:55 -!- Randolf [~randolf@205.250.80.249] has quit [Ping timeout: 268 seconds]     
11:55 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
11:56 < gmaxwell> Would it be entirely crazy to make debug=1 not enable all debugging options, but a "many" option, that turns off absurdly chatty stuff (leveldb internals would be the one thing now).
11:56 < gmaxwell> ?     
11:56 < provoostenator> +1     
11:57 < gmaxwell> I don't think any of us have ever found the leveldb internals logging useful so far. And I know I always disable it and curse when I accidentally level it on.
11:57 < sdaftuar> that seems to be everyone's experience afaik
11:57 < gmaxwell> er leave it on.
11:58 < gmaxwell> I suppose I've learned a bit about how much background stuff leveldb does due to it. :)
11:58 -!- jamesob [~jamesob@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds]     
11:58 < wumpus> I don't like the chatty net logging either
11:58 < gmaxwell> At least I've found that stuff useful. I'd be okay with it off in debug=1 though I'd often turn it on.
11:58 < wumpus> which is why I opened #12219, I think we need a DEBUG..ERROR axis as well
11:59 < gribble> https://github.com/bitcoin/bitcoin/issues/12219 | More granular net logging · Issue #12219 · bitcoin/bitcoin · GitHub
11:59 < sdaftuar> yeah we should tackle that
11:59 < provoostenator> The flickering makes it hard to watch an IBD in real time.
11:59 < gmaxwell> or at least chatty net doesn't bother me so much since upgrading nodes to 1TB ssds...
11:59 < wumpus> apart from the category we also need a log level, that'd make logging things more sane without singling out specific categories
11:59 < wumpus> or splitting up categories
12:00 < wumpus> I think debug=1 should remain 'log everything possible', which doesn't rule out more selective logging options
12:00 < gmaxwell> I'd buy a debug vs error sort of axis though I'm doubtful about a really granular level, as people will irritatingly set them pretty subjectively.
12:01 -!- jamesob [~jamesob@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev     
12:01 < gmaxwell> or I suppose if we just had a debug=many or debug=most that would be fine too.  I seem to screw up debug=1 and then excluding for some reason.
12:01 < wumpus> or something like debug=1 debug=-leveldb
12:02 < gmaxwell> also having a single setting is more useful when I'm asking users to set things.
12:02 < wumpus> allowing categories to be disabled
12:02 < cfields> gmaxwell: agreed. -debug and -debug=all don't have to be the same thing
12:02 < gmaxwell> we have -debugexclude 
12:02 < wumpus> but yes it is subjective and dpeends on what you want to debug
12:02 < wumpus> which is why making a single selection for -debug=1 seems weird to me
12:03 < wumpus> some messages might be less interesting for what you're debugging, but that's why we have categories in the first place
12:03 < gmaxwell> Though also for some of this user stuff, I think it would be very useful to have a circular buffer in ram that always gets a MUCH higher debug level than what goes to disk (e.g. every debug option that isn't computationally expensive)
12:03 < gmaxwell> and on crashes we could make a best effort attempt to dump the circular buffer to a file in a crash handler.
12:04 < wumpus> debug=1 is super-overkill last resort for when you really don't know where to look
12:04 < wumpus> gmaxwell: yes, we need that too
12:04 < gmaxwell> wumpus: or when round trips are expensive. if I have a user reporting an issue I don't want to iterate on a bunch of options. I just want all the info that might be relevant, but the leveldb stuff is so far useless and very bloaty.
12:04 < promag> -debug-net -debug-foo (-debug enables all)?
12:05 < wumpus> we already have -debug=net -debug=foo
12:05 < gmaxwell> promag: you can already -debug=category to add categories and -debugexclude to remove them.
12:05 < wumpus> gmaxwell: still you need a selection of categories then
12:05 < promag> but you can't have levels right?
12:05 < gmaxwell> right now I tell users to debug=1 and debugexclude leveldb. 
12:06 < wumpus> gmaxwell: it's unlikely that you want debugging for ,say, torcontrol, even though that logging is extremely useful if you're debugging that
12:06 < gmaxwell> wumpus: tor control isn't that chatty however.
12:06 < gmaxwell> net is chatty but one of the most useful thing to log.
12:06 < wumpus> but it might become so, or another chatty category could be added
12:06 < wumpus> that's pretty subjective though
12:06 < wumpus> because you're interested in net
12:07 < gmaxwell> probably if I could grab a circular buffer with everything the question wrt support would go away.
12:07 < wumpus> currently I have the problem that I'm interested in high-level network stuff, e.g. incoming connections, outgoing connections, what clients are connecting, what are their IPs, when do they disconnect. I don't need to see every single packet.
12:08 < wumpus> but debug=net is way too chatty
12:08 < gmaxwell> I agree that net messages and net-activity should be split.
12:08 -!- Derrekito [~derrekito@98.29.141.81] has quit [Remote host closed the connection]     
12:08 < gmaxwell> I do frequently like net-activity for debugging because from that I can more or less trace the state that the node is in.
12:08 -!- mandric [~mandric@24.1.62.93] has quit [Quit: Quit]     
12:09 < wumpus> sure, I don't mwan that detailed net logging should go away or such
12:09 < wumpus> it certainly has good uses when you're debugging network things
12:09 < wumpus> in any case I think a log level would resolve some of these problems
12:09 < wumpus> 'I want to see all categories, but only at INFO levell, not DEBUG and below'
12:10 < wumpus> where DEBUG would be the chatty stuff
12:10 < promag> hence -debug-net=X
12:10 < gmaxwell> Please lets not make more than three levels though.
12:10 < wumpus> then if you want net DEBUG, you enable net debug
12:10 < wumpus> I agre,but let's not get into bikeshedding about the number of levels
12:10 -!- aruns__ [~indistylo@27.59.7.205] has quit [Ping timeout: 248 seconds]     
12:10 -!- CubicEarths [~cubiceart@ip59-200-50-179.ct.co.cr] has joined #bitcoin-core-dev     
12:10 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Ping timeout: 240 seconds]     
12:11 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 255 seconds]     
12:11 < gmaxwell> my concern there is if there are a dozen levels, people will argue over the levels, or worse not argue over them and set them randomly and then I'll just have to be debugging everything to avoid inexplicably missing log entries.
12:11 < wumpus> ERROR is clear, INFO/DEBUG can be set depend on chattiness
12:11 < wumpus> I don't think we need more
12:12 < gmaxwell> At least my expirence is that I usually want almost everything or nothing.  (basically, everything that isn't so chatty that it makes handling the logs a burden)
12:12 < gmaxwell> Yes, thats why I said three. I think three we can handle easily.
12:12 < gmaxwell> I guess one question is about "error", there are "peer violated the protocol" sorts of errors, and "omg our state is corrupted" sorts of errors.
12:13 < wumpus> ERROR would be potentially dangerous but not fatal errors, maybe WARNING is a better name
12:13 < wumpus> peer violated the protocol is INFO imo
12:13 < wumpus> it's not dangerous to us
12:13 < gmaxwell> We might want to adapt our language to call the first things "abnormal" (e.g. info level log, and the log text should not use the word error but perhaps use the word abnormal).
12:14 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
12:14 < wumpus> right
12:15 < provoostenator> I'm switching my testnet seed back on tomorrow unless something really surprising happens.
12:15 -!- checksauce [~checksauc@184.82.31.240] has joined #bitcoin-core-dev     
12:16 < provoostenator> Or I can do it in 20 minutes if we want rc1 complaints to stop coming in.
12:16 < wumpus> but anyhow, if you come up with a specific combination of categories that would be useful as single -debug= option, I wouldn't be against it
12:17 < wumpus> provoostenator: we should just tag r2
12:18 < provoostenator> I'll know in ~10 minutes whether todays fixex made my crash go away (fairly certain it did).
12:19 -!- CubicEarths [~cubiceart@ip59-200-50-179.ct.co.cr] has quit [Remote host closed the connection]     
12:20 < gmaxwell> wumpus: okay.  Well right now I think all minus leveldb internals is useful, at that seems like what a lot of us are using much of the time.
12:20 < wumpus> gmaxwell: I think it needs a better definition though, something like debug=lowtraffic
12:21 -!- CubicEarths [~cubiceart@ip59-200-50-179.ct.co.cr] has joined #bitcoin-core-dev     
12:21 < wumpus> not everythingbutleveldb lol
12:21 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
12:21 < wumpus> it also gives guidance for people to add or not categories to that in the future
12:22 < wumpus> or to remove categories once they become noisy
12:22 < gmaxwell> well net is high traffic but useful, leveldb is high traffic but so far I've not found it useful.
12:22 < wumpus> but what is the rationale of the combination then?
12:22 < gmaxwell> omit useless chatty things.
12:23 -!- CubicEarths [~cubiceart@ip59-200-50-179.ct.co.cr] has quit [Remote host closed the connection]     
12:23 < wumpus> let's kill leveldb logging completely if it's so useless
12:23 -!- CubicEarths [~cubiceart@ip59-200-50-179.ct.co.cr] has joined #bitcoin-core-dev     
12:24 -!- checksauce [~checksauc@184.82.31.240] has quit [Remote host closed the connection]     
12:24 < wumpus> libevent too, probably
12:24 < meshcollider> it seems my gitian issue lies when it is trying to download zeromq-4.2.2.tar.gz for bitcoincore.org/depends-sources
12:24 < wumpus> it can be even more hilariously useless
12:24 < gmaxwell> It's at least of conjectural use e.g. if we were chasing some leveldb internal bug. 
12:25 < wumpus> oh sure it can be useful, esp when adding custom debugging to leveldb to troubleshoot some issue
12:25 < wumpus> that's why a bridge exists
12:25 < cfields> meshcollider: you probably had all other sources already and your lxc is failing to make any net connections
12:25 < gmaxwell> I mean we could also leave the code for the bridge there but remove the logging level.
12:25 < meshcollider> cfields: that's true, was the version of zeromq bumped for 0.16
12:26 < cfields> believe so
12:26 < cfields> yes, it was
12:26 < gmaxwell> I opened the conversation basically with the idea of having leveldb (and maybe later other things) being log categories you never get unless you explicitly ask for them.
12:26 < gmaxwell> maybe libevent would fall into that too.
12:27 < gmaxwell> I've noticed it being useless too but just never had it be chatty enough to bother me.
12:27 < wumpus> so I still think =lowtraffic makes sense
12:27 < gmaxwell> I suppose we could lowtraffic then turn back on net-messages.
12:28 < gmaxwell> (I mean to achieve my normal desired logging config which is basically low traffic things plus net messages)
12:28 < wumpus> we should just include net int hat
12:28 < gmaxwell> I'm imagining net divided into per-message logging and the rest (e.g. connections)
12:28 < wumpus> with the future remark that if there is a low-traffic net category, that should be in instead
12:28 < gmaxwell> right
12:28 -!- CubicEar_ [~cubiceart@201.191.198.99] has joined #bitcoin-core-dev     
12:29 < meshcollider> cfields: yep you're right, it works fine if I make the depends directory beforehand, the new zeromq downloaded successfully 
12:29 < cfields> great
12:29 < meshcollider> cfields: thanks :)
12:29 < cfields> np     
12:30 < gmaxwell> Another thing to think about is the performance impacts of logging, some of our logs cause computation that is probably pretty bad for performance.
12:32 -!- CubicEarths [~cubiceart@ip59-200-50-179.ct.co.cr] has quit [Ping timeout: 276 seconds]     
12:32 < wumpus> I think that's true for libevent and leveldb logging too, they require a special enabling flag, which causes those libraries to send the messages at all
12:33 < wumpus> gmaxwell: that'd only be problematic for high-volume messages, I'm sure e.g. computing the BENCH messages takes some cycles, but they only happen once per block
12:34 < wumpus> and in the total validation tme that's probably neglible
12:34 < gmaxwell> The leveldb stuff looks kind of expensive.
12:34 < wumpus> I don't think we have low-traffic messages that take significant computation
12:35 < gmaxwell> And I recall that there were some moderate traffic messages that did stuff like an extra iteration over all inputs in transactions or something.
12:35 < wumpus> for high traffic, yes, I woudln't be surprised if the net logging slowed some things down
12:35 < wumpus> if you have to write a message for every incoming packet to a file, it becomes disk bound
12:35 -!- CubicEarths [~cubiceart@ip59-200-50-179.ct.co.cr] has joined #bitcoin-core-dev     
12:36 < wumpus> oh I didn't know that
12:38 -!- mandric [~mandric@24.1.62.93] has joined #bitcoin-core-dev     
12:39 < zelest> sorry for asking in here, but I did some quick googling and it seems like OneFixt is known in here? May I ask who he/she is? :o
12:39 -!- CubicEar_ [~cubiceart@201.191.198.99] has quit [Ping timeout: 268 seconds]     
12:40 < wumpus> can we have some review on #12329 please, I'd like to tag rc2 before I go to bed
12:40 < gribble> https://github.com/bitcoin/bitcoin/issues/12329 | net: dont retry failed oneshot connections forever by theuni · Pull Request #12329 · bitcoin/bitcoin · GitHub
12:41 -!- CubicEarths [~cubiceart@ip59-200-50-179.ct.co.cr] has quit [Remote host closed the connection]     
12:46 -!- mmgen [~mmgen@gateway/tor-sasl/mmgen] has quit [Quit: (https://github.com/mmgen) leaving]     
12:47 -!- propumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-core-dev     
12:48 -!- contrapumpkin [~copumpkin@haskell/developer/copumpkin] has quit [Ping timeout: 256 seconds]     
12:49 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
12:50 -!- propumpkin is now known as contrapumpkin     
12:50 < wumpus> and that's the last one
12:52 -!- PaulCape_ [~PaulCapes@ip72-209-228-50.dc.dc.cox.net] has quit [Read error: Connection reset by peer]     
12:53 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]     
12:53 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
12:55 -!- PaulCapestany [~PaulCapes@ip72-209-228-50.dc.dc.cox.net] has joined #bitcoin-core-dev     
13:01 -!- PaulCapestany [~PaulCapes@ip72-209-228-50.dc.dc.cox.net] has quit [Read error: Connection reset by peer]     
13:03 -!- PaulCape_ [~PaulCapes@ip72-209-228-50.dc.dc.cox.net] has joined #bitcoin-core-dev     
13:07 -!- ProfMac [~ProfMac@2001:470:b8ac:0:2d41:4b66:5eef:a6cf] has quit [Ping timeout: 240 seconds]     
13:09 -!- ProfMac [~ProfMac@2001:470:b8ac:0:1d9e:c0d0:e3bb:5604] has joined #bitcoin-core-dev     
13:09 -!- PaulCape_ [~PaulCapes@ip72-209-228-50.dc.dc.cox.net] has quit [Ping timeout: 256 seconds]     
13:11 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
13:14 -!- ProfMac [~ProfMac@2001:470:b8ac:0:1d9e:c0d0:e3bb:5604] has quit [Ping timeout: 265 seconds]     
13:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 248 seconds]     
13:17 -!- PaulCapestany [~PaulCapes@ip72-209-228-50.dc.dc.cox.net] has joined #bitcoin-core-dev     
13:29 -!- deeDd [b99f9c13@gateway/web/freenode/ip.185.159.156.19] has joined #bitcoin-core-dev     
13:33 -!- ProfMac [~ProfMac@67-198-113-220.static.grandenetworks.net] has joined #bitcoin-core-dev     
13:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
13:36 -!- Aaronva__ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
13:39 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 265 seconds]     
13:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds]     
13:43 -!- pgupta [~pgupta@193.60.220.253] has joined #bitcoin-core-dev     
13:51 -!- sipa [~pw@2001:19f0:ac01:2fb:5400:ff:fe5b:c3ff] has joined #bitcoin-core-dev     
13:51 < sipa> oops, seems i accidentally left this channel and forgot about the meeting as well
13:53 -!- mandric [~mandric@24.1.62.93] has quit [Quit: Computer has gone to sleep.]     
13:58 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 276 seconds]     
14:00 -!- jamesob [~jamesob@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Ping timeout: 264 seconds]     
14:03 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has quit [Ping timeout: 260 seconds]     
14:13 < luke-jr> sipa: there was discussion of how to handle Segwit-back-to-the-start type stuff, and I thought perhaps it would be better as an annex to the Segwit BIP(s) rather than an entirely new BIP (making 2 BIPs for each fork); would you be okay with that, as an author of the BIP in question?
14:16 < gmaxwell> and then you're gonna add (hardfork) to the segwit bips and collect your cheque from Ver? :P
14:17 < jnewbery> re logging - we already have an alias -debug=all which aliases to -debug=1 (~0). Doesn't seem like to much of a stretch to add a new alias debug=gmax* which aliases to all the categories that greg wants to see (*name TBD)
14:17 -!- keks_ [5b4055c9@gateway/web/freenode/ip.91.64.85.201] has quit [Ping timeout: 260 seconds]     
14:18 < jnewbery> perhaps -debug=standard , -debug=default, -debug=...
14:18 < jnewbery> I also agree that logging should log to a circular buffer in memory and then have a background thread flushing to disk. I bet there are plenty of places where we're logging to disk while holding cs_main for example
14:21 < jnewbery> (in fact I started implementing that a few months ago, but never finished)
14:22 < gmaxwell> I'd like to get to a state where our logs by default can log virutally nothing, and on fault we can dump a good amount of context.
14:24 < gmaxwell> this also would address a lot of privacy concerns, where we avoid logging detailed data that would make node logs attractive for trying to trace transactions.
14:24 < luke-jr> gmaxwell: as an annex, it's clearer to consider it an implementation detail ;)
14:24 < luke-jr> ie, "you can tighten the rules using method A or method B, and the outcome is the same"
14:42 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev     
14:51 -!- pgupta [~pgupta@193.60.220.253] has quit [Remote host closed the connection]     
14:57 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]     
15:01 -!- bule [~bule@gateway/tor-sasl/bule] has joined #bitcoin-core-dev     
15:02 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Ping timeout: 268 seconds]     
15:04 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Quit: intcat]     
15:05 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
15:10 -!- larafale [~larafale@ax213-1-82-66-157-194.fbx.proxad.net] has quit [Remote host closed the connection]     
15:11 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
15:11 -!- larafale [~larafale@ax213-1-82-66-157-194.fbx.proxad.net] has joined #bitcoin-core-dev     
15:13 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has joined #bitcoin-core-dev     
15:14 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has joined #bitcoin-core-dev     
15:14 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.]     
15:15 -!- larafale [~larafale@ax213-1-82-66-157-194.fbx.proxad.net] has quit [Ping timeout: 240 seconds]     
15:20 -!- ProfMac [~ProfMac@67-198-113-220.static.grandenetworks.net] has quit [Ping timeout: 256 seconds]     
15:26 -!- Aaronva__ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds]     
15:26 -!- MTennis [~Tennis@unaffiliated/tennis] has joined #bitcoin-core-dev     
15:29 -!- MTennis [~Tennis@unaffiliated/tennis] has quit [Client Quit]     
15:35 -!- Dizzle [~dizzle@108.171.182.16] has quit [Remote host closed the connection]     
15:40 -!- deeDd [b99f9c13@gateway/web/freenode/ip.185.159.156.19] has quit [Quit: Page closed]     
15:52 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev     
15:59 -!- vicenteH [~user@35.233.15.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]     
16:14 -!- CubicEarths [~cubiceart@201.191.198.61] has joined #bitcoin-core-dev     
16:18 -!- CubicEarths [~cubiceart@201.191.198.61] has quit [Read error: Connection reset by peer]     
16:19 -!- CubicEarths [~cubiceart@201.191.254.210] has joined #bitcoin-core-dev     
16:21 -!- CubicEarths [~cubiceart@201.191.254.210] has quit [Remote host closed the connection]     
16:26 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Quit: Leaving...]     
16:29 -!- CubicEarths [~cubiceart@201.191.254.210] has joined #bitcoin-core-dev     
16:37 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
16:47 -!- wxss [~user@95.143.195.106] has quit [Quit: leaving]     
16:48 -!- CubicEarths [~cubiceart@201.191.254.210] has quit [Read error: Connection reset by peer]     
16:58 < meshcollider> wumpus: I think I've finished off the release notes
16:58 < meshcollider> If others could double check I haven't made any stupid mistakes or left anything out that'd be good
16:58 < meshcollider> https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.16.0-Release-notes
17:01 < sipa> meshcollider: address_type is also added to getnewaddress
17:01 < meshcollider> sipa: but that RPC is deprecated now so should we even bother adding that?
17:02 < sipa> what?
17:02 < meshcollider> oh sorry I misread and thought you said addwitnessaddress
17:02 < sipa> you're confusing getnewaddress with addwitnessaddress, i think?
17:02 < meshcollider> yeah
17:03 < sipa> also, with the inclusion of scripts in dump/import, i think those RPCs may just work fine
17:04 < meshcollider> sipa: true, we should test it properly first before claiming though IMO?
17:04 -!- Dizzle [~dizzle@108.171.182.16] has quit [Quit: Leaving...]     
17:04 < sipa> meshcollider: yes, absolutely
17:04 < sipa> but i think there's a good chance it just works now
17:04 < meshcollider> Oh I'll just remove mention of those RPCs altogether for now rather than saying they are or are not supported
17:05 < sipa> sign/verify and importmulti definitely don't support segwit addresses
17:06 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
17:08 < promag> s/segwit/SegWit ?
17:09 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev     
17:09 < promag> or who cares?
17:09 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev     
17:12 < promag> #low-level-rpc-changes should mention fundrawtransaction change type and addmultisigaddress address type ?
17:13 < sipa> meshcollider: validateaddress has had many changes
17:13 < meshcollider> promag: you can change them all if you want :)
17:13 < sipa> just mentioning it now in case someone wants to do a writeup
17:14 < sipa> if not, i'll do so in a few days
17:14 < meshcollider> promag: I added them to the segwit sections rather than the low level RPC changes, IMO no point duplicating the info as long as its in a logical place
17:15 < promag> ok cool
17:15 < meshcollider> sipa: what kind of changes, andrews PR hasnt been merged yet has it
17:15 < meshcollider> I must have missed something
17:15 < sipa> meshcollider: included in 11403
17:16 < sipa> commit 3eaa003c8
17:16 < fanquake> In the SHA256 ASM section. s/has/have s/this was/they were s/but is/but are and remove "is no" .
17:17 < fanquake> Can we get conflicts when editing the wiki? I don't want to touch it in case I mess up your good work.
17:17 < sipa> meshcollider: specifically, there are new "embedded" and "pubkeys" fields that apply to non-segwit as well
17:18 < meshcollider> fanquake: I guess there might be conflicts if we edited the same part but I'm not currently editing so it should be ok
17:18 < meshcollider> sipa: ooh ok I missed those, will add then
17:19 < sipa> also, validateaddress has new functionality related to P2SH-P2WPKH, so that doesn't fit under BIP173 support
17:23 < promag> do we have any idea what are the top 5 of most called RPC 
17:27 < gmaxwell> it's very different for different users.
17:27 < gmaxwell> getblocktemplate and listtransactions are probably the most common rpcs (for miners, and people getting payments, respectively)
17:28 < gmaxwell> and then other than a few status things, I'd expect everything else to be basically insubstantial compared to those.
17:28 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
17:31 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
17:32 -!- acehighwind [403cb06e@gateway/web/freenode/ip.64.60.176.110] has joined #bitcoin-core-dev     
17:37 -!- jamesob [~jamesob@pool-71-183-54-211.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
17:38 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
17:38 < promag> gmaxwell: listunspent?
17:39 -!- unholymachine [~quassel@2601:8c:c003:9f16:98a:ee0d:32e9:a426] has quit [Remote host closed the connection]     
17:39 < gmaxwell> I wouldn't expect listunspent to be called more than sendrawtransaction, which would be rare since we know that network wide there is only a certian amount of that.
17:39 -!- unholymachine [~quassel@2601:8c:c003:9f16:7c51:bf1f:a30a:a954] has joined #bitcoin-core-dev     
17:40 -!- bule [~bule@gateway/tor-sasl/bule] has quit [Ping timeout: 255 seconds]     
17:46 < promag> ok ty
17:52 -!- acehighwind [403cb06e@gateway/web/freenode/ip.64.60.176.110] has quit [Ping timeout: 260 seconds]     
18:02 < promag> gmaxwell: does this make sense https://github.com/promag/bitcoin/commit/c409b1adac59329b78b8c48f131f8ca032988412 ?
18:04 < gmaxwell> I don't think so-- at least if I understand it correctly. listtransactions should be atomic with the blockchain. If the chain reorgs you shouldn't get mixed data on transactions. An example of how this could result in funds loss, say I pay you with a transaction then doublespend it to pay more fees with another txn also paying you.  If you see a reorg that goes from one to the other during a lis
18:04 < gmaxwell> ttransactions, they you might see both payments as confirmed and credit the user twice.
18:07 < promag> gmaxwell: it's still atomic
18:07 < promag> sorting the output is done without the locks
18:08 < gmaxwell> hm? is it copying all the data then? otherwise confirm counts and whatnot would get updated, no?
18:09 < promag> i think so, AcentryToJSON
18:09 < gmaxwell> oh I see how I was misreading it.
18:10 < gmaxwell> okay thats plausable
18:10 < promag> I guess this is easy to bench
18:12 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 255 seconds]     
18:13 < bitcoin-git> [bitcoin] promag opened pull request #12330: Reduce scope of cs_main and cs_wallet locks in listtransactions (master...2018-02-listtransactions) https://github.com/bitcoin/bitcoin/pull/12330
18:13 -!- tknp [~tknp@unaffiliated/tknp] has joined #bitcoin-core-dev     
18:14 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
18:15 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev     
18:21 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
18:22 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has quit [Quit: Leaving.]     
18:26 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]     
18:27 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev     
18:27 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
18:31 -!- veleiro [~sleeper@fsf/member/veleiro] has joined #bitcoin-core-dev     
18:36 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.]     
18:40 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has joined #bitcoin-core-dev     
18:42 -!- goatpig [56f75164@gateway/web/freenode/ip.86.247.81.100] has quit [Quit: Page closed]     
18:49 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has quit [Remote host closed the connection]     
18:55 -!- jamesob [~jamesob@pool-71-183-54-211.nycmny.fios.verizon.net] has quit [Ping timeout: 260 seconds]     
18:58 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
19:03 -!- mandric [~mandric@108-228-58-104.lightspeed.cicril.sbcglobal.net] has joined #bitcoin-core-dev     
19:04 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has joined #bitcoin-core-dev     
19:05 -!- instagibbs [~instagibb@pool-100-15-116-35.washdc.fios.verizon.net] has quit [Ping timeout: 246 seconds]     
19:05 -!- instagibbs [~instagibb@pool-100-15-116-35.washdc.fios.verizon.net] has joined #bitcoin-core-dev     
19:08 -!- Franklin_ [47eaa5df@gateway/web/freenode/ip.71.234.165.223] has joined #bitcoin-core-dev     
19:11 -!- punch [~punch@8.12.28.87] has quit [Ping timeout: 240 seconds]     
19:12 -!- DrFeelGood [~DrFeelGoo@unaffiliated/olufunmilayo] has joined #bitcoin-core-dev     
19:21 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Ping timeout: 240 seconds]     
19:25 -!- mandric [~mandric@108-228-58-104.lightspeed.cicril.sbcglobal.net] has quit [Quit: Computer has gone to sleep.]     
19:28 -!- quer [~quer@ip-95-222-42-15.hsi15.unitymediagroup.de] has joined #bitcoin-core-dev     
19:35 -!- quer [~quer@ip-95-222-42-15.hsi15.unitymediagroup.de] has quit []     
19:38 -!- bule [~bule@gateway/tor-sasl/bule] has joined #bitcoin-core-dev     
19:46 < Franklin_> does anyone have examples of cross chain atomic swap script(s) for onchain swaps?
19:49 -!- quer [~quer@ip-95-222-42-15.hsi15.unitymediagroup.de] has joined #bitcoin-core-dev     
19:58 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev     
20:03 -!- quer [~quer@ip-95-222-42-15.hsi15.unitymediagroup.de] has quit []     
20:03 -!- quer [~quer@ip-95-222-42-15.hsi15.unitymediagroup.de] has joined #bitcoin-core-dev     
20:12 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 255 seconds]     
20:13 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev     
20:15 < dafuq> could someone who knows unix/linux possibly chime in on PR #12322?
20:15 < gribble> https://github.com/bitcoin/bitcoin/issues/12322 | Docs: Remove step making cloned repository world-writable for Windows build. by murrayn · Pull Request #12322 · bitcoin/bitcoin · GitHub
20:17 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
20:22 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Quit: Leaving]     
20:23 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev     
20:24 -!- quer [~quer@ip-95-222-42-15.hsi15.unitymediagroup.de] has quit [Changing host]     
20:24 -!- quer [~quer@unaffiliated/quer] has joined #bitcoin-core-dev     
20:24 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Client Quit]     
20:27 -!- Aliencorpse [~Aliencorp@2605:a601:b024:600:2406:738d:9065:9a84] has joined #bitcoin-core-dev     
20:28 -!- quer [~quer@unaffiliated/quer] has quit []     
20:30 -!- instagibbs [~instagibb@pool-100-15-116-35.washdc.fios.verizon.net] has quit [Ping timeout: 240 seconds]     
20:31 -!- quer [~quer@unaffiliated/quer] has joined #bitcoin-core-dev     
20:32 -!- instagibbs [~instagibb@pool-100-15-116-35.washdc.fios.verizon.net] has joined #bitcoin-core-dev     
20:36 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has quit [Ping timeout: 240 seconds]     
20:41 -!- justan0theruser is now known as justanotheruser     
21:00 -!- tknp [~tknp@unaffiliated/tknp] has quit [Quit: tknp]     
21:23 -!- checksauce [~checksauc@184.82.31.240] has joined #bitcoin-core-dev     
21:26 -!- checksauce [~checksauc@184.82.31.240] has quit [Read error: Connection reset by peer]     
21:29 -!- checksau_ [~checksauc@s91904424.blix.com] has joined #bitcoin-core-dev     
21:42 -!- g00d_N1ght_ [~Z@r49-2-155-48.cpe.vividwireless.net.au] has joined #bitcoin-core-dev     
21:45 < gmaxwell> wumpus: I think the FD issue is likely fixed.  I ran RC1 in valgrind and after a few minutes of running had a branch on uninitilized in socket close.
21:45 < gmaxwell> I pulled up to master, compiled, restarted, and now hours later no such error.
21:46 < gmaxwell> As suspected, an uninitilied close was closing random FDs.
21:47 -!- g00d_N1ght_ [~Z@r49-2-155-48.cpe.vividwireless.net.au] has quit [Quit: Leaving]     
21:48 -!- aruns__ [~indistylo@27.59.7.205] has joined #bitcoin-core-dev     
21:49 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has quit [Quit: Leaving]     
21:50 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
21:53 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 256 seconds]     
22:08 -!- veleiro [~sleeper@fsf/member/veleiro] has quit [Quit: Leaving.]     
22:11 < meshcollider> That's good \o/
22:21 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has joined #bitcoin-core-dev     
22:25 -!- bule [~bule@gateway/tor-sasl/bule] has quit [Ping timeout: 255 seconds]     
22:26 -!- checksauce [~checksauc@184.82.31.240] has joined #bitcoin-core-dev     
22:28 -!- flokie [~flokie@unaffiliated/flokie] has quit [Read error: Connection reset by peer]     
22:29 -!- checksau_ [~checksauc@s91904424.blix.com] has quit [Ping timeout: 276 seconds]     
22:40 -!- Franklin_ [47eaa5df@gateway/web/freenode/ip.71.234.165.223] has quit [Ping timeout: 260 seconds]     
22:52 -!- aruns__ [~indistylo@27.59.7.205] has quit [Remote host closed the connection]     
22:54 -!- aruns__ [~indistylo@27.59.7.205] has joined #bitcoin-core-dev     
22:54 -!- aruns__ [~indistylo@27.59.7.205] has quit [Remote host closed the connection]     
23:29 -!- veleiro [~sleeper@fsf/member/veleiro] has joined #bitcoin-core-dev     
23:34 -!- veleiro [~sleeper@fsf/member/veleiro] has quit [Ping timeout: 256 seconds]     
23:41 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 248 seconds]     
23:43 < bitcoin-git> [bitcoin] murrayn opened pull request #12331: Docs: Properly alphabetize output of CLI --help option. (master...help_changes) https://github.com/bitcoin/bitcoin/pull/12331
23:45 -!- justan0theruser is now known as justanotheruser     
23:47 -!- veleiro [~sleeper@fsf/member/veleiro] has joined #bitcoin-core-dev     
23:54 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev     
23:55 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
23:57 -!- veleiro [~sleeper@fsf/member/veleiro] has left #bitcoin-core-dev []