12018-02-01T00:02:18 *** Evel-Knievel has quit IRC
22018-02-01T00:05:40 <GitHub131> [bitcoin-detached-sigs] jonasschnelli opened pull request #1: 0.16: osx signatures for 0.16.0rc1 (0.16...0.16) https://github.com/bitcoin-core/bitcoin-detached-sigs/pull/1
32018-02-01T00:16:09 *** cloaks has joined #bitcoin-core-dev
42018-02-01T00:16:33 *** moctost has quit IRC
52018-02-01T00:18:24 *** wampum has joined #bitcoin-core-dev
62018-02-01T00:29:04 *** Victorsueca has quit IRC
72018-02-01T00:30:25 *** Victorsueca has joined #bitcoin-core-dev
82018-02-01T00:44:35 *** hirish has quit IRC
92018-02-01T00:45:01 *** hirish has joined #bitcoin-core-dev
102018-02-01T00:50:41 *** dund has quit IRC
112018-02-01T00:50:59 *** dund has joined #bitcoin-core-dev
122018-02-01T00:54:04 *** dafuq[m] has quit IRC
132018-02-01T01:00:22 *** AaronvanW has joined #bitcoin-core-dev
142018-02-01T01:05:41 *** AaronvanW has quit IRC
152018-02-01T01:06:41 *** dcousens has quit IRC
162018-02-01T01:07:11 *** dcousens has joined #bitcoin-core-dev
172018-02-01T01:09:02 *** dabura667 has joined #bitcoin-core-dev
182018-02-01T01:16:45 <GitHub8> [bitcoin-detached-sigs] theuni closed pull request #1: 0.16: osx signatures for 0.16.0rc1 (0.16...0.16) https://github.com/bitcoin-core/bitcoin-detached-sigs/pull/1
192018-02-01T01:17:16 <bitcoin-git> [bitcoin] fivepiece opened pull request #12321: p2wsh address in decodescript (master...decodescript-p2wsh) https://github.com/bitcoin/bitcoin/pull/12321
202018-02-01T01:17:33 <meshcollider> mryandao: see #12254
212018-02-01T01:17:33 *** Krellan has quit IRC
222018-02-01T01:17:35 <gribble> https://github.com/bitcoin/bitcoin/issues/12254 | BIP 158: Compact Block Filters for Light Clients by jimpo · Pull Request #12254 · bitcoin/bitcoin · GitHub
232018-02-01T01:18:09 <meshcollider> Oh oops, I'm too late :)
242018-02-01T01:18:41 *** Krellan has joined #bitcoin-core-dev
252018-02-01T01:18:55 *** Gaylord37Sanford has quit IRC
262018-02-01T01:25:21 *** belcher has quit IRC
272018-02-01T01:27:12 <achow101> cfields: I saw that the detached sigs were pushed, but they don't seem to be working rn
282018-02-01T01:27:29 <cfields> achow101: not quite yet, still working on it
292018-02-01T01:27:51 <achow101> oh, ok
302018-02-01T01:27:54 <cfields> this is the first release with the new key, and the first that's not just me signing. So it's a bit kludgy
312018-02-01T01:28:25 <achow101> we haven't done the mpc rsa thing yet, have we?
322018-02-01T01:29:17 <cfields> no, didn't make it in time
332018-02-01T01:29:23 <cfields> ok, pushed the tag. should work now
342018-02-01T01:29:32 <cfields> off to find food before everything closes, bbl
352018-02-01T01:29:56 <cfields> gitian builders: v0.16.0rc1 detached sigs are pushed. Please ping me if there are any issues
362018-02-01T01:38:51 *** larafale has quit IRC
372018-02-01T01:39:27 *** larafale has joined #bitcoin-core-dev
382018-02-01T01:43:27 *** larafale has quit IRC
392018-02-01T01:44:12 *** contrapumpkin has quit IRC
402018-02-01T01:44:37 *** Murch has quit IRC
412018-02-01T01:46:15 *** contrapumpkin has joined #bitcoin-core-dev
422018-02-01T01:59:23 *** Ed57Effertz has joined #bitcoin-core-dev
432018-02-01T02:00:28 *** Murch has joined #bitcoin-core-dev
442018-02-01T02:01:39 *** Murch has quit IRC
452018-02-01T02:04:56 *** Murch has joined #bitcoin-core-dev
462018-02-01T02:16:19 *** RubenSomsen has joined #bitcoin-core-dev
472018-02-01T02:16:59 *** goatpig has quit IRC
482018-02-01T02:17:55 *** Chris_Stewart_5 has joined #bitcoin-core-dev
492018-02-01T02:32:06 *** Murch has quit IRC
502018-02-01T02:35:30 *** Murch has joined #bitcoin-core-dev
512018-02-01T02:36:17 *** Murch has quit IRC
522018-02-01T02:42:42 *** wampum_ has joined #bitcoin-core-dev
532018-02-01T02:43:13 *** wampum has quit IRC
542018-02-01T02:43:13 *** wampum_ is now known as wampum
552018-02-01T02:51:03 *** ghost43 has quit IRC
562018-02-01T02:55:32 *** arbitrary_guy has quit IRC
572018-02-01T02:56:19 *** ghost43 has joined #bitcoin-core-dev
582018-02-01T03:01:53 *** To7 has quit IRC
592018-02-01T03:04:35 *** arbitrary_guy has joined #bitcoin-core-dev
602018-02-01T03:06:37 *** Evel-Knievel has joined #bitcoin-core-dev
612018-02-01T03:10:48 *** Ed57Effertz has quit IRC
622018-02-01T03:35:36 *** Krellan has quit IRC
632018-02-01T03:36:52 *** Krellan has joined #bitcoin-core-dev
642018-02-01T03:37:06 *** wraithm_ has joined #bitcoin-core-dev
652018-02-01T03:38:01 *** d9b4bef9 has quit IRC
662018-02-01T03:38:32 *** wraithm_ has quit IRC
672018-02-01T03:39:05 *** wraithm has joined #bitcoin-core-dev
682018-02-01T03:40:33 *** Chris_Stewart_5 has quit IRC
692018-02-01T03:41:07 *** d9b4bef9 has joined #bitcoin-core-dev
702018-02-01T04:10:41 *** Randolf has joined #bitcoin-core-dev
712018-02-01T04:37:18 *** tryphe has quit IRC
722018-02-01T04:37:42 *** tryphe has joined #bitcoin-core-dev
732018-02-01T04:39:05 *** davec has quit IRC
742018-02-01T04:41:12 *** davec has joined #bitcoin-core-dev
752018-02-01T04:42:20 *** checksauce has joined #bitcoin-core-dev
762018-02-01T04:45:22 <dx25> with 0.16.0rc1 on exit i'm seeing "IO Error: ...chainstate/244997.ldb: Bad file descriptor", system error while flushing: Database I/O error.
772018-02-01T04:45:36 <dx25> Does not seem to be happening with v0.15.2 or older version
782018-02-01T05:02:45 *** AaronvanW has joined #bitcoin-core-dev
792018-02-01T05:06:44 *** flokie has joined #bitcoin-core-dev
802018-02-01T05:07:10 *** AaronvanW has quit IRC
812018-02-01T05:36:58 *** gelango has joined #bitcoin-core-dev
822018-02-01T05:39:10 *** gelango has left #bitcoin-core-dev
832018-02-01T05:42:32 *** arbitrary_guy has quit IRC
842018-02-01T06:02:43 *** indistylo has joined #bitcoin-core-dev
852018-02-01T06:05:44 *** Emcy_ has joined #bitcoin-core-dev
862018-02-01T06:08:50 *** Emcy has quit IRC
872018-02-01T06:16:19 *** arowser has quit IRC
882018-02-01T06:17:45 *** arowser has joined #bitcoin-core-dev
892018-02-01T06:24:05 *** Murch has joined #bitcoin-core-dev
902018-02-01T06:26:12 *** Krellan has quit IRC
912018-02-01T06:26:52 *** Krellan has joined #bitcoin-core-dev
922018-02-01T06:41:44 *** promag has quit IRC
932018-02-01T06:44:28 *** promag has joined #bitcoin-core-dev
942018-02-01T06:49:33 *** Emcy has joined #bitcoin-core-dev
952018-02-01T06:51:48 *** Emcy_ has quit IRC
962018-02-01T07:01:57 *** laurentmt has joined #bitcoin-core-dev
972018-02-01T07:03:37 *** AaronvanW has joined #bitcoin-core-dev
982018-02-01T07:06:36 <gmaxwell> dx25: can you tell us some about your system? What OS, etc.
992018-02-01T07:06:59 <gmaxwell> dx25: we believe thats a new issue, which will likely block the release until we fix it.
1002018-02-01T07:07:42 <gmaxwell> dx25: we've had one developer hit it but don't have a reliable reproduction yet, and maybe there is something in common between systems that have hit it which would help track it down
1012018-02-01T07:07:54 <gmaxwell> e.g. what OS, kernel version, etc.
1022018-02-01T07:08:19 *** AaronvanW has quit IRC
1032018-02-01T07:11:05 *** laurentmt has quit IRC
1042018-02-01T07:18:48 *** Lynet has joined #bitcoin-core-dev
1052018-02-01T07:24:00 *** indistylo has quit IRC
1062018-02-01T07:24:26 *** indistylo has joined #bitcoin-core-dev
1072018-02-01T07:25:52 *** gelango has joined #bitcoin-core-dev
1082018-02-01T07:32:24 *** gelango has quit IRC
1092018-02-01T07:40:40 *** meshcollider has quit IRC
1102018-02-01T07:56:45 *** go1111111 has quit IRC
1112018-02-01T07:57:51 *** AaronvanW has joined #bitcoin-core-dev
1122018-02-01T08:02:48 *** AaronvanW has quit IRC
1132018-02-01T08:10:15 *** bsm117532 has joined #bitcoin-core-dev
1142018-02-01T08:14:30 *** promag has quit IRC
1152018-02-01T08:22:26 *** Murch has quit IRC
1162018-02-01T08:31:42 *** Krellan has quit IRC
1172018-02-01T08:32:26 *** Krellan has joined #bitcoin-core-dev
1182018-02-01T08:36:38 *** anja_ has joined #bitcoin-core-dev
1192018-02-01T08:53:45 *** indistylo has quit IRC
1202018-02-01T09:02:57 *** Sinclair6 has quit IRC
1212018-02-01T09:04:01 *** d9b4bef9 has quit IRC
1222018-02-01T09:06:57 *** keks_ has joined #bitcoin-core-dev
1232018-02-01T09:07:08 *** d9b4bef9 has joined #bitcoin-core-dev
1242018-02-01T09:12:38 *** sanada has quit IRC
1252018-02-01T09:15:05 *** AaronvanW has joined #bitcoin-core-dev
1262018-02-01T09:17:23 *** indistylo has joined #bitcoin-core-dev
1272018-02-01T09:17:30 *** sanada has joined #bitcoin-core-dev
1282018-02-01T09:21:38 *** Sinclair6 has joined #bitcoin-core-dev
1292018-02-01T09:25:39 *** lio17 has quit IRC
1302018-02-01T09:32:00 *** indistylo has quit IRC
1312018-02-01T09:32:47 *** lio17 has joined #bitcoin-core-dev
1322018-02-01T09:41:52 *** sanada has quit IRC
1332018-02-01T09:43:13 *** sanada has joined #bitcoin-core-dev
1342018-02-01T09:46:30 *** indistylo has joined #bitcoin-core-dev
1352018-02-01T09:48:28 *** pedrobranco has joined #bitcoin-core-dev
1362018-02-01T09:56:24 <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
1372018-02-01T10:04:58 *** pedrobranco has quit IRC
1382018-02-01T10:09:52 *** farsider350 has joined #bitcoin-core-dev
1392018-02-01T10:10:42 *** go1111111 has joined #bitcoin-core-dev
1402018-02-01T10:24:41 *** ghost43 has quit IRC
1412018-02-01T10:24:58 *** Krellan_ has joined #bitcoin-core-dev
1422018-02-01T10:26:31 *** Krellan has quit IRC
1432018-02-01T10:26:43 *** AaronvanW has quit IRC
1442018-02-01T10:27:13 *** shesek has quit IRC
1452018-02-01T10:28:00 *** farsider350 has quit IRC
1462018-02-01T10:28:31 *** aruns has joined #bitcoin-core-dev
1472018-02-01T10:29:00 *** indistylo has quit IRC
1482018-02-01T10:29:41 *** ghost43 has joined #bitcoin-core-dev
1492018-02-01T10:30:23 *** intcat has quit IRC
1502018-02-01T10:31:37 *** intcat has joined #bitcoin-core-dev
1512018-02-01T10:33:04 *** AaronvanW has joined #bitcoin-core-dev
1522018-02-01T10:41:50 *** Krellan_ has quit IRC
1532018-02-01T10:42:52 *** Krellan has joined #bitcoin-core-dev
1542018-02-01T10:44:02 *** JackH has joined #bitcoin-core-dev
1552018-02-01T10:45:10 *** Lynet has quit IRC
1562018-02-01T10:48:01 *** AaronvanW has quit IRC
1572018-02-01T10:53:49 <dafuq> a PR change to the --help CLI options would fall under what category?
1582018-02-01T10:58:17 <wumpus> docs
1592018-02-01T11:02:17 *** meshcollider has joined #bitcoin-core-dev
1602018-02-01T11:02:18 *** larafale has joined #bitcoin-core-dev
1612018-02-01T11:03:30 *** MickMSaunders___ has joined #bitcoin-core-dev
1622018-02-01T11:04:39 <dafuq> ok, seems most suitable but does involve code changes
1632018-02-01T11:05:11 <wumpus> yes, that doesn't matter, as long as it is message changes
1642018-02-01T11:05:36 <dafuq> thanks
1652018-02-01T11:09:05 *** midnightmagic_ has joined #bitcoin-core-dev
1662018-02-01T11:09:38 *** Lynet has joined #bitcoin-core-dev
1672018-02-01T11:09:40 *** helo_ has joined #bitcoin-core-dev
1682018-02-01T11:11:15 *** Jackielove4u_ has joined #bitcoin-core-dev
1692018-02-01T11:11:16 *** midnightmagic has quit IRC
1702018-02-01T11:11:17 *** helo has quit IRC
1712018-02-01T11:11:17 *** Jackielove4u has quit IRC
1722018-02-01T11:11:18 *** bitbee has quit IRC
1732018-02-01T11:11:18 *** nsh has quit IRC
1742018-02-01T11:11:24 *** Jackielove4u_ is now known as Jackielove4u
1752018-02-01T11:11:27 *** RubenSomsen has quit IRC
1762018-02-01T11:11:30 *** da2ce7 has quit IRC
1772018-02-01T11:11:43 *** nsh- has joined #bitcoin-core-dev
1782018-02-01T11:11:48 *** da2ce7 has joined #bitcoin-core-dev
1792018-02-01T11:12:08 *** ibrightly has quit IRC
1802018-02-01T11:12:42 *** bitbee has joined #bitcoin-core-dev
1812018-02-01T11:13:48 *** Guyver2 has joined #bitcoin-core-dev
1822018-02-01T11:13:49 *** ibrightly has joined #bitcoin-core-dev
1832018-02-01T11:14:30 *** lifeofguenter has quit IRC
1842018-02-01T11:16:16 *** lifeofguenter has joined #bitcoin-core-dev
1852018-02-01T11:17:55 *** indistylo has joined #bitcoin-core-dev
1862018-02-01T11:20:20 *** aruns has quit IRC
1872018-02-01T11:21:15 *** midnightmagic_ is now known as midnightmagic
1882018-02-01T11:24:26 *** lnostdal has quit IRC
1892018-02-01T11:25:03 *** indistylo has quit IRC
1902018-02-01T11:25:44 *** lnostdal has joined #bitcoin-core-dev
1912018-02-01T11:27:40 <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
1922018-02-01T11:29:06 *** bitcoin-core-dev has joined #bitcoin-core-dev
1932018-02-01T11:32:18 *** Krellan has quit IRC
1942018-02-01T11:33:20 *** Krellan has joined #bitcoin-core-dev
1952018-02-01T11:33:52 *** bitcoin-core-dev has quit IRC
1962018-02-01T11:36:26 *** AaronvanW has joined #bitcoin-core-dev
1972018-02-01T11:36:35 *** RubenSomsen has joined #bitcoin-core-dev
1982018-02-01T11:41:13 *** AaronvanW has quit IRC
1992018-02-01T11:46:10 *** indistylo has joined #bitcoin-core-dev
2002018-02-01T11:47:28 *** lnostdal has quit IRC
2012018-02-01T11:47:52 *** lnostdal has joined #bitcoin-core-dev
2022018-02-01T11:52:12 <bitcoin-git> [bitcoin] AkioNak opened pull request #12324: speed up Unserialize_impl for prevector (master...unserialize) https://github.com/bitcoin/bitcoin/pull/12324
2032018-02-01T11:57:19 *** farsider350 has joined #bitcoin-core-dev
2042018-02-01T11:59:22 *** AaronvanW has joined #bitcoin-core-dev
2052018-02-01T12:00:13 *** dabura667 has quit IRC
2062018-02-01T12:07:28 *** Krellan has quit IRC
2072018-02-01T12:08:11 *** Krellan has joined #bitcoin-core-dev
2082018-02-01T12:08:39 *** AaronvanW has quit IRC
2092018-02-01T12:09:13 *** wxss has joined #bitcoin-core-dev
2102018-02-01T12:13:45 *** jtimon has quit IRC
2112018-02-01T12:14:05 *** shesek has joined #bitcoin-core-dev
2122018-02-01T12:16:44 *** promag has joined #bitcoin-core-dev
2132018-02-01T12:24:07 *** Lynet has quit IRC
2142018-02-01T12:25:38 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2152018-02-01T12:38:32 *** belcher has joined #bitcoin-core-dev
2162018-02-01T12:49:46 <provoostenator> I'm getting "Fatal Internal Error" during IBD on testnet3 with 0.16.0rc1, twice. Will investigate.
2172018-02-01T12:50:10 <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
2182018-02-01T12:50:32 <provoostenator> Might be a disk permission thing. "Pre-allocating up to position 0x3000000 in blk00002.dat" "ERROR: WriteBlockToDisk: ftell failed" "*** Failed to write block"
2192018-02-01T12:52:46 *** checksauce has quit IRC
2202018-02-01T12:53:12 *** checksauce has joined #bitcoin-core-dev
2212018-02-01T12:53:20 <wumpus> disk full?
2222018-02-01T12:53:21 <provoostenator> Also seeing a bunch of "socket recv error Bad file descriptor (9)" messages, not sure what that's about.
2232018-02-01T12:53:32 *** checksauce has quit IRC
2242018-02-01T12:53:35 <wumpus> oof bad file descriptor
2252018-02-01T12:53:39 <provoostenator> No, plenty of space. It's an external SSD though, so can't rule out a hardware problem.
2262018-02-01T12:53:45 <wumpus> provoostenator: see https://github.com/bitcoin/bitcoin/issues/12323
2272018-02-01T12:54:03 <dx25> mine's also an external drive, not ssd tho
2282018-02-01T12:54:09 *** Giszmo has joined #bitcoin-core-dev
2292018-02-01T12:54:10 <wumpus> no, it's possibly a regression in 0.16
2302018-02-01T12:54:11 *** Giszmo has quit IRC
2312018-02-01T12:54:45 *** laurentmt has joined #bitcoin-core-dev
2322018-02-01T12:55:10 <provoostenator> Getting this crash every other minute now on testnet. Will try local drive just to rule out hardware issue.
2332018-02-01T12:55:20 <dx25> i'm on qubes, fedora25 vm, 4.9.56 kernel
2342018-02-01T12:57:37 *** RubenSomsen has quit IRC
2352018-02-01T13:00:20 <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
2362018-02-01T13:01:25 <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.
2372018-02-01T13:01:40 *** Chris_Stewart_5 has quit IRC
2382018-02-01T13:03:25 <wumpus> I seriously doubt this is a hardware issue
2392018-02-01T13:03:39 <wumpus> are you doing anything special with the node? regular RPC requests, for example?
2402018-02-01T13:04:06 *** larafale_ has joined #bitcoin-core-dev
2412018-02-01T13:04:10 <wumpus> or any fd related settings in bitcoin.conf?
2422018-02-01T13:04:57 <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.
2432018-02-01T13:05:20 *** laurentmt has quit IRC
2442018-02-01T13:05:50 <provoostenator> server=1 rpcuser=... rpcpassword=... listen=0
2452018-02-01T13:06:20 <provoostenator> I used a symlink to point to the SSD drive.
2462018-02-01T13:06:27 <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.
2472018-02-01T13:06:29 <provoostenator> Ah there we go again: crash.
2482018-02-01T13:07:27 *** larafale has quit IRC
2492018-02-01T13:07:31 <provoostenator> (no symlink involved this time, nor an external drive). Crashed happened at or after block 64709 (testnet)
2502018-02-01T13:07:36 <wumpus> provoostenator: so it happens even without listening
2512018-02-01T13:07:37 <dx25> i was doing no rpc stuff
2522018-02-01T13:08:09 <wumpus> provoostenator: that rules out some p2p races I guess, but what can it be then...
2532018-02-01T13:08:15 *** larafale has joined #bitcoin-core-dev
2542018-02-01T13:08:31 <wumpus> provoostenator: you're able to reliably reproduce this? could try git bisecting, if it was ok with 0.15.1
2552018-02-01T13:08:50 <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)
2562018-02-01T13:08:58 <wumpus> (or find some later commit where the issue doesn't exist)
2572018-02-01T13:08:59 *** Angelo28Carroll has joined #bitcoin-core-dev
2582018-02-01T13:09:31 <provoostenator> I just down the other mainnet QT instance, will try once more. Then I'll compare versions after that.
2592018-02-01T13:09:34 <dx25> also sync related here, but on mainnet
2602018-02-01T13:09:36 <provoostenator> Pretty reliable so far
2612018-02-01T13:11:15 *** dermoth has quit IRC
2622018-02-01T13:11:16 *** dermoth_ has joined #bitcoin-core-dev
2632018-02-01T13:11:27 *** larafale_ has quit IRC
2642018-02-01T13:11:33 *** dermoth_ is now known as dermoth
2652018-02-01T13:16:39 <provoostenator> It was built with: ./configure --disable-tests --disable-bench --with-miniupnpc=no
2662018-02-01T13:17:09 <provoostenator> Hooray, another crash. Ok, should be easy to bisect.
2672018-02-01T13:17:38 <provoostenator> Height 8089 (testnet)
2682018-02-01T13:19:13 <wumpus> yes, would make a backup of the data directory to make sure you start with the same state every time
2692018-02-01T13:19:24 *** aruns has joined #bitcoin-core-dev
2702018-02-01T13:19:25 <wumpus> at hight 8089 at least that isn't too much data
2712018-02-01T13:20:07 <provoostenator> I get this crash with a fresh testnet3 directory.
2722018-02-01T13:20:28 <provoostenator> I'll keep a copy for forensics
2732018-02-01T13:20:40 *** meshcollider has quit IRC
2742018-02-01T13:22:08 *** indistylo has quit IRC
2752018-02-01T13:22:58 <wumpus> I'll hold up on uploading executables for rc1 for now
2762018-02-01T13:23:37 *** AaronvanW has joined #bitcoin-core-dev
2772018-02-01T13:26:17 *** nsh- is now known as nsh
2782018-02-01T13:26:54 <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.
2792018-02-01T13:29:57 <provoostenator> (no difference)\
2802018-02-01T13:30:06 *** Victorsueca has quit IRC
2812018-02-01T13:30:12 <provoostenator> Height 401 :-)
2822018-02-01T13:30:17 <wumpus> I wouldn't expect it to be so predictable in that case
2832018-02-01T13:31:15 *** Victorsueca has joined #bitcoin-core-dev
2842018-02-01T13:44:40 *** Giszmo has joined #bitcoin-core-dev
2852018-02-01T13:45:18 *** ProfMac has quit IRC
2862018-02-01T13:47:06 <provoostenator> Other than ccache and skipping tests and bench, any hints on how to make it compile faster?
2872018-02-01T13:48:16 <wumpus> do only 'make -j<x> src/bitcoind'
2882018-02-01T13:48:25 <wumpus> you don't really need to rebuild cli and such
2892018-02-01T13:53:25 *** aruns__ has joined #bitcoin-core-dev
2902018-02-01T13:53:45 *** AaronvanW has quit IRC
2912018-02-01T13:55:04 *** ProfMac has joined #bitcoin-core-dev
2922018-02-01T13:55:11 *** AaronvanW has joined #bitcoin-core-dev
2932018-02-01T13:55:56 *** aruns has quit IRC
2942018-02-01T13:56:07 <provoostenator> Right, I should test if this is QT related first, and otherwise just build bitcoind
2952018-02-01T13:58:58 *** CubicEarths has joined #bitcoin-core-dev
2962018-02-01T14:02:38 <wumpus> yes, you could also only built -qt with a similar command, but it takes much longer
2972018-02-01T14:04:04 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2982018-02-01T14:04:11 <provoostenator> I know, I was doing that (make src/qt/bitcoin-qt)
2992018-02-01T14:04:32 <provoostenator> Is there a reason the binaries end up in the /src path rather than in e.g. /dist?
3002018-02-01T14:07:21 *** CubicEar_ has joined #bitcoin-core-dev
3012018-02-01T14:07:49 *** CubicEar_ has quit IRC
3022018-02-01T14:08:20 *** CubicEar_ has joined #bitcoin-core-dev
3032018-02-01T14:09:54 <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`<
3042018-02-01T14:09:56 *** Cheeseo has joined #bitcoin-core-dev
3052018-02-01T14:10:43 *** jamesob has joined #bitcoin-core-dev
3062018-02-01T14:10:53 *** CubicEarths has quit IRC
3072018-02-01T14:12:32 *** jamesob has quit IRC
3082018-02-01T14:12:47 *** CubicEar_ has quit IRC
3092018-02-01T14:12:53 *** cheese_ has quit IRC
3102018-02-01T14:15:15 <morcos> just to clarify we think the crash is caused by what? a Bad file descriptor issue occuring on block write?
3112018-02-01T14:15:28 <morcos> We've also seen it on ldb which causes a crash
3122018-02-01T14:15:37 <morcos> and on socket send/recv which doesn't
3132018-02-01T14:16:30 <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"
3142018-02-01T14:17:01 *** Krellan has quit IRC
3152018-02-01T14:18:46 *** Krellan has joined #bitcoin-core-dev
3162018-02-01T14:19:16 <provoostenator> But http://termbin.com/83iva
3172018-02-01T14:19:40 <provoostenator> I wonder what "Interrupting HTTP server" is about.
3182018-02-01T14:20:17 *** jamesob has joined #bitcoin-core-dev
3192018-02-01T14:21:40 <wumpus> there is no error there - you didn't simply send a stop command?
3202018-02-01T14:22:16 <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"
3212018-02-01T14:22:33 <provoostenator> I'm blaming gremlins. Bisecting now.
3222018-02-01T14:23:16 <wumpus> no, that's true, normally that's accompanied by an error being logged, this looks like a succesful shutdown
3232018-02-01T14:23:36 <wumpus> you did paste the right debug.log? :)
3242018-02-01T14:25:22 *** AaronvanW has quit IRC
3252018-02-01T14:26:17 <provoostenator> Not sure actually, double checking
3262018-02-01T14:27:54 *** Krellan has quit IRC
3272018-02-01T14:28:24 <provoostenator> Default og locations changed between 0.15 and 0.16. Will try again.
3282018-02-01T14:28:58 *** Krellan has joined #bitcoin-core-dev
3292018-02-01T14:30:07 <wumpus> default log location changed?!
3302018-02-01T14:30:46 <wumpus> should not be the case, it's still <datadir>/debug.log, sounds more likely you've set a different datadir for -qt
3312018-02-01T14:32:28 <provoostenator> Or accidentally used mainnet for bitcoind.
3322018-02-01T14:37:00 <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.
3332018-02-01T14:37:12 <BlueMatt> provoostenator: if you're trying to bisect, I'd recommend focusing on any changes to net
3342018-02-01T14:37:38 <BlueMatt> eg #11363
3352018-02-01T14:37:41 <gribble> https://github.com/bitcoin/bitcoin/issues/11363 | net: Split socket create/connect by theuni · Pull Request #11363 · bitcoin/bitcoin · GitHub
3362018-02-01T14:37:47 <BlueMatt> and #10663
3372018-02-01T14:37:49 <gribble> https://github.com/bitcoin/bitcoin/issues/10663 | net: split resolve out of connect by theuni · Pull Request #10663 · bitcoin/bitcoin · GitHub
3382018-02-01T14:38:04 <BlueMatt> though I dont see anything obvious in net on master that should be causing this
3392018-02-01T14:38:54 <provoostenator> BlueMatt: bisecting everything involves less thinking :-)
3402018-02-01T14:39:55 <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.
3412018-02-01T14:40:04 *** goatpig has joined #bitcoin-core-dev
3422018-02-01T14:40:49 <provoostenator> Maybe "Bad file descriptor" is a good enough proxy.
3432018-02-01T14:46:06 <morcos> cfields asked me to add some asserts for debugging this
3442018-02-01T14:46:10 <morcos> https://0bin.net/paste/X-6vyuCUUlN+XY1l#5VoMIrtAP6S0Yex-7eAwDNLJl/7UT2e7medmcgsVtvA
3452018-02-01T14:46:15 <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
3462018-02-01T14:46:45 <morcos> I just tried a fresh sync of testnet3 with these asserts patched on 0.16.0rc1 and the middle assert triggered
3472018-02-01T14:47:27 <morcos> last line in debug log
3482018-02-01T14:47:29 <morcos> 2018-02-01 14:40:00.528984 socket select error Bad file descriptor (9)
3492018-02-01T14:47:52 *** AaronvanW has joined #bitcoin-core-dev
3502018-02-01T14:49:04 <cfields> BlueMatt: that seems like a really good candidate, yes. I went through it earlier this week already, but maybe i keep missing something
3512018-02-01T14:49:42 <morcos> here is the backtrace from that thread:
3522018-02-01T14:49:45 <morcos> https://0bin.net/paste/OmSDtVV-u0EwBaEp#Muh7dQfn6+kzip0Ib-b5brUozDZtCZblT1ev2lNtfdT
3532018-02-01T14:49:52 <wumpus> also going to test with those asserts
3542018-02-01T14:50:07 *** Giszmo has quit IRC
3552018-02-01T14:50:21 <cfields> morcos: can you do a 'thread apply all bt' ?
3562018-02-01T14:50:44 <cfields> if it's a leak in something like 11363, it won't show up in a bt though :(
3572018-02-01T14:51:28 <cfields> though also, a leak should be obvious after a quick peek at /proc
3582018-02-01T14:51:55 <wumpus> would be nice if it was able to rewind the process to see what closed fd 9
3592018-02-01T14:52:04 <morcos> https://0bin.net/paste/FotU51A-Z98LdS0u#aWgxDyxhAn5L4XIex7Ko+kjMJ+qkAL0CJ77NubzV6io
3602018-02-01T14:52:08 <morcos> cfields: ^^
3612018-02-01T14:52:31 <cfields> thanks
3622018-02-01T14:52:42 <cfields> wumpus: i think 9 is EBADFD, not the fd#
3632018-02-01T14:52:54 <morcos> yeah i hope so, b/c it's always 9
3642018-02-01T14:53:04 <wumpus> cfields: oh, right it doesn't print the actual fd number
3652018-02-01T14:53:54 <provoostenator> http://termbin.com/h7jy
3662018-02-01T14:54:02 <provoostenator> "System error: CAutoFile::write: write failed: unspecified iostream_category error"
3672018-02-01T14:54:25 <provoostenator> It then happily processes a few more blocks and shuts down
3682018-02-01T14:54:40 <wumpus> so the buckshot hit CAutoFile's descriptor this time
3692018-02-01T14:55:06 <wumpus> this is so weird, looks like some evil background thread is randomly closing fds
3702018-02-01T14:55:35 <provoostenator> Unfortunately that took almost 20 minutes to crash, so this bisect will take a while, but probably worth it.
3712018-02-01T14:55:57 <cfields> maybe some callback isn't taking cs_main while touching block files?
3722018-02-01T14:56:11 <cfields> provoostenator: it'd be great if you could catch it in gdb
3732018-02-01T14:56:26 <cfields> that should allow a 'freeze' long enough to ld your fd's
3742018-02-01T14:56:30 <cfields> *ls
3752018-02-01T14:56:40 <provoostenator> gdb?
3762018-02-01T14:56:55 <cfields> provoostenator: debugger
3772018-02-01T14:56:57 <wumpus> cfields: right, it could well be something else than net calls, I remember there is a PR that changes locking around block files
3782018-02-01T14:57:36 <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.
3792018-02-01T14:58:00 <cfields> sure
3802018-02-01T14:58:06 <provoostenator> That should also provide more assurance that the fix actually fixes it.
3812018-02-01T14:58:12 <morcos> cfields: now i hit the first assert
3822018-02-01T14:58:45 <cfields> morcos: if it's some fd leak, it'd make sense that you'd get EBADFD randomly, all over the place
3832018-02-01T14:58:48 *** mmgen has joined #bitcoin-core-dev
3842018-02-01T14:58:55 <cfields> morcos: any chance you can catch it in gdb?
3852018-02-01T14:59:01 <morcos> yeah, ok so if i run in gdb, then you want what, the list of what's in /proc/pid, or what
3862018-02-01T14:59:10 <cfields> yea
3872018-02-01T14:59:42 <cfields> try to break on assert (might be _assert or __assert) in gdb, so it hangs before exit is called
3882018-02-01T15:02:38 *** Giszmo has joined #bitcoin-core-dev
3892018-02-01T15:03:49 <wumpus> cfields: maybe #11281 / ccd8ef65f93ed82a87cee634660bed3ac17d9eb5?
3902018-02-01T15:03:54 <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
3912018-02-01T15:04:05 <morcos> it's on to me, it's not going to crash now
3922018-02-01T15:04:31 <wumpus> cfields: it changes locking around block file reading, at least
3932018-02-01T15:04:32 <cfields> morcos: heh, gdb tends to throw timings just enough so that everything works perfectly
3942018-02-01T15:04:33 *** aruns__ has quit IRC
3952018-02-01T15:05:04 <cfields> wumpus: good find, taking a look
3962018-02-01T15:06:13 *** Victorsueca has quit IRC
3972018-02-01T15:06:14 <cfields> morcos: wait, you said you hit the first one? that should be much more interesting
3982018-02-01T15:06:25 <cfields> i guess th core file is blown away already? :(
3992018-02-01T15:06:45 <wumpus> cfields: the one I was thinking of https://github.com/bitcoin/bitcoin/pull/11913 is not merged :)
4002018-02-01T15:07:26 *** Victorsueca has joined #bitcoin-core-dev
4012018-02-01T15:07:31 <cfields> wumpus: ah, heh
4022018-02-01T15:07:36 <wumpus> no problems with testnet sync here w/ cfields's assertions
4032018-02-01T15:07:51 <morcos> cfield: no i saved it
4042018-02-01T15:07:53 <wumpus> (at least at block 319000)
4052018-02-01T15:08:16 <cfields> morcos: could you do a 'thread apply all bt' for that one?
4062018-02-01T15:08:57 <morcos> how do i easily output that to a file
4072018-02-01T15:09:04 <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
4082018-02-01T15:09:11 <wumpus> gdb logging
4092018-02-01T15:09:27 <wumpus> morcos: https://sourceware.org/gdb/onlinedocs/gdb/Logging-Output.html
4102018-02-01T15:11:54 *** dermoth has quit IRC
4112018-02-01T15:12:19 *** dermoth has joined #bitcoin-core-dev
4122018-02-01T15:15:04 <morcos> some serious user error there
4132018-02-01T15:15:08 <morcos> https://0bin.net/paste/43cNNOSrrPlIyVqt#BE1tyObep4Y9aLIpDDVC4kwVFJYxctxlhMJTE3xF08j
4142018-02-01T15:15:57 <cfields> thanks
4152018-02-01T15:15:57 <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)"
4162018-02-01T15:16:08 <wumpus> (https://github.com/bitcoin/bitcoin/issues/12323#issuecomment-362296158)
4172018-02-01T15:17:58 <cfields> I don't think it can be called unitialized?
4182018-02-01T15:18:24 <wumpus> closing an uninitialized fd would explain this perfectly, though
4192018-02-01T15:18:54 <wumpus> if you can reproduce this, maybe log all CloseSocket calls and see if it ends up with any funny data
4202018-02-01T15:18:56 *** Dizzle has joined #bitcoin-core-dev
4212018-02-01T15:18:59 <cfields> yes it would
4222018-02-01T15:19:24 <wumpus> (or at least those for which the close() fails, because we ignore closes return value right now)
4232018-02-01T15:19:36 <cfields> and it matches provoostenator's log as well
4242018-02-01T15:19:40 <wumpus> yep
4252018-02-01T15:20:49 <cfields> oh wait, that's an else if(), not an else
4262018-02-01T15:20:56 <cfields> maybe that can happen
4272018-02-01T15:21:14 <morcos> yeah seems like you are missing a catch all else
4282018-02-01T15:21:54 <cfields> looks like it'd happen as a result of a dns seed handing out a bad/local ip
4292018-02-01T15:22:03 <morcos> nice find by david60
4302018-02-01T15:22:25 <cfields> morcos: do you see dns queries before crashes in your logs?
4312018-02-01T15:22:26 <morcos> cfields: that would match my having it happen a lot when i noticed i was using dns seeds a lot
4322018-02-01T15:22:49 <morcos> i did previously, i don't know if i exclusively checked , but i had observed it was doing a lot of dns querying
4332018-02-01T15:23:05 <cfields> I'll pr a fix for that right now either way. Seems like a really good candidate, though
4342018-02-01T15:23:18 <cfields> ok
4352018-02-01T15:23:43 <cfields> maybe you could force it by setting up a phony seed and returning only 127.0.0.1
4362018-02-01T15:24:16 <cfields> i think 2 phony entries in /etc/hosts would work
4372018-02-01T15:25:52 <morcos> 2? any 2? one ip4 and one ip6?
4382018-02-01T15:25:57 <provoostenator> That would be nice, in that case you can even write a test for it?
4392018-02-01T15:27:36 <cfields> morcos: 127.0.0.1 seed.bitcoin.sipa.be
4402018-02-01T15:27:46 <cfields> i think that should do it?
4412018-02-01T15:28:21 <morcos> i think i tried that, let me see what happened, it didn't crash yet
4422018-02-01T15:29:26 <provoostenator> I've never had a crash before or during headers sync, always during block downloads.
4432018-02-01T15:31:47 <cfields> morcos: ok, 127.0.0.1 would still pass IsValid, we'll have to use a more busted value
4442018-02-01T15:33:23 <morcos> i got it to crash again not sure if it was because of those entries or what
4452018-02-01T15:33:26 <morcos> in gdb
4462018-02-01T15:34:12 <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
4472018-02-01T15:35:01 <cfields> morcos: dns query at the end of your log?
4482018-02-01T15:35:07 <morcos> https://0bin.net/paste/3T-vAUCXmHtlqJ9X#1UvKDgv7oZR4uZEEV0WqIGFDNdUQFTW3xFHkE0R-UOe
4492018-02-01T15:35:10 <gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
4502018-02-01T15:35:44 <provoostenator> gribble: lol
4512018-02-01T15:35:59 <cfields> morcos: ok, so you're not running through fd's. Closing a random one makes way more sense
4522018-02-01T15:35:59 <morcos> oh that was stupid, i changed the mainnet dns seeds but was running on testnet
4532018-02-01T15:36:17 <cfields> heh
4542018-02-01T15:36:54 *** Aaronvan_ has joined #bitcoin-core-dev
4552018-02-01T15:37:07 *** Giszmo has quit IRC
4562018-02-01T15:37:17 <cfields> morcos: try setting it to 0.0.0.0 instead. Not sure if the resolver will actually hand that out, though
4572018-02-01T15:37:35 *** Aaronva__ has joined #bitcoin-core-dev
4582018-02-01T15:37:46 <cfields> actually, if that's the case, I should be able to repro too instead of asking you to :p
4592018-02-01T15:37:55 <cfields> off to test
4602018-02-01T15:38:16 <morcos> cfields: ok yeah it did load dns seeds before this crash though
4612018-02-01T15:38:26 <wumpus> well it also depends on what is in the uninitialized memory
4622018-02-01T15:39:02 <morcos> btw, before i forget, it seemed that running in testnet was reading peers.dat from .bitcoin and not testnet3
4632018-02-01T15:39:09 <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
4642018-02-01T15:39:10 <morcos> i deleted both of them to force dnsseeds
4652018-02-01T15:39:10 <cfields> wumpus: true, but an assert on a successfull close() should point it out quickly i should think
4662018-02-01T15:39:48 <cfields> wumpus: wouldn't anything other than -1 in memory cause a problem?
4672018-02-01T15:40:26 <wumpus> cfields: it might, though closing fd 0 (stdin) is harmless in our case
4682018-02-01T15:40:30 *** AaronvanW has quit IRC
4692018-02-01T15:40:53 <cfields> hmm
4702018-02-01T15:41:53 <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.
4712018-02-01T15:41:53 *** Aaronvan_ has quit IRC
4722018-02-01T15:42:30 *** Giszmo has joined #bitcoin-core-dev
4732018-02-01T15:43:52 <cfields> makes sense
4742018-02-01T15:43:56 <cfields> morcos: fyi, there's -forcednsseed
4752018-02-01T15:45:32 *** Aaronva__ has quit IRC
4762018-02-01T15:46:01 *** AaronvanW has joined #bitcoin-core-dev
4772018-02-01T15:46:07 *** owowo has quit IRC
4782018-02-01T15:46:35 *** Giszmo has quit IRC
4792018-02-01T15:47:11 <morcos> cfields: I added an assert in netbase.cpp CloseSocket that ret != error and I hit it
4802018-02-01T15:47:37 <cfields> morcos: great! can you print hSocket there ?
4812018-02-01T15:47:41 *** shesek has quit IRC
4822018-02-01T15:49:28 <morcos> 0?
4832018-02-01T15:49:33 <morcos> looks like addrConnect is 0
4842018-02-01T15:49:46 <morcos> looks like this is all a test from provoostenator as its coming from his seed
4852018-02-01T15:50:11 <cfields> morcos: you didn't set yours in /etc/hosts ?
4862018-02-01T15:50:21 <provoostenator> Interesteing, is my testnet seed doing something funny?
4872018-02-01T15:50:36 <morcos> actually i'm not sure abou tthat, since i'm not familiar with this code
4882018-02-01T15:50:49 <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
4892018-02-01T15:51:20 <provoostenator> Mmm, it might actually be down. Let me check
4902018-02-01T15:51:24 <morcos> cfields i did make changes in /etc/hosts, but isn't seed.bitcoin.sipa.be a mainnet seed?
4912018-02-01T15:51:46 <cfields> morcos: yea, but you said you had all of em. didn't know what you set in there
4922018-02-01T15:51:50 <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"
4932018-02-01T15:52:04 <cfields> provoostenator: it's down for me...
4942018-02-01T15:52:18 <provoostenator> For me as well.
4952018-02-01T15:52:24 <cfields> but that should return 0 addresses and not try a connection. It shouldn't end up trying to connect to 0...
4962018-02-01T15:52:31 <provoostenator> I still need to setup monitoring.
4972018-02-01T15:52:34 <cfields> provoostenator: leave it down while we're testing :)
4982018-02-01T15:52:38 <morcos> here is the bt from that thread
4992018-02-01T15:52:41 <morcos> https://0bin.net/paste/X7-3MRaRJlLP8PoG#ApzQJmsY+N3H64RbQ-42PwxlbdJhXwpSvnx1BoINmZ+
5002018-02-01T15:52:51 <provoostenator> cfields: will do, just ping me when you want me to bring it back
5012018-02-01T15:53:00 <morcos> let me know if you want me to look at any particular value
5022018-02-01T15:55:08 <cfields> weird, i don't hit an assert there
5032018-02-01T15:55:09 <morcos> isn't it telling that in my /proc/pid/fd i didn't have a FD 0 in the earlier paste
5042018-02-01T15:55:10 *** dcousens has quit IRC
5052018-02-01T15:55:14 <morcos> i also don't have one in this paste
5062018-02-01T15:55:21 *** dcousens has joined #bitcoin-core-dev
5072018-02-01T15:55:27 <morcos> sorry not paste, example or whatever
5082018-02-01T15:55:33 <wumpus> morcos: that's very telling
5092018-02-01T15:55:37 *** lnostdal has quit IRC
5102018-02-01T15:55:51 <cfields> morcos: very good point. that would explain the environment difference too
5112018-02-01T15:56:21 <morcos> didn't follow that last part
5122018-02-01T15:57:08 <cfields> morcos: if something about your OS/mem/etc. makes 0 a more likely value for you than everyone else
5132018-02-01T15:57:29 <provoostenator> My seed died with: https://0bin.net/paste/2bx9a3iijDdBgWXg#dlXDiXwy9dVkyvR0yuCyjzH4scHaL+6GHT-ll14wOrD
5142018-02-01T15:58:42 <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
5152018-02-01T15:59:35 <morcos> huh, the fix didn't fix it?
5162018-02-01T16:00:03 <sdaftuar> wasn't running with the fix -- just verifying that hSocket could indeed be uninitialized
5172018-02-01T16:00:08 <cfields> or are you saying that you've verified that you can hit the else branch?
5182018-02-01T16:00:13 <sdaftuar> ^ that
5192018-02-01T16:00:15 <cfields> ok, great
5202018-02-01T16:00:16 *** checksauce has joined #bitcoin-core-dev
5212018-02-01T16:00:49 <cfields> morcos: have you been on testnet every time you've hit this?
5222018-02-01T16:01:19 <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
5232018-02-01T16:01:49 <cfields> but i guess that does jive with your complaints that we're querying the seeds too often
5242018-02-01T16:02:12 <cfields> heh, in fact, you would've been noticing that because there'd be an entry at the end of every log file
5252018-02-01T16:02:18 *** helo_ is now known as helo
5262018-02-01T16:02:18 <morcos> no all the prior times were mainnet
5272018-02-01T16:02:21 <provoostenator> Doesn't it pick a seed at random?
5282018-02-01T16:02:35 <morcos> but yes i was querying dns seeds occasionally
5292018-02-01T16:02:44 <morcos> i don't know what you mean about seing an etnry at the end of every log file
5302018-02-01T16:02:45 <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.
5312018-02-01T16:03:08 <morcos> the problem is if there is a dnsseed that is returning garbage somehow, it'll periodically retry it right?
5322018-02-01T16:03:18 <morcos> so if everytime it does that, it results in me close fd 0
5332018-02-01T16:03:26 <morcos> which at that point has been reused for soemthing else
5342018-02-01T16:03:34 <morcos> it'll cause an error
5352018-02-01T16:03:37 *** owowo has joined #bitcoin-core-dev
5362018-02-01T16:03:37 *** owowo has joined #bitcoin-core-dev
5372018-02-01T16:04:12 <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
5382018-02-01T16:04:15 <morcos> but maybe thats what you're saying
5392018-02-01T16:04:27 <cfields> morcos: it only hits the seeds if we don't have enough peers
5402018-02-01T16:04:53 <cfields> it shouldn't keep retrying anything just because it failed
5412018-02-01T16:04:57 *** Giszmo has joined #bitcoin-core-dev
5422018-02-01T16:05:12 <cfields> wait, it might now!
5432018-02-01T16:06:13 <provoostenator> Should there be a functional test for dealing with broken DNS seeds?
5442018-02-01T16:06:40 <cfields> provoostenator: does your seed support filtering?
5452018-02-01T16:07:13 <cfields> it would make sense if a connection was tried because it was a oneshot()...
5462018-02-01T16:07:17 <morcos> cfields: it looked to me that it adds it to oneshot
5472018-02-01T16:07:28 <morcos> isn't that what it does with dnsseeds
5482018-02-01T16:07:33 <morcos> assuming you need them
5492018-02-01T16:07:38 <cfields> that's a new change, sec
5502018-02-01T16:08:05 <cfields> so we're not differentiating between a failed resolve, and a resolve with 0 results
5512018-02-01T16:08:53 <morcos> cfields: yeah can you look at line 390 in net.cpp
5522018-02-01T16:09:03 <morcos> i don't know what that does, but what happens if it fails
5532018-02-01T16:09:10 <cfields> #11512
5542018-02-01T16:09:13 <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
5552018-02-01T16:09:17 <morcos> if (Lookup(pszDest, resolved, default_port, fNameLookup && !HaveNameProxy(), 256) && !resolved.empty()) {
5562018-02-01T16:10:54 *** Murch has joined #bitcoin-core-dev
5572018-02-01T16:11:00 *** dermoth has quit IRC
5582018-02-01T16:13:00 *** dermoth has joined #bitcoin-core-dev
5592018-02-01T16:14:23 <provoostenator> cfields: I use sipa's tool with the default settings, see my 0bin past above for full command
5602018-02-01T16:16:28 <cfields> morcos: ok, red herring. I see what's happening.
5612018-02-01T16:16:45 <cfields> it fails on the filtered resolve, so it does a oneshot for the unfiltered one. working as intended
5622018-02-01T16:17:05 <cfields> but they're both down, so you get a random socket
5632018-02-01T16:18:35 <cfields> wumpus: i'm more and more confident that this is the issue
5642018-02-01T16:19:03 <wumpus> cfields: great!
5652018-02-01T16:19:18 <cfields> and very sorry that i introduced it :(
5662018-02-01T16:19:22 <wumpus> means we can do rc2 soon
5672018-02-01T16:19:37 *** CubicEarths has joined #bitcoin-core-dev
5682018-02-01T16:19:38 <wumpus> heh no worries
5692018-02-01T16:20:14 <wumpus> happy if it's this and some problem deep in leveldb
5702018-02-01T16:20:23 <morcos> provoostenator is right though we should have a test for bad dns seed.
5712018-02-01T16:22:22 <cfields> we could add that to the travis cron job
5722018-02-01T16:22:45 <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
5732018-02-01T16:22:59 *** SopaXorzTaker has joined #bitcoin-core-dev
5742018-02-01T16:23:13 <cfields> oh, i thought the concern was not knowing that dns seeds were down
5752018-02-01T16:23:27 <sdaftuar> i think the concern is making sure we handle it when they are? or really both i guess...
5762018-02-01T16:24:08 <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.
5772018-02-01T16:24:17 <cfields> 2018-02-01 16:23:47 Closing bad socket: 1266668816
5782018-02-01T16:24:47 <cfields> 2018-02-01 16:24:30 Closing bad socket: 100640016
5792018-02-01T16:24:57 <cfields> yep, that's it
5802018-02-01T16:29:06 *** PaulCapestany has quit IRC
5812018-02-01T16:29:32 *** Giszmo has quit IRC
5822018-02-01T16:32:05 *** AaronvanW has quit IRC
5832018-02-01T16:33:15 *** AaronvanW has joined #bitcoin-core-dev
5842018-02-01T16:37:20 *** Krellan has quit IRC
5852018-02-01T16:38:07 *** AaronvanW has quit IRC
5862018-02-01T16:39:33 *** Krellan has joined #bitcoin-core-dev
5872018-02-01T16:39:41 <provoostenator> Mmm, if it's DNS related bisect might end up finding the PR where my seed was merged. Anyway, we'll see.
5882018-02-01T16:41:05 *** Randolf has quit IRC
5892018-02-01T16:42:57 *** Giszmo has joined #bitcoin-core-dev
5902018-02-01T16:43:42 *** Giszmo has quit IRC
5912018-02-01T16:44:05 *** AaronvanW has joined #bitcoin-core-dev
5922018-02-01T16:44:37 *** Victorsueca has quit IRC
5932018-02-01T16:45:46 *** Victorsueca has joined #bitcoin-core-dev
5942018-02-01T16:46:56 *** lnostdal has joined #bitcoin-core-dev
5952018-02-01T16:48:05 *** AaronvanW has quit IRC
5962018-02-01T16:48:58 *** CubicEarths has quit IRC
5972018-02-01T16:50:04 *** PaulCapestany has joined #bitcoin-core-dev
5982018-02-01T16:51:21 *** dund has quit IRC
5992018-02-01T16:52:06 *** dund has joined #bitcoin-core-dev
6002018-02-01T16:52:35 *** LeMiner2 has joined #bitcoin-core-dev
6012018-02-01T16:53:12 *** SevenTimes_ has joined #bitcoin-core-dev
6022018-02-01T16:53:51 *** rfree_irc has quit IRC
6032018-02-01T16:54:44 *** SevenTimes_ has quit IRC
6042018-02-01T16:54:55 *** LeMiner has quit IRC
6052018-02-01T16:54:56 *** LeMiner2 is now known as LeMiner
6062018-02-01T16:55:46 *** SevenTimes has joined #bitcoin-core-dev
6072018-02-01T16:55:58 *** rfree_irc has joined #bitcoin-core-dev
6082018-02-01T16:57:02 *** shesek has joined #bitcoin-core-dev
6092018-02-01T16:57:30 *** SevenTimes__ has quit IRC
6102018-02-01T16:58:56 *** SevenTimes_ has joined #bitcoin-core-dev
6112018-02-01T17:00:21 <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
6122018-02-01T17:01:05 *** SevenTimes has quit IRC
6132018-02-01T17:01:48 *** checksau_ has joined #bitcoin-core-dev
6142018-02-01T17:02:55 *** CubicEarths has joined #bitcoin-core-dev
6152018-02-01T17:03:05 <instagibbs> promag, how come that error doesn't result in *all* qt coin control settings getting ignored?
6162018-02-01T17:03:44 *** checksauce has quit IRC
6172018-02-01T17:04:49 <promag> instagibbs: I think the only affected are `change_type = g_change_type;` and `signalRbf = fWalletRbf;`
6182018-02-01T17:05:17 <promag> because these are set with argument
6192018-02-01T17:07:24 * instagibbs looking at how feerates are set
6202018-02-01T17:07:43 <promag> and CoinControlDialog::coinControl->SetNull() is only when the "Enable coin control features" is unchecked
6212018-02-01T17:08:01 <promag> instagibbs: yeah didn't look at that
6222018-02-01T17:08:54 *** promag has quit IRC
6232018-02-01T17:09:38 *** CubicEarths has quit IRC
6242018-02-01T17:12:02 *** AaronvanW has joined #bitcoin-core-dev
6252018-02-01T17:12:05 *** aruns__ has joined #bitcoin-core-dev
6262018-02-01T17:12:30 <provoostenator> ^ created the above to track my bisect progress
6272018-02-01T17:12:53 <provoostenator> Well, below: #12328
6282018-02-01T17:12:54 <gribble> https://github.com/bitcoin/bitcoin/issues/12328 | Consistent crashes for v0.16.0rc1 · Issue #12328 · bitcoin/bitcoin · GitHub
6292018-02-01T17:14:03 *** Murch has quit IRC
6302018-02-01T17:14:07 *** lnostdal has quit IRC
6312018-02-01T17:14:42 *** lnostdal has joined #bitcoin-core-dev
6322018-02-01T17:15:00 <instagibbs> promag, your analysis looks correct, those two should be those effected
6332018-02-01T17:17:22 *** SevenTimes__ has joined #bitcoin-core-dev
6342018-02-01T17:17:58 *** RubenSomsen has joined #bitcoin-core-dev
6352018-02-01T17:18:57 *** SevenTimes_ has quit IRC
6362018-02-01T17:22:05 *** Murch has joined #bitcoin-core-dev
6372018-02-01T17:28:36 *** lnostdal has quit IRC
6382018-02-01T17:28:42 *** promag has joined #bitcoin-core-dev
6392018-02-01T17:29:09 *** lnostdal has joined #bitcoin-core-dev
6402018-02-01T17:31:39 *** Guest1780 has joined #bitcoin-core-dev
6412018-02-01T17:39:10 *** aruns__ has quit IRC
6422018-02-01T17:39:32 *** Emcy_ has joined #bitcoin-core-dev
6432018-02-01T17:40:18 *** Chris_Stewart_5 has quit IRC
6442018-02-01T17:41:09 *** meshcollider has joined #bitcoin-core-dev
6452018-02-01T17:41:51 *** Emcy has quit IRC
6462018-02-01T17:44:30 *** AaronvanW has quit IRC
6472018-02-01T17:45:45 *** AaronvanW has joined #bitcoin-core-dev
6482018-02-01T17:46:25 *** AaronvanW has quit IRC
6492018-02-01T17:52:08 *** owowo has quit IRC
6502018-02-01T17:53:04 <provoostenator> Produced a crash using an older version: https://github.com/bitcoin/bitcoin/commit/16bac24f60fa3ae27cb2d9d89dfdd245694445d4
6512018-02-01T17:53:10 <provoostenator> Four more bisect steps to go
6522018-02-01T17:53:33 <provoostenator> Well, that's just 7 days ago...
6532018-02-01T17:54:09 <provoostenator> I added the log to the above issue.
6542018-02-01T17:54:13 <ProfMac> "should" the DNS discover use IPv4 when onlynet=IPv6?
6552018-02-01T17:54:18 *** Chris_Stewart_5 has joined #bitcoin-core-dev
6562018-02-01T17:55:39 *** Randolf has joined #bitcoin-core-dev
6572018-02-01T17:56:00 <wumpus> AFAIK there's no way in the libc API to do DNS resolving only over either IPv4 or IPv6
6582018-02-01T17:56:49 *** shesek has quit IRC
6592018-02-01T17:57:05 *** AaronvanW has joined #bitcoin-core-dev
6602018-02-01T17:57:05 *** PaulCapestany has quit IRC
6612018-02-01T17:57:16 <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
6622018-02-01T17:58:19 *** PaulCape_ has joined #bitcoin-core-dev
6632018-02-01T17:59:50 *** Guest1780 has quit IRC
6642018-02-01T18:01:40 *** AaronvanW has quit IRC
6652018-02-01T18:04:11 <wumpus> (hm, how many ISPs give out IPv6 DNS servers in the first place?)
6662018-02-01T18:06:28 <wumpus> probably only those that only give clients a IPv6 address
6672018-02-01T18:07:05 <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
6682018-02-01T18:10:24 *** AaronvanW has joined #bitcoin-core-dev
6692018-02-01T18:18:37 *** mandric has joined #bitcoin-core-dev
6702018-02-01T18:20:26 *** promag has quit IRC
6712018-02-01T18:21:48 <cfields> wumpus: you can kinda fudge it with AI_ADDRCONFIG, as we do
6722018-02-01T18:22:16 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/895fbd768f0c...84291d18dd69
6732018-02-01T18:22:16 <bitcoin-git> bitcoin/master 96dbd38 Cory Fields: net: initialize socket to avoid closing random fd's
6742018-02-01T18:22:17 <bitcoin-git> bitcoin/master 84291d1 Wladimir J. van der Laan: Merge #12326: net: initialize socket to avoid closing random fd's...
6752018-02-01T18:22:29 <cfields> oh, you mean the resolver itself
6762018-02-01T18:22:51 <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.16: https://github.com/bitcoin/bitcoin/commit/e54c1ac110664efd58b7351139da55284f58f2ca
6772018-02-01T18:22:51 <bitcoin-git> bitcoin/0.16 e54c1ac Cory Fields: net: initialize socket to avoid closing random fd's...
6782018-02-01T18:23:11 <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
6792018-02-01T18:23:39 <cfields> wumpus: i think there's another issue there, introduced by (my suggestion in) 11512
6802018-02-01T18:24:02 <wumpus> cfields: yes, I was assuming he meant the network used by the resolver itself, selecting only one kind of results sounds feasible
6812018-02-01T18:24:03 <cfields> I believe that failed resolves will end up forever connecting as oneshots, since failed oneshots get re-added
6822018-02-01T18:24:31 *** aruns__ has joined #bitcoin-core-dev
6832018-02-01T18:24:59 <wumpus> whoops
6842018-02-01T18:25:13 <cfields> looking into it
6852018-02-01T18:31:30 *** Krellan has quit IRC
6862018-02-01T18:37:16 *** Krellan has joined #bitcoin-core-dev
6872018-02-01T18:42:35 *** Krellan has quit IRC
6882018-02-01T18:48:58 <cfields> actually, anyone know why oneshots are re-added in the first place? https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp#L1685
6892018-02-01T18:49:14 <cfields> sipa maybe ?
6902018-02-01T18:49:37 <wumpus> I don't know, I woudln't have expected that either
6912018-02-01T18:49:51 <wumpus> if it's one-shot - if it fails, that was the shot
6922018-02-01T18:50:04 <cfields> right
6932018-02-01T18:50:37 <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
6942018-02-01T18:51:46 <BlueMatt> cfields: if your network is done
6952018-02-01T18:51:51 <BlueMatt> or something like that
6962018-02-01T18:52:04 <BlueMatt> there was some pr that made things more robust if your net is down
6972018-02-01T18:52:08 <BlueMatt> maybe that is related?
6982018-02-01T18:52:18 <cfields> BlueMatt: wouldn't that same logic apply to everything, not just oneshots?
6992018-02-01T18:52:32 <BlueMatt> uhhhh, uhhhhh
7002018-02-01T18:52:36 <BlueMatt> ?
7012018-02-01T18:53:02 *** arbitrary_guy has joined #bitcoin-core-dev
7022018-02-01T18:53:15 <wumpus> for non-oneshot connections I could understand it better
7032018-02-01T18:53:23 <wumpus> maybe the logic is the wrong way around?
7042018-02-01T18:54:11 <cfields> looks like it's been this way since they were introduced: 478b01d9a797f3ea
7052018-02-01T18:54:59 *** jigawatt has joined #bitcoin-core-dev
7062018-02-01T18:56:01 <cfields> heh, when provoostenator gets his seed back up and running, he'll likely be DDoS'd like crazy
7072018-02-01T18:56:08 <wumpus> maybe it's been the wrong way around since the beginning, and no one ever reasoned this far
7082018-02-01T18:56:54 <wumpus> well at least there haven't been rc1 binaries, so the scale of DoS is likely limited :)
7092018-02-01T18:57:33 <cfields> heh
7102018-02-01T18:59:33 <cfields> i'll go ahead and PR the removal, maybe someone will chime in with a valid reason otherwise
7112018-02-01T18:59:44 <wumpus> agreed
7122018-02-01T19:00:10 <wumpus> #startmeeting
7132018-02-01T19:00:10 <lightningbot> Meeting started Thu Feb 1 19:00:10 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
7142018-02-01T19:00:10 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
7152018-02-01T19:00:25 <provoostenator> hi
7162018-02-01T19:00:32 <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
7172018-02-01T19:00:34 <achow101> hi
7182018-02-01T19:00:35 <jonasschnelli> hi
7192018-02-01T19:00:39 <cfields> hi
7202018-02-01T19:00:52 <sdaftuar> ack
7212018-02-01T19:00:58 <jcorgan> hey folks
7222018-02-01T19:01:04 <meshcollider> hi
7232018-02-01T19:01:08 <luke-jr> hi
7242018-02-01T19:01:14 <BlueMatt> 0.16!
7252018-02-01T19:01:19 <meshcollider> \o/
7262018-02-01T19:01:23 <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
7272018-02-01T19:01:30 <BlueMatt> ack
7282018-02-01T19:01:31 <achow101> what issues?
7292018-02-01T19:01:32 <cfields> agreed
7302018-02-01T19:01:48 <cfields> achow101: see backlog for the last ~3hrs
7312018-02-01T19:02:01 <wumpus> https://github.com/bitcoin/bitcoin/milestone/30
7322018-02-01T19:02:18 <wumpus> the serious issue is https://github.com/bitcoin/bitcoin/issues/12323
7332018-02-01T19:02:46 <achow101> ok
7342018-02-01T19:03:24 <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
7352018-02-01T19:03:34 <wumpus> cfields is working on a patch for that
7362018-02-01T19:03:42 <instagibbs> oh right, thursday
7372018-02-01T19:03:59 <wumpus> https://github.com/bitcoin/bitcoin/pull/12327 fixes a more minor issue with coin control and the change type setting
7382018-02-01T19:04:05 <wumpus> in the gui
7392018-02-01T19:04:20 <jonasschnelli> by the way, is it a policy that a DNS seed also runs a node (same ip) for the oneshot?
7402018-02-01T19:04:34 <wumpus> jonasschnelli: no, that's not necessary
7412018-02-01T19:04:48 <wumpus> jonasschnelli: it looks up the DNS seed which will return a (the first?) node
7422018-02-01T19:04:51 <jonasschnelli> wumpus: okay. My seeders will refuse connections to 8333
7432018-02-01T19:05:02 <jonasschnelli> wumpus: okay.
7442018-02-01T19:05:34 <wumpus> jonasschnelli: that is not the IP of the DNS server. I was confused about that too at some point in the past.
7452018-02-01T19:05:50 <jonasschnelli> I think also has something do to with tor mode
7462018-02-01T19:05:54 <provoostenator> Using A records is what makes it confusing
7472018-02-01T19:05:54 <cfields> yea, it's just some random peer
7482018-02-01T19:06:18 <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)
7492018-02-01T19:06:32 <jonasschnelli> BlueMatt: sure.
7502018-02-01T19:06:41 <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
7512018-02-01T19:06:53 <jonasschnelli> But in tor only mode, don't we do a oneshot to the seeds?
7522018-02-01T19:06:58 <wumpus> no
7532018-02-01T19:06:58 <provoostenator> BlueMatt: and an effective way to DDOS yourself
7542018-02-01T19:07:12 <jonasschnelli> wumpus: okay. Thanks... never looked that up properly
7552018-02-01T19:07:30 <wumpus> it never looks up the IP of the DNS server at all, that's all happening below the libc abstraction
7562018-02-01T19:07:49 <wumpus> any topics?
7572018-02-01T19:09:14 *** Chris_Stewart_5 has quit IRC
7582018-02-01T19:10:03 <jonasschnelli> Everyone already back at work it seems
7592018-02-01T19:10:04 <wumpus> ok.. seems not... well please review anything under the 0.16.0 milestone, and anything added in the next day too
7602018-02-01T19:10:09 <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
7612018-02-01T19:10:12 <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
7622018-02-01T19:10:14 <wumpus> then we'll tag rc2 after that
7632018-02-01T19:10:42 <wumpus> and try to find the next round of bugs :)
7642018-02-01T19:10:50 <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
7652018-02-01T19:10:51 <wumpus> sdaftuar: okay
7662018-02-01T19:11:03 <sdaftuar> mostly i want to know if there are any concept NACKs
7672018-02-01T19:11:14 <wumpus> #topic enforce SCRIPT_VERIFY_P2SH and SCRIPT_VERIFY_WITNESS from genesis (sdaftuar)
7682018-02-01T19:12:17 <sdaftuar> and i guess the other question is confirming whether/how such a change should be documented
7692018-02-01T19:12:19 <cfields> +0
7702018-02-01T19:12:40 <cfields> sdaftuar: going forward, you mean? or this one?
7712018-02-01T19:12:44 <sdaftuar> both?
7722018-02-01T19:12:48 <sdaftuar> i drafted a BIP for this one
7732018-02-01T19:13:05 <cfields> well going forward, i think we could specify this intention as part of a soft-fork bip?
7742018-02-01T19:13:06 <wumpus> no NACK from me, if the code can be simplified that way then it's great
7752018-02-01T19:13:29 <BlueMatt> +1
7762018-02-01T19:13:34 <wumpus> it doesn't change the rules enforced for current blocks, does it?
7772018-02-01T19:13:38 <wumpus> how is it a softfork?
7782018-02-01T19:13:42 <sdaftuar> no effect on current blocks
7792018-02-01T19:13:56 <wumpus> if it's a softfork I am misunderstanding
7802018-02-01T19:14:04 <BlueMatt> its a soft spoon - only prevents a 6-month reorg from removing segwit :p
7812018-02-01T19:14:06 <luke-jr> it restricts the rules on older blocks
7822018-02-01T19:14:07 <sdaftuar> it's a softfork under a technical definition
7832018-02-01T19:14:10 <BlueMatt> not a fork
7842018-02-01T19:14:18 <sdaftuar> of making valid things now invalid
7852018-02-01T19:14:21 <cfields> sorry, my fault.
7862018-02-01T19:14:29 <morcos> +1 as well.. but i do have concerns about how we could do this on a going forward basis
7872018-02-01T19:14:30 <wumpus> oh, right
7882018-02-01T19:14:38 <provoostenator> Or just Buried Deployment?
7892018-02-01T19:14:39 <wumpus> but it makes no difference bencause the old blocks all qualify
7902018-02-01T19:14:41 <luke-jr> the question comes down to, are we limiting soft/hardfork definitions to only ones that affect future blocks?
7912018-02-01T19:14:43 <morcos> it seems like if this is always our intention, then as soon as we announce a future soft fork
7922018-02-01T19:14:53 <morcos> some jack ass is going to mine violations just to make us annoyed
7932018-02-01T19:15:00 <BlueMatt> luke-jr: yes, we should start calling buried deployments spoons
7942018-02-01T19:15:02 <luke-jr> or do we consider this an implementation detail?
7952018-02-01T19:15:13 <cfields> morcos: true
7962018-02-01T19:15:17 <sdaftuar> morcos: i think it's not really worth worrying about that
7972018-02-01T19:15:21 <wumpus> I see this as an implementation detail to validation
7982018-02-01T19:15:32 <wumpus> there's no need to cause a lot of rufus about it
7992018-02-01T19:15:42 <wumpus> if you call it softfork you'll have the miners in arms, and whatnot
8002018-02-01T19:15:43 <cfields> luke-jr: well if there's an absolutely massive reorg, it's not just an implementation detail, no?
8012018-02-01T19:15:48 <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
8022018-02-01T19:16:03 <sdaftuar> morcos: oh i see your point
8032018-02-01T19:16:07 <wumpus> because then it also needs to be signaled some way, I guess
8042018-02-01T19:16:10 <luke-jr> cfields: if there's an absolutely massive reorg, it's unclear what the outcome will be period
8052018-02-01T19:16:24 <luke-jr> cfields: for example, Knots has a checkpoint on a Segwit block
8062018-02-01T19:16:30 <cfields> well isn't the intention here to clarify that outcome?
8072018-02-01T19:16:32 <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
8082018-02-01T19:16:35 <wumpus> if there's a reorg that big that all segwit blocks are reorged out, well...
8092018-02-01T19:16:53 <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
8102018-02-01T19:17:00 <wumpus> yes, I'm sure there will be discussion enough in that case
8112018-02-01T19:17:14 <sdaftuar> so backdating the segwit rules matches consensus, in that sense
8122018-02-01T19:17:15 <BlueMatt> so, definitely not a fork
8132018-02-01T19:17:22 <wumpus> right
8142018-02-01T19:18:10 <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.
8152018-02-01T19:18:26 <cfields> morcos: i half agree about after-the-fact. Not mentioning backdating with the intention of doing so anyway is a bit... iffy
8162018-02-01T19:18:31 <luke-jr> BIPs are for cross-software standards, which doesn't really include implementation details
8172018-02-01T19:18:34 <BlueMatt> seems fine to me, I also appreciate gmaxwell's partially-joking suggestion of calling it a spoon
8182018-02-01T19:18:48 <wumpus> hehe
8192018-02-01T19:18:51 <luke-jr> (actually, we have a repo for gitian docs already, right?)
8202018-02-01T19:18:51 <sdaftuar> i personally think that it's helpful to put it in a BIP, because it affects the implementation of existing BIPs
8212018-02-01T19:18:52 <BlueMatt> and then doing a bip and just saying "Soft Spoon"
8222018-02-01T19:19:05 <sdaftuar> but i don't feel strongly
8232018-02-01T19:19:19 <BlueMatt> i mean we use BIPs for things that are core-specific anyway, like getblocktemplate
8242018-02-01T19:19:23 <wumpus> but in the end it doesn't matter whether people implement this BIP
8252018-02-01T19:19:27 <wumpus> because it's an implementation detail
8262018-02-01T19:19:27 <luke-jr> BlueMatt: GBT isn't Core-specific
8272018-02-01T19:19:29 <sdaftuar> wumpus: agreed
8282018-02-01T19:19:32 <sdaftuar> it's an informational BIP
8292018-02-01T19:19:37 <cfields> luke-jr: there are several post-mortem BIPs
8302018-02-01T19:19:38 <wumpus> BlueMatt: well that's an interface! interfaces need documentation
8312018-02-01T19:19:42 <kanzure> hi.
8322018-02-01T19:20:29 <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
8332018-02-01T19:20:37 <wumpus> if a softspoon drops at 300000 blocks deep and no one hears it, did it happen at all?
8342018-02-01T19:20:44 <luke-jr> one for the deployment and implementation, and another for the reinterpretation of the deployment
8352018-02-01T19:20:54 <sdaftuar> luke-jr: that seems reasonable to me as well, if the BIP authors agree?
8362018-02-01T19:22:08 <wumpus> luke-jr: agree
8372018-02-01T19:22:25 <luke-jr> none of the authors appear to be here now, but I doubt they'd object
8382018-02-01T19:22:34 <luke-jr> at least for Segwit
8392018-02-01T19:23:32 <provoostenator> And the winner of the git bisect game is....
8402018-02-01T19:23:37 <provoostenator> bluematt! https://github.com/bitcoin/bitcoin/commit/62e764219b25f5d5a4de855e53f62c43130ec918
8412018-02-01T19:23:53 *** Chris_Stewart_5 has joined #bitcoin-core-dev
8422018-02-01T19:23:57 <BlueMatt> we already decided it was cfields' fault
8432018-02-01T19:24:07 <sdaftuar> i knew it was both of you
8442018-02-01T19:24:08 * BlueMatt is gonna keep repeating that until someone buys it
8452018-02-01T19:24:10 <sdaftuar> :)
8462018-02-01T19:24:21 * BlueMatt *definitely* didnt also review and ack the bug-introducing pr......
8472018-02-01T19:24:23 <cfields> heh it was me for sure
8482018-02-01T19:24:41 <cfields> the busted part of 62e7642 was even my suggestion!
8492018-02-01T19:25:10 <wumpus> it's everyone's fault for not finding the fault in review! :)
8502018-02-01T19:25:17 <sdaftuar> +1
8512018-02-01T19:25:32 <cfields> well, sorry everyone. I'm glad it didn't make it into a release.
8522018-02-01T19:25:52 <luke-jr> I'm glad someone noticed it before a release XD
8532018-02-01T19:25:54 <wumpus> the rc process, it works
8542018-02-01T19:26:15 <cfields> yea, the surge of reports in the last ~day is actually really nice to see
8552018-02-01T19:26:19 <provoostenator> Bad linux skills on my part (causing the seed not to restart): it works
8562018-02-01T19:26:38 <sdaftuar> good thing it was down or we never would have found this before release!
8572018-02-01T19:26:44 <sdaftuar> (which is very disturbing)
8582018-02-01T19:26:54 <wumpus> we do need tests for the DNS seed code
8592018-02-01T19:27:02 <meshcollider> clearly
8602018-02-01T19:27:04 <provoostenator> +1 for tests there
8612018-02-01T19:27:15 <cfields> agreed. I'll add some.
8622018-02-01T19:27:20 <BlueMatt> lol, maybe keep your dnsseed down until after rc cycle? :P
8632018-02-01T19:27:57 <wumpus> any other topics?
8642018-02-01T19:28:07 <cfields> or we could just add a dummy seednode to test.com or something :p
8652018-02-01T19:30:03 <wumpus> testing that code is not entirely trivial as-is as you somehow need to redirect DNS resolving
8662018-02-01T19:30:22 <wumpus> if no other topics, I'm closing the meeting early
8672018-02-01T19:30:43 <wumpus> #endmeeting
8682018-02-01T19:30:43 <lightningbot> Meeting ended Thu Feb 1 19:30:43 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
8692018-02-01T19:30:43 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-02-01-19.00.html
8702018-02-01T19:30:43 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-02-01-19.00.txt
8712018-02-01T19:30:43 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-02-01-19.00.log.html
8722018-02-01T19:30:44 <cfields> sgtm
8732018-02-01T19:30:48 <luke-jr> noooooooooooooooooo
8742018-02-01T19:30:50 <sdaftuar> ack
8752018-02-01T19:30:53 <gmaxwell> damnit
8762018-02-01T19:31:06 <gmaxwell> missed the meeting by 30 seconds.
8772018-02-01T19:31:09 <luke-jr> lol
8782018-02-01T19:31:27 <gmaxwell> Without reading the logs, can we apply the fixes for that fd issue and RC2 like lightning?
8792018-02-01T19:31:38 <sdaftuar> i believe that is the plan
8802018-02-01T19:31:47 <wumpus> yes, that is the plan
8812018-02-01T19:32:03 <gmaxwell> Good.
8822018-02-01T19:32:48 <wumpus> merge+backport #12323 and #12312 and tag rc2, and just skip executables for rc1
8832018-02-01T19:32:49 <gribble> https://github.com/bitcoin/bitcoin/issues/12323 | File descriptor problem, causing leveldb crash · Issue #12323 · bitcoin/bitcoin · GitHub
8842018-02-01T19:32:50 <gribble> https://github.com/bitcoin/bitcoin/issues/12312 | QT ignores -changetype=bech32 when coin control features are enabled · Issue #12312 · bitcoin/bitcoin · GitHub
8852018-02-01T19:33:55 *** SopaXorzTaker has quit IRC
8862018-02-01T19:34:16 *** Murch has quit IRC
8872018-02-01T19:34:21 <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).
8882018-02-01T19:34:23 <gribble> https://github.com/bitcoin/bitcoin/issues/12326 | net: initialize socket to avoid closing random fds by theuni · Pull Request #12326 · bitcoin/bitcoin · GitHub
8892018-02-01T19:34:43 *** Murch has joined #bitcoin-core-dev
8902018-02-01T19:35:27 <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.
8912018-02-01T19:35:42 <gmaxwell> jcorgan: awesome!
8922018-02-01T19:35:56 <cfields> wumpus: and 12329 ?
8932018-02-01T19:36:08 <wumpus> jcorgan: congratulations!
8942018-02-01T19:36:10 <gmaxwell> (I mean, nooo sucks for gnuradio; and all my SDR projects)
8952018-02-01T19:36:42 <cfields> jcorgan: very cool. 12 years is a long time
8962018-02-01T19:37:03 <wumpus> cfields: huh I meant that one
8972018-02-01T19:37:15 <jcorgan> i think that's half over some people here's lifetime
8982018-02-01T19:37:18 <jcorgan> *of
8992018-02-01T19:37:22 <wumpus> oh cool maybe I can go to gnu radio now
9002018-02-01T19:37:41 <sdaftuar> wait what
9012018-02-01T19:37:42 <cfields> jcorgan: you're Bitcoin Core maintainer now! congrats.
9022018-02-01T19:37:45 <achow101> jcorgan: more than half
9032018-02-01T19:38:46 <instagibbs> \o/
9042018-02-01T19:39:07 <instagibbs> who here is best to bug about gitian? I'd hate to blow away my gitian directory yet again...
9052018-02-01T19:39:28 <sdaftuar> who is going to answer yes to that question
9062018-02-01T19:39:35 <instagibbs> someone who loves... pain
9072018-02-01T19:39:37 <achow101> instagibbs: probably cfields
9082018-02-01T19:39:50 * cfields points at achow101
9092018-02-01T19:39:53 <sdaftuar> lol
9102018-02-01T19:39:54 <cfields> instagibbs: what's the issue?
9112018-02-01T19:39:56 * instagibbs throws VM out the window
9122018-02-01T19:40:00 *** promag has joined #bitcoin-core-dev
9132018-02-01T19:40:13 <instagibbs> ill DM, it's likely intractible
9142018-02-01T19:40:23 <wumpus> it's surprising in how many different ways gitian can fail
9152018-02-01T19:40:41 <cfields> this is going to be the least sexy slide into a DM ever...
9162018-02-01T19:40:58 <promag> o/ late..
9172018-02-01T19:41:03 <achow101> gitian is kinda outdated. it looks like its doing things that aren't really supported anymore
9182018-02-01T19:41:09 <jcorgan> anyway, carry on, i have to go fly a plane in the sky
9192018-02-01T19:41:48 *** shesek has joined #bitcoin-core-dev
9202018-02-01T19:42:18 <instagibbs> cfields, lol
9212018-02-01T19:42:27 <wumpus> lol indeed
9222018-02-01T19:43:19 *** zautomata1 has quit IRC
9232018-02-01T19:43:27 <meshcollider> 0.16 crashes my gitian build too grr 0.15.1 was ok
9242018-02-01T19:43:37 <meshcollider> I probably need to upgrade something
9252018-02-01T19:43:41 <instagibbs> trying as far back as 0.14.1, not working
9262018-02-01T19:43:45 <wumpus> strange, nothing should have changed in that regard
9272018-02-01T19:43:52 <instagibbs> (something I know this VM did correctly once)
9282018-02-01T19:43:55 *** zautomata has joined #bitcoin-core-dev
9292018-02-01T19:43:59 <wumpus> still uses the same version of ubuntu for buildling, still uses the same packages, etc
9302018-02-01T19:44:09 *** Krellan has joined #bitcoin-core-dev
9312018-02-01T19:44:12 <achow101> I bet some package updated and that just broke everything
9322018-02-01T19:48:47 *** Krellan has quit IRC
9332018-02-01T19:50:12 *** checksau_ has quit IRC
9342018-02-01T19:51:42 <instagibbs> cfields fixed my issue... was looking at my even older version of gitian that I had failed to rename to something sensible
9352018-02-01T19:53:58 <bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/84291d18dd69...41363fe11df5
9362018-02-01T19:53:58 <bitcoin-git> bitcoin/master 6558f8a João Barbosa: [gui] Defer coin control instancing...
9372018-02-01T19:53:59 <bitcoin-git> bitcoin/master 41363fe Jonas Schnelli: Merge #12327: [gui] Defer coin control instancing...
9382018-02-01T19:54:44 *** Murch has quit IRC
9392018-02-01T19:54: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
9402018-02-01T19:55:27 *** Randolf has quit IRC
9412018-02-01T19:55:52 *** Murch has joined #bitcoin-core-dev
9422018-02-01T19:56:27 <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).
9432018-02-01T19:56:31 <gmaxwell> ?
9442018-02-01T19:56:47 <provoostenator> +1
9452018-02-01T19:57:11 <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.
9462018-02-01T19:57:25 <sdaftuar> that seems to be everyone's experience afaik
9472018-02-01T19:57:47 <gmaxwell> er leave it on.
9482018-02-01T19:58:08 <gmaxwell> I suppose I've learned a bit about how much background stuff leveldb does due to it. :)
9492018-02-01T19:58:10 *** jamesob has quit IRC
9502018-02-01T19:58:21 <wumpus> I don't like the chatty net logging either
9512018-02-01T19:58:48 <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.
9522018-02-01T19:58:58 <wumpus> which is why I opened #12219, I think we need a DEBUG..ERROR axis as well
9532018-02-01T19:59:00 <gribble> https://github.com/bitcoin/bitcoin/issues/12219 | More granular net logging · Issue #12219 · bitcoin/bitcoin · GitHub
9542018-02-01T19:59:08 <sdaftuar> yeah we should tackle that
9552018-02-01T19:59:22 <provoostenator> The flickering makes it hard to watch an IBD in real time.
9562018-02-01T19:59:44 <gmaxwell> or at least chatty net doesn't bother me so much since upgrading nodes to 1TB ssds...
9572018-02-01T19:59:47 <wumpus> apart from the category we also need a log level, that'd make logging things more sane without singling out specific categories
9582018-02-01T19:59:50 <wumpus> or splitting up categories
9592018-02-01T20:00:50 <wumpus> I think debug=1 should remain 'log everything possible', which doesn't rule out more selective logging options
9602018-02-01T20:00:56 <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.
9612018-02-01T20:01:04 *** jamesob has joined #bitcoin-core-dev
9622018-02-01T20:01:39 <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.
9632018-02-01T20:01:59 <wumpus> or something like debug=1 debug=-leveldb
9642018-02-01T20:02:03 <gmaxwell> also having a single setting is more useful when I'm asking users to set things.
9652018-02-01T20:02:05 <wumpus> allowing categories to be disabled
9662018-02-01T20:02:22 <cfields> gmaxwell: agreed. -debug and -debug=all don't have to be the same thing
9672018-02-01T20:02:34 <gmaxwell> we have -debugexclude
9682018-02-01T20:02:41 <wumpus> but yes it is subjective and dpeends on what you want to debug
9692018-02-01T20:02:54 <wumpus> which is why making a single selection for -debug=1 seems weird to me
9702018-02-01T20:03:20 <wumpus> some messages might be less interesting for what you're debugging, but that's why we have categories in the first place
9712018-02-01T20:03:25 <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)
9722018-02-01T20:03:48 <gmaxwell> and on crashes we could make a best effort attempt to dump the circular buffer to a file in a crash handler.
9732018-02-01T20:04:06 <wumpus> debug=1 is super-overkill last resort for when you really don't know where to look
9742018-02-01T20:04:26 <wumpus> gmaxwell: yes, we need that too
9752018-02-01T20:04:57 <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.
9762018-02-01T20:04:58 <promag> -debug-net -debug-foo (-debug enables all)?
9772018-02-01T20:05:20 <wumpus> we already have -debug=net -debug=foo
9782018-02-01T20:05:23 <gmaxwell> promag: you can already -debug=category to add categories and -debugexclude to remove them.
9792018-02-01T20:05:44 <wumpus> gmaxwell: still you need a selection of categories then
9802018-02-01T20:05:48 <promag> but you can't have levels right?
9812018-02-01T20:05:50 <gmaxwell> right now I tell users to debug=1 and debugexclude leveldb.
9822018-02-01T20:06:02 <wumpus> gmaxwell: it's unlikely that you want debugging for ,say, torcontrol, even though that logging is extremely useful if you're debugging that
9832018-02-01T20:06:13 <gmaxwell> wumpus: tor control isn't that chatty however.
9842018-02-01T20:06:24 <gmaxwell> net is chatty but one of the most useful thing to log.
9852018-02-01T20:06:31 <wumpus> but it might become so, or another chatty category could be added
9862018-02-01T20:06:51 <wumpus> that's pretty subjective though
9872018-02-01T20:06:54 <wumpus> because you're interested in net
9882018-02-01T20:07:13 <gmaxwell> probably if I could grab a circular buffer with everything the question wrt support would go away.
9892018-02-01T20:07:58 <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.
9902018-02-01T20:08:11 <wumpus> but debug=net is way too chatty
9912018-02-01T20:08:14 <gmaxwell> I agree that net messages and net-activity should be split.
9922018-02-01T20:08:21 *** Derrekito has quit IRC
9932018-02-01T20:08:41 <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.
9942018-02-01T20:08:43 *** mandric has quit IRC
9952018-02-01T20:09:04 <wumpus> sure, I don't mwan that detailed net logging should go away or such
9962018-02-01T20:09:18 <wumpus> it certainly has good uses when you're debugging network things
9972018-02-01T20:09:45 <wumpus> in any case I think a log level would resolve some of these problems
9982018-02-01T20:09:59 <wumpus> 'I want to see all categories, but only at INFO levell, not DEBUG and below'
9992018-02-01T20:10:08 <wumpus> where DEBUG would be the chatty stuff
10002018-02-01T20:10:12 <promag> hence -debug-net=X
10012018-02-01T20:10:13 <gmaxwell> Please lets not make more than three levels though.
10022018-02-01T20:10:15 <wumpus> then if you want net DEBUG, you enable net debug
10032018-02-01T20:10:36 <wumpus> I agre,but let's not get into bikeshedding about the number of levels
10042018-02-01T20:10:39 *** aruns__ has quit IRC
10052018-02-01T20:10:48 *** CubicEarths has joined #bitcoin-core-dev
10062018-02-01T20:10:57 *** RubenSomsen has quit IRC
10072018-02-01T20:11:03 *** intcat has quit IRC
10082018-02-01T20:11:21 <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.
10092018-02-01T20:11:52 <wumpus> ERROR is clear, INFO/DEBUG can be set depend on chattiness
10102018-02-01T20:11:59 <wumpus> I don't think we need more
10112018-02-01T20:12:02 <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)
10122018-02-01T20:12:15 <gmaxwell> Yes, thats why I said three. I think three we can handle easily.
10132018-02-01T20:12:45 <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.
10142018-02-01T20:13:03 <wumpus> ERROR would be potentially dangerous but not fatal errors, maybe WARNING is a better name
10152018-02-01T20:13:19 <wumpus> peer violated the protocol is INFO imo
10162018-02-01T20:13:26 <wumpus> it's not dangerous to us
10172018-02-01T20:13:42 <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).
10182018-02-01T20:14:05 *** intcat has joined #bitcoin-core-dev
10192018-02-01T20:14:46 <wumpus> right
10202018-02-01T20:15:23 <provoostenator> I'm switching my testnet seed back on tomorrow unless something really surprising happens.
10212018-02-01T20:15:27 *** checksauce has joined #bitcoin-core-dev
10222018-02-01T20:16:20 <provoostenator> Or I can do it in 20 minutes if we want rc1 complaints to stop coming in.
10232018-02-01T20:16:21 <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
10242018-02-01T20:17:33 <wumpus> provoostenator: we should just tag r2
10252018-02-01T20:18:33 <provoostenator> I'll know in ~10 minutes whether todays fixex made my crash go away (fairly certain it did).
10262018-02-01T20:19:27 *** CubicEarths has quit IRC
10272018-02-01T20:20:25 <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.
10282018-02-01T20:20:57 <wumpus> gmaxwell: I think it needs a better definition though, something like debug=lowtraffic
10292018-02-01T20:21:16 *** CubicEarths has joined #bitcoin-core-dev
10302018-02-01T20:21:19 <wumpus> not everythingbutleveldb lol
10312018-02-01T20:21:30 *** promag has quit IRC
10322018-02-01T20:21:41 <wumpus> it also gives guidance for people to add or not categories to that in the future
10332018-02-01T20:22:00 <wumpus> or to remove categories once they become noisy
10342018-02-01T20:22:09 <gmaxwell> well net is high traffic but useful, leveldb is high traffic but so far I've not found it useful.
10352018-02-01T20:22:32 <wumpus> but what is the rationale of the combination then?
10362018-02-01T20:22:54 <gmaxwell> omit useless chatty things.
10372018-02-01T20:23:32 *** CubicEarths has quit IRC
10382018-02-01T20:23:32 <wumpus> let's kill leveldb logging completely if it's so useless
10392018-02-01T20:23:47 *** CubicEarths has joined #bitcoin-core-dev
10402018-02-01T20:24:15 *** checksauce has quit IRC
10412018-02-01T20:24:20 <wumpus> libevent too, probably
10422018-02-01T20:24:27 <meshcollider> it seems my gitian issue lies when it is trying to download zeromq-4.2.2.tar.gz for bitcoincore.org/depends-sources
10432018-02-01T20:24:28 <wumpus> it can be even more hilariously useless
10442018-02-01T20:24:37 <gmaxwell> It's at least of conjectural use e.g. if we were chasing some leveldb internal bug.
10452018-02-01T20:25:08 <wumpus> oh sure it can be useful, esp when adding custom debugging to leveldb to troubleshoot some issue
10462018-02-01T20:25:16 <wumpus> that's why a bridge exists
10472018-02-01T20:25:21 <cfields> meshcollider: you probably had all other sources already and your lxc is failing to make any net connections
10482018-02-01T20:25:31 <gmaxwell> I mean we could also leave the code for the bridge there but remove the logging level.
10492018-02-01T20:25:49 <meshcollider> cfields: that's true, was the version of zeromq bumped for 0.16
10502018-02-01T20:26:01 <cfields> believe so
10512018-02-01T20:26:09 <cfields> yes, it was
10522018-02-01T20:26:35 <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.
10532018-02-01T20:26:48 <gmaxwell> maybe libevent would fall into that too.
10542018-02-01T20:27:14 <gmaxwell> I've noticed it being useless too but just never had it be chatty enough to bother me.
10552018-02-01T20:27:17 <wumpus> so I still think =lowtraffic makes sense
10562018-02-01T20:27:36 <gmaxwell> I suppose we could lowtraffic then turn back on net-messages.
10572018-02-01T20:28:11 <gmaxwell> (I mean to achieve my normal desired logging config which is basically low traffic things plus net messages)
10582018-02-01T20:28:12 <wumpus> we should just include net int hat
10592018-02-01T20:28:37 <gmaxwell> I'm imagining net divided into per-message logging and the rest (e.g. connections)
10602018-02-01T20:28:40 <wumpus> with the future remark that if there is a low-traffic net category, that should be in instead
10612018-02-01T20:28:46 <gmaxwell> right
10622018-02-01T20:28:56 *** CubicEar_ has joined #bitcoin-core-dev
10632018-02-01T20:29:08 <meshcollider> cfields: yep you're right, it works fine if I make the depends directory beforehand, the new zeromq downloaded successfully
10642018-02-01T20:29:32 <cfields> great
10652018-02-01T20:29:49 <meshcollider> cfields: thanks :)
10662018-02-01T20:29:55 <cfields> np
10672018-02-01T20:30:19 <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.
10682018-02-01T20:32:26 *** CubicEarths has quit IRC
10692018-02-01T20:32: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
10702018-02-01T20:33:36 <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
10712018-02-01T20:34:03 <wumpus> and in the total validation tme that's probably neglible
10722018-02-01T20:34:46 <gmaxwell> The leveldb stuff looks kind of expensive.
10732018-02-01T20:34:49 <wumpus> I don't think we have low-traffic messages that take significant computation
10742018-02-01T20:35:17 <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.
10752018-02-01T20:35:17 <wumpus> for high traffic, yes, I woudln't be surprised if the net logging slowed some things down
10762018-02-01T20:35:52 <wumpus> if you have to write a message for every incoming packet to a file, it becomes disk bound
10772018-02-01T20:35:52 *** CubicEarths has joined #bitcoin-core-dev
10782018-02-01T20:36:35 <wumpus> oh I didn't know that
10792018-02-01T20:38:13 *** mandric has joined #bitcoin-core-dev
10802018-02-01T20:39:22 <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
10812018-02-01T20:39:51 *** CubicEar_ has quit IRC
10822018-02-01T20:40:24 <wumpus> can we have some review on #12329 please, I'd like to tag rc2 before I go to bed
10832018-02-01T20:40:25 <gribble> https://github.com/bitcoin/bitcoin/issues/12329 | net: dont retry failed oneshot connections forever by theuni · Pull Request #12329 · bitcoin/bitcoin · GitHub
10842018-02-01T20:41:10 *** CubicEarths has quit IRC
10852018-02-01T20:46:12 *** mmgen has quit IRC
10862018-02-01T20:47:55 *** propumpkin has joined #bitcoin-core-dev
10872018-02-01T20:48:04 *** contrapumpkin has quit IRC
10882018-02-01T20:49:23 *** Krellan has joined #bitcoin-core-dev
10892018-02-01T20:50:16 *** propumpkin is now known as contrapumpkin
10902018-02-01T20:50:42 <wumpus> and that's the last one
10912018-02-01T20:52:37 *** PaulCape_ has quit IRC
10922018-02-01T20:53:09 *** Krellan has quit IRC
10932018-02-01T20:53:40 *** Krellan has joined #bitcoin-core-dev
10942018-02-01T20:55:19 *** PaulCapestany has joined #bitcoin-core-dev
10952018-02-01T21:01:00 *** PaulCapestany has quit IRC
10962018-02-01T21:03:04 *** PaulCape_ has joined #bitcoin-core-dev
10972018-02-01T21:07:48 *** ProfMac has quit IRC
10982018-02-01T21:09:06 *** ProfMac has joined #bitcoin-core-dev
10992018-02-01T21:09:17 *** PaulCape_ has quit IRC
11002018-02-01T21:11:33 *** Aaronvan_ has joined #bitcoin-core-dev
11012018-02-01T21:14:22 *** ProfMac has quit IRC
11022018-02-01T21:14:41 *** AaronvanW has quit IRC
11032018-02-01T21:17:19 *** PaulCapestany has joined #bitcoin-core-dev
11042018-02-01T21:29:14 *** deeDd has joined #bitcoin-core-dev
11052018-02-01T21:33:26 *** ProfMac has joined #bitcoin-core-dev
11062018-02-01T21:35:39 *** AaronvanW has joined #bitcoin-core-dev
11072018-02-01T21:36:42 *** Aaronva__ has joined #bitcoin-core-dev
11082018-02-01T21:39:01 *** Aaronvan_ has quit IRC
11092018-02-01T21:40:33 *** AaronvanW has quit IRC
11102018-02-01T21:43:04 *** pgupta has joined #bitcoin-core-dev
11112018-02-01T21:51:00 *** sipa has joined #bitcoin-core-dev
11122018-02-01T21:51:13 <sipa> oops, seems i accidentally left this channel and forgot about the meeting as well
11132018-02-01T21:53:27 *** mandric has quit IRC
11142018-02-01T21:58:53 *** Chris_Stewart_5 has quit IRC
11152018-02-01T22:00:57 *** jamesob has quit IRC
11162018-02-01T22:03:10 *** esotericnonsense has quit IRC
11172018-02-01T22:13:57 <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?
11182018-02-01T22:16:08 <gmaxwell> and then you're gonna add (hardfork) to the segwit bips and collect your cheque from Ver? :P
11192018-02-01T22:17:21 <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)
11202018-02-01T22:17:34 *** keks_ has quit IRC
11212018-02-01T22:18:01 <jnewbery> perhaps -debug=standard , -debug=default, -debug=...
11222018-02-01T22:18:55 <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
11232018-02-01T22:21:10 <jnewbery> (in fact I started implementing that a few months ago, but never finished)
11242018-02-01T22:22:34 <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.
11252018-02-01T22:24:00 <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.
11262018-02-01T22:24:11 <luke-jr> gmaxwell: as an annex, it's clearer to consider it an implementation detail ;)
11272018-02-01T22:24:49 <luke-jr> ie, "you can tighten the rules using method A or method B, and the outcome is the same"
11282018-02-01T22:42:17 *** fanquake has joined #bitcoin-core-dev
11292018-02-01T22:51:24 *** pgupta has quit IRC
11302018-02-01T22:57:13 *** Guyver2 has quit IRC
11312018-02-01T23:01:07 *** bule has joined #bitcoin-core-dev
11322018-02-01T23:02:55 *** Murch has quit IRC
11332018-02-01T23:04:01 *** intcat has quit IRC
11342018-02-01T23:05:25 *** intcat has joined #bitcoin-core-dev
11352018-02-01T23:10:50 *** larafale has quit IRC
11362018-02-01T23:11:23 *** Murch has joined #bitcoin-core-dev
11372018-02-01T23:11:24 *** larafale has joined #bitcoin-core-dev
11382018-02-01T23:13:52 *** esotericnonsense has joined #bitcoin-core-dev
11392018-02-01T23:14:26 *** Giszmo has joined #bitcoin-core-dev
11402018-02-01T23:14:37 *** fanquake has quit IRC
11412018-02-01T23:15:27 *** larafale has quit IRC
11422018-02-01T23:20:30 *** ProfMac has quit IRC
11432018-02-01T23:26:38 *** Aaronva__ has quit IRC
11442018-02-01T23:26:44 *** MTennis has joined #bitcoin-core-dev
11452018-02-01T23:29:08 *** MTennis has quit IRC
11462018-02-01T23:35:29 *** Dizzle has quit IRC
11472018-02-01T23:40:52 *** deeDd has quit IRC
11482018-02-01T23:52:15 *** Dizzle has joined #bitcoin-core-dev
11492018-02-01T23:59:40 *** vicenteH has quit IRC